@togglebits I am curious as to why the tilt_sensor.state (primary) = NULL. I believe it should show true or false. I have to use binary_sensor.state instead in my rules.
Again, not sure if this is related to Reactor/ZwaveJSController implementation or the actual Z-Wave JS UI docker version. I have copied, below, the attributes of the tilt sensor in hopes it can help.
Thanks in advance.
Reactor version 23302
ZWaveJSController version 23254
Z-Wave JS UI version 9.3.0.724519f
zwave-js version 12.2.3
@toggledbits I have noticed after upgrading both Reactor and ZWaveJSController to version 24257 that two of my devices/entities, TILT-ZWAVE2.5-ECO and Zooz ZSE18, had their entity re-named in an unusual way and also appears to be duplicated.
Reactor version 24257
ZWaveJSController version 24257
Z-Wave JS UI version 9.18.1
zwave-js version 13.2.0
Vestibule Motion Sensor State attributes/partial screenshot of entities it created. All entities have the same attributes.
motion_sensor.state=true x_zwave_values.Notification_Home_Security_Motion_sensor_status=8 zwave_device.capabilities=[113] zwave_device.endpoint=0 zwave_device.failed=null zwave_device.manufacturer_info=null zwave_device.node_id=23 zwave_device.valueId=[113,"Notification","Home Security","Home Security","Motion sensor status","Motion sensor status"] zwave_device.version_info=nullTilt Sensor Door State and Tilt Sensor Door State Simple attributes/partial screenshot of entities it created. All entities have similar attributes with exception of x_zwave_values.Notification_Access_Control_Door_State = 22 or 23.
tilt_sensor.state=true x_zwave_values.Notification_Access_Control_Door_state=22 zwave_device.capabilities=[113] zwave_device.endpoint=0 zwave_device.failed=null zwave_device.manufacturer_info=null zwave_device.node_id=24 zwave_device.valueId=[113,"Notification","Access Control","Access Control","Door state","Door state"] zwave_device.version_info=null tilt_sensor.state=true x_zwave_values.Notification_Access_Control_Door_state_simple=22 zwave_device.capabilities=[113] zwave_device.endpoint=0 zwave_device.failed=null zwave_device.manufacturer_info=null zwave_device.node_id=24 zwave_device.valueId=[113,"Notification","Access Control","Access Control","Door state (simple)","Door state (simple)"] zwave_device.version_info=null tilt_sensor.state=false x_zwave_values.Notification_Access_Control_Door_state=23 zwave_device.capabilities=[113] zwave_device.endpoint=0 zwave_device.failed=null zwave_device.manufacturer_info=null zwave_device.node_id=24 zwave_device.valueId=[113,"Notification","Access Control","Access Control","Door state","Door state"] zwave_device.version_info=null tilt_sensor.state=false x_zwave_values.Notification_Access_Control_Door_state_simple=23 zwave_device.capabilities=[113] zwave_device.endpoint=0 zwave_device.failed=null zwave_device.manufacturer_info=null zwave_device.node_id=24 zwave_device.valueId=[113,"Notification","Access Control","Access Control","Door state (simple)","Door state (simple)"] zwave_device.version_info=nullI'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:
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 🙂
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.
After a couple of weeks, I noticed that my Remotec zrc90 isn't working as expected.
Scenes are working in ZWaveJS, but this device has a strange behavior: the scene change, but then it's set again to null. In Reactor, this remains null:
battery_power.level=0.7 battery_power.since=1725817957361 x_debug.dt={"description":"Scene master 8 button remote","model":"BW8510/ZRC-90US","default_name":"Scene master 8 button remote","manufacturerId":21076,"productType":0,"productId":34064} x_zwave_values.Battery_isLow=false x_zwave_values.Battery_level=70 x_zwave_values.Central_Scene_scene_001=null x_zwave_values.Central_Scene_scene_002=null x_zwave_values.Central_Scene_scene_003=null x_zwave_values.Central_Scene_scene_004=null x_zwave_values.Central_Scene_scene_005=null x_zwave_values.Central_Scene_scene_006=null x_zwave_values.Central_Scene_scene_007=null x_zwave_values.Central_Scene_scene_008=null x_zwave_values.Central_Scene_slowRefresh=null x_zwave_values.Manufacturer_Specific_manufacturerId=21076 x_zwave_values.Manufacturer_Specific_productId=34064 x_zwave_values.Manufacturer_Specific_productType=1 x_zwave_values.Version_firmwareVersions=["1.1","1.1"] x_zwave_values.Version_hardwareVersion=3 x_zwave_values.Version_libraryType=2 x_zwave_values.Version_protocolVersion="4.5" x_zwave_values.Wake_Up_controllerNodeId=1 x_zwave_values.Wake_Up_wakeUpInterval=0 zwave_device.capabilities=[91,114,128,132,134] zwave_device.endpoint=0 zwave_device.failed=false zwave_device.generic_class="Remote Controller" zwave_device.impl_sig="24242:1:22315:1" zwave_device.is_beaming=false zwave_device.is_listening=false zwave_device.is_routing=false zwave_device.is_secure=false zwave_device.manufacturer_info=[21076,1,34064] zwave_device.max_data_rate=null zwave_device.node_id=154 zwave_device.specific_class="Simple Remote Control" zwave_device.status=2 zwave_device.status_text="awake" zwave_device.version_info=[null,"1.1"] zwave_device.wakeup_interval=0Anything I could look at? Thanks.
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.
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
Reactor (Multi-System/Multi-Hub) Announcements
-
Build 22178 (latest, zwavejs)
NOTE: I will be on holiday for most of the month of July, and with limited Internet access. During this time, I will not be able to provide software support, fixes or builds, and likely will not have much time or means to read and answer questions. Please step up and provide support to your peers if questions come up!
- HassController: Set null state for switches and sensors when Hass reports them unavailable.
- HassController: Bless Hass to 2022.6.7.
- Docs: Improve details in Synology/Docker installation.
-
Build 22179 (latest, zwavejs)
NOTE: I will be on holiday for most of the month of July, and with limited Internet access. During this time, I will not be able to provide software support, fixes or builds, and likely will not have much time or means to read and answer questions. Please step up and provide support to your peers if questions come up!
- HassController: Fix an issue that may randomly affect/disable assignment of primary attributes (since 22118).
- Fix a problem in after...within (time-restricted) sequence conditions.
-
Build 22203 (latest, zwavejs)
- Expressions: the
time()
function has been extended to allow parsing of date/time values in strings in forms beyond ISO-8601; most simple date/time forms should work, particularly those that closely adhere to your locale's default. A string that contains only a time will be converted to that moment on the current date; a string that contains only a date will yield midnight on that date. If a given string cannot be converted, an error will be thrown. Refer to the documentation for Expressions for more information. - HassController: Bless Hass to 2022.7.6
- Docs: documentation for Reactions now includes additional information about rule-based reaction behaviors and action groups, and has been "modernized" to use the terminology of Multi-Hub Reactor rather than that of the Reactor for Vera plugin.
- Expressions: the
-
Build 22233 (latest, zwavejs)
BARE-METAL INSTALL USERS: When upgrading to this version, you must upgrade package dependencies after unpacking the archive file (delete any existing
package-lock.json
file and then runnpm install --no-save --omit dev
). The UI will not function properly if you fail to perform this upgrade.ALL USERS -- REMINDER: A hard refresh of your browser is necessary after upgrading to any new build.
- Upgraded the Bootstrap library to 5.2, which gave rise to a large number of required UI changes, and an opportunity for some useful cleanups. The Bootstrap Icons library was also upgraded to 1.9. All of this also means that Internet Explorer is no longer a supported browser (use its replacement, Edge).
- HassController: Bless Hass to 2022.8.6
-
Build 22240 (latest, zwavejs)
BARE-METAL USERS: If you are upgrading to this version from any version earlier than 22233, you need to update your package dependencies. Pleasee see the post for that build for instructions.
ALL USERS -- REMINDER: A hard refresh of your browser is necessary after upgrading to any new build.
- PR 0000327: Reaction Entity Action layout for additional data fields is messy.
- VeraController: Ensure
x_vera_device.failed
and.configured
are null if Vera fails to provide state for these values. - EzloController: Dead-marking and automatic removal (after delay) of entities for Ezlo devices/rooms/scenes that no longer exist (functional parity with other hub Controller objects).
- HassController: Implement mappings for scenes, scripts, and automations. All of these can have their actions run via Reactor's
script.run
action. Automations also can be en-/disabled using thepower_switch
capability actions (and entity primary state is the automation's en-/disabled state). All appear as runnable scenes in the dashboard. - UI: Improve highlighting of containing groups when sort/drop changes to conditions are made in the rules editor.
- HassController: Bless Hass to 2022.8.7
-
Just a news item: the ZWaveJSController is now an official add-on, available for download from
extras
. Instructions for installing it are in the Reactor documentation.For (only) those users who have been using the zwavejs build series for testing ZWaveJSController, you will now need to go back to the latest build series, and install ZWaveJSController as referenced above. There will be no further builds on the zwavejs branch. Also, ZWaveJSController no longer requires an authentication key to use, so you can remove the
auth
entry from configuration (it will be ignored and is harmless if you leave it). -
Reactor build 22248
Docker Container Users: After upgrading to this build image, please check your
NODE_PATH
environment value in your container configuration; it should read/opt/reactor:/opt/reactor/node_modules
. If it does not, please correct it (some container managers, including Synology, do not automatically reapply/update values from newer images to existing containers).- Run Reaction action: New option "wait for completion" causes the current reaction to wait for the started reaction to finish. When unchecked (default), the started reaction runs concurrently with the reaction that starts it. This (concurrent) is the behavior of all prior versions of Reactor, and since unchecked is the default, the behavior of your existing reactions does not change (unless you go in and change it). docref
- Internal changes to support general release of ZWaveJSController.
ZWaveJSController build 22248
- Reduce default logging level to 5.
- Remove unused dependency.
-
Reactor build 22251
Bare-metal Install Users: If you are upgrading to this version from any version prior to 22233, you need to update your package dependencies. Please see the announcement for that build for instructions.
Docker Container Users: If you are upgrading to this build from any build earlier than 22248, you need to check that your
NODE_PATH
for your container is correctly updated. See the announcement for that build for details and instructions.ALL USERS -- REMINDER: A hard refresh of your browser is necessary after upgrading to any new build.
- PR 0000328: Rule Editor: editing condition options of parent of nested groups opens child's condition options panel (fixed).
- Entities list: fix name search parity with Entity Picker (ID matches).
- Change the way object arguments to actions in reactions are stored. Previously, they were stored in the reaction as native objects by converting the given string as JSON (the input was expected to be JSON) in the UI. This made expression substitution unavailable in those (object) arguments. Now, they are stored by the UI as given (i.e. a string), so substitutions are now available in those arguments. This specifically removes the limitation that
x_hass_system.call_service
could not perform substition in itsdata
argument. It now works as expected. A deprecation warning has been added to the Engine to detect argument values stored as native objects in actions that will cause an alert to be displayed notifying the user that the reaction/action needs to be edited. Any trivial edit to the field, followed by a save of the reaction, will update the form of the data and eliminate future alerts. - Dashboard: Fix stray "x" displayed on Sensor layout when source entity's units are null.
- HassController: Bless Hass to 2022.9.0
-
Reactor build 22252
Bare-metal Install Users: If you are upgrading to this version from any version prior to 22233, you need to update your package dependencies. Please see the announcement for that build for instructions.
Docker Container Users: If you are upgrading to this build from any build earlier than 22248, you need to check that your
NODE_PATH
for your container is correctly updated. See the announcement for that build for details and instructions.ALL USERS -- REMINDER: A hard refresh of your browser is necessary after upgrading to any new build.
- PR 0000329: Rule Editor: editing sunrise/sunset condition, if only sunrise/sunset selectors are modified last, the rule does not save as configured. If other condition fields are edited after, it saves correctly.
-
Reactor build 22256
Bare-metal Install Users: If you are upgrading to this version from any version prior to 22233, you need to update your package dependencies. Please see the announcement for that build for instructions.
Docker Container Users: If you are upgrading to this build from any build earlier than 22248, you need to check that your
NODE_PATH
for your container is correctly updated. See the announcement for that build for details and instructions.ALL USERS -- REMINDER: A hard refresh of your browser is necessary after upgrading to any new build.
ALL USERS -- IMPORTANT: As a result of entity storage changes in this build, existing entity storage (cache) is invalidated and rebuilt when this build is first run. That will cause all entities to be reported as newly-discovered, even though they were known before. However, this should be minimally disruptive to your logic, if at all. You may also safely ignore any warnings you see in the logs about "incompatible serialization data" on that first run; those are expected.
- PR 0000331: In the "Pulse" output condition options, the option to limit the number of pulses vanished from the editor during the upgrade to Bootstrap 5 (i.e. since 22233). It has been restored. This did not affect the operation of existing repeat count limits on conditions. If a pulsing condition was edited, that would have removed the limit, so if you use this feature, you might check those conditions that should use it. Opening the rule detail in the Rule Sets list of rules to see the condition descriptions is sufficient to see if it's there or not -- you don't need to go into the editor to see it. When present, the condition description will include "repeat after x seconds up to y times."
- Fix spurious data format warning for HTTP Request actions.
- Entities now have metadata (data about data) for each attribute that provides the time last modified, as well as the previous value and the effective time of the previous value. In addition, any data type and other definition information known for the attribute will also be present. The quickest way to see attribute metadata is to hover over the name of an attribute in the detail panel of an entity in the Entities list. The attribute metadata is accessible in expressions via each entity's
attribute_meta
property. The subkeys of this property are capability names, and within each capability are the attribute names, and within the attribute names are the metadata elements. For example, in the commonly used form of expressiongetEntity( entity_id ).attributes.power_switch.state
we would get the value of thestate
attribute in thepower_switch
capability of whatever entity was matched; this tells us if the switch is on or off. To get the time that value was set, we would usegetEntity( entity_id ).attribute_meta.power_switch.state.last_modified
. Those of you trying to use thelastupdate
property on an entity for various purposes (such as failed node detection) should particularly take note of this change and the capability it provides. - Docs: New page Expressions with Entities & Attributes in the How-To section.
- (Advisory) HubitatController: Hub variables are limited to 255 characters by the hub firmware. Attempts to set a hub variable to a longer string will fail. See the Limitations in the HubitatController docs for more details.
- VeraController: The
sys_system.reload
action was incorrectly reloading the remote Vera hub; that's not really its job, but rather the job ofx_vera_sys.reload
. If you have been usingsys_system.reload
to restart Luup, please switch tox_vera_sys.reload
. As of this build,sys_system.reload
will cause VeraController to resync all devices and entities (i.e. it's a restart of VeraController, not your Vera). - HassController: Bless Hass to 2022.9.2
ZWaveJSController build 22256
- Send notice (displays in Status widget) when a new node is discovered.
-
Reactor build 22257
Bare-metal Install Users: If you are upgrading to this version from any version prior to 22233, you need to update your package dependencies. Please see the announcement for that build for instructions.
Docker Container Users: If you are upgrading to this build from any build earlier than 22248, you need to check that your
NODE_PATH
for your container is correctly updated. See the announcement for that build for details and instructions.ALL USERS -- REMINDER: A hard refresh of your browser is necessary after upgrading to any new build.
ALL USERS -- IMPORTANT: If you are upgrading to this build from a build earlier than 22256, please read the advisories for that build prior to proceeding.
- VeraController: Specific support for iBlinds2 (Window Blind Controller mfg 647 prod 3,13) to handle its 50%=fully open way of doing business (since the covering is made up of slats/louvers, the 0 and 100 positions are closed fully tilted one direction or the other, with 50% being "flat" between the two).
- VeraController: The generic
cover.set
action was missing, and nativetoggled
capability support was added for window coverings (toggles between open and closed, as one might expect). - Dashboard: The Cover widget (window covering) was not changing its icon when the covering changed state.
- HubitatController: Tighten checking and handling around oddly-named attributes. Apparently at least one Hubitat user has a device that has a HE-native attribute with a space in its name, causing an exception to attribute naming tightened in 22256. This was causing a no-start on the controller. This build maps out non-alphanumeric characters from Hubitat to underscores, and also provides additional error handling to prevent a single attribute from stopping the controller startup.
-
Reactor build 22258
Bare-metal Install Users: If you are upgrading to this version from any version prior to 22233, you need to update your package dependencies. Please see the announcement for that build for instructions.
Docker Container Users: If you are upgrading to this build from any build earlier than 22248, you need to check that your
NODE_PATH
for your container is correctly updated. See the announcement for that build for details and instructions.ALL USERS -- REMINDER: A hard refresh of your browser is necessary after upgrading to any new build.
ALL USERS -- IMPORTANT: If you are upgrading to this build from a build earlier than 22256, please read the advisories for that build prior to proceeding.
- VirtualEntityController: This new controller type lets you create virtual entities (devices) and manipulate them. docs.
- Entities list: Fix metadata pop-ups that sometimes "stick", caused by the entity updating and the popper losing its reference element in the DOM. Also make the pop-ups more dynamic by updating them when the attribute updates.
- HassController: Devices that Hass identifies in the "motion" device class will get the
motion_sensor
capability in addition to the ubiquitousbinary_sensor
, andmotion_sensor.state
will be the primary attribute. - VeraController: Make sure all extended per-Vera-service capabilities are defined as stubs.
- HassController: Bless Hass to 2022.9.4.
-
MQTTController build 22260
- Add new template
owntracks_in_region
- Add new template
-
Reactor build 22264
ALL USERS -- IMPORTANT: If you are upgrading from any version earlier than 22256, please read the advisories and prerequisites for that build.
- VirtualEntityController: Added ability to make periodic HTTP requests and parse results to apply to attributes (see docs).
- PR 0000332: Fix missing "minutes" label (since BS5) on Interval condition fields (cosmetic).
- Added new
location
capability for geographic location (attributes: latitude, longitude, elevation). This is intended as a target for geolocation integrations. - Docs: Updated for new
owntracks_in_region
template. - Docs: Fixed an error in the example config for VirtualEntityController.
- HassController: Bless Hass to 2022.9.5
-
Reactor build 22266
ALL USERS -- IMPORTANT: If you are upgrading from any version earlier than 22256, please read the advisories and prerequisites for that build, below.
- PR 0000333: EzloController: problem with wss (secure websocket) connection injected at 22264.
-
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).