@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
Version 1.0 Pre-release Discussion
-
@toggledbits , As you stated in another thread "Capabilities on Hubitat are free-form, and there's no indication which capability might be the most useful or primary". Could you add the ability for a user to manually select the primary capability for each Hubitat device? This would allow the Entities screen to display info in the primary value. If the Dashboard feature is added in the future then the Hubitat device should display correctly there also.( I also would like to request the dashboard)
-
This might be off topic and it also reveals my lack of programming skills. But I wounder how is MSR going to be installed, once it leaves beta? I use it on a stationary Windows 10, and the problem is if the power goes out. Then my PC reboots and I have to start the app and change catalog and finally execute "node app.js". I could install it on a RPi, don't know if it can work alongside and on the same RPi as I got Home assistant installed? Then it would start straight away, when the power gets back. To summarize, it's basicly two questions;
- In which ways are we going to be able to install and start up MSR?
- Is it possible to install MSR on a RPi that already is running HA? Or on a Home assistant blue (Odroid N2+)?
Another feature that would be nice is to have a optional setting of automatic updates.
Regardsless - MSR is a great (one of the best) contribution to the smart home community - at least for me. Great job!! -
There was a thread about having MSR auto start on a Pi. I set it up on my Pi and it did work MSR was started automatically after a reboot / power on.
https://smarthome.community/topic/439/how-to-auto-start-on-rpi-reboot?_=1621588014603
-
@fanan At least initially, like many other projects, I expect MSR to be delivered in the following forms:
- Primary: Docker container. This facilitates not only a simpler integrated package to install that contains its dependencies, but also easily takes care of starting at boot on most systems. There are currently Docker containers available for Linux amd64 and armv7l (i.e. RPi4) architectures.
- Generic tarball. This will be a manual install for platform power users (Linux, Windows, and anywhere else nodejs and the companion dependencies can be installed by the user). There are available examples for automatic startup for systemd.
There's no reason you cannot install MSR next to Hass or anything else on a platform that allows you to install such things (clearly you're not going to install it on your Hubitat). I don't know anything about Hass Blue, but if it lets you install docker containers or the generic package, I see no reason you can't run them side-by-side.
@cw-kid said in Version 1.0 Pre-release Discussion:
@matteburk
There was a thread about having MSR auto start on a Pi.Slightly modernized version of the same here, should work on any platform that supports systemd: https://smarthome.community/post/8011
-
@fanan said in Version 1.0 Pre-release Discussion:
Another feature that would be nice is to have a optional setting of automatic updates.
I'll address this issue separately.
I think there are two interpretations here, so I'll start with the interpretation that I would more specifically call "unattended upgrades". Philosophically I'm opposed to unattended upgrades in all things, particularly on things that become "mission critical" in my environment. There is no "good time" for such updates except when I'm there to initiate them and recover if they come a gutser. History has shown that they otherwise will happen when I am far from home, usually for a sustained period and while Internet access is unavailable or inconvenient. When fully unattended upgrades to MSR happen, that will be your sign that I am no longer associated with this project.
The other interpretation is "push-to-start" upgrades from the UI. This is, frankly, a very low priority for me, and will not be something I entertain for 1.0, or likely 1.x. Docker containers are easily upgraded with a four-line script on command line-driven platforms, and still pretty painless in, for example, the Synology GUI (and still doable on the command line there as well). For users of the generic tarball, the detar and restart is even simpler. I understand that one click from the GUI would be easier, I don't disagree there, but keep in mind you've all been working in a mode where, for much of the history of its availability, MSR updates have come almost daily. That is not the norm, and I would not want it to be in production. In fact, production will go more to the model I use for R4V, where there is basically a very slow-moving release channel, a faster "stable" channel, and a bleeding-edge "latest" (what you have today).
The feature also introduces something that Reactor currently doesn't (on its own) require: access to a cloud infrastructure. Upgrades from within MSR require it to access cloud services, some existing, some not. This implies a lot of things, not the least of which include its security, its construction, and its cost to maintain and serve. If it gets done at some point, it will not come lightly, or easily, and it will likely be accompanied by license fees.
-
@toggledbits I fully understand and respect that! Thanks for taking the time!
Hope you have a great weekend! -
Would a Menu item for accessing the reactor log file or portion of the log be possible.Or ideally a way to monitor the log in real time from the GUI for troubleshooting?
-
@sweetgenius said in Version 1.0 Pre-release Discussion:
Would a Menu item for accessing the reactor log file or portion of the log be possible.Or ideally a way to monitor the log in real time from the GUI for troubleshooting?
+1 for this.
-
How about exposing the Status and Alerts levels under Reactor_System, so that Rules could be written to react to, say, a Rule getting stuck SET for too long, or the count of a particular (esp. unexpected) Alert going too high, etc.? I love my warning messages!
-
This post is deleted!
-
Hi!
I've only been using MSR for 3 days, so I'm too much of a beginner to have opinions, but I want to try to collaborate:
-
First thanks to @cw-kid , with the simple tip of the installation page in the manual, I finally managed to take the step and install it on Windows 10. I see some comments on automatic startup, it was simple to put in the task scheduler a bat to run the "node app.js", and works very well on computer restarts. Now I did not understand why the instruction "Running Reactor Continuously" with the command "nohup ./app.sh &", what is the difference?
-
Regarding the Constraints question, I don't see much value, or don't know how to use them. I thought that if we first have the obligation to meet the Constraints (e.g. be in home mode and time between 8am and 5pm), only then do we start evaluating the Triggers (e.g. movement in room, open door...) it would make more sense to me. That is Constraints as a basic obligation, and Triggers in the next group of the variables of the action. Right now I'm thinking of putting everything in the Triggers block.
As I commented I only have 3 days, but I already see that Patrick @toggledbits again doing an exceptional job, if the Reactor was already great, I do not know how to classify what will be the MSR by the little I've seen. What I see for the future:
-
A translation will be needed in the selectors of so many technical terms, for a more fluent, layman-friendly message. An example FROM x_vera_svc_micasaverde_com_SecuritySensor1.Tripped TO only Tripped;
-
A dashboard unique to the Rule Sets. What you have today allows us to turn on/off, edit, reset... I think of something simple and straightforward like the Action Icon (I love the Reactor icon), green color on, yellow already have conditions met and could go into execution, and red in execution. It would be a dashboard for easier visualization on the phone. If you can then configure that shows or not would be great, who knows version 3, 4....;
And sorry this may not be the forum, but reading the posts I see a strong tendency to recommend the use of the Docker container. Is there a real difference in usage with respect to having the Windows 10 installation? Are there performance issues? Any functions that will not operate well? Is the communication between HA and the computer running Windows 10 worse? I see on the Vera panel that a device changes condition to unTrigger, and it takes quite a while to see the reaction on the MSR, is there a difference between container and windows?
Once again my many thanks to everyone for the work being done, I finally see a light in not depending on hardware to be able to have good automation at home, in a simpler way. As many have commented, soon Vera will be just a radio antenna
-