-
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
Added IP camera to Ezlo, what is causing this
-
@toggledbits I added an IP camera to my Ezlo for testing and my global variable for Ezlo devices that are not responding randomly do a quick toggle from empty to "IP camera" then back to empty.
Is it the controller interface not supporting IP cameras or something else causing this?
@2021-10-19T23:24:07.826Z[latest-21292]2021-10-19T23:10:00.043Z <Engine:NOTICE> Resuming reaction Schema - Dräneringspump<SET> (rule-ktd8obiy:S) from step 2 [latest-21292]2021-10-19T23:10:00.043Z <Engine:5:Engine.js:1504> Engine#1 reaction rule-ktd8obiy:S step 2 perform { "entity": "vera>device_53", "action": "power_switch.off" } [latest-21292]2021-10-19T23:10:00.043Z <Engine:5:Engine.js:1407> _process_reaction_queue() task returned, new status 3; task 29 [latest-21292]2021-10-19T23:10:00.044Z <VeraController:null> VeraController#vera enqueue task for Entity#vera>device_53 action power_switch.off: task { "newTargetValue": "0", "DeviceNum": 53, "id": "action", "serviceId": "urn:upnp-org:serviceId:SwitchPower1", "action": "SetTarget" } [latest-21292]2021-10-19T23:10:00.044Z <Engine:5:Engine.js:1442> _process_reaction_queue ending with 1 in queue; none delayed/ready; waiting [latest-21292]2021-10-19T23:10:00.048Z <Engine:5:Engine.js:1442> _process_reaction_queue() wake-up! [latest-21292]2021-10-19T23:10:00.049Z <Engine:5:Engine.js:1403> _process_reaction_queue() running task 29 { "tid": 29, "id": "rule-ktd8obiy:S", "rule": "rule-ktd8obiy", "__reaction": [RuleReaction#rule-ktd8obiy:S], "next_step": 3, "status": 1, "ts": 1634684400015, "parent": --null--, "__resolve": --function--, "__reject": --function--, "__promise": [object Promise], "attempts": 3 } [latest-21292]2021-10-19T23:10:00.049Z <Engine:NOTICE> Resuming reaction Schema - Dräneringspump<SET> (rule-ktd8obiy:S) from step 3 [latest-21292]2021-10-19T23:10:00.049Z <Engine:INFO> Schema - Dräneringspump<SET> all actions completed. [latest-21292]2021-10-19T23:10:00.049Z <Engine:5:Engine.js:1407> _process_reaction_queue() task returned, new status -1; task 29 [latest-21292]2021-10-19T23:10:00.050Z <Engine:5:Engine.js:1442> _process_reaction_queue ending with 0 in queue; none delayed/ready; waiting [latest-21292]2021-10-19T23:17:00.724Z <VeraController:ERR> VeraController#vera update request failed: FetchError: network timeout at: http://127.0.0.1:3480/data_request?id=status&DataVersion=574966431&Timeout=15&MinimumDelay=100&output_format=json&_r=1634685402721 [latest-21292]2021-10-19T23:24:07.826Z <EzloController:WARN> EzloController#ezlo warning: update parameter serviceNotification for Entity#ezlo>device_615e11a7129e071220cb5f8d not previously defined! (value now (boolean)false) [latest-21292]2021-10-19T23:24:07.826Z <EzloController:WARN> EzloController#ezlo warning: update parameter syncNotification for Entity#ezlo>device_615e11a7129e071220cb5f8d not previously defined! (value now (boolean)false) [latest-21292]2021-10-19T23:24:07.828Z <Rule:INFO> Rule#rule-ku32xyj5 evaluation in progress; waiting for completion [latest-21292]2021-10-19T23:24:07.828Z <Rule:INFO> Rule#rule-kue8adhf evaluation in progress; waiting for completion [latest-21292]2021-10-19T23:24:07.828Z <Engine:5:Engine.js:981> Engine#1 set global EzloDevicesNotResponding; value=(string)IP Camera [latest-21292]2021-10-19T23:24:12.474Z <Rule:INFO> Rule#rule-ku32xyj5 evaluation in progress; waiting for completion [latest-21292]2021-10-19T23:24:12.475Z <Rule:INFO> Rule#rule-kue8adhf evaluation in progress; waiting for completion [latest-21292]2021-10-19T23:24:12.476Z <Engine:5:Engine.js:981> Engine#1 set global EzloDevicesNotResponding; value=(string) [latest-21292]2021-10-19T23:24:12.482Z <Rule:INFO> Notifiering - Ezlo devices OK (Rule#rule-kue8adhf) SET! [latest-21292]2021-10-19T23:24:12.483Z <Engine:5:Engine.js:1442> _process_reaction_queue() wake-up! [latest-21292]2021-10-19T23:24:12.487Z <Rule:INFO> Notifiering - Ezlo devices OK (Rule#rule-kue8adhf) RESET! -
I need a more complete picture than this. Show the rule(s) involved and the global variables, please. There is a rule toggling at the end of the log snippet, but since you haven't really given me any context to know what is what, what it's doing or not doing, and why, I have no context for what I'm looking at.
And actually, now that I look at it, am I even looking at the rules, or are you just asking about the two log entries at the timestamp you gave? Not clear what your question/problem is....?
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
@toggledbits Sorry for not giving the whole picture. My question is if you know why "IP Camera" is added and removed from the variable within seconds.
Looking at it further myself though it seems like the Ezlo actually is reporting this device as "not reachable" for a few seconds, I misread the log and thought it was within ms and the WARN of "not previously defined" made me curious.The rule is just sending me a notification and triggers if the variable changes from anything to anything AND variable == string"", Pulse for 1 second.
The global expression is
Sorry to bother unnecessary
I guess I'll just remove the camera or filter it out in the expression as it's sending me notifications that all devices are responding again when my other rule that notifies me of devices not responding haven't had the chance to pick up the quick toggle. -
The logs are showing that the eZLO is sending updates, and apparently that value changed state twice in about 5 seconds: you can see at 24:07 where the global variable changes, so it has gotten one update and handled it, and then at 24:12 it has gotten another and changed it back. It would be an eZLO-side mystery to unravel why it's sending not-reachable followed by reachable so quickly, maybe a bug in their firmware, maybe just the way it works. It seems possible, even likely, that during any restart of the hub, devices would be marked down until they are known up, and some will just be left in the last known state until a new state is established, and given that the Vera engineering team is still present for the eZLO firmware, I'm sure they are still up to their old tricks and there is some inconsistency in which is chosen for which device or device class/type. I would not be at all surprised if IP-driven devices (like cameras) are marked for failure immediately when any request to the device fails, even on the first try, so lapses in network/wifi or the camera itself may lead to spurious marking of the device as failed followed by a quick recovery. These are all very real risks of the problem being solved.
So, probably something to mention in the other thread on this general (device error) subject: you may need to add a "sustained for" to your rule to dampen response, to allow for such momentary lapses, which are probably more common than we've ever realized, but will be on full display now that people are implementing rules like this.
The logged warnings... since eZLO is such a great unfinished unknown, and there are many inconsistencies and undocumented behaviors of their system and API, when an update for a device from the API arrives with a value that was not in the first device inventory, the warning is issued. Reactor then just adds the value to the device and carries on as if it was always there. So that's largely debug/notice of a surprise, but nothing harmful. And I'm not sure the values involved are even documented; I'll have to look (
serviceNotificationis known according to the API docs, and seems to be an internal value;syncNotificationis undocumented). But in any case, the warnings are advisory only and harmless and irrelevant to behavior here.Thanks for posting the screen shots in English!
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
@toggledbits Sustained for is the way to go here, thank you for your advice.
I can say that for Zigbee devices their firmware is a mess, a reboot of the controller marks all devices unreachable until they are physically toggled or reporting new sensor values, so rebooting means going around the house like a fool toggling lights and blowing on temp/humidity sensors, and if you don't do it fast enough you have to reboot again to give the devices a new chance to phone home in time.