-
Hi @toggledbits
Just a quick question. I noticed that I can't test a "set variable" action when the rule is not active. I wanted to set a global expression in a reaction and wanted to test it by pushing the "Run action now" button in the border of the reaction, but it didn't do anything. Only when I activated the rule, the button worked.
Is this a bug or is this by design?
I'm running the latest docker build:
latest-23114-e4060aae -
-
I've done a bit of repackaging of MSR to make it work as an add-on under Home Assistant mostly for my own purposes but hopefully it makes it a bit easier to install and get going.
GitHub - mrw298/hassio-reactor-addon GitHub - mrw298/hassio-reactor-addon
Contribute to mrw298/hassio-reactor-addon development by creating an account on GitHub.
-
Hi Everyone,
I am just starting to move over from Vera to Home Assistant using MSR.
On vera I had been using DelayLight. I have tried to replicate it with help from youtube (https://www.youtube.com/watch?v=fc_ij0D1hXE) Reactor for Vera #006 - Emulating DelayLight in Reactor.
I have created 6 rules that sort of work. but I am just wondering if this is best practice or should can it be built in 1 rule like the old vera way?
-
Hi!
I tried to find an answer in both the forum and by myself, without any luck. I'm trying to make my Echo device play a mp3 file. The same mp3 file is easy to play with other smart speakers (Sonos, Google/Nest) - that it no problem. Same approch do not work with Echo devices. The mp3 files I want to use is located on my HA installation (config/www/audio), running on ver. 2023.5.4. I have MSR ver 23114.
Is there a way to do this easily?
Thanks!
/Fanan -
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. -
I'm controlling a HVAC device through the MQTTController. While setting up the entity config in reactor.yaml, I started with this on the action block:
set_setpoint: topic: "ezlo_mqtt/set/item/%topic%/set/Tsetpoint" payload: expr: "parameters.setpoint" type: rawHowever, as the setpoint is a number in the UI, things were not fully parseable as a number and nothing was outputted to mqtt.
So I've added this code to MQTTController.js at line 1449 to add the payload type 'number':
} else if ( 'number' === act.payload.type ) { payload = String( payload ); } else if (''raw' !== ( act.payload.type || 'raw' ) ) {After this change, I was able to set the payload type to number:
set_setpoint: topic: "ezlo_mqtt/set/item/%topic%/set/Tsetpoint" payload: expr: "parameters.setpoint" type: numberAnd things worked as intended, being able to send numbers in the actions bit of a rule set.
-
Some background
switch (on/off) brightness color
I'm trying to integrate a Zigbee device into the MSR using zigbee2mqtt bridge and MQTTController. The device in question is a cheap mood light that has following properties that I'd like to control:I'v already managed to get the switch part working and can toggle the light on/off. Also the brightness value is mapped back to MSR. In zigbee2mqtt it has a value range from 0 to 254, so this the reason for the expression:
expr: 'payload.brightness / 254'Here's the entity definition (don't know whether the type should be something else than the Switch)
zigbee-lidl-mood-light: name: 'Lidl Mood Light' friendly_name: 'Mood Light' type: Switch uses_template: lidl-moodlightAnd the corresponding template (NOTE: rgb_color has not been defined in this example):
lidl-moodlight: init: "zigbee2mqtt/%friendly_name%/get/state" query: "zigbee2mqtt/%friendly_name%/get/state" capabilities: - power_switch - toggle - dimming primary_attribute: power_switch.state events: "zigbee2mqtt/%friendly_name%": "power_switch.state": json_payload: true expr: 'upper(payload.state) == "ON"' "dimming.level": json_payload: true expr: 'payload.brightness / 254' actions: power_switch: "on": topic: "zigbee2mqtt/%friendly_name%/set/state" payload: 'ON' "off": topic: "zigbee2mqtt/%friendly_name%/set/state" payload: 'OFF' set: topic: "zigbee2mqtt/%friendly_name%/set/state" payload: expr: "parameters.state ? 'ON' : 'OFF'" type: raw toggle: topic: "zigbee2mqtt/%friendly_name%/set/state" payload: 'TOGGLE'The problem
In order to control the brightness or the RGB color values, I would have send a JSON payload in corresponding actions. But I have no idea how to define it in the template. The reason why the switch part is working is that the zigbee2mqtt accepts also plain ON / OFF / TOGGLE string payloads in that case.But the brightness should be controlled with the following payload:
{"brightness": 196}And the RGB color like:
{"color":{"rgb":"46,102,150"}}Here's the link for the documentation (the Exposes part defines the messages).
So how should I define the JSON payload for example for the dimming action? It definitely should be some sort of expressions since I have to map the MSR real value (0...1) to (0...254) for the zigbee2mqtt.
actions: dimming: set: topic: "zigbee2mqtt/%friendly_name%/set" payload: expr: ????? type: jsonAnother problem is the RGB value. I could use the rgb_color capability for the setting but the problem is that the zigbee2mqtt only reports the current color in hue/saturation or xy coordinates.
Here's an example of published message after setting the color:
Topic: zigbee2mqtt/Mood Light QoS: 0 { "brightness":254, "color":{ "hue":240, "saturation":100, "x":0.1355, "y":0.0399 }, "color_mode":"xy", "color_temp":574, "linkquality":96, "state":"ON" }I would have to map those values back to RGB, but is it even possible with existing constructs in MQTTController's templates?
Help would be appreciated @toggledbits
br,
mgvra -
Good evening,
I was wondering if it would be possible to send out a push notification when there is a update to MSR to HA users. I know how to set up notifications through Reactor to HA users, but I'm unsure what to look for in regards to updates. I know that MSR itself will tell me there is an update, but unless I'm logged into MSR in a browser, I'm not always going to see that.Just updated to latest-23114-e4060aae MSR
Home Assistant 2023.4.6
Supervisor 2023.04.1
Operating System 10.0 -
MSR tooltip says that "disabled groups are ignored, as if they did not exist (conditions don't run)".
Just want to clarify if it's by design that actions beneath disabled groups should run? They do run, but intuitively I was expecting them to be disabled as well.
Running the latest build under Docker.
-
I am running MSR on a small windows machine. Earlier this week, the machine restarted and Reactor restarted as well. I am now experiencing an issue in which Reactor doesn't seem to be making any updates or calling any scenes. Reactor is communicating with Vera and all entities seem to be accurate (ie lights on or off) and manually clicking on Actions seems to work just fine. The Status page also seems accurate and displays rules automatically being SET and RESET. But when the Reaction changes from SET to RESET or vice versa, none of the actions are actually invoked.
For example, I manually ran a SET action at 11:29 and my lights turned on. At 11:30, the Status Dashboard shows the rule updating to RESET, but the lights did not turn off.
I have included a screenshot of the rule history below as well as the log for these times as well.
Any ideas on what can be going on? I have tried restarting the Windows machine as well as Reactor multiple times to see if this fixes this behavior but have not had any success. Any information is appreciated.
78f9f75f-d24c-4ff4-a23a-fda0c98cbcbc-image.png
[stable-22274]2023-04-14T03:29:39.161Z VeraController:null VeraController#vera enqueued task for Entity#vera>scene_3 action script.run: task [Object]{ "SceneNum": "3", "DeviceNum": 0, "id": "action", "serviceId": "urn:micasaverde-com:serviceId:HomeAutomationGateway1", "action": "RunScene" }
[stable-22274]2023-04-14T03:29:39.587Z VeraController:INFO VeraController#vera 0 dead entities older than 86400000s purged
[stable-22274]2023-04-14T03:29:45.763Z Rule:NOTICE Evening Lights Rule (Rule#rule-la4gnzmt) configuration changed; reloading
[stable-22274]2023-04-14T03:29:45.766Z Rule:NOTICE Evening Lights Rule (Rule#rule-la4gnzmt) stopping
[stable-22274]2023-04-14T03:29:45.772Z Rule:NOTICE Evening Lights Rule (Rule#rule-la4gnzmt) stopped
[stable-22274]2023-04-14T03:29:45.773Z Rule:NOTICE Rule#rule-la4gnzmt (Evening Lights Rule) starting
[stable-22274]2023-04-14T03:29:45.777Z Rule:INFO Evening Lights Rule (Rule#rule-la4gnzmt) starting evaluation; because startup
[stable-22274]2023-04-14T03:29:45.779Z Rule:INFO Evening Lights Rule (Rule#rule-la4gnzmt) evaluated; rule state transition from RESET to SET!
[stable-22274]2023-04-14T03:29:45.802Z Rule:INFO Evening Lights Rule (Rule#rule-la4gnzmt) evaluation complete
[stable-22274]2023-04-14T03:29:45.809Z Rule:INFO Evening Lights Rule (Rule#rule-la4gnzmt) started
[stable-22274]2023-04-14T03:29:45.811Z Engine:INFO Enqueueing "Evening Lights Rule<SET>" (rule-la4gnzmt:S)
[stable-22274]2023-04-14T03:29:45.840Z Engine:NOTICE Starting reaction Evening Lights Rule<SET> (rule-la4gnzmt:S)
[stable-22274]2023-04-14T03:29:45.842Z Engine:INFO Evening Lights Rule<SET> all actions completed.
[stable-22274]2023-04-14T03:30:00.008Z Rule:INFO Evening Lights Rule (Rule#rule-la4gnzmt) starting evaluation; because timer-trigger Timer#rule-la4gnzmt
[stable-22274]2023-04-14T03:30:00.024Z Rule:INFO Evening Lights Rule (Rule#rule-la4gnzmt) evaluated; rule state transition from SET to RESET!
[stable-22274]2023-04-14T03:30:00.055Z Rule:INFO Evening Lights Rule (Rule#rule-la4gnzmt) evaluation complete
[stable-22274]2023-04-14T03:30:00.062Z Engine:INFO Enqueueing "Evening Lights Rule<RESET>" (rule-la4gnzmt:R)
[stable-22274]2023-04-14T03:30:00.079Z Engine:NOTICE Starting reaction Evening Lights Rule<RESET> (rule-la4gnzmt:R)
[stable-22274]2023-04-14T03:30:00.080Z Engine:INFO Evening Lights Rule<RESET> all actions completed.
[stable-22274]2023-04-14T03:30:01.099Z VeraController:INFO VeraController#vera 0 dead entities older than 86400000s purged -
Good morning,
I'm sorry if this has been asked (I did search, but couldn't find anything), I've run into a bit of a snag in some of my reactions using OpenWeatherMap. I made the assumption (you know what they say about assume), that the Forecast Temperature value was the Daily High, when in fact it's the current Temperature. It turns out you can get that information from OpenWeatherMap, but it's a on paid tier API.I am looking at alternatives, such as the haas>weather_forcast_home value from Home Assistant, as well as Pirate Weather, however, the value of those Forecast High is in an array.
27f55490-7869-434f-bcac-e1e5398b3aea-image.png
1df1a841-90f0-4dbe-8f73-ff3fc04595e2-image.png
How do I pull the values in that array out and make them useful in MSR?
I'm running latest-23078-d592d400 and HA 2023.3.5 on RPI4
-
To anyone using Pushover who has added Custom sounds to your Pushover account: how did you get them to appear in the sounds dropdown in MSR?
-
Hi guys,
I want to import my reactor sensors in the MSR addon for Home Assistant, but I can't find the app.js file anywhere. So now I don't know where to put the backup file.
I have not tried to put it in the main directory (config/reactor) yet. Wanted to know if I'm the only one with the problem.
Reactor addon: v0.0.8
MSR: 23063-c464b685
Home Assistant 2023.3.3
Supervisor 2023.03.1
Operating System 9.5
Frontend 20230202.0 - latestI started with v0.0.7, have just updated everything. Still no file.
-
@toggledbits was looking thru rule sets and updating which (new) lights I wanted REMII to impact and saw that this...
4711b0df-5e98-4992-bb25-d0e53203f0e8-image.png
...is showing as (missing) in the rule Deactivatedand looking in the dropdown of Variables it appears I cannot select that local expression (only Global) as I did when originally building this out back in 2021.
27f7025c-057e-441a-88ea-dc4bdf39614d-image.png
In looking at the rule Active Period I'm seeing:
487074ef-3bfa-4a84-b03d-ed6d920c118c-image.png which appears to be pointing to setting a variable in a rule?It's admittedly been a couple years since this was built and it's def not fresh in my memory.
-
MSR: latest-23078-d592d400
--Docker image on unRAID
Hubitat C-7: 2.3.5.121I'm always looking to simplify my rules and reactions and having finally grasped the Array function with a loop of perform.Action, I decided to re-write one of my rules. The kids like to play music on the Echo devices at a high volume, and I also have TTS loud during the night if a door/window are to open. In order to not have her yell at me later, I wrote a rule that resets the volume on each Echo device to a level of 2. However having 7 Echo's, there are many steps in my Reaction. Set the volume on device 1, wait a few seconds, set the volume on the device 2, wait, and so on.
Sample snippet of the set reaction: (This works BTW.)
2f5aafc0-bf97-4622-b41c-60649253590e-image.pngTo make it better, I created an array of the devices and want to run a perform.Action command. Less steps with the same results. Or so I thought. The end result is now a volume level of 0 or 1. I think the Echo gets confused. Either way, not a level of 2 like I was expecting. BTW volume 1 across the room is too low, in case you were wondering.
New set reaction:
${{ each device in Echo_devices: performAction( device, 'volume.set', { level:0.20 } ); 0 }}
da62dfb0-f433-4fc6-897f-d38c190f8c9a-image.pngThe av_transport.stop works as expected. The issue is with the volume.set, {level:0.20}. Do I have something wrong in my command?
Global expressions used:
8d054dca-20dc-4e97-aa6d-4537c9da4ea9-image.png -
Good evening all,
I've run across a quirk with my iBlinds motors in Home Assistant. Each iBlinds zwave motor has two controls that I can use. One is a switch, and one is a cover control.ee654e5d-d191-4082-a7f2-6b161923de75-image.png cid:A1190F3F-FB02-4332-93DE-9A15A490D9AB
The switch control is a binary on/off switch. On, the blind goes to the "open" position (v2 controllers, 50%, v3 controllers user definable parameter)
If you click on the cover icon, it moves between two positions. Essentially, it's closed in both positions, just 180 degrees apart. The cover control does give you the granularity to move to any position between 0 and 100, which is sometimes useful, when you just don't want it open or closed, such as letting some light in, but closing it enough when the sun is shining directly into the window and blinding everyone.
Here's the problem, which I've brought up with iBlinds support, and they're singing Simon and Garfunkel (Sound of Silence). The two controls don't update each other. If I open or close using the switch, the cover position value doesn't change. If I open or close using the cover control, the switch doesn't change to on or off. I've verified that this isn't just an issue with the dashboard/templates I'm using by going into the developer tools on HA and the values do not change. I've also checked those values in Reactor (Entities tab) and they do not update properly.
I've come up with a Reactor work around which sort of forces the controls to update. If anyone knows of a better way, please tell me. I have two rules set up that monitor for changes in the switch state, that then performs a x_haas_cover.set_cover_position to either 0 or 50 for either to off or to on respectively.
40b352f9-c599-4768-ac02-cd7bcb4b3b33-image.png
db1d73d4-1fc9-4785-a75a-068c42e63b48-image.png
This is sort of a one way street at the moment. I don't have a reverse rule set up to change the switch value, but the current rule seems more of an issue.
All that being said. I have 14 iBlinds motors in my home. That would mean 28 rules in Reactor. I know how to set up a Dynamic Group Control for Triggers. I put all 14 switches in the reactor.yaml file, and I can use those for triggers. How would I go about using 14 corresponding cover controls for the reactions?
It may be a simple matter, but I'm not sure. One thing i can say is the name of the switch and cover entities are the same, except for the control type:
0bbf3cb0-ab71-4c9c-b254-d3009f5b092c-image.png
Edit:
Running:
Reactor: latest-23078-d592d400
Home Assistant 2023.3.5
Supervisor 2023.03.3
Operating System 9.5
Frontend 20230309.1 - latest -
Post has been updated.
Need some guidance in determining what this error means.
Running Reactor latest-23078-d592d400; ZWaveJSController; Docker on Synology; Home Assistant 2023.3.6; Z-Wave JS UI 8.11.1
I have searched the site and could not find anything related to my question.
I know what the rule does. Yet, I cannot find the relationship with this error.
If someone could point me in the right direction, it would be appreciated.
Thanks in advance
Rule is as follow:
If the garage side door opens when the alarm is not armed and that both my spouse and I are at home:
Set Reaction: turn on the Siren_8 (basically a two seconds beep that was configured with the Aeotec Siren to warn us that the door is open)
Reset Reaction: turn off the Siren_8 in case it wants to keep beeping
Here's the updated error.
[latest-23078]2023-03-26T22:31:36.772Z <Rule:INFO> Door Sensors State (rule-lerjv6if in Control Room) starting evaluation; because entity-changed BinarySensor#hass>binary_sensor_garage_side_door_openclose_window_door_is_open [latest-23078]2023-03-26T22:31:36.772Z <Rule:INFO> Notification: Home Security - Garage side door just opened (Disarmed Only) (rule-lbmoup28 in Notifications) starting evaluation; because entity-changed BinarySensor#hass>binary_sensor_garage_side_door_openclose_window_door_is_open [latest-23078]2023-03-26T22:31:36.773Z <Rule:INFO> Any door open? (rule-lfn41thm in Home Security) trigger evaluation result is false (previously true) [latest-23078]2023-03-26T22:31:36.773Z <Rule:INFO> Any door open? (rule-lfn41thm in Home Security) evaluated; rule state transition from SET to RESET! [latest-23078]2023-03-26T22:31:36.782Z <Rule:INFO> Door Sensors State (rule-lerjv6if in Control Room) trigger evaluation result is false (previously true) [latest-23078]2023-03-26T22:31:36.783Z <Rule:INFO> Door Sensors State (rule-lerjv6if in Control Room) evaluated; rule state transition from SET to RESET! [latest-23078]2023-03-26T22:31:36.790Z <Rule:INFO> Notification: Home Security - Garage side door just opened (Disarmed Only) (rule-lbmoup28 in Notifications) trigger evaluation result is false (previously true) [latest-23078]2023-03-26T22:31:36.791Z <Rule:INFO> Notification: Home Security - Garage side door just opened (Disarmed Only) (rule-lbmoup28 in Notifications) evaluated; rule state transition from SET to RESET! [latest-23078]2023-03-26T22:31:36.799Z <Rule:INFO> Alarm triggered (rule-lbqu752y in Home Security) starting evaluation; because data-changed Data#states:cs-rule-lfn41thm [latest-23078]2023-03-26T22:31:36.799Z <Rule:INFO> Toggle Vestibule scene 003 LED color state between green/blue (rule-lfn441bq in Home Security) starting evaluation; because data-changed Data#states:cs-rule-lfn41thm [latest-23078]2023-03-26T22:31:36.800Z <Rule:INFO> Any door open? (rule-lfn41thm in Home Security) evaluation complete [latest-23078]2023-03-26T22:31:36.800Z <Rule:INFO> Door Sensors State (rule-lerjv6if in Control Room) evaluation complete [latest-23078]2023-03-26T22:31:36.800Z <Rule:INFO> Notification: Home Security - Garage side door just opened (Disarmed Only) (rule-lbmoup28 in Notifications) evaluation complete [latest-23078]2023-03-26T22:31:36.801Z <Rule:INFO> Alarm triggered (rule-lbqu752y in Home Security) trigger evaluation result is false (previously true) [latest-23078]2023-03-26T22:31:36.802Z <Rule:INFO> Alarm triggered (rule-lbqu752y in Home Security) evaluated; trigger state changed (false), but rule state remains RESET [latest-23078]2023-03-26T22:31:36.804Z <Rule:INFO> Toggle Vestibule scene 003 LED color state between green/blue (rule-lfn441bq in Home Security) trigger evaluation result is false (previously true) [latest-23078]2023-03-26T22:31:36.804Z <Rule:INFO> Toggle Vestibule scene 003 LED color state between green/blue (rule-lfn441bq in Home Security) evaluated; rule state transition from SET to RESET! [latest-23078]2023-03-26T22:31:36.812Z <Rule:INFO> Alarm triggered (rule-lbqu752y in Home Security) evaluation complete [latest-23078]2023-03-26T22:31:36.812Z <Rule:INFO> Toggle Vestibule scene 003 LED color state between green/blue (rule-lfn441bq in Home Security) evaluation complete [latest-23078]2023-03-26T22:31:36.814Z <Engine:INFO> Enqueueing "Door Sensors State<RESET>" (rule-lerjv6if:R) [latest-23078]2023-03-26T22:31:36.815Z <Engine:INFO> Enqueueing "Notification: Home Security - Garage side door just opened (Disarmed Only)<RESET>" (rule-lbmoup28:R) [latest-23078]2023-03-26T22:31:36.817Z <Engine:INFO> Enqueueing "Toggle Vestibule scene 003 LED color state between green/blue<RESET>" (rule-lfn441bq:R) [latest-23078]2023-03-26T22:31:36.819Z <Engine:NOTICE> Starting reaction Door Sensors State<RESET> (rule-lerjv6if:R) [latest-23078]2023-03-26T22:31:36.820Z <Engine:NOTICE> Starting reaction Notification: Home Security - Garage side door just opened (Disarmed Only)<RESET> (rule-lbmoup28:R) [latest-23078]2023-03-26T22:31:36.822Z <Engine:NOTICE> Starting reaction Toggle Vestibule scene 003 LED color state between green/blue<RESET> (rule-lfn441bq:R) [latest-23078]2023-03-26T22:31:36.823Z <ZWaveJSController:INFO> ZWaveJSController#zwavejs performing zwave_device.set_config on Switch#zwavejs>128-0 with [Object]{ "parameter": "9", "size": 1, "value": 2, "bitmask": 0 } [latest-23078]2023-03-26T22:31:36.830Z <HassController:INFO> HassController#hass action x_hass_input_text.set_value([Object]{ "value": "Closed" }) on Entity#hass>input_text_h_door_sensors_state succeeded [latest-23078]2023-03-26T22:31:36.831Z <Engine:INFO> Resuming reaction Door Sensors State<RESET> (rule-lerjv6if:R) from step 1 [latest-23078]2023-03-26T22:31:36.832Z <Engine:INFO> Door Sensors State<RESET> all actions completed. [latest-23078]2023-03-26T22:31:37.043Z <Rule:INFO> Batteries State (rule-leucn9pp in Control Room) starting evaluation; because entity-changed ValueSensor#hass>sensor_garage_side_door_openclose_battery_level [latest-23078]2023-03-26T22:31:37.044Z <Rule:INFO> Notification: Battery - Low level warning (rule-lbh1vt4k in Notifications) starting evaluation; because entity-changed ValueSensor#hass>sensor_garage_side_door_openclose_battery_level [latest-23078]2023-03-26T22:31:37.045Z <Rule:INFO> Batteries State (rule-leucn9pp in Control Room) trigger evaluation result is true (previously true) [latest-23078]2023-03-26T22:31:37.046Z <Rule:INFO> Batteries State (rule-leucn9pp in Control Room) evaluated; trigger state unchanged (true); rule state remains SET [latest-23078]2023-03-26T22:31:37.060Z <Rule:INFO> Notification: Battery - Low level warning (rule-lbh1vt4k in Notifications) trigger evaluation result is true (previously true) [latest-23078]2023-03-26T22:31:37.060Z <Rule:INFO> Notification: Battery - Low level warning (rule-lbh1vt4k in Notifications) evaluated; trigger state unchanged (true); rule state remains SET [latest-23078]2023-03-26T22:31:37.062Z <Rule:INFO> Batteries State (rule-leucn9pp in Control Room) evaluation complete [latest-23078]2023-03-26T22:31:37.062Z <Rule:INFO> Notification: Battery - Low level warning (rule-lbh1vt4k in Notifications) evaluation complete [latest-23078]2023-03-26T22:31:37.146Z <Rule:INFO> Notification: Battery - Low level warning (rule-lbh1vt4k in Notifications) starting evaluation; because entity-changed Group#groups>low_battery [latest-23078]2023-03-26T22:31:37.156Z <Rule:INFO> Notification: Battery - Low level warning (rule-lbh1vt4k in Notifications) trigger evaluation result is true (previously true) [latest-23078]2023-03-26T22:31:37.157Z <Rule:INFO> Notification: Battery - Low level warning (rule-lbh1vt4k in Notifications) evaluated; trigger state unchanged (true); rule state remains SET [latest-23078]2023-03-26T22:31:37.157Z <Rule:INFO> Notification: Battery - Low level warning (rule-lbh1vt4k in Notifications) evaluation complete [latest-23078]2023-03-26T22:31:37.161Z <Engine:INFO> Resuming reaction Toggle Vestibule scene 003 LED color state between green/blue<RESET> (rule-lfn441bq:R) from step 2 [latest-23078]2023-03-26T22:31:37.162Z <Engine:INFO> Toggle Vestibule scene 003 LED color state between green/blue<RESET> all actions completed. [latest-23078]2023-03-26T22:31:37.316Z <HassController:INFO> HassController#hass action x_hass_siren.turn_off([Object]{ }) on Entity#hass>siren_siren_8 succeeded [latest-23078]2023-03-26T22:31:37.317Z <Engine:INFO> Resuming reaction Notification: Home Security - Garage side door just opened (Disarmed Only)<RESET> (rule-lbmoup28:R) from step 2 [latest-23078]2023-03-26T22:31:37.317Z <Engine:INFO> Notification: Home Security - Garage side door just opened (Disarmed Only)<RESET> all actions completed. [latest-23078]2023-03-26T22:31:38.892Z <Rule:INFO> Any door open? (rule-lfn41thm in Home Security) starting evaluation; because entity-changed BinarySensor#hass>binary_sensor_garage_side_door_openclose_window_door_is_open [latest-23078]2023-03-26T22:31:38.892Z <Rule:INFO> Door Sensors State (rule-lerjv6if in Control Room) starting evaluation; because entity-changed BinarySensor#hass>binary_sensor_garage_side_door_openclose_window_door_is_open [latest-23078]2023-03-26T22:31:38.893Z <Rule:INFO> Notification: Home Security - Garage side door just opened (Disarmed Only) (rule-lbmoup28 in Notifications) starting evaluation; because entity-changed BinarySensor#hass>binary_sensor_garage_side_door_openclose_window_door_is_open [latest-23078]2023-03-26T22:31:38.894Z <Rule:INFO> Any door open? (rule-lfn41thm in Home Security) trigger evaluation result is true (previously false) [latest-23078]2023-03-26T22:31:38.894Z <Rule:INFO> Any door open? (rule-lfn41thm in Home Security) evaluated; rule state transition from RESET to SET! [latest-23078]2023-03-26T22:31:38.907Z <Rule:INFO> Door Sensors State (rule-lerjv6if in Control Room) trigger evaluation result is true (previously false) [latest-23078]2023-03-26T22:31:38.907Z <Rule:INFO> Door Sensors State (rule-lerjv6if in Control Room) evaluated; rule state transition from RESET to SET! [latest-23078]2023-03-26T22:31:38.916Z <Rule:INFO> Notification: Home Security - Garage side door just opened (Disarmed Only) (rule-lbmoup28 in Notifications) trigger evaluation result is true (previously false) [latest-23078]2023-03-26T22:31:38.917Z <Rule:INFO> Notification: Home Security - Garage side door just opened (Disarmed Only) (rule-lbmoup28 in Notifications) evaluated; rule state transition from RESET to SET! [latest-23078]2023-03-26T22:31:38.925Z <Rule:INFO> Alarm triggered (rule-lbqu752y in Home Security) starting evaluation; because data-changed Data#states:cs-rule-lfn41thm [latest-23078]2023-03-26T22:31:38.925Z <Rule:INFO> Toggle Vestibule scene 003 LED color state between green/blue (rule-lfn441bq in Home Security) starting evaluation; because data-changed Data#states:cs-rule-lfn41thm [latest-23078]2023-03-26T22:31:38.926Z <Rule:INFO> Any door open? (rule-lfn41thm in Home Security) evaluation complete [latest-23078]2023-03-26T22:31:38.926Z <Rule:INFO> Door Sensors State (rule-lerjv6if in Control Room) evaluation complete [latest-23078]2023-03-26T22:31:38.926Z <Rule:INFO> Notification: Home Security - Garage side door just opened (Disarmed Only) (rule-lbmoup28 in Notifications) evaluation complete [latest-23078]2023-03-26T22:31:38.927Z <Rule:INFO> Alarm triggered (rule-lbqu752y in Home Security) trigger evaluation result is true (previously false) [latest-23078]2023-03-26T22:31:38.930Z <Rule:INFO> Alarm triggered (rule-lbqu752y in Home Security) constraints not met! [latest-23078]2023-03-26T22:31:38.930Z <Rule:INFO> Alarm triggered (rule-lbqu752y in Home Security) evaluated; trigger state changed (true), but rule state remains RESET [latest-23078]2023-03-26T22:31:38.931Z <Rule:INFO> Toggle Vestibule scene 003 LED color state between green/blue (rule-lfn441bq in Home Security) trigger evaluation result is true (previously false) [latest-23078]2023-03-26T22:31:38.932Z <Rule:INFO> Toggle Vestibule scene 003 LED color state between green/blue (rule-lfn441bq in Home Security) evaluated; rule state transition from RESET to SET! [latest-23078]2023-03-26T22:31:38.939Z <Rule:INFO> Alarm triggered (rule-lbqu752y in Home Security) evaluation complete [latest-23078]2023-03-26T22:31:38.939Z <Rule:INFO> Toggle Vestibule scene 003 LED color state between green/blue (rule-lfn441bq in Home Security) evaluation complete [latest-23078]2023-03-26T22:31:38.941Z <Engine:INFO> Enqueueing "Door Sensors State<SET>" (rule-lerjv6if:S) [latest-23078]2023-03-26T22:31:38.942Z <Engine:INFO> Enqueueing "Notification: Home Security - Garage side door just opened (Disarmed Only)<SET>" (rule-lbmoup28:S) [latest-23078]2023-03-26T22:31:38.943Z <Engine:INFO> Enqueueing "Toggle Vestibule scene 003 LED color state between green/blue<SET>" (rule-lfn441bq:S) [latest-23078]2023-03-26T22:31:38.945Z <Engine:NOTICE> Starting reaction Door Sensors State<SET> (rule-lerjv6if:S) [latest-23078]2023-03-26T22:31:38.946Z <Engine:NOTICE> Starting reaction Notification: Home Security - Garage side door just opened (Disarmed Only)<SET> (rule-lbmoup28:S) [latest-23078]2023-03-26T22:31:38.948Z <Engine:NOTICE> Starting reaction Toggle Vestibule scene 003 LED color state between green/blue<SET> (rule-lfn441bq:S) [latest-23078]2023-03-26T22:31:38.949Z <ZWaveJSController:INFO> ZWaveJSController#zwavejs performing zwave_device.set_config on Switch#zwavejs>128-0 with [Object]{ "parameter": "9", "size": 1, "value": 1, "bitmask": 0 } [latest-23078]2023-03-26T22:31:38.956Z <HassController:INFO> HassController#hass action x_hass_input_text.set_value([Object]{ "value": "Open" }) on Entity#hass>input_text_h_door_sensors_state succeeded [latest-23078]2023-03-26T22:31:38.957Z <Engine:INFO> Resuming reaction Door Sensors State<SET> (rule-lerjv6if:S) from step 1 [latest-23078]2023-03-26T22:31:38.958Z <Engine:INFO> Door Sensors State<SET> all actions completed. [latest-23078]2023-03-26T22:31:39.284Z <Engine:INFO> Resuming reaction Toggle Vestibule scene 003 LED color state between green/blue<SET> (rule-lfn441bq:S) from step 2 [latest-23078]2023-03-26T22:31:39.284Z <Engine:INFO> Toggle Vestibule scene 003 LED color state between green/blue<SET> all actions completed. [latest-23078]2023-03-26T22:31:39.530Z <HassController:INFO> HassController#hass action x_hass_siren.turn_on([Object]{ "tone": "30" }) on Entity#hass>siren_siren_8 succeeded [latest-23078]2023-03-26T22:31:39.531Z <Engine:INFO> Resuming reaction Notification: Home Security - Garage side door just opened (Disarmed Only)<SET> (rule-lbmoup28:S) from step 2 [latest-23078]2023-03-26T22:31:39.531Z <Engine:INFO> Notification: Home Security - Garage side door just opened (Disarmed Only)<SET> all actions completed. [latest-23078]2023-03-26T22:31:40.341Z <Rule:INFO> Notification: Home Security - Open/close water main shut-off valve (rule-kvo8us5v in Notifications) starting evaluation; because entity-changed BinarySensor#hass>binary_sensor_siren_siren_active_8 [latest-23078]2023-03-26T22:31:40.351Z <Rule:INFO> Notification: Home Security - Open/close water main shut-off valve (rule-kvo8us5v in Notifications) trigger evaluation result is false (previously false) [latest-23078]2023-03-26T22:31:40.352Z <Rule:INFO> Notification: Home Security - Open/close water main shut-off valve (rule-kvo8us5v in Notifications) evaluated; trigger state unchanged (false); rule state remains RESET [latest-23078]2023-03-26T22:31:40.353Z <Rule:INFO> Notification: Home Security - Open/close water main shut-off valve (rule-kvo8us5v in Notifications) evaluation complete [latest-23078]2023-03-26T22:31:40.645Z <Rule:INFO> Notification: Home Security - Open/close water main shut-off valve (rule-kvo8us5v in Notifications) starting evaluation; because entity-changed Group#groups>water_leak_detected [latest-23078]2023-03-26T22:31:40.654Z <Rule:INFO> Notification: Home Security - Open/close water main shut-off valve (rule-kvo8us5v in Notifications) trigger evaluation result is false (previously false) [latest-23078]2023-03-26T22:31:40.654Z <Rule:INFO> Notification: Home Security - Open/close water main shut-off valve (rule-kvo8us5v in Notifications) evaluated; trigger state unchanged (false); rule state remains RESET [latest-23078]2023-03-26T22:31:40.655Z <Rule:INFO> Notification: Home Security - Open/close water main shut-off valve (rule-kvo8us5v in Notifications) evaluation complete [latest-23078]2023-03-26T22:31:41.311Z <Rule:INFO> Any door open? (rule-lfn41thm in Home Security) starting evaluation; because entity-changed BinarySensor#hass>binary_sensor_garage_side_door_openclose_window_door_is_open [latest-23078]2023-03-26T22:31:41.312Z <Rule:INFO> Door Sensors State (rule-lerjv6if in Control Room) starting evaluation; because entity-changed BinarySensor#hass>binary_sensor_garage_side_door_openclose_window_door_is_open [latest-23078]2023-03-26T22:31:41.313Z <Rule:INFO> Notification: Home Security - Garage side door just opened (Disarmed Only) (rule-lbmoup28 in Notifications) starting evaluation; because entity-changed BinarySensor#hass>binary_sensor_garage_side_door_openclose_window_door_is_open [latest-23078]2023-03-26T22:31:41.315Z <Rule:INFO> Any door open? (rule-lfn41thm in Home Security) trigger evaluation result is false (previously true) [latest-23078]2023-03-26T22:31:41.315Z <Rule:INFO> Any door open? (rule-lfn41thm in Home Security) evaluated; rule state transition from SET to RESET! [latest-23078]2023-03-26T22:31:41.327Z <Rule:INFO> Door Sensors State (rule-lerjv6if in Control Room) trigger evaluation result is false (previously true) [latest-23078]2023-03-26T22:31:41.327Z <Rule:INFO> Door Sensors State (rule-lerjv6if in Control Room) evaluated; rule state transition from SET to RESET! [latest-23078]2023-03-26T22:31:41.335Z <Rule:INFO> Notification: Home Security - Garage side door just opened (Disarmed Only) (rule-lbmoup28 in Notifications) trigger evaluation result is false (previously true) [latest-23078]2023-03-26T22:31:41.336Z <Rule:INFO> Notification: Home Security - Garage side door just opened (Disarmed Only) (rule-lbmoup28 in Notifications) evaluated; rule state transition from SET to RESET! [latest-23078]2023-03-26T22:31:41.343Z <Rule:INFO> Alarm triggered (rule-lbqu752y in Home Security) starting evaluation; because data-changed Data#states:cs-rule-lfn41thm [latest-23078]2023-03-26T22:31:41.343Z <Rule:INFO> Toggle Vestibule scene 003 LED color state between green/blue (rule-lfn441bq in Home Security) starting evaluation; because data-changed Data#states:cs-rule-lfn41thm [latest-23078]2023-03-26T22:31:41.344Z <Rule:INFO> Any door open? (rule-lfn41thm in Home Security) evaluation complete [latest-23078]2023-03-26T22:31:41.344Z <Rule:INFO> Door Sensors State (rule-lerjv6if in Control Room) evaluation complete [latest-23078]2023-03-26T22:31:41.344Z <Rule:INFO> Notification: Home Security - Garage side door just opened (Disarmed Only) (rule-lbmoup28 in Notifications) evaluation complete [latest-23078]2023-03-26T22:31:41.345Z <Rule:INFO> Alarm triggered (rule-lbqu752y in Home Security) trigger evaluation result is false (previously true) [latest-23078]2023-03-26T22:31:41.346Z <Rule:INFO> Alarm triggered (rule-lbqu752y in Home Security) evaluated; trigger state changed (false), but rule state remains RESET [latest-23078]2023-03-26T22:31:41.347Z <Rule:INFO> Toggle Vestibule scene 003 LED color state between green/blue (rule-lfn441bq in Home Security) trigger evaluation result is false (previously true) [latest-23078]2023-03-26T22:31:41.348Z <Rule:INFO> Toggle Vestibule scene 003 LED color state between green/blue (rule-lfn441bq in Home Security) evaluated; rule state transition from SET to RESET! [latest-23078]2023-03-26T22:31:41.354Z <Rule:INFO> Alarm triggered (rule-lbqu752y in Home Security) evaluation complete [latest-23078]2023-03-26T22:31:41.355Z <Rule:INFO> Toggle Vestibule scene 003 LED color state between green/blue (rule-lfn441bq in Home Security) evaluation complete [latest-23078]2023-03-26T22:31:41.356Z <Engine:INFO> Enqueueing "Door Sensors State<RESET>" (rule-lerjv6if:R) [latest-23078]2023-03-26T22:31:41.357Z <Engine:INFO> Enqueueing "Notification: Home Security - Garage side door just opened (Disarmed Only)<RESET>" (rule-lbmoup28:R) [latest-23078]2023-03-26T22:31:41.360Z <Engine:INFO> Enqueueing "Toggle Vestibule scene 003 LED color state between green/blue<RESET>" (rule-lfn441bq:R) [latest-23078]2023-03-26T22:31:41.361Z <Engine:NOTICE> Starting reaction Door Sensors State<RESET> (rule-lerjv6if:R) [latest-23078]2023-03-26T22:31:41.363Z <Engine:NOTICE> Starting reaction Notification: Home Security - Garage side door just opened (Disarmed Only)<RESET> (rule-lbmoup28:R) [latest-23078]2023-03-26T22:31:41.365Z <Engine:NOTICE> Starting reaction Toggle Vestibule scene 003 LED color state between green/blue<RESET> (rule-lfn441bq:R) [latest-23078]2023-03-26T22:31:41.366Z <ZWaveJSController:INFO> ZWaveJSController#zwavejs performing zwave_device.set_config on Switch#zwavejs>128-0 with [Object]{ "parameter": "9", "size": 1, "value": 2, "bitmask": 0 } [latest-23078]2023-03-26T22:31:41.374Z <HassController:INFO> HassController#hass action x_hass_input_text.set_value([Object]{ "value": "Closed" }) on Entity#hass>input_text_h_door_sensors_state succeeded [latest-23078]2023-03-26T22:31:41.375Z <Engine:INFO> Resuming reaction Door Sensors State<RESET> (rule-lerjv6if:R) from step 1 [latest-23078]2023-03-26T22:31:41.375Z <Engine:INFO> Door Sensors State<RESET> all actions completed. [latest-23078]2023-03-26T22:31:41.497Z <Rule:INFO> Notification: Update Available - Home Assistant (rule-lbmnmfds in Notifications) starting evaluation; because entity-changed ValueSensor#hass>sensor_docker_hub [latest-23078]2023-03-26T22:31:41.498Z <Rule:INFO> Notification: Update Available - Home Assistant (rule-lbmnmfds in Notifications) trigger evaluation result is false (previously false) [latest-23078]2023-03-26T22:31:41.498Z <Rule:INFO> Notification: Update Available - Home Assistant (rule-lbmnmfds in Notifications) evaluated; trigger state unchanged (false); rule state remains RESET [latest-23078]2023-03-26T22:31:41.499Z <Rule:INFO> Notification: Update Available - Home Assistant (rule-lbmnmfds in Notifications) evaluation complete [latest-23078]2023-03-26T22:31:41.501Z <Rule:INFO> Notification: Update Available - Home Assistant (rule-lbmnmfds in Notifications) starting evaluation; because entity-changed BinarySensor#hass>binary_sensor_docker_hub_update_available [latest-23078]2023-03-26T22:31:41.502Z <Rule:INFO> Notification: Update Available - Home Assistant (rule-lbmnmfds in Notifications) trigger evaluation result is false (previously false) [latest-23078]2023-03-26T22:31:41.502Z <Rule:INFO> Notification: Update Available - Home Assistant (rule-lbmnmfds in Notifications) evaluated; trigger state unchanged (false); rule state remains RESET [latest-23078]2023-03-26T22:31:41.503Z <Rule:INFO> Notification: Update Available - Home Assistant (rule-lbmnmfds in Notifications) evaluation complete [latest-23078]2023-03-26T22:31:41.709Z <Engine:INFO> Resuming reaction Toggle Vestibule scene 003 LED color state between green/blue<RESET> (rule-lfn441bq:R) from step 2 [latest-23078]2023-03-26T22:31:41.709Z <Engine:INFO> Toggle Vestibule scene 003 LED color state between green/blue<RESET> all actions completed. [latest-23078]2023-03-26T22:31:49.669Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) starting evaluation; because entity-changed System#reactor_system>system [latest-23078]2023-03-26T22:31:49.670Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) trigger evaluation result is false (previously false) [latest-23078]2023-03-26T22:31:49.670Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) evaluated; trigger state unchanged (false); rule state remains RESET [latest-23078]2023-03-26T22:31:49.670Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) evaluation complete [latest-23078]2023-03-26T22:31:49.675Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) starting evaluation; because entity-changed System#reactor_system>system [latest-23078]2023-03-26T22:31:49.675Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) trigger evaluation result is false (previously false) [latest-23078]2023-03-26T22:31:49.676Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) evaluated; trigger state unchanged (false); rule state remains RESET [latest-23078]2023-03-26T22:31:49.676Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) evaluation complete [latest-23078]2023-03-26T22:31:49.678Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) starting evaluation; because entity-changed System#reactor_system>system [latest-23078]2023-03-26T22:31:49.679Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) trigger evaluation result is false (previously false) [latest-23078]2023-03-26T22:31:49.679Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) evaluated; trigger state unchanged (false); rule state remains RESET [latest-23078]2023-03-26T22:31:49.680Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) evaluation complete [latest-23078]2023-03-26T22:31:49.682Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) starting evaluation; because entity-changed System#reactor_system>system [latest-23078]2023-03-26T22:31:49.683Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) trigger evaluation result is false (previously false) [latest-23078]2023-03-26T22:31:49.683Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) evaluated; trigger state unchanged (false); rule state remains RESET [latest-23078]2023-03-26T22:31:49.683Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) evaluation complete [latest-23078]2023-03-26T22:31:52.484Z <Rule:INFO> Notification: Home Security - Open/close water main shut-off valve (rule-kvo8us5v in Notifications) starting evaluation; because entity-changed BinarySensor#hass>binary_sensor_siren_siren_active_8 [latest-23078]2023-03-26T22:31:52.485Z <Rule:INFO> Any door open? (rule-lfn41thm in Home Security) starting evaluation; because entity-changed BinarySensor#hass>binary_sensor_garage_side_door_openclose_window_door_is_open [latest-23078]2023-03-26T22:31:52.485Z <Rule:INFO> Door Sensors State (rule-lerjv6if in Control Room) starting evaluation; because entity-changed BinarySensor#hass>binary_sensor_garage_side_door_openclose_window_door_is_open [latest-23078]2023-03-26T22:31:52.486Z <Rule:INFO> Notification: Home Security - Garage side door just opened (Disarmed Only) (rule-lbmoup28 in Notifications) starting evaluation; because entity-changed BinarySensor#hass>binary_sensor_garage_side_door_openclose_window_door_is_open [latest-23078]2023-03-26T22:31:52.502Z <Rule:INFO> Notification: Home Security - Open/close water main shut-off valve (rule-kvo8us5v in Notifications) trigger evaluation result is false (previously false) [latest-23078]2023-03-26T22:31:52.502Z <Rule:INFO> Notification: Home Security - Open/close water main shut-off valve (rule-kvo8us5v in Notifications) evaluated; trigger state unchanged (false); rule state remains RESET [latest-23078]2023-03-26T22:31:52.505Z <Rule:INFO> Any door open? (rule-lfn41thm in Home Security) trigger evaluation result is true (previously false) [latest-23078]2023-03-26T22:31:52.505Z <Rule:INFO> Any door open? (rule-lfn41thm in Home Security) evaluated; rule state transition from RESET to SET! [latest-23078]2023-03-26T22:31:52.515Z <Rule:INFO> Door Sensors State (rule-lerjv6if in Control Room) trigger evaluation result is true (previously false) [latest-23078]2023-03-26T22:31:52.515Z <Rule:INFO> Door Sensors State (rule-lerjv6if in Control Room) evaluated; rule state transition from RESET to SET! [latest-23078]2023-03-26T22:31:52.524Z <Rule:INFO> Notification: Home Security - Garage side door just opened (Disarmed Only) (rule-lbmoup28 in Notifications) trigger evaluation result is true (previously false) [latest-23078]2023-03-26T22:31:52.525Z <Rule:INFO> Notification: Home Security - Garage side door just opened (Disarmed Only) (rule-lbmoup28 in Notifications) evaluated; rule state transition from RESET to SET! [latest-23078]2023-03-26T22:31:52.537Z <Rule:INFO> Notification: Home Security - Open/close water main shut-off valve (rule-kvo8us5v in Notifications) evaluation complete [latest-23078]2023-03-26T22:31:52.538Z <Rule:INFO> Alarm triggered (rule-lbqu752y in Home Security) starting evaluation; because data-changed Data#states:cs-rule-lfn41thm [latest-23078]2023-03-26T22:31:52.538Z <Rule:INFO> Toggle Vestibule scene 003 LED color state between green/blue (rule-lfn441bq in Home Security) starting evaluation; because data-changed Data#states:cs-rule-lfn41thm [latest-23078]2023-03-26T22:31:52.538Z <Rule:INFO> Any door open? (rule-lfn41thm in Home Security) evaluation complete [latest-23078]2023-03-26T22:31:52.538Z <Rule:INFO> Door Sensors State (rule-lerjv6if in Control Room) evaluation complete [latest-23078]2023-03-26T22:31:52.539Z <Rule:INFO> Notification: Home Security - Garage side door just opened (Disarmed Only) (rule-lbmoup28 in Notifications) evaluation complete [latest-23078]2023-03-26T22:31:52.540Z <HassController:INFO> HassController#hass action x_hass_siren.turn_off([Object]{ }) on Entity#hass>siren_siren_8 succeeded [latest-23078]2023-03-26T22:31:52.541Z <Rule:INFO> Alarm triggered (rule-lbqu752y in Home Security) trigger evaluation result is true (previously false) [latest-23078]2023-03-26T22:31:52.542Z <Rule:INFO> Alarm triggered (rule-lbqu752y in Home Security) constraints not met! [latest-23078]2023-03-26T22:31:52.542Z <Rule:INFO> Alarm triggered (rule-lbqu752y in Home Security) evaluated; trigger state changed (true), but rule state remains RESET [latest-23078]2023-03-26T22:31:52.544Z <Rule:INFO> Toggle Vestibule scene 003 LED color state between green/blue (rule-lfn441bq in Home Security) trigger evaluation result is true (previously false) [latest-23078]2023-03-26T22:31:52.544Z <Rule:INFO> Toggle Vestibule scene 003 LED color state between green/blue (rule-lfn441bq in Home Security) evaluated; rule state transition from RESET to SET! [latest-23078]2023-03-26T22:31:52.551Z <Rule:INFO> Alarm triggered (rule-lbqu752y in Home Security) evaluation complete [latest-23078]2023-03-26T22:31:52.552Z <Rule:INFO> Toggle Vestibule scene 003 LED color state between green/blue (rule-lfn441bq in Home Security) evaluation complete [latest-23078]2023-03-26T22:31:52.565Z <Engine:NOTICE> [Engine]Engine#1 entry 171 reaction rule-lbmoup28:R: [Error] terminated [-] [latest-23078]2023-03-26T22:31:52.565Z <Engine:CRIT> Error: terminated [-] Error: terminated at Engine._process_reaction_queue (/opt/reactor/server/lib/Engine.js:1555:47) at runMicrotasks (<anonymous>) at processTicksAndRejections (node:internal/process/task_queues:96:5) -
MSR: latest-23078-d592d400
--Docker image on unRAID
Hubitat: 2.3.5.121I was having an issue this morning where MSR wasn't seeing any hub updates from my Hubitat. In looking at the logs I was seeing pages of "reactor.log size hit rotation limit, rotating" messages. I purged these logs and restarted MSR thinking the logs were the cause of being stuck or something. I also changed the default from 2 MB and 5 logs to 3 MB and 9 logs. Long story short, that wasn't the issue and my HE needed a reboot. I had just rebooted a couple of days ago, so I didn't think that was the problem.
Back on topic here. Everything seems to be communicating and MSR is seeing the updates now, however I feel that my logs filled up way too fast. Granted 3 MB isn't very large these days. Is it normal to take about 45 minutes to fill up nine 3 MB log files? Or does this seem excessive? I only changed the size and qty in my logging.yaml file.
cedba928-6adc-4f24-be57-4fa4184e9128-image.png aa2c5edf-629f-45a3-8083-6f3dece48e05-image.png
-
@toggledbits said in Can I use Dynamic Group Control for Triggers and Reactions?:
Note that @gwp1 is using ZWaveJSController to interface with iBlinds, not HassController. So this is more direct control that circumvents HA's interpretation.
I saw that, but ZWaveJSController doesn't seem to be an option in my instance. I do use ZWaveJS UI on HA. What's the difference here?
Edit. I found it in your documentation. I tried installing it, but Reactor is telling me that the zwavejs controller is down. Do I need to do anything on Home Assistant to make it available?
d4f165eb-ba31-49e3-9f0c-ff49e4710f4e-image.png
The WS Server is enabled and set to port 3000. That's what I set up in my reactor.yaml file.
- id: zwavejs implementation: ZWaveJSController enabled: true config: source: ws://192.168.1.141:3000 # modify the IP address as needed;
Change in Plans (Don't Panic)
-
Everyone, I've had a change in thinking.
As many of you know, I had decided to not build an MSR interface for eZLO's new controllers, for multiple reasons, not the least of which was that I had chosen not to use an eZLO hub in my future HA. I am currently straddling three hubs: Vera, Home Assistant, and Hubitat. I am actually very much enjoying the flexibility this has provided. But these three hubs are enough for the moment, and when the venerable Vera Plus on which my house has operated since 2017 dies, I will likely just move the rest of my ZWave devices to the other hubs and reduce by one.
Another reason for my previous decision was the risk of fluidity/instability in the eZLO APIs. Since this is first generation work, and even now as they approach the three-year mark on development and are still in "beta" with much functionality still incomplete or missing altogether (plugin UI framework?... anyone? anyone?), it stands to reason that, like all projects in this phase in particular, choices are made that need to be revisited. To be fair, Hass and Hubitat are not immune from this either, even as much more mature products with greater market penetration. In any case, I've demurred because of the high perceived risk of change and breakage, and didn't want to put myself (again) on the critical path of my own user base waiting for me to catch up. I accept now, however, that events like this are just part and parcel of the environment in which I've chosen to work. As I said, if it's not eZLO changing something, it's going to be Hass, or something else. I haven't had a breaking change hit from the Hubitat side yet, but it's probably just a matter of time. Just as I seek to improve my work, they must seek to improve theirs.
The upshot is that I've decided to write an eZLO interface, and I've been working on that for a few days and now have a working prototype running. It works with the few devices I have available for it, and there's a lot that's assumed and untested about all the others. Think back to March, when MSR was first released -- the process of going through and stabilizing these interfaces under all the different external conditions, with devices in your environments that I don't, and sometimes cannot, have -- it takes time. Drilling out all of the details of device behaviors and data, and how each hub handles them differently, takes time. But it's going to be a reality. Aside from this, reading the other forums makes me realize just how much this is needed, if only because there appears as yet to be no articulated concrete plan (e.g. words beyond a promise with no date) to support easy migration from a Vera to an eZLO. MSR touts itself as a tool to assist such migrations between hubs. An eZLO interface must exist.
To set expectations: you'll see the first version of this interface in a build in the next couple of weeks. It will be an add-in. Like MSR itself, I will be limiting the initial audience, and those of you that participate in the early use and testing will be asked to provide lots of diagnostics and feedback (so please don't ask/participate if you're not willing and able to put in the time). It's brand new, unfinished work; there will be lots of bugs, and lots of holes, and it's going to take a lot to get them all squashed and filled, respectively.
Based on what I've learned so far from this project, I also want to forewarn you that it may include access to my cloud infrastructure for automatic logging (to make our mutual efforts to examine problems easier and faster), at least during the early stages. At the moment, MSR has no hard Internet-access dependencies, so this is a change for this interface work.
Also, I probably will ultimately be charging a modest monthly or annual subscription for the eZLO interface, which is a change from policy and practice to date. The amount of effort the project has demanded and can demand in future makes it necessary that I consider a business model. I know that gives some pause, but it should also give you confidence that I am thinking of a long-term future. But, those of you who, as of this writing, hold active accounts on the MSR bug tracker and have participated so valuably in the testing and improvement of MSR, are grand-fathered in to a perpetual (personal/non-commercial use) license to MSR and this interface (no fees, at least for what parts are produced by my hand; I cannot control what others may choose to do if/when third party development takes root). I am considering extending that benefit to everyone who has donated to my projects from the start to date; that is, including those who supported Reactor for Vera, without which MSR would never had been born.
I can probably predict from these forums and others who the active eZLO users are going to be, but if you want to work with me on it, please let me know by reply here. I will be relying on you heavily, because I am not going to be a big consumer of the hub, so a lot of the work will require data collected from you and your hub and investigative work on that evidence, rather than first-hand experience and witnessed events in my own environment. But I'm confident it will work, as much gets done this way already, and investing in more and deeper troubleshooting tools is always a good investment.
Thanks to all of you who have supported this project. Onward...
-
Looking forward to seeing the Ezlo version of MSR, I don't use the Ezlo hubs so I won't be able to contribute but with the addition of MSR it may make switching from my Vera Plus to an Ezlo controller a total possibility. I am sure MSR will become a staple for the platform just like how Reactor was in the Vera controllers. Good luck Patrick!!!
-
MSR has enabled me to explore Hubitat and I have been impressed with many features. Zigbee works much better and I have added devices that integrate well into my home control most of which is on VeraPlus. I am slowly moving to the VeraPlus just hosting the devices with most of the control through MR.
I pay for Altui and was thinking the other day I would not be opposed to a subscription plan for MSR as it is more valuable to me than Altui.
I was thinking about playing with Home Assistant but could pick up an ezlo plus controller if you are looking for guinea pigs. I could certainly give you the view of someone who just knows enough to be dangerous.
Thanks for all your work helping folks realize their home automation dreams. -
@Pabla To be clear, MSR will not run on the eZLO hub, just as it does not run on Hubitat or Vera. MSR will always run on independent hardware (Hass can be an exception because you are in control of the host hardware). So if you're running MSR on Synology, RPI, or your favorite Linux or Windows host, it will interface with eZLO in exactly the same way that it does with Vera, Hass, and Hubitat.
-
@toggledbits Ah yes that's what I mean't
-
My Ezlo+ is collecting dust right now, my system has been more stable than ever with the HA-MSR-Vera system I'm running at the moment.
-
I have an Ezlo Plus and an Ezlo Atom. On the Elzo Plus I have lots of devices on there, however most of them are emulated virtual devices mirrored from the "real" devices on my production Vera Plus, this was done using Rene's 3rd party Vera to Ezlo bridge plugin.
I do also have some real Z-Wave devices paired directly to the Ezlo Plus hub.
I would be happy to help test this new MSR interface and I am very happy to see you have decided to make it. This is a massive boost for Ezlo themselves in my opinion as they currently have no native logic rules engine of their own.
The "rule sets" in the beta Ezlo web GUI are basic and pretty much Vera scenes you would find in the Vera mobile app and only have a little improvement thus far, for example we now have basic AND / OR however in these scenes, which we never had on the Vera firmware hubs.
PM me if you want direct access to my Ezlo Plus controller happy for you to poke around and have a look at it.
-
@toggledbits I bought 2 test controllers a while back, and I would be more than happy to help any way I can.
Do you have any idea what use case/device interaction scope would look like to give you the data you need?
I am pretty flexible over here...
-
@toggledbits I’m so thankful for the time and effort you put into MSR so the least I can do is give something back. I’d love to participate with my Ezlo Plus running about 20 zigbee devices in production, the logic is already in MSR so switching to a new interface would be easy for testing.
-
Thanks to all who have replied/volunteered. Variety of devices is key, so anything and everything is helpful. As you may have seen in these forums, even several months into fairly stable integrations for the other hubs, devices keep popping up with little exceptions or gaps in completion. More data is better is less. All of the interfaces drop files in the
logs
folder at the moment that I can use for fairly good diagnostics and forensics, so that theme will continue and get some embellishments for eZLO.I expect the first wave of testing will just be "look and see"... do the devices come in as correct MSR entities, do they have their correct attributes, and are they correctly identified and, where appropriate, assigned sensible system capabilities (in addition to extension capabilities of the
x_ezlo_etc
variety). Startup configuration is also always a first-level challenge, and in this case, we'll have two different options: secured access (login through eZLO's cloud to get a local access token), and unsecured access (secured access can be disabled on the hub, eliminating the need for cloud login/token requests to get local access to the hub). Login + attributes will enable all of the rule/condition capabilities automatically. The second wave will follow immediately (as in with the next breath) to see that actions work and to what extent they need extension or repair, and that completes reactions. Things converged pretty quickly with the other three interfaces, so I'm hopeful this can be highly functional in short order. -
I have a VeraPlus (daily driver), another VeraPlus (used/spare), an eZLO Atom 2.0 (unused), Vera Edge running the LInux f/w (unused), an eZLO Plus (beta testing / unused) and an old Vera 1 (connected / idle) divided among two different residences.
@toggledbits , surely others have made a similar offer by now, so I presume you are "set" for want of controllers -- but IF you require any of these for use in-house, just ask and I'll happily ship/donate.
Likewise, IF you need me to test some particular thing out from my side (Synology NAS > Docker > MSR > hub(s)), also just ask. Who knows, it might be the first/last thing I ever do with eZLO hardware, which otherwise is going in the trash at some point.
Glad you made this decision; I was concerned that you might inadvertently wind up with spare time on your hands. Oh, and THANK YOU for so thoughtfully grandfathering those who've toiled in the trenches alongside you lo these many weeks and months. For that you will not be sorry.
- Libra
-
@librasun I actually have a pretty big fist full of controllers myself. It's not really controllers I'm wanting for, it's devices and environments. The more hands this touches that aren't mine, the more things break, and the better things get for it. Hold on to them!
@librasun said in Change in Plans (Don't Panic):
Who knows, it might be the first/last thing I ever do with eZLO hardware, which otherwise is going in the trash at some point.
I absolutely doubt most users of the Atom or PlugHub would be a user of MSR (except in some fringe cases, like for an out-building). But those eZLO Plus's (in full or prototype/skeletal form) could be useful. They seem to have a similar architecture to the Raspberry Pi 4. Maybe once I get the ZWaveJS interface fleshed out (that's also been in the works), I can just publish an MSR replacement firmware for the Plus hardware. You know, for science.
-
@toggledbits said in Change in Plans (Don't Panic):
can just publish an MSR replacement firmware for the Plus hardware. You know, for science
So would it also act as a Z-Wave radio?
Or would you still need another second hub like Vera or the Ezlo or Hubitat etc, to act as the Z-Wave controller?
-
ZWaveJS would just talk to the on-board ZWave chip (via a serial/USB interface). Vera works the same way. So, yes, it would function as the ZWave radio in addition to being the rules engine.
-
So an all in one controller then!
Might have to get my hands on another Ezlo Plus hub, so I can test both setups, native Ezlo or MSR with Z-Wave JS.
-
@toggledbits said in Change in Plans (Don't Panic):
So, yes, it would function as the ZWave radio in addition to being the rules engine.
Looking forward to this, so I could add openluup to the mix and call it a day
-
I have a plus, but not many devices on it. I use it for broad link as i could not get the broadlink2 plugin working on openloop. will to test though. Like the idea of Zwavejs, love science.
-
I have as many before me, a Ezlo Plus laying around, and collecting dust. I've been waiting for a good reason to use it. When I got the Ezlo Plus, and I heard of the new Z-wave standard with better range I went really hopeful. Combined with MSR it looked like a winning concept. But the lack of stabilty, a working UI, and non-beta made me loose interest. If I can contribute in any way, I'd be honoured.
-
While I think a complete replacement firmware would be a fun exercise (and very possibly useful), we already have shown with openLuup and MSR that a Vera on its own is pretty stable in a reduced role as a ZWave radio and little else. So far my testing with the eZLO hub is yielding similar results, with the added benefit that it's demonstrably more stable when ZWave devices become unreachable (the Achilles Heel of current Vera firmware). I suspect we'll find that MSR running on a Pi, NAS, or other host against an eZLO hub still on its native firmware gives almost all of the benefits, without the need to replace the firmware on the hub itself. It will be fun to try it both ways, but I suspect that the simplest solution is going to be the best. And it will be here in a few days, where figuring out the firmware replacement will likely take a good bit more effort (and so is not really a goal, currently, just more of an experiment for a future weekend).
-
Hi,
I have already commented on the other forum that my VeraPlus was saved from an incinerator or the tires of my car a few times, thanks to Reactor, and gained new life with MSR, so Patrick you know that you have in my person a collaborator (with limitations of technical knowledge), but a person who likes to explore and especially give suggestions that help users.
But, in my humble opinion, I will not make the mistake of buying an eZLO, I am seriously considering investing now in a Hubitat because I am tired of my VeraPlus being incompatible with any ZegBee or other devices with S2. The eZLO developers should follow the same line of not listening to the 3PP, the independent developers, and go back to repeating Vera's mistakes in my opinion.
This way I recognize your huge effort for the HA community, I am sure you have done a lot but in this new eZLO endeavor I will not be able to help, count me full on MSR for VeraPlus and Hubitat.