Hi, @toggledbits!
I have a question about the execution behavior. See the code below, and I'll explain the situation.
12957c3e-ff06-46c9-929d-b53f936665df-image.png
This is a routine that, at a certain point, determines that the desktop on which the VM hosting the Reactor is located receives an instruction to perform a shutdown (Shell Command).
When this happens, the desktop is turned off, and then Hubitat detects by a "ping" that the VM has been down, waits 15 seconds, turns off the power to this desktop, and then 15 seconds later turns on the desktop with the Reactor VM again.
After restarting the desktop, the VM is loaded, and the Reactor is triggered. Still, the following problem occurs: I expected that when the rule was continued to be executed again, the next step would be executed, that of the 900-second delay after shutdown, but the Shell command is executed again, and then it goes into a loop, the rule does not advance.
To break the loop, I first have to make the VM not load, change the desktop password, and then start the VM. In this case, Reactor generates an error when trying to execute the Shell Command because of the invalid password and then finishes the routine following the 900 delay step.
b58b0d4a-d6c1-4fe3-bab7-4222acea9607-image.png
Is my interpretation that when it returns, the routine should continue to the next step that has not yet been executed incorrectly? Or does Reactor, through the shutdown command, interpret that it hasn't finished this step and keep trying, which is the correct reaction?
Thanks for clarifying.
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 @toggledbits ,
I'm slowly moving my ZWave network from Vera to ZWaveJS. I successfully cloned my ZWave network using a spare Vera Edge (a new post for the community later when I'll be fully back from vacation) and I'm testing a couple of things before moving everything to ZWaveJS.
In the meanwhile, I have a couple of venetian blinds connected to Fibaro Roller Shutters 2 (FGR222) and I'm using some proprietary ZWave commands to control the tilt position, that right now I'm sending via Vera (with some code from the old place, messing with this):
af7f883c-f49e-419c-a2fe-8669572e3792-image.png
The ZWaveJS values are reported via this:
x_zwave_values.Manufacturer_Proprietary_fibaro_venetianBlindsPosition=0 x_zwave_values.Manufacturer_Proprietary_fibaro_venetianBlindsTilt=0I hope there's a way to expose a separate device to control the tilt position directly, without doing the mess I'm doing now. Let me know if you need some files. Thanks.
As per @toggledbits request, new topic.
Position and cover commands not working and position/cover attributes are incorrect. Dimming is OK.
cover.state=null dimming.level=1 dimming.step=0.1 energy_sensor.units="kWh" energy_sensor.value=0.41 position.value=null power_sensor.units="W" power_sensor.value=0 power_switch.state=true x_debug.dt={"entity_class":"Cover","match":"deviceClass.generic.key=17;deviceClass.specific.key=6","capabilities":["cover","toggle","position"],"primary_attribute":"cover.state"} x_zwave_values.Meter_reset=null x_zwave_values.Meter_value_65537=0.41 x_zwave_values.Meter_value_66049=0 x_zwave_values.Multilevel_Switch_Down=null x_zwave_values.Multilevel_Switch_Up=null x_zwave_values.Multilevel_Switch_currentValue=99 x_zwave_values.Multilevel_Switch_duration="unknown" x_zwave_values.Multilevel_Switch_restorePrevious=null x_zwave_values.Multilevel_Switch_targetValue=99 x_zwave_values.Notification_Power_Management_Over_current_status=0 x_zwave_values.Notification_System_Hardware_status=0 x_zwave_values.Notification_alarmLevel=null x_zwave_values.Notification_alarmType=null zwave_device.capabilities=[38,50,113] zwave_device.endpoint=1 zwave_device.failed=null zwave_device.impl_sig="24225:1:22315:1" zwave_device.manufacturer_info=null zwave_device.node_id=148 zwave_device.version_info=nullThanks!
Another one for you, @toggledbits.
I have two water sensors (same device, NAS-WS01Z), but one is reporting leak_detector.state=true even if no alarm is detected (I double checked from ZWaveJS UI):
battery_power.level=0.86 battery_power.since=null leak_detector.state=true x_debug.dt={"entity_class":"Notification Sensor","match":"deviceClass.generic.key=7"} x_zwave_values.Battery_isLow=false x_zwave_values.Battery_level=86 x_zwave_values.Binary_Sensor_Water=false x_zwave_values.Configuration_Alarm_Activity_Duration=5 x_zwave_values.Configuration_Alarm_Beep=1 x_zwave_values.Configuration_Alarm_Duration=120 x_zwave_values.Configuration_Alarm_Interval=null x_zwave_values.Configuration_Basic_Set_Level=255 x_zwave_values.Configuration_First_Alarm_Activity_Duration=null x_zwave_values.Configuration_Water_Detection=1 x_zwave_values.Manufacturer_Specific_manufacturerId=600 x_zwave_values.Manufacturer_Specific_productId=4229 x_zwave_values.Manufacturer_Specific_productType=3 x_zwave_values.Notification_Water_Alarm_Sensor_status=null x_zwave_values.Notification_alarmLevel=0 x_zwave_values.Notification_alarmType=0 x_zwave_values.Version_firmwareVersions=null x_zwave_values.Version_hardwareVersion=null x_zwave_values.Version_libraryType=null x_zwave_values.Version_protocolVersion=null x_zwave_values.Wake_Up_controllerNodeId=1 x_zwave_values.Wake_Up_wakeUpInterval=43200 zwave_device.capabilities=[48,112,113,114,128,132,134] zwave_device.endpoint=0 zwave_device.failed=false zwave_device.generic_class="Notification Sensor" zwave_device.impl_sig="24225:1:22315:1" zwave_device.is_beaming=false zwave_device.is_listening=false zwave_device.is_routing=true zwave_device.is_secure=false zwave_device.last_wakeup=1724143899220 zwave_device.manufacturer_info=[600,3,4229] zwave_device.max_data_rate=null zwave_device.node_id=114 zwave_device.specific_class="Notification Sensor" zwave_device.status=1 zwave_device.status_text="asleep" zwave_device.version_info=[null,null] zwave_device.wakeup_interval=43200here's the other one, correctly report the leak status:
battery_power.level=1 battery_power.since=null leak_detector.state=false x_debug.dt={"entity_class":"Notification Sensor","match":"deviceClass.generic.key=7"} x_zwave_values.Battery_isLow=false x_zwave_values.Battery_level=100 x_zwave_values.Binary_Sensor_Water=false x_zwave_values.Configuration_Alarm_Activity_Duration=5 x_zwave_values.Configuration_Alarm_Beep=1 x_zwave_values.Configuration_Alarm_Duration=120 x_zwave_values.Configuration_Alarm_Interval=1 x_zwave_values.Configuration_Basic_Set_Level=255 x_zwave_values.Configuration_First_Alarm_Activity_Duration=60 x_zwave_values.Configuration_Water_Detection=1 x_zwave_values.Manufacturer_Specific_manufacturerId=600 x_zwave_values.Manufacturer_Specific_productId=4229 x_zwave_values.Manufacturer_Specific_productType=3 x_zwave_values.Notification_Water_Alarm_Sensor_status=0 x_zwave_values.Notification_alarmLevel=null x_zwave_values.Notification_alarmType=null x_zwave_values.Version_firmwareVersions=["2.54"] x_zwave_values.Version_hardwareVersion=48 x_zwave_values.Version_libraryType=6 x_zwave_values.Version_protocolVersion="4.5" x_zwave_values.Wake_Up_controllerNodeId=1 x_zwave_values.Wake_Up_wakeUpInterval=43200 zwave_device.capabilities=[48,112,113,114,128,132,134] zwave_device.endpoint=0 zwave_device.failed=false zwave_device.generic_class="Notification Sensor" zwave_device.impl_sig="24225:1:22315:1" zwave_device.is_beaming=false zwave_device.is_listening=false zwave_device.is_routing=true zwave_device.is_secure=false zwave_device.last_wakeup=1724105239533 zwave_device.manufacturer_info=[600,3,4229] zwave_device.max_data_rate=null zwave_device.node_id=113 zwave_device.specific_class="Notification Sensor" zwave_device.status=1 zwave_device.status_text="asleep" zwave_device.version_info=[null,"2.54"] zwave_device.wakeup_interval=43200Also, both seems to have no primary value. Thanks.
Good morning,
I have a service MQTT service that needs a restart occasionally. The add-on (Smartbed MQTT) is for the smart bed base for my bed. It has a "safety light" that I can control from HAAS & MSR as a light entity, and also moves the head of the bed to a preset at bedtime, and then lies it back flat in the morning The problem is, from time to time, the light becomes "unavailable" Restarting from the Add-ons tab in HAAS always fixes it, but I should be able to detect when it happens when "light.tempur_pedic_safety_lights" is not true or false, i.e., unavailable.
What I don't know how to do is how to restart that service. Does anybody have experience in restarting add-ons from MSR?
Running:
Reactor (Multi-hub) latest-24212-3ce15e25 ZWaveJSController [0.1.24232]HAAS:
RPi5-64 (8GB) Core 2024.7.3 Supervisor 2024.08.0 Operating System 13.0 Frontend 20240710.0Hi-
I have an android media player entity publishing from HA. I watch for changes in transport state and media title to trigger some actions.
Though those attributes report as expected, the set rule is being throttled for possible flapping.
There is an attribute for media position that continually updates, I suspect it is causing the evaluations to run constantly.
The workaround I am seeking is to ignore those attributes in HA or MSR. Anyone know how, or have a better idea??
Thx
Btw- this problem has spanned versions of HA and reactor, but I am current on both. Too current on HA for transparency, but the issue has survived several updates.
Referencing an expression inside a reaction is in the form of ${{ expression }}. When referenced inside my shell command to set the watering delay duration for my Rachio sprinkler system, it just does not work.
If I enter "86400" instead of referencing the expression lWateringDelayDuration, it works. Either I am doing something wrong or referencing an expression inside a shell command is not supported.
Reactor version: 24212
Local Expression
lWateringDelayDuration =
Setting Reaction using Shell command
curl -X PUT -H "Content-Type: application/json" -H "Authorization: Bearer xxxxxxxxxx -d '{ "id" : "xxxxxxxxxx", "duration" : ${{ lWateringDelayDuration}} }' https://api.rach.io/1/public/device/rain_delayThanks in advance
As per @toggledbits request, here's a new topic.
My Fibaro Door Window Sensor 2 (FGDW002) is always reporting as open, even if
x_zwave_values.Notification_Access_Control_Door_state=23 x_zwave_values.Notification_Access_Control_Door_state_simple=23which means that the door is closed. It was working before and I could downgrade to test, if necessary. Thanks.
Hi @toggledbits,
I'm not sure if it's a bug or something, but I have a lot of Fibaro Double Switch (FGS223) as follows.
In the example, it's zwavejs>65-2:
energy_sensor.units="kWh" energy_sensor.value=0.21 power_sensor.units="W" power_sensor.value=0 power_switch.state=false x_debug.dt={"entity_class":"Switch","match":"deviceClass.generic.key=16","capabilities":["power_switch","toggle"],"primary_attribute":"power_switch.state"} x_zwave_values.Binary_Switch_currentValue=false x_zwave_values.Binary_Switch_targetValue=false x_zwave_values.Meter_reset=null x_zwave_values.Meter_value_65537=0.21 x_zwave_values.Meter_value_66049=0 zwave_device.capabilities=[37,50] zwave_device.endpoint=2 zwave_device.failed=null zwave_device.impl_sig="23326:1:22315:1" zwave_device.manufacturer_info=null zwave_device.node_id=65 zwave_device.version_info=nullWhen operating endpoint 2, it's triggered endpoint 1. Endpoint 1 is fine. This is causing a lot of troubles, as you may imagine.
Also, endpoint 0 is not really a switch, and the associated actions are not doing anything at all. Maybe these could be removed. Also, I see battery_maintenance and power_source capabilities, all with null values.
battery_maintenance.charging=null battery_maintenance.rechargeable=false battery_maintenance.replace=false battery_maintenance.state=null heat_detector.state=false power_source.source=null power_switch.state=null x_debug.dt={"entity_class":"Switch","match":"deviceClass.generic.key=16","capabilities":["power_switch","toggle"],"primary_attribute":"power_switch.state","description":"Double Switch 2","model":"FGS223","default_name":"Double Switch 2","manufacturerId":271,"productType":515,"productId":4096} x_zwave_values.Central_Scene_scene_001=null x_zwave_values.Central_Scene_scene_002=null x_zwave_values.Central_Scene_slowRefresh=null x_zwave_values.Configuration_First_Channel_Energy_Reports_Threshold=100 x_zwave_values.Configuration_First_Channel_Operating_Mode=0 x_zwave_values.Configuration_First_Channel_Power_Reports_Minimum_Time_Between_Reports=10 x_zwave_values.Configuration_First_Channel_Power_Reports_Threshold=20 x_zwave_values.Configuration_First_Channel_Pulse_Time_for_Blink_Mode=5 x_zwave_values.Configuration_First_Channel_Reaction_to_Key_S1_for_Delay_Auto_ON_OFF_Modes=0 x_zwave_values.Configuration_First_Channel_Time_Parameter_for_Delay_Auto_ON_OFF_Modes=50 x_zwave_values.Configuration_General_Purpose_Alarm_Response=3 x_zwave_values.Configuration_Include_Consumption_By_Device_Itself_in_Reports=0 x_zwave_values.Configuration_Input_Button_Switch_Configuration=2 x_zwave_values.Configuration_Key_S1_Associations_Double_Click_Value_Sent=99 x_zwave_values.Configuration_Key_S1_Associations_Send_OFF_With_Single_Click_2=0 x_zwave_values.Configuration_Key_S1_Associations_Send_ON_With_Single_Click_1=0 x_zwave_values.Configuration_Key_S1_Associations_Send_When_Double_Clicking_8=0 x_zwave_values.Configuration_Key_S1_Associations_Send_When_Holding_and_Releasing_4=0 x_zwave_values.Configuration_Key_S1_Associations_Switch_OFF_Value_Sent=0 x_zwave_values.Configuration_Key_S1_Associations_Switch_ON_Value_Sent=255 x_zwave_values.Configuration_Key_S1_Send_Scenes_When_Held_Down_and_Released_8=1 x_zwave_values.Configuration_Key_S1_Send_Scenes_When_Pressed_1_Time_1=1 x_zwave_values.Configuration_Key_S1_Send_Scenes_When_Pressed_2_Times_2=1 x_zwave_values.Configuration_Key_S1_Send_Scenes_When_Pressed_3_Times_4=1 x_zwave_values.Configuration_Key_S2_Associations_Double_Click_Value_Sent=99 x_zwave_values.Configuration_Key_S2_Associations_Send_OFF_With_Single_Click_2=0 x_zwave_values.Configuration_Key_S2_Associations_Send_ON_With_Single_Click_1=0 x_zwave_values.Configuration_Key_S2_Associations_Send_When_Double_Clicking_8=0 x_zwave_values.Configuration_Key_S2_Associations_Send_When_Holding_and_Releasing_4=0 x_zwave_values.Configuration_Key_S2_Associations_Switch_OFF_Value_Sent=0 x_zwave_values.Configuration_Key_S2_Associations_Switch_ON_Value_Sent=255 x_zwave_values.Configuration_Key_S2_Send_Scenes_When_Held_Down_and_Released_8=1 x_zwave_values.Configuration_Key_S2_Send_Scenes_When_Pressed_1_Time_1=1 x_zwave_values.Configuration_Key_S2_Send_Scenes_When_Pressed_2_Times_2=1 x_zwave_values.Configuration_Key_S2_Send_Scenes_When_Pressed_3_Times_4=1 x_zwave_values.Configuration_Periodic_Active_Power_Reports=3600 x_zwave_values.Configuration_Periodic_Energy_Reports=3600 x_zwave_values.Configuration_Report_During_Blink_Mode=0 x_zwave_values.Configuration_Second_Channel_Energy_Reports_Threshold=100 x_zwave_values.Configuration_Second_Channel_Operating_Mode=0 x_zwave_values.Configuration_Second_Channel_Power_Reports_Minimum_Time_Between_Reports=10 x_zwave_values.Configuration_Second_Channel_Power_Reports_Threshold=20 x_zwave_values.Configuration_Second_Channel_Pulse_Time_for_Blink_Mode=5 x_zwave_values.Configuration_Second_Channel_Reaction_to_Key_S2_for_Delay_Auto_ON_OFF_Modes=0 x_zwave_values.Configuration_Second_Channel_Time_Parameter_for_Delay_Auto_ON_OFF_Modes=50 x_zwave_values.Configuration_Send_Secure_Commands_to_2nd_Association_Group_1=1 x_zwave_values.Configuration_Send_Secure_Commands_to_3rd_Association_Group_2=1 x_zwave_values.Configuration_Send_Secure_Commands_to_4th_Association_Group_4=1 x_zwave_values.Configuration_Send_Secure_Commands_to_5th_Association_Group_8=1 x_zwave_values.Configuration_Smoke_CO_or_CO2_Alarm_Response=3 x_zwave_values.Configuration_State_After_Power_Failure=1 x_zwave_values.Configuration_Temperature_Alarm_Response=1 x_zwave_values.Configuration_Time_of_Alarm_State=600 x_zwave_values.Configuration_Water_Flood_Alarm_Response=2 x_zwave_values.Manufacturer_Specific_manufacturerId=271 x_zwave_values.Manufacturer_Specific_productId=4096 x_zwave_values.Manufacturer_Specific_productType=515 x_zwave_values.Notification_Heat_Alarm_Heat_sensor_status=0 x_zwave_values.Notification_Power_Management_Over_current_status=0 x_zwave_values.Notification_alarmLevel=null x_zwave_values.Notification_alarmType=null x_zwave_values.Protection_exclusiveControlNodeId=null x_zwave_values.Protection_local=0 x_zwave_values.Protection_rf=0 x_zwave_values.Protection_timeout=null x_zwave_values.Version_firmwareVersions=["3.2"] x_zwave_values.Version_hardwareVersion=3 x_zwave_values.Version_libraryType=3 x_zwave_values.Version_protocolVersion="4.5" zwave_device.capabilities=[91,112,113,114,117,134] zwave_device.endpoint=0 zwave_device.failed=false zwave_device.generic_class="Binary Switch" zwave_device.impl_sig="23326:1:22315:1" zwave_device.is_beaming=false zwave_device.is_listening=true zwave_device.is_routing=true zwave_device.is_secure=false zwave_device.manufacturer_info=[271,515,4096] zwave_device.max_data_rate=null zwave_device.node_id=65 zwave_device.specific_class="Binary Power Switch" zwave_device.status=4 zwave_device.status_text="alive" zwave_device.version_info=[null,"3.2"]Thanks.
Good morning,
I'm having an issue with controlling my Zooz Zen14 outdoor double outlet. I should be able to control each outlet individually, and this does work when use Home Assistant (haas) from Reactor.
When I use zwavejs, I see 3 entries:
8305eccf-a99e-421f-ad18-1f08da9c8c9c-image.png
The first entry is for the overall device. I can turn both outlets on and off (in theory) by setting the power_switch state to on or off. This does turn them on and off when using zwavejs.
When I go to the individual outlets, performing the power_switch.on or power_switch.off actions turns them all (main, 1 and 2) on or off, and not just the individual outlets. When I perform the same action from haas, turning on outlet 1 will turn on the main switch and 1, but not 2.
I reviewed the logs for that node and I'm not seeing anything obvious.
:~/reactor/logs$ cat reactor.log.1 | grep ZWaveJSController#zwavejs | grep "node 216" [latest-24212]2024-08-07T00:19:00.233Z <ZWaveJSController:INFO> ZWaveJSController#zwavejs update node 216 value "0:37:targetValue:" data [Object]{ "source": "node", "event": "value updated", "nodeId": 216, "args": { "commandClassName": "Binary Switch", "commandClass": 37, "endpoint": 0, "property": "targetValue", "newValue": true, "prevValue": false, "propertyName": "targetValue" } } [latest-24212]2024-08-07T00:19:00.235Z <ZWaveJSController:INFO> ZWaveJSController#zwavejs update node 216 value "0:37:currentValue:" data [Object]{ "source": "node", "event": "value updated", "nodeId": 216, "args": { "commandClassName": "Binary Switch", "commandClass": 37, "property": "currentValue", "endpoint": 0, "newValue": true, "prevValue": false, "propertyName": "currentValue" } } [latest-24212]2024-08-07T00:19:00.321Z <ZWaveJSController:INFO> ZWaveJSController#zwavejs update node 216 value "0:37:currentValue:" data [Object]{ "source": "node", "event": "value updated", "nodeId": 216, "args": { "commandClassName": "Binary Switch", "commandClass": 37, "property": "currentValue", "endpoint": 0, "newValue": true, "prevValue": true, "propertyName": "currentValue" } } [latest-24212]2024-08-07T00:19:00.322Z <ZWaveJSController:INFO> ZWaveJSController#zwavejs update node 216 value "0:37:targetValue:" data [Object]{ "source": "node", "event": "value updated", "nodeId": 216, "args": { "commandClassName": "Binary Switch", "commandClass": 37, "property": "targetValue", "endpoint": 0, "newValue": true, "prevValue": true, "propertyName": "targetValue" } } [latest-24212]2024-08-07T00:19:00.323Z <ZWaveJSController:INFO> ZWaveJSController#zwavejs update node 216 value "0:37:duration:" data [Object]{ "source": "node", "event": "value updated", "nodeId": 216, "args": { "commandClassName": "Binary Switch", "commandClass": 37, "property": "duration", "endpoint": 0, "newValue": { "value": 0, "unit": "seconds" }, "prevValue": { "value": 0, "unit": "seconds" }, "propertyName": "duration" } } [latest-24212]2024-08-07T00:19:02.189Z <ZWaveJSController:INFO> ZWaveJSController#zwavejs update node 216 value "1:37:currentValue:" data [Object]{ "source": "node", "event": "value updated", "nodeId": 216, "args": { "commandClassName": "Binary Switch", "commandClass": 37, "property": "currentValue", "endpoint": 1, "newValue": true, "prevValue": false, "propertyName": "currentValue" } } [latest-24212]2024-08-07T00:19:02.192Z <ZWaveJSController:INFO> ZWaveJSController#zwavejs update node 216 value "1:37:targetValue:" data [Object]{ "source": "node", "event": "value updated", "nodeId": 216, "args": { "commandClassName": "Binary Switch", "commandClass": 37, "property": "targetValue", "endpoint": 1, "newValue": true, "prevValue": false, "propertyName": "targetValue" } } [latest-24212]2024-08-07T00:19:02.193Z <ZWaveJSController:INFO> ZWaveJSController#zwavejs update node 216 value "1:37:duration:" data [Object]{ "source": "node", "event": "value updated", "nodeId": 216, "args": { "commandClassName": "Binary Switch", "commandClass": 37, "property": "duration", "endpoint": 1, "newValue": { "value": 0, "unit": "seconds" }, "prevValue": { "value": 0, "unit": "seconds" }, "propertyName": "duration" } } [latest-24212]2024-08-07T05:32:30.127Z <ZWaveJSController:INFO> ZWaveJSController#zwavejs configuring node 216 endpoint 0 (entity "216-0") [latest-24212]2024-08-07T05:32:30.127Z <ZWaveJSController:INFO> ZWaveJSController#zwavejs configuring node 216 endpoint 1 (entity "216-1") [latest-24212]2024-08-07T05:32:30.128Z <ZWaveJSController:INFO> ZWaveJSController#zwavejs configuring node 216 endpoint 2 (entity "216-2")I'm running:
Reactor (Multi-hub) latest-24212-3ce15e25
ZWaveJSController [0.1.23326] (with zwavejs_data from 7/25/2024)
HA:
Core 2024.7.3
Supervisor 2024.08.0
Operating System 12.3
Frontend 20240710.0
I think this feature request could be accomplished with the use of two or more rules, but it would be great if there was a way to wait for an event or trigger to occur before continuing on in the reactions.
For example, I have a rule that will turn on some exterior lights if you arrive home after the porch lights have been turned off. Right now this rule randomly will turn off between 5-10 minutes after the person has entered the geofence. On some occasions this 5-10 minutes isn't long enough, say if you are unloading the car or something. I would like to kick off the reaction, but pause it part way through and wait for the door to close and lock, then continue it on. Hubitat Rule Machine has a "Wait for event" option, but I really want to keep all my logic within MSR.
Hi,
Running the latest version 24212 on docker.
I want to run some appliances when my solar panels deliver over 1200 watts to the net. In this example the dryer. So when the dryer is turned on, the rule starts (SET). There first is a 3 min delay in case the dryer is turned on manually, that is group "Check if auto start is needed". If the dryer is not running, the status is set to waiting, and the shown Repeat Until should wait as long the power delivered is higher than -1200 for at least 120 seconds and the status is still waiting. Higher as the value is negative. For some reason that repeat until "DR Wait for solar high or manual start" looks skipped. Nothing in the logs. What am I missing?
Reactor Automation.png (g_DryerStatus should have been "waiting" and not "running" the moment the log was captured, so that should not be the issue. Unless it takes some time for a variable to actually change?)
Cheers Rene
I have got some warnings i reactor that a rule is throttled because it update rate is over 120/minute, happens now and when with a week or two in between.
The rule monitors my house power consumption when charging my car, and if if consumption risks to kill a main fuse, it stops the charging.
Thought I was clever when I in Constraints added that my car should be located at home and charging is active, but apparantly it wasn't clever enough...
I had understand it that if Constraints isn't true, then the triggers isn't evaluated.
I have a Shelly 3EM meter that measure three channel/phases and updates every second. So just for this three channels it is 180 updates per minute...
And now when I start to take a closer look I can se in my logs that this rule is evaluated with every value change on any of the three phases...
So ~11MB of logs only goes back in time around 16 hours...🙀
So what is the best solution?
Should move my "Constraints" in an new trigger group, before my existing triggers?
Rule as it is now
e5486a1b-7c3c-4ffc-b259-beed64948f2e-image.png
Hi!
I'm wondering if it's possible now, or if it's something that can be solved in a future version, to be able to remove the entities that no longer exist and are crossed out all at once. Currently, you have to mark them one by one, which takes a lot of time. Is there any way to make this more efficient?
I'm on MSR version 24212-3ce15e25.
Thanks!
/Fanan
I'm slowly migrating all my stuff to MQTT under MSR, so I have a central place to integrate everything (and, in a not-so-distant future, to remove virtual devices from my Vera and leave it running zwave only).
Anyway, here's my reactor-mqtt-contrib package:
![](https://github.com/fluidicon.png)
Contrib MQTT templates for Reactor. Contribute to dbochicchio/reactor-mqtt-contrib development by creating an account on GitHub.
Simply download yaml files (everything or just the ones you need) and you're good to go.
I have mapped my most useful devices, but I'll add others soon. Feel free to ask for specific templates, since I've worked a lot in the last weeks to understand and operate them.
The templates are supporting both init and query, so you have always up-to-date devices at startup, and the ability to poll them. Online status is supported as well, so you can get disconnected devices with a simple expression.
Many-many thanks to @toggledbits for its dedication, support, and patience with me and my requests 🙂
Good morning,
I'm trying to figure out if there is a way to evaluate if a command was completed and retry if it did not complete.
I have 14 iBlinds 3.1 z-wave controllers in my home. 95% of the time, they work just fine. Occasionally, I'll get a blind that does not open on the first attempt. When I go into Home Assistant, and manually open or close the blind, it works.
I have 3 reactions set up for each room. One to open, one to close, and one partial open for sun glare. Each of them is set up as below.
5afc9924-4300-4718-9e23-8855c4a3a9fd-image.png
The reactions are set up to wait for 5 seconds before going onto the next blind, so the z-wave network doesn't get overwhelmed.
In addition, the set command to run the reactions has "Wait for completion" checked.
3919fc06-c1f1-4c49-bf95-716028d18a27-image.png
I also have a routine set up whenever a z-wave device reports as non-functional (dead), it'll get pinged to wake it up. This usually works to wake them up.
16df4bff-c733-4ec2-a55c-c964238ada3b-image.png
Appreciate any ideas to make this more reliable.
I'm running:
Reactor latest-24190-bd310acc, Bare-metal on Fedora WaveJSController [0.1.23326] Home Assistant: 2024.7.0Reactor (Multi-System/Multi-Hub) Announcements
-
Reactor build 22274
ALL USERS -- IMPORTANT: If you are upgrading from any version earlier than 22256, please read the advisories and prerequisites for that build, below.
- HubitatController: Fix too-aggressive caching of entities that makes entity names too "sticky" when device name or label is changed on hub. Note that a particularity of Hubitat, unlike most other hubs currently supported, requires a soft restart of either the controller instance (using
sys_system.restart
on the HubitatController's system entity) or a restart of Reactor to "see" the rename (Hubitat does not send an event when a device is renamed, so Reactor can't know). - HassController: Bless Hass to 2022.9.7
- HubitatController: Fix too-aggressive caching of entities that makes entity names too "sticky" when device name or label is changed on hub. Note that a particularity of Hubitat, unlike most other hubs currently supported, requires a soft restart of either the controller instance (using
-
-
Reactor build 22291
ALL USERS -- IMPORTANT: If you are upgrading from any version earlier than 22256, please read the advisories and prerequisites for that build, below.
- HubitatController: Breaking change: Devices that use HE's PressureMeasurement capability will now report pressure on
pressure_sensor.value
rather than the genericvalue_sensor.value
. I'm not sure this is widely used if at all, so I chose to just make the breaking change rather than deprecate and hold on to the old behavior for months. - PR 0000283: Reactions Editor: allow drag-drop between groups. This still has some minor issues, but these are due to limitations/defects in jquery-ui (so we'll have to live with them for now).
- PR 0000334: Docs, fix an error in the example expression for metadata.
- HubitatController: Implement polling as a replacement for Hubitat's Z-Wave Poller app, which is widely reported to not work well (the author's own experience corroborates these reports). Polling is only needed for legacy Z-Wave devices that do not support instant status or some equivalent (hail, etc.) that Hubitat understands. [docs]
- DynamicGroupController: the
include_entity
andexclude_entity
selectors now can use a regular expression to match entity canonical IDs. [docs] - InfluxFeed: New advanced attribute handling key
skip_null
to suppress export of null measurement values; [docs] - Fix a sync issue in the UI when deleting entities that previously required a hard refresh of the browser.
- UI: Fixed alignment of icons and buttons for large items in the Alerts widget (Status page).
- Documentation: Updated documentation on building Controllers, and provided new example code (WhiteBITController).
- HassController: Tighten capabilities for voltage, current, energy, power, and humidity sensor types. If you have automations using temperature or humidity sensors in Hass, please make sure your conditions use the
temperature_sensor.value
orhumidity_sensor.value
attributes, and not the genericvalue_sensor.value
attribute -- this generic attribute is now deprecated and will be removed from a future release. - HassController: Bless Hass to 2022.10.4
MQTTController build 22291
NOTE: This version requires Reactor version 22291 or higher.
- Add optional default value in topic substitutions. That is, the substitution string
%flavor:chocolate%
would insert the word chocolate if flavor was not defined in the entity configuration. - Template
owntracks_in_region
adds auser
field that can be set if your Owntracks needs it. The Owntracks topic is/owntracks/user/deviceid
, so theuser
field should be set in your entity configuration (withtopic
andregionName
to whatever is in thatuser
portion of the topic (e.g. if your Owntracks publishesowntracks/fred/fredsphone
thentopic
should be set tofredsphone
anduser
should be set tofred
). - Code cleanup and sync with Controller base class updates.
ZWaveJSController build 22291
NOTE: This version requires Reactor version 22291 or higher.
- Code cleanup and sync with Controller base class updates.
- HubitatController: Breaking change: Devices that use HE's PressureMeasurement capability will now report pressure on
-
Reactor build 22293
ALL USERS -- IMPORTANT: If you are upgrading from any version earlier than 22256, please read the advisories and prerequisites for that build, below.
- PR 0000337: Condition with "sustained for" less than X seconds malfunctions (triggers immediately).
- PR 0000336: Fix group error indication not clearing when creating new group in a reaction (global or rule-based).
- Fix an error in the translation string for "sustained for" options when the "less than X seconds" form is used (was showing incorrectly in rule status view human-readable form).
- VirtualEntityController: scheduling of HTTP requests can now be done at specific times via the
at
setting for the request (an alternative tointerval
). [docs] - VirtualEntityController: the
quiet_failure
flag now accepts either a boolean value or integer; if boolean true, notifications are never sent for failed HTTP requests. If numeric, a notification is sent only after that number of requests has failed. [docs]
-
Reactor build 22302
ALL USERS -- IMPORTANT: If you are upgrading from any version earlier than 22256, please read the advisories and prerequisites for that build, below.
- UI/Status: Running Reactions widget now has "stop" button to terminate a running reaction (caveat operator).
- UI/Status: Tighten the display up a bit (remove excess whitespace).
- UI/Status: Fix alerts list that can overflow its container horizontally, causing a confusing display with multiple scoll bars.
- UI/Rule Editor: An notice/badge is now shown for collapsed sections that are not empty (i.e. when content is hidden).
- Fix condition operator "is EMPTY" (and its negated partner) on array type operand (only) was incorrectly reporting not empty in some circumstances.
- Additional UI embellishments for condition (triggers/constraints) and action (reactions) drag-drop. Still some limitations/inconsistencies/bugs in jquery-ui (which provides the drag/drop/sort implementation). If you can't get your object exactly where you want it, drop it close (i.e. into the group you want it in), then drag it again to its final position within the group.
- Action logging from all controllers now uses INFO level logging rather than forced logging (this is mostly a help to me because I separately log warning and higher priority in my test and home configurations so I can more clearly see errors -- it removes noise from that).
- HassController: Bless Hass to 2022.10.5
-
Reactor build 22305
ALL USERS -- IMPORTANT: If you are upgrading from any version earlier than 22256, please read the advisories and prerequisites for that build, below.
- Engine: fix bug that could cause expressions having array or object results to not detect change reliably.
- UI/Rules/Reactions: the changes operator should not be available in constraints (changes is an event, and constraints are static, not event-driven).
- UI/Rules Editor: enforce minimum size for condition type menu (tidier layout).
- UI/Reaction Editor: improve field layout, prevent fields from pushing controls out of container, enforce minimum size for action type menu (tidier layout).
-
Reactor build 22308
ALL USERS -- IMPORTANT: If you are upgrading from any version earlier than 22256, please read the advisories and prerequisites for that build, below.
- PR 0000343: Fix missing fields for notification action (Pushover title reported; 22305 injection).
- PR 0000342: Documentation fix, error in example code for
if
expressions in Expressions doc. - PR 0000341: Ease entity ID restriction (for users with international characters in entity IDs).
- PR 0000340: Localization of "upgrade available" alert message.
- PR 0000339: push()/unshift() functions not working as expected (not a lexp issue, it's a last-value storage/comparison problem when value is object type).
- PR 0000338: Version/license/meta info for extensions is now displayed on the About page.
-
Reactor 22328
ALL USERS -- IMPORTANT: If you are upgrading from any version earlier than 22256, please read the advisories and prerequisites for that build, below.
- The
baseurl
config key/value is no longer required. It is used only in exceptional circumstances. It is now commented out in default configurations (dist-config/reactor.yaml
), and setting it is no longer required as an installation step. Users configuring their systems to use HTTPS access to the Reactor UI should, instead of usingbaseurl: https://...
, setuse_tls: true
in thereactor
section of their configuration. - Improve messages in Run Reaction actions when there is an error starting the reaction.
- DynamicGroupController: make sure change in group name in configuration is always applied at startup.
- HassController: implementation for
device_tracker
service to location capability. - HassController: since HA appears to provide conversion, enable all color modes if any is supported.
- HassController: Add support for new
xy_color
capability. - HassController: Allow YAML form service data in
call_service
actions. The service data can now be formatted as YAML or JSON. The former is the default unless{
is the first character in the field, to preserve compatibility with existing actions using JSON data. - Add
xy_color
system capability. - Fix a startup issue on Windows.
- PR 0000345: Fix expression doc example for
each
statement - HassController: Bless Hass to 2022.11.4
ZWaveJSController 22323
NOTE: This version requires Reactor build 22314 or higher.
- Allow
zwave_device.set_config
parameter to be either string (property name) or number (property/configuration parameter ID). This should improve usability for this action. - Store property ID in metadata for
x_zwave_values
attributes. - Improve "first guess" device support for many devices when Z-Wave JS is still running interviews and Reactor comes up (i.e. when data from Z-Wave JS about devices is incomplete).
- Improve device support for multiple Fibaro, Aeotec, Everspring devices.
- Improve manufacturer/device support for Remotec, Poly-Control, Danalock, Zipato, Nortek, NEO, Minoston (EVA Logik).
MQTTController 33326
NOTE: This version requires Reactor build 22306 or higher.
- Allow templates to be stored in individual files in a
config/mqtt_templates
subdirectory. This should improve users' configuration management for community-contributed templates. - Additional error checking in install script.
- Implement entity deadmarking like other controllers.
- Improve entity initialization/resilience to isolated configuration problems.
- Incorporate some device template fixes from @therealdb (with gratitude for his ongoing contributions).
- Support for deterministic updating of attributes on a topic by using a new/alternate array-based configuration syntax. [docs]
- Support for
requires
key in templates to facilitate user-feedback when a template is used but a configuration value required by the template it not provided by the user.
- The
-
Reactor build 22337
ALL USERS -- IMPORTANT: If you are upgrading from any version earlier than 22256, please read the advisories and prerequisites for that build, below.
- Rules UI: Improved detection in UI (or more correctly, notification from core to UI) of "trouble" on rules.
- HassController: reconfigure entities on HA version change; support for person, weather, number, button, sun.
- HTTPAPI: API requests are now logged by default.
- HTTPAPI: A malformed
monitored_entities
configuration will no longer prevent theperform
API request from completing. - HassController: Bless Hass to 2022.11.5
-
Reactor build 22349
NOTE: If you get missing entity errors from your rules when you first start this version, don't panic. Just wait a few seconds and then restart Reactor; it should then start clean.
IMPORTANT: The bare-metal distributions no longer include package dependencies pre-installed. It is therefore critical that you install/update dependencies every time you upgrade by running
npm run deps
in the Reactor install directory (for Linux users; Windows users please refer to the installation documentation. This advisory does not apply to docker-based installs — Reactor docker images always include package dependencies pre-installed.- Expressions:
isNaN()
now returns false when passednull
. This is now different from JavaScript, whereparseFloat(null)/parseInt(null)
returnNaN
, butisNaN(null)
(oddly, IMO) returns true. - Fix an error in Group class implementation that was causing spurious errors from DynamicGroupController after a member entity was deleted or purged.
- VeraController: Improve detection of UV sensor child devices registered as GenericSensor device type and having LightSensor1/CurrentLevel state variable when LightSensor1 isn't even a declared service for the type (i.e. a mess). This applies specifically to Aeotec Multi-Sensor 6 devices on 7.32beta4, but may apply to other devices/firmware.
- EzloController: Sound sensors are now handled with Reactor value_sensor capability.
- EzloController: Guard against missing item enumerated in data for a device (data inconsistency in Ezlo API's returned device data).
- UI Entities List: UI now stores the last 10 actions and their parameters, and restores the parameters when an action is repeated.
- UI Entities List: Action parameter default values for certain types are now provided correctly (some types would come up blank even though a non-blank default was provided in the parameter definition).
- HassController: Bless Hass to 2022.12.6
- i18n: Improve messages for Rules/Predicates when dependent objects are missing.
- Improvements from the 22343 silent release (see below).
MQTTController build 22350
- Improve handling of
x_mqtt_device.online
attribute for templates that have custom LWT event.
- Expressions:
-
Reactor build 23010
- Stop Reaction action now allows you to stop the current/running reaction. This is intended to be used in constrained groups, where a match to the constraints may stop the reaction to prevent it from doing anything else.
- New
ev_charger
system capability. - Reaction Editor: Fix incorrect storage type for boolean arguments affecting some controllers.
- HassController: Bless Hass to 2023.1.2
MQTTController build 23010
- Fix spurious message when stopping MQTTController instance.
ZWaveJSController build 23011
- Fix a possible runtime error during node configuration if the target node isn't yet fully ready.
- Support for iblinds V3.
-
Reactor build 23028
- UI/Rules Editor: Collapsed sections now change the color of the "hidden content" badge -- red if the hidden content contains an error that needs to be corrected before save, green if it contains modified conditions or actions, and info blue (as before) if no errors and unmodified. No badge is shown if the section is empty (as before). The badge icon has been changed to a crossed eye.
- Docs: Add Portainer installation instructions: https://reactor.toggledbits.com/docs/Installation-docker-portainer/
- EzloController: If there are too many consecutive timeouts on requests to the hub, recycle the hub connection.
- HassController: Bless Hass to 2023.1.7
-
Reactor build 23049
- Rule and Reaction Editors: Use fixed "helper" for drag/drop to circumvent limitations in jQuery-UI causing odd restrictions and side-effects when dragging large objects (like HTTP Request actions). It's not as cool-looking, but function over form is required here.
- Docs: Provide installation link for community-supplied HassOS add-on; thank you to mrw298 for this.
- HubitatController: Do not automatically select the Hub Information device for health probes; the new Hub Information v3 operates differently from previous versions and now is longer usable for health probes. A device will be chosen at random unless the
probe_device
config is set. [docs] - HassController: Bless Hass to 2023.2.5
-
Reactor build 23063
- Reaction Editor (UI): restore wide fields in HTTP Request action; injection from changes in 23049.
- Reaction Editor (UI): fix detection of substitution in some cases that would cause single-action "try" button to not be disabled when a substitution was in the action's parameters (substitution isn't performed on single-action try).
- Entities Page: Action dialog now warns that substitution isn't performed in that tool (launching an action from entity detail panel).
- HassController: support for humidifier/dehumidifier (domain/service and device class, respectively).
- VirtualEntityController: Fix an error in config check that was not allowing underscore (
_
) in entity IDs. - VirtualEntityController: Enforce
x_virtualentity.set_attribute
parameters more aggressively (better error message when not provided). - VirtualEntityController: Fix an error in
x_virtualentity.set_attribute
that would cause the HTTP API to not give a response when the action completed. - I18n: Rework the loading of locale settings files, their relation to the node or browser locale, and the configurable overrides. Reactor will now use the requested locale (host config, browser config/URL, Reactor config) even if a translation file is not available for it. This places the burden on JS' native Intl, which is ample, and reduces some complexity in Reactor's model.
- HassController: Bless Hass to 2023.3.1
ZWaveJSController build 23063
- Command class
Sound Switch
now maps tochime
capability (Aeotec Siren 6, others) - Support multi-step action implementations (e.g.
chime.play
needs to set two values sequentially (volume then sound).
-
Reactor build 23078
- Fix loading of local capabilities definitions broken in a previous build.
- HassController: Bless Hass to 2023.3.5
-
Reactor build 23114
- Conditions: add
is NOT TRUE
andis NOT FALSE
operators. Theis NOT TRUE
operator (for example) is unlike theis FALSE
operator in that, if the tested value isnull
, theis NOT TRUE
operator result would be true, while theis FALSE
operator result would be false. This distinction facilitates some tests where it may be desirable to handlenull
as equivalent to eithertrue
orfalse
without having to provide an additional, separateis NULL
condition (and possibly an enclosing OR group). - DynamicGroupController: document group actions; this makes it an official feature (was experimental).
- Engine/Rule: Clean up a misspelled method name.
- InfluxFeed docs: update supported and recommended versions. [doc]
- HubitatController: Tweak reconnect timing decay (allow for longer decay when hub cannot be contacted for an extended period).
- Reactions: Clarify what "Disabled" means in the constraints of a Group action (incl. Repeat...While) of a reaction. It does not disable the actions in the group. The disable flag applies to the constraint conditions only, having the same effect as it would on rule-based triggers and constraints (i.e. it becomes as if the constraint conditions do not exist). [docs] and [docs]
- HassController: Bless Hass to 2023.4.6
- Conditions: add
-
MQTTController 23135
- In action payload, force conversion of all data types to string for "raw" output, rather than assuming result of expression is a string (although docs say to do that, it's just too easy to omit, and too easy to change it so the requirement is moot).
- Add
parameter: name
value form to action payload definition to draw payload value from the named parameter without the need to use anexpr
ession (this follows the implementation of action definitions in other Controller instances as well). That is, you can specify, for example,parameter: level
instead of usingexpr: parameters.level
(assuming the parameter value requires no scaling or other modifications to be compatible with the device). [docs]
-
Reactor Build 23171
NOTE: This build includes fixes made in a prior silent release (where the change(s) affected only one user).
DEPRECATION NOTICE: Support for versions of Home Assistant prior to 2022.5.3 will be removed on the next build. These older versions may continue to operate successfully with HassController going forward, but I will not address/fix issues for them.
- PR 0000356: Fix an issue where a rule with multiple sunrise/sunset conditions using the between operator chooses the first condition's before/after constraints rather than its own (i.e. it was choosing the control states from the first row rather than the current row).
- SystemController: the deprecated
suninfo.sun_angle
attribute is now removed (its replacement issuninfo.elevation
). - HubitatController: Hub variables can now be set up to 1024 characters with hub firmware 2.3.5.135 and above; for earlier firmware, the limit is 255 characters. The length limit is enforced by the hub, not HubitatController.
- HassController: Bless Hass to 2023.6.2
-
Reactor build 23196 (latest and stable branches)
NOTICE: As announced in the release note for the previous build (23171), Home Assistant versions earlier than 2022.5.3 are no longer supported.
- Introduce a maximum delay in the write-back of certain storage containers (e.g. that used for expressions).
- Docs: fix an error in an example on the How-To: Expressions with Entities page.
- HassController: Bless Hass to 2023.7.2
-
Reactor build 23218
- Improve the initialization of new global variables so they don't show "not yet evaluated" until a non-null value is set (null is a valid evaluation result and should remove the "not yet").
- Expressions: improve the display of non-printing characters in the expression editor's "current value" display (they now display as Unicode escape sequences).
- i18n: Fix init of localized weekday names when most recent Sunday occurs in prior month (caused, for example, incorrect weekday checkbox labels in Weekday conditions; cosmetic only, no operational effect).
- SystemController: for Reactor update, include update branch, version, and commit as attributes on system entity.
- Entities page: New Copy Attributes button in entity detail copies all attribute values to the clipboard.
- HassController: Bless Hass to 2023.8.0
-
Reactor Build 23242
- Rules Editor: Fixed an issue where a condition option change to the duration operator with no change to duration value may not be saved.
- HassController: Add mapping for
proximity
domain (tovalue_sensor
). - HassController: Bless Hass to 2023.8.2