-
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
Switching from Vera to Hubitat
-
Well finally after a long time, I bought my Hubitat and start the process of working with 2 hubs, with the final goal of staying only with Hubitat.
I want to share my first insight, and of course then a shortlist if you can help to speed up my change with some information.
First perception Hubitat is much more professional, lighter, more technical, and thus more difficult for beginners. Vera has the Dashboard and Devices part more visually elaborated, it is easier and faster to see things, something that Hubitat has to build but gives much more potential for creation. Hubitat's manuals and documents are infinitely better. In summary, the more technical features in my opinion, far outweigh the visual point of Vera.
Some small doubts:
- Is there in Hubitat a way to update/force neighbor nodes?
- In Vera I use the variable x_vera_device.failed or zwave_device.failed to detect devices with problems (long discussions in other posts), in MSR I don't see this variable for Hubitat devices, how to know the device is in a failure state? In MSR Entities I see that Vera devices have many more variables than Hubitat devices.
- In this matchEntities({capability:['x_vera_device']}) expression that lists all the devices, for this x_vera_device parameter it only shows what is in the Vera, which would be common to any hub?
- Who is the equivalent of Vera's Switchboard Plugin from @toggledbits on Hubitat? Do you have something like SiteSensor?
Sorry for asking these questions, I have already searched the manuals and forums and they are issues that after a week of searching I still can't solve.
Thanks.
-
@wmarcolin said in Switching from Vera to Hubitat:
Is there in Hubitat a way to update/force neighbor nodes?
We don't even know that a node is ZWave. But that's not different from Hass. One of the disappointments of those platforms.
@wmarcolin said in Switching from Vera to Hubitat:
In Vera I use the variable x_vera_device.failed or zwave_device.failed to detect devices with problems (long discussions in other posts), in MSR I don't see this variable for Hubitat devices, how to know the device is in a failure state?
See #1
@wmarcolin said in Switching from Vera to Hubitat:
In this matchEntities({capability:['x_vera_device']}) expression that lists all the devices, for this x_vera_device parameter it only shows what is in the Vera, which would be common to any hub?
x_vera_deviceis a capability that exists only on Vera devices. It's a container for the additional information we can get from the Vera that other platforms don't have in common.@wmarcolin said in Switching from Vera to Hubitat:
Who is the equivalent of Vera's Switchboard Plugin from @toggledbits on Hubitat? Do you have something like SiteSensor?
This is two separate questions. Virtual devices can be created on Hubitat by clicking "Add Virtual Device" in the Devices list.
I'm not aware of anything like SiteSensor on Hubitat, but I'm not deeply familiar with the breadth of their community apps. It's a good bit of a looser environment than the Vera App Marketplace defined. But, MSR can fulfill the SiteSensor role, as has been discussed in this category in other posts.
-
@toggledbits hi!
Regarding x_vera_device.failed or zwave_device.failed I understand and I am disappointed by this as well. Well, I follow the search task on the forums to see what I can find, surely I am not the only one who wants to do a check when a device stops responding.
With the point of listing all devices, something similar to x_vera_device for Hubitat to give the same? Any suggestions on what would be a common point across all Hubitat devices?
Ok, now I understand Add Virtual Device, but nothing compared to Switchboard
searching now how to create a radio switch.Site Sensor ok I will follow what we have discussed in this forum, I don't like, Sitesensor seems more transparent/impactful than being in a recurrent way triggering the MSR to test every 5 seconds the internet.
I'm seeing that the road will be longer than I thought, strong advantage that I'm really seeing is the compatibility with devices, especially S2, and of course start using Zigbee, I have 4 devices that I bought more than a year and finally will use.
-
@wmarcolin said in Switching from Vera to Hubitat:
With the point of listing all devices, something similar to x_vera_device for Hubitat to give the same? Any suggestions on what would be a common point across all Hubitat devices?
It is the purpose of the
x_capabilities to express hub-specific data and behavior. It is the purpose of the "standard" capabilities ( likepower_switchandtemperature_sensor) to provide a "lingua franca" interpretation of the data when possible (and I encourage you to use those capabilities when possible in preference to thex_capabilties).The
x_capabilities try to expose as much information as the hub offers in its raw form, so I would examine your entities and look at what's there. If there are opportunities to map those to standard services and it hasn't been done, bring that to my attention and I can add that mapping. But nonetheless, you are not cut off from the data; it's all there. What you don't find there is data that doesn't exist (i.e. isn't offered by the hub).In the case of Hubitat, if data or capability (action) is not exposed through MakerAPI, the Hubitat forums should receive that complaint. And it's more effective if those complaints come from multiple users (i.e. not just me). But Hass, Ezlo, it's all the same... if there's a way to figure it out, I will (especially if you help by providing data I don't have access to), but if the hub's API doesn't offer the necessary data, the hub has to change, not MSR.
-
@toggledbits thanks for the reply online, I will take your message and see what I should do and of course try to help.
But today I am really bothered by Hubitat not signaling clearly that a device is failing. Yesterday, more than 24 hours ago, I purposely unplugged a plug from the electricity supply to see if there were any failure signals, and there are none.
This to me is extremely serious, devices can for some reason lose communication, stop working, and only when an action fails should we investigate and understand. This is absurd to me, if I go on vacation and the door/window or motion sensors are not responding, does that mean that the alarm will not work? Maybe my analysis is hasty, but this is serious, I want to act before, when I already know that a communication established by wakeup interval does not happen, I will be warned.
I posted a similar message in the Hubitat group of users and received this comment (https://community.hubitat.com/t/how-many-ex-vera-owners-are-here/44951/122), I will look into this Device Activity Check that you have developed.
Again Patrick, thank you very much for your always kind attention, I saw that in another chat you mention that you have to take some time for your son, to go to University. Good luck, and unplug for a while
who knows, maybe you'll come back with more brilliant ideas for all of us.Thanks.
-
This is another reason I'm doing my own ZWave-JS integration for MSR, and not relying on, for example, HA (which uses ZWave-JS now) to be a sufficient pass-through. That makes Reactor much more "hub-ish", I realize, but this is a clear example where the middle-man (HA) is not contributing to capability.