-
Hi!
In Home Assistant I sometimes uses the TTS, either to my Sonos or Google speakers. With reactor in Vera I also use TTS.
But in MSR I can't select the TTS-service. It's simply not there. Am I missing something, or is this the case, so far?
Thanks!
/Fanan -
Hi
I just enabled the Telegram profile in my notification.yaml file. I added my bot ID and Chat ID.
I then added a notify action in a rules Reaction, but no notification is received to my phone.
I can run the raw HTTPS request URL in a browser and that works OK and my notification is received OK.
Also I wasn't sure what this means and I tried it commented out and not.
default_disable_notification: "false"
Likewise with this one:
default_parse_mode: ""
Also I see there is a bug listed here already, maybe related?
Thanks
-
I'm on vacation and finally moving a couple of scenes from Vera luup to MSR. So far, so good, even if I'll need more time to practice.
One thing that I'm actually doing is to run a dehumidifier with this logic:
run between 7 and 23 only and if the temperature is below 10 C and humidity is >= 70This is the easy part. The other thing I do is to run the dehum for 2 hours and then wait 4 hours before running it again. I'm too newbie to this and can't figure it out how to properly build this condition, without messing or overcomplicating things.
Any hint is appreciated 🙂 Thanks.
-
In version 21336 the HubitatController: can't assign x_hubitat_extra_attributes value as primary attribute issue that was previously fixed (Mantis 261) has returned. If I remove the local_hubitat_devices.yaml and restart, the experimental "type guessing" feature does a pretty good job of assigning the primary attributes on most devices. I wouldn't expect MSR to guess an extra attribute but setting it manually causes the error again.
[latest-21336]2021-12-03T17:29:05.399Z <Structure:INFO> Starting controller HubitatController#hubitat [latest-21336]2021-12-03T17:29:05.430Z <Structure:INFO> Starting controller OWMWeatherController#weather [latest-21336]2021-12-03T17:29:05.461Z <Structure:INFO> Starting controller SystemController#reactor_system [latest-21336]2021-12-03T17:29:05.462Z <SystemController:NOTICE> Controller SystemController#reactor_system is now online. [latest-21336]2021-12-03T17:29:05.487Z <app:INFO> Structure running; pausing for controllers' initial ready [latest-21336]2021-12-03T17:29:05.517Z <HubitatController:NOTICE> HubitatController#hubitat not ready; performing initial connect/query [latest-21336]2021-12-03T17:29:05.534Z <HassController:NOTICE> HassController#hass connected, starting protocol [latest-21336]2021-12-03T17:29:05.540Z <HassController:INFO> HassController#hass successful authentication with ws://192.168.1.21:8123; fetching initial data... [latest-21336]2021-12-03T17:29:05.544Z <HassController:INFO> HassController#hass Hass reports version "2021.11.5" location Home timezone America/Chicago state RUNNING safe_mode false [latest-21336]2021-12-03T17:29:05.632Z <HassController:NOTICE> Controller HassController#hass is now online. [latest-21336]2021-12-03T17:29:05.799Z <Entity:ERR> Entity#hubitat>568 attempt to set primary to x_hubitat_extra_attributes.Status invalid: capability not extended [latest-21336]2021-12-03T17:29:05.800Z <HubitatController:WARN> HubitatController#hubitat can't set local primary attribute x_hubitat_extra_attributes.Status on Entity#hubitat>568: Error: Invalid primary attribute assignment; capability not assigned (x_hubitat_extra_attributes.Status) [latest-21336]2021-12-03T17:29:05.817Z <Entity:ERR> Entity#hubitat>481 attempt to set primary to x_hubitat_extra_attributes.dbSize invalid: capability not extended [latest-21336]2021-12-03T17:29:05.818Z <HubitatController:WARN> HubitatController#hubitat can't set local primary attribute x_hubitat_extra_attributes.dbSize on Entity#hubitat>481: Error: Invalid primary attribute assignment; capability not assigned (x_hubitat_extra_attributes.dbSize) [latest-21336]2021-12-03T17:29:05.825Z <HubitatController:INFO> HubitatController#hubitat connecting to hub's eventsocket WebSocket API at ws://192.168.1.70/eventsocket [latest-21336]2021-12-03T17:29:05.842Z <HubitatController:INFO> HubitatController#hubitat successful connection to ws://192.168.1.70/eventsocket [latest-21336]2021-12-03T17:29:05.856Z <HubitatController:NOTICE> HubitatController#hubitat current mode is Day (1) [latest-21336]2021-12-03T17:29:05.859Z <HubitatController:NOTICE> Controller HubitatController#hubitat is now online. [latest-21336]2021-12-03T17:29:06.088Z <OWMWeatherController:INFO> OWMWeatherController#weather done; 1 locations, 0 failed [latest-21336]2021-12-03T17:29:06.089Z <OWMWeatherController:NOTICE> Controller OWMWeatherController#weather is now online. [latest-21336]2021-12-03T17:29:06.090Z <app:NOTICE> Starting HTTP server and API... -
Patrick I have a question if I may?
I have an MSR ruleset to turn on my lounge lights at "40 minutes before sunset".
The trigger for this rule is another rule that evaluates if its 40 minutes before sunset.
Looking at the summary card for the rule that turns on the lights and also for the reference rule for "40 minutes before sunset", they state they reset at 12:00am.
However if I manually turn off my lights before 12:00am or after 12:00am, they are not automatically turned back on again which is correct.
On the Ezlo Meshbot rules that have recently added being able to select one rules state as another rules trigger etc.
However on their current system when I manually turn my lights off, they automatically are turned back on again.
Seems their rule state just looks at "finished" aka its after 40 minutes before sunset.
So seems they are not resetting the referenced rules state for whenever its after "40 minutes before sunset" and that time event has already passed.
Please can you explain how this works in MSR?
cc28f4f9-13af-43bf-9c34-52c5ceb10511-image.png
a698b4fd-e16a-4c76-a550-8c6e276720fe-image.png
686a1a84-540c-4ada-b783-00a45c2388fa-image.png
585d4a2c-db0f-4060-a448-0cc720bad2f1-image.png
Thanks
-
A few new functions have worked their way into Reactor's expression language over the last couple of months, and while they are documented in the change logs and documentation, it seems some of you are not aware of them, so I'm going to pick one out and highlight it, maybe do others later...
A lot of you build strings in expressions by simple concatenation, and there's nothing wrong with that, but there's a new function in the expression language that can help you clean things up, in particular when handling numeric values.
I've noticed many of you will round your results either on the calculation, or in some cases, in a separate variable. For example, say we have a pair of expressions that retrieves the indoor and outdoor temperature from a sensor and the weather service:
indoor = getEntity( 'hubitat>144' ).attributes.temperature_sensor.value' ) outdoor = getEntity( 'weather>home' ).attributes.wx.temperatureThe weather service, since it converts from degrees K in its reporting to degrees C, may have an irrational or repeating value (e.g. 8.233333333...). As a result, when you compute the difference, it, too, may have an irrational or repeating result, so you decide to round it to one decimal:
tempDiff = round( outdoor - indoor, 1 )Then, perhaps you have a rule that if the differential is greater than 10 degrees, you send a notification, and the notification uses all three variables in the message string:
${{ 'The outdoor temperature is ' + outdoor + 'C and the indoor temperature is ' + indoor + 'C; the difference is ' + tempDiff + 'C' }}This is fine, except that the outdoor temperature isn't rounded, so you decide to fix that. There are at least three ways: add a round() to the outdoor variable expression, or create a third variable like outdoorRounded = round( outdoor, 1 ), or, use the round() function into the substitution expression
${{ 'The outdoor temperature is ' + round( outdoor, 1 ) + 'C and the indoor temperature is ' + indoor + 'C; the difference is ' + tempDiff + 'C' }}It's all getting very messy... Let's use format() instead of string concatenation, and not worry about rounding the difference, so we keep the maximum precision possible for any calcs or tests that use it. We go back to:
indoor = getEntity( 'hubitat>144' ).attributes.temperature_sensor.value' ) outdoor = getEntity( 'weather>home' ).attributes.wx.temperature tempDiff = outdoor - indoorNow our string substitution:
${{ format( "The outdoor temperature is {0:.1f}C and the indoor temperature is {1:.1f}C; the difference is {2:.1f}C", outdoor, indoor, tempDiff ) }}Here, format() is building the message string. Each {} (curly-brace) pair denotes the substitution of a parameter to follow. The number first inside the opening curly brace is the parameter number, starting from 0 as the first parameter. So parameter 0 in this example refers to the variable outdoor, and 1 is indoor, and 2 is tempDiff. Using the numbers, parameters can be inserted in any order.
Each of these substitutions in the example includes an optional format specification. If no format specification is given (e.g. {0}), then the parameter is converted to a string with no special formatting, but since we can get numbers like 8.233333... it's desirable to use some formatting to make it pretty. The format is separated from the parameter number by the : (colon) in the substitution. The format we're using for all three parameters is .1f, which is <width>.<precision>f. Any number before the dot is a fixed field width, but since we want no extra spaces, we just don't specify a width (it's blank for our example), and the value will take as much space as it needs. The f at the end tells format() that the value is going to be formatted as a floating point number, and the .1 before the f tells the formatter to display a single decimal digit. So our 8.23333333 value would be displayed as 8.2, without using extra functions or variables, or dropping precision in a calculation. For clarity, 10.875 would be displayed/inserted as 10.9 in this example, because the formatter will round the displayed result to the specified number of decimal digits.
Tip: for simple string insertions that require no special formatting, format() will let you skip the parameter numbers if the parameters are in the same order as the substitutions, and the default format is (generic) string (s), so format( "{} x {} = {}", "alpha", "beta", "gamma" ) produces the string alpha x beta = gamma.
Docs for format are in the Reactor documentation under the heading Special Reactor Functions.
-
I updated to latest-21337-b535732 last night before heading off to sleep. I have a ruleset that checks for phone charging, mode evening, and room-assistant home. The system then waits five minutes and flips to mode night and announces it has done so via Echo devices.
At 05:30 ET each morning the system shifts to mode day.
However...
Last night MSR went thru the paces but mode evening never switched to mode night. Multiple attempts including reboots of MSR and Hubitat, no change.
This morning, instead of mode day it went back to mode evening which isn't supposed to trigger until sunset. This is confirmed across MSR, H-A, and Hubitat.
I'd missed the 21336 update and went from 21332 to 21337. I'll be log diving after coffee is ready.
Updated title to reflect what the issue seems to actually be.
-
Build 21228 has been released. Docker images available from DockerHub as usual, and bare-metal packages here.
Home Assistant up to version 2021.8.6 supported; the online version of the manual will now state the current supported versions; Fix an error in OWMWeatherController that could cause it to stop updating; Unify the approach to entity filtering on all hub interface classes (controllers); this works for device entities only; it may be extended to other entities later; Improve error detail in messages for EzloController during auth phase; Add isRuleSet() and isRuleEnabled() functions to expressions extensions; Implement set action for lock and passage capabilities (makes them more easily scriptable in some cases); Fix a place in the UI where 24-hour time was not being displayed. -
Hi,
MSR 21332 on Raspberry pi OS with Docker.
Very simple rule with one condition and one action. I am using a 15 second pulse along with a condition that must be sustained for 60 seconds.
From what I can see, it seems that the 'Pulse' output counter is starting as soon as the condition is met and not after the 'Sustained' time period. In my case, to have a 15 second pulse with a 60 seconds sustained time, I need to adjust the "Pulse" output to 75 seconds. Still for my case, anything below 60 seconds 'Pulse' and the condition never goes true.
I was expecting the Pulse time to start after the condition 'Sustained time' ( when used ) has completed.
-
Hi,
I am running the docker version of MSR (21332) on raspberry pi OS along with a Home assistant supervised (Docker). I used to be on HAAS OS.
Most of the MSR installation files are using the pi user/group except some file here and there where root user/group is used. This is not causing any functional issue that I am aware of except for the log files. When I SSH into the raspberry file (using the pi user) I can use the sudo command to look at the logs no problem however normally I do the configuration and log inspection via SAMBA. For some reason all logs have the root user and group and security set to 640 (read /write for user root and read for root group). Therefore SAMBA, using the user pi cannot access the logs. I tried changing the user/group and permission but when the log are re-written (when full) it comes back to root.
e742c6d9-1a25-409e-8b16-26d19b96de13-image.png
I played with the permission on log.2,3,4,5 in the example above.
Is that the normal behaviour or something is wrong in my setup?
Can the permission be relaxed a bit to say 644? that would give the pi user read access.
Thanks in advance.
-
Hi @toggledbits it is possible to have an array in the following way
["Window 1"]["Status On"]
["Window 2"]["Status On"]
["Window 3"]["Status Off"]
["Window 4"]["Status On"]That is, bidirectional.
How would this array be loaded? Normally we use Variable = ${{ ["Window 1", "Window 2", "Window 3", "Window 4"] }}, how would the array pair be loaded?.
Then the use, how would be a looping where I want to ask who has "Status On" and it returns me a new array with the part 1, that is the list of "Window"?
Or another search, I provide the information of the content of part 1, as "Window 2" and it would return me an array with the part 2 "Satus On".
Is it possible to have something like this?
Could you give the examples?
Thanks.
-
I've recently updated to latest build 21332 and notice in the Readme file that I should update nodejs to 16.13.0 or higher before end of March. I've had a go at doing this, but think I've not done it correctly as I get the following responses in the terminal:
pi@raspberrypi:~ $ node -v
v14.17.0
pi@raspberrypi:~ $ nodejs -v
v16.13.0Is this correct? If not then what steps do I need to carry out to update nodejs properly.
Any help from the group would be much appreciated.
-
Use case: Honeywell API gets easily flustered resulting in either one or both of my t-stats not receiving the change command/s. As such, I've written some "course correction" rulesets that basically look at the present situation and, if not matching what should be there, resends the command.
Now... logic says if the first send didn't get thru then APIs generally aren't going to like another one right on it's heels. To combat this, I've added a Restriction to the correction ruleset that says the status must exist for 420 seconds before it will fire. This (hopefully) also prevents a race state when the real rule set AND the correction spring into action at the same time.
I set a notification reaction to let me know a course correction had to be implemented but I've noticed that it fires even if the Restriction on the actual reaction never completes (is found unnecessary) and, as such, the correction ruleset never actually needs to fire.
The ask: can a notification be tied to fire ONLY if/when the action actually fires?
Hopefully that is clearer than mud.
Solved here https://smarthome.community/post/10319.
-
Hi
Wanted to create a rule for monitoring the battery level of Z-Wave devices on my Vera hub.
I can select the battery level as the trigger OK.
But not sure how to handle the Reaction to send an alert / notification ?
If in the triggers I have multiple devices monitored for their battery level
39a2f0af-c2e4-450b-a1ce-f542df31d02d-image.png
How could I create say a TTS announcement or text alert that mentions the name of the device who's battery level has dropped below 10% ? The device that has triggered the rule.
I'd rather not have to create an individual rule for each device etc.
Any ideas?
Thanks
-
My trusty vera plus is starting to have some issues that are making me think that it is about to die. i now get constant luup reloads even though i've moved almost everything except for z-wave devices and the iphone locator off that machine. it is even booting off an ssd drive to minimize wear and tear on the internal memory. I've moved all my logic off box to MSR, so it is just a glorified zwave adapter. I would love to hear any ideas that would make moving 60ish devices off that box to something else as painless as possible. the thought of excluding and including the devices sends shivers down my spine, so anything that helps me migrate the network would be greatly welcomed. anyone have any suggestions?
-
I have 3 outside temperatures and I would like to pick the middle value of the 3 to use as the outside air temperature for calculations and logic.
The obvious, to me, mid() function does not seem to exist. What function can I use to pick the middle of the three values?
Thanks,
Tom -
I'm probably going to release my first pass at the MQTTController for Reactor (aka MSR) this week. It doesn't yet intrinsically know about a lot of devices, but you can train it for pretty much anything, I think, and it would be great if a couple of our heavy MQTT users could help check it out and maybe help contribute some device templates.
I'm hoping to package it up for mid-week, assuming the rest of life stays on track.
Success factors for the test: solid familiarity with MQTT, a big mix of devices, and comfortable editing YAML (for creating the templates/mappings).
-
Whenerver openLuup restarts or reloads Luup MQTTController can't reconnect and I have to restart Reactor to solve it.
[latest-21321]2021-11-24T07:39:17.842Z <MQTTController:NOTICE> broker connection is offline; waiting for auto-reconnect [latest-21321]2021-11-24T07:39:17.844Z <MQTTController:ERR> Controller MQTTController#mqtt is off-line! [latest-21321]2021-11-24T07:39:32.849Z <MQTTController:NOTICE> attempting reconnect [latest-21321]2021-11-24T07:40:15.473Z <MQTTController:NOTICE> broker connection is offline; waiting for auto-reconnect [latest-21321]2021-11-24T07:40:30.475Z <MQTTController:NOTICE> attempting reconnect [latest-21321]2021-11-24T07:40:52.696Z <MQTTController:NOTICE> broker connection is offline; waiting for auto-reconnect [latest-21321]2021-11-24T07:41:07.702Z <MQTTController:NOTICE> attempting reconnect [latest-21321]2021-11-24T07:41:40.213Z <MQTTController:NOTICE> broker connection is offline; waiting for auto-reconnect [latest-21321]2021-11-24T07:41:55.217Z <MQTTController:NOTICE> attempting reconnect [latest-21321]2021-11-24T07:57:39.113Z <MQTTController:NOTICE> broker connection is offline; waiting for auto-reconnect [latest-21321]2021-11-24T07:57:54.114Z <MQTTController:NOTICE> attempting reconnect [latest-21321]2021-11-24T07:58:16.396Z <MQTTController:NOTICE> broker connection is offline; waiting for auto-reconnect [latest-21321]2021-11-24T07:58:31.399Z <MQTTController:NOTICE> attempting reconnect [latest-21321]2021-11-24T07:58:37.271Z <MQTTController:NOTICE> broker connection is offline; waiting for auto-reconnect [latest-21321]2021-11-24T07:58:52.278Z <MQTTController:NOTICE> attempting reconnect -
I have multiple sensors connected to via Bluetooth to a Tasmota device.
All sensors report their values in the SENSOR topic, how do I map those to individual entities? -
I can no longer access the Rule Sets menu after upgrading to build 21275. Nothing happens when I click on Rule Sets. Other menu options work fine. I have cleared history, hard refreshed the browser, Rebooted. Works fine in Firefox and google chrome. I have always used Safari.
Suggestions?Safari for Mac version 15.0
MSR Version 21275-df3d784
Synology Docker
[Solved] Is there a cap or max number of devices a Global Reaction should not exceed?
-
Noticed in the last few nights that my Global Reaction to turn on a mere six lights in the evenings the same two devices no longer turn on. One is a dimming smart bulb, the other is a wall outlet.
This has been running flawlessly for months - just in the last few nights I've noticed these two devices being left behind and yes, it's always these two devices only.
"What changed?"
- No Hubitat firmware updates
- No new devices added to Hubitat
- list itemTwo MSR updates (the last two, I keep up with the latest)
- list itemHome Assistant releases (should have zero bearing, HA is nothing more than pretty dashboards)
- list itemAdded MQTT to MSR
I did do a z-wave "repair" last night and am waiting to see if this helps.
Is there any maximum or cap on number of devices that should be included in a Global Reaction?
*Marked as solved as the question asked was answered. The issue persists but the question was answered.
-
You don't say specifically, but when you say "dimming smart bulb", I'm thinking plugin, not ZWave. Can be more specific about the devices involved?
To answer the question asked, no, there's no limit.
-
It's a smartbulb, unfortunately Hubitat labels it as "Generic ZWave Smart Dimmer" which is misleading. This appears to be a GoControl Z-Wave Dimmable LED Light Bulb, LB60Z-1.
The second device is also misleadingly named in Hubitat as "Generic Z-Wave Relay". It is a GoControl WO15Z outlet.
-
Something I don't do on Hubitat that I have to do on Vera is pace actions... by default, VeraController will not send actions more frequently than every 25ms, and this pace seems to work (there have not been any complaints about missing actions that can't be attributed to other causes).
Maybe Hubitat needs it too... that would be a bummer. If adding delays to your reaction resolves the issue, that points in that direction.
-
These just happen to be the last two devices in the Global Reaction. I'll add a one second delay ahead of each of them and see what happens tonight.
-
So the one second delay was implemented and, upon the anointed time the previously two missing lights were on as expected.
-
OK, so I'll add some pacing to Hubitat as well. That's disappointing.
-
As this has worked flawlessly since MSR was released I'm inclined this is an unfortunate code change somewhere in one of the last releases of Hubitat - although, their last release was some weeks ago. Perhaps something in one of the last couple MSR releases "triggered" something they'd changed that had previously been dormant? Dunno. Thinking aloud.
-
None of the recent code changes to Hubitat would affect the performance of actions. The most notable of the changes was resolution of race condition during startup (when the Mode and HSM states are truly updated during startup), and not remotely close to the action implementation. All of the other changes are trivial, and again, not near the action implementation.
It would be easy to prove that the actions are being sent, if you want to run a more detailed test. The logging of actions on Hubitat is, and has been for some time, unconditional, so there will be (or not) evidence in the logs that the actions were sent to Hubitat. If you remove your recently-added delays and run like it was until it fails again, then peruse the logs, I'm pretty sure you'll find those actions were being attempted, at least. I strongly suspect they will be there. If not, there's a high chance we'll see another reason for why they are not.
This highlights, again, that reporting problems in the blind isn't useful. The logs are there for a reason. If something on the engine side isn't working as expected, it should be among the first places you look.
-
Removed the delays I'd added and... everything ran just fine for the second night in a row (one with, one sans, the delays.). lol
-
Of course. The performance of the Hubitat and the mesh are also an issue here. It's a complex system with many variables.