[Solved] Hubitat>MSR and dedicated Maker API

Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.

Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).

Run rule on dimmer change?

Reactor latest-23302-b7def56a; docker on Ubuntu 20.04; With Vera Plus and Ezlo Plus controllers

I'm trying to tie the dimmer level of a dimmer switch to the dimmer level of a dimmable device (fan canopy light controller). In the triggers section of the rule I can select "dimming.level changes" as the condition, and I can get said dimming level in an expression that I then use to set the dimming.set attribute of the dimming device in the Set Reaction section, but this only works when going from 0--><some value>. When going from <some value> --> <some other value> or <some value>-->0, this does not work, because the rule is already set (it went true with the first change, and hasn't gone false yet - this is expected behavior as per the documentation)

I can fix the <some value>-->0 issue by setting the Reset Reaction, but how can I get the rule to run - and set the entity dimming level - every time the switch value changes?

(I tired to upload a screen shot of what I have, but I just kept getting errors)

Multi-System Reactor

CallMeBot new interface?

Hi @toggledbits

Apparently, there have been some changes to the CallMeBot interface, as the service recently stopped working for me. I've tried several configurations, and none of the ones below are working.

# CallMeBot CallMeBot: profiles: default: # description - A friendly description of this profile (for menus) description: Default Profile New # # api_url - Access URL for CallMeBot API being used api_url: http://api.callmebot.com/start.php # # api_key - (if needed) API key (use for Facebook API, WhatsApp API, etc.). # If the API you are using does not require it, leave it # commented out or blank. api_key: "177xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxTGk" # # source - (if needed) Source field for some APIs. If yours does not require # it, leave it commented out or blank. #source: "source-value" # # phone - (if needed) Phone field for some APIs. If yours does not require # it, leave it commented out or blank. phone: "+5xxxxxxxx33" # # user - (if needed) User field for some APIs. If yours does not require # it, leave it commented out or blank. #user: "@xxxxxxxxxxxxx" # # lang - (optional) Language/voice; default "en-US-Standard-C". # See CallMeBot docs for possible values. lang: "en-US-Standard-C" # # rpt - (optional) Number of times to repeat message; default: 1. rpt: 2

I have already tested using the phone or the user.

Looking at the action log, I see that it starts, runs and finishes without any problems.

[latest-23302]2023-11-05T14:35:54.106Z <Engine:INFO> Enqueueing "teste<SET>" (rule-lolk0nlj:S) [latest-23302]2023-11-05T14:35:54.108Z <Engine:NOTICE> Starting reaction teste<SET> (rule-lolk0nlj:S) [latest-23302]2023-11-05T14:35:54.111Z <Engine:INFO> teste<SET> all actions completed.

When testing directly on the site, I see that it no longer uses API, and I haven't even found where to generate the API KEY.

http://api.callmebot.com/start.php?source=web&user=+5xxxxxxxx33&text=Teste callmebot pelo numero novo&lang=en-US-Standard-C

Please, can you advise me on what I should do to solve the problem?

Thanks.

Multi-System Reactor

Motion activated light now showing activation delay

Hi,

For years I have been using a rule that uses motion detection to maintain or turn on a light. For a while now, I noticed a significant delay (20 to 30 sec.) between the motion detection and the light coming on.

Here is my setup:

I am running the docker Home assistant 2023.11.3 and MSR 23302 on a Raspberry Pi 4 with raspian 64 bit. Motion sensor are coming from my DSC alarm panel via the HA Envisalink integration. The lights switch are zwave and are handled by HA via zwave-JS-UI.

I am not a software developper nor a specialist but here is, based on the log files of HA, MSR and zwavejs, the sequence of event as I understand it, on Nov 28 :

03:41:48 Home assistant sensor detect the motion. (from HA sensor log)
03:41:48 Reactor log report the "Living Rule Light On Set"
03:42:18 Both the zwavejsui and zwavejs logs show the light activation requests/commands

This is a delay of a little more than 30 ses between time that MSR activate the rule and zwavejs receive the request to turn on the light.

When I look at the detailed MSR logs, I can see that there is some time between the initial rule activation and its completion that correspond to the time line above. Again, without understanding everyting, the delay seemed to be coming from MSR (Or my rules/configuration). Here's the MSR Log:

Access via Synology

Here are the 2 Rules that control the light:

Living Room Light On

Screenshot 2023-11-29 114149.jpg

Living Room Light Off

Screenshot 2023-11-29 114451.jpg

This is not a major issue but it is a change from the initial behaviur I was having.

Thanks in advance

Multi-System Reactor

Using Zooz ZEN32 Scene Controller as Trigger

Hello all, I recently installed a Zooz ZEN 32 scene controller and was looking for some guidance on how I could use a button press as a trigger in MSR. The scene controller has a total of 5 buttons that can activate scenes based on single press, double press, triple till 5 presses and also a press and hold. Currently in MSR I see an entity for the scene controller itself and separate entities for each button.

Using the MSR native Z wave controller I can see the button.state (shows if it was pressed single double...) and button.since which shows the last time the button was pressed. The issue with the button.state is that say I press the scene controller button once its state is single but it never "resets" it's state will remain single. So if I press the button again the trigger won't work (pulse action won't work here because the state never changes).

Going through HA similar issue but instead the x_hass.state is used and the number pertains to how many presses 0 means one press, 3 means 2 presses and so on. But again the x_hass.state never resets to an "off" state so retriggering the rule will not work if you press the button again.

Before I tackle this in other ways using separate rules, input booleans and expressions is there any other way I can go about this? To me I need to trigger that is something like button_pressed.single but I don't see that option.

No logs since there is technically no issues and no real examples since I am stuck at the triggers part lol.

MSR 23302
Z Wave 0.1.23194
HA 2023.11.2

Multi-System Reactor

Upcoming Release -- Plan for the Future

Beginning with the next Reactor release, there will be some dependency changes and new deprecations.

These apply to users on bare-metal installs only. If you are running Reactor in a docker container, the following does not apply to you — the container supplies its own dependencies and will be up-to-date.

All versions of nodejs prior to 18 are now end-of-life (no maintenance), so starting with the next Reactor build, they are deprecated for use with Reactor; they will continue to work until March 1 2024 (about 3 months from now), so you need to upgrade before that date. The recommended version of nodejs is 20, which is the current long-term support (LTS) version (EOL in mid-2026). Version 18 is the prior LTS version and still supported (by OpenJS Foundation and Reactor) until mid-2025, so it's a good fallback if you have issues getting version 20 running. As of this writing, the current 20 is 20.10.0, and the current 18 is 18.18.2. Both have been tested with Reactor 23302.

Now, nodejs version 20.9.0 seems to have dependencies that are not easily resolved on Raspberry Pi OS (formerly Raspbian) Buster (Debian 10). If you are using an RPi running Buster, you should select nodejs 18. That gives you until mid-2025 to upgrade both nodejs and the RPi OS to a more modern version (the current RPi OS is bookworm, Debian 12, 64-bit). The tools/rpi-install.sh script will be enhanced for the next build to try to discern what is reasonable for your system and make the appropriate upgrades; it is safe to run even on a current Reactor install.

If you are running an OS other than Raspberry Pi OS, try for nodejs 20, but use 18 as a fallback if you can't get it installed and running.

Multi-System Reactor

Honeywell TH6320ZW2003_T6_Pro_ZWave shows hvac_control.state="heat" in zwaveJSController

@togglebits I have another one for you.

HASS controller shows hvac_control.state="heating, cooling or idle".

ZWaveJSController controller shows hvac_control.state="heat, cool, or idle"

I believe hvac_control.state="heating, cooling or idle" should be what the ZWaveJSController should show.

"heat", "cool" or "off" are values assigned to the hvac_control.mode attribute.

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 thermostat 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

battery_power.level=0.95 battery_power.since=1700301347874 humidity_sensor.units="%" humidity_sensor.value=40 hvac_blower_unit.filter_change=null hvac_blower_unit.mode="low" hvac_blower_unit.state=true hvac_control.mode="heat" hvac_control.state="heat" hvac_cooling_unit.setpoint=23.5 hvac_cooling_unit.state=false hvac_cooling_unit.units="°C" hvac_heating_unit.setpoint=20.5 hvac_heating_unit.state=false hvac_heating_unit.units="°C" power_source.source=null temperature_sensor.units="°C" temperature_sensor.value=20.5 x_debug.dt={"entity_class":"Thermostat","match":"deviceClass.generic.key=8","capabilities":["hvac_control"],"primary_attribute":"hvac_control.state","description":"T6 Pro Z-Wave Programmable Thermostat","model":"TH6320ZW","default_name":"Honeywell T6 Pro Thermostat","values":[{"valueId":"113:Power Management:Mains status","capabilities":{"power_source":{"attributes":{"source":{"expr":"([ 'unknown', 'unknown', 'dc', 'ac' ])[value ?# 0] ?? 'unknown'","update_only":true}}}}}],"manufacturerId":57,"productType":17,"productId":8} x_zwave_values.Battery_isLow=false x_zwave_values.Battery_level=95 x_zwave_values.Configuration_Adaptive_Intelligent_Recovery=1 x_zwave_values.Configuration_Air_Filter_1_Reminder=0 x_zwave_values.Configuration_Air_Filter_2_Reminder=0 x_zwave_values.Configuration_Air_Filters=1 x_zwave_values.Configuration_Auto_Changeover=0 x_zwave_values.Configuration_Auto_Differential=0 x_zwave_values.Configuration_Aux_Heat_Cycle_Rate=9 x_zwave_values.Configuration_Aux_Heat_Outdoor_Lockout=0 x_zwave_values.Configuration_Auxiliary_Emergency_Control=0 x_zwave_values.Configuration_Auxiliary_Heat_Droop=0 x_zwave_values.Configuration_Auxiliary_Heat_Type=0 x_zwave_values.Configuration_Balance_Point=0 x_zwave_values.Configuration_Clock_Format=1 x_zwave_values.Configuration_Compressor_Protection=5 x_zwave_values.Configuration_Cool_Stage_1_Cycle_Rate=3 x_zwave_values.Configuration_Cool_Stage_2_Cycle_Rate=3 x_zwave_values.Configuration_Cool_Stages=1 x_zwave_values.Configuration_Daylight_Saving=1 x_zwave_values.Configuration_Dehumidification_Filter_Reminder=0 x_zwave_values.Configuration_Emergency_Heat_Cycle_Rate=9 x_zwave_values.Configuration_Emergency_Heat_Type=0 x_zwave_values.Configuration_Equipment_Type=2 x_zwave_values.Configuration_Fossil_Kit_Control=0 x_zwave_values.Configuration_Heat_Stage_1_Cycle_Rate=3 x_zwave_values.Configuration_Heat_Stage_2_Cycle_Rate=3 x_zwave_values.Configuration_Heat_Stages=1 x_zwave_values.Configuration_High_Cool_Stage_Finish=0 x_zwave_values.Configuration_High_Heat_Stage_Finish=0 x_zwave_values.Configuration_Humidification_Pad_Reminder=0 x_zwave_values.Configuration_Idle_Brightness=0 x_zwave_values.Configuration_Maximum_Heat_Temperature=75 x_zwave_values.Configuration_Minimum_Cool_Temperature=66 x_zwave_values.Configuration_Outdoor_Temperature_Sensor=0 x_zwave_values.Configuration_Reversing_Valve=0 x_zwave_values.Configuration_Schedule_Type=2 x_zwave_values.Configuration_Temperature_Offset=0 x_zwave_values.Configuration_Temperature_Scale=1 x_zwave_values.Configuration_UV_Bulb_1_Reminder=0 x_zwave_values.Configuration_UV_Bulb_2_Reminder=0 x_zwave_values.Configuration_UV_Devices=0 x_zwave_values.Configuration_Up_Stage_Timer_Aux_Heat=0 x_zwave_values.Configuration_Ventilation_Filter_Reminder=0 x_zwave_values.Manufacturer_Specific_manufacturerId=57 x_zwave_values.Manufacturer_Specific_productId=8 x_zwave_values.Manufacturer_Specific_productType=17 x_zwave_values.Multilevel_Sensor_Air_temperature=20.5 x_zwave_values.Multilevel_Sensor_Humidity=40 x_zwave_values.Notification_Power_Management_Mains_status=3 x_zwave_values.Notification_alarmLevel=0 x_zwave_values.Notification_alarmType=0 x_zwave_values.Thermostat_Fan_Mode_mode=1 x_zwave_values.Thermostat_Fan_Mode_off=false x_zwave_values.Thermostat_Fan_State_state=1 x_zwave_values.Thermostat_Mode_manufacturerData=null x_zwave_values.Thermostat_Mode_mode=1 x_zwave_values.Thermostat_Operating_State_state=0 x_zwave_values.Thermostat_Setpoint_setpoint_1=20.5 x_zwave_values.Thermostat_Setpoint_setpoint_11=18 x_zwave_values.Thermostat_Setpoint_setpoint_12=26 x_zwave_values.Thermostat_Setpoint_setpoint_2=23.5 x_zwave_values.Version_firmwareVersions=["1.3","1.4"] x_zwave_values.Version_hardwareVersion=1 x_zwave_values.Version_libraryType=6 x_zwave_values.Version_protocolVersion="4.61" zwave_device.capabilities=[49,64,66,67,68,69,112,113,114,128,134] zwave_device.endpoint=0 zwave_device.failed=false zwave_device.generic_class="Thermostat" zwave_device.impl_sig="23318: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=[57,17,8] zwave_device.max_data_rate=null zwave_device.node_id=16 zwave_device.specific_class="General Thermostat V2" zwave_device.status=4 zwave_device.status_text="alive" zwave_device.version_info=[null,"1.3"]

Multi-System Reactor

Dismiss -option for updates

Certain MSR updates are irrelevant for some users (e.g. only Hass related changes when you are not using one), so I was wondering if there could be a dismiss (firmware) feature similar to Hubitat?

Then when you'll use "dismiss", a blue checkmark would disappear until there's a new firmware.

Multi-System Reactor

case statement with a single when clause fails

Noticed that if I try to use a case statement, I'll have to have multiple when clauses, otherwise I'll get syntax error.

(I tried to include a screenshot, but got parse error from the forum...)

The following works:

case when condition == true: "This is true" when condition == false: "Now it is false" else "Something else" end

But this will end up with syntax error:

case when condition == true: "This is true" else "Something else" end

Using build 23242 on Docker

Multi-System Reactor

[Solved] HTTP API no response on perform action

When doing something like curl -o - 'http://localhost:8111/api/v1/entity/ezlo>device_61baf509129e0725bd9f80e1/attribute/dimming.level' I get a response with current dimming level for example "0.6"
but curl -o - 'http://localhost:8111/api/v1/entity/ezlo>device_61baf509129e0725bd9f80e1/perform/dimming.set?level=0.8' sets the dimming level to 0.8 but gives no response which causes the connection to eventually timeout.

Doing it in a browser performs the action but leaves the tab with a spinning wheel of a loading page.

Is this expected behavior?

Edit: Solved in build 22142

Multi-System Reactor

TILT-ZWAVE2.5-ECO tilt_sensor.state (primary) = NULL

@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

battery_power.level=0.99 battery_power.since=1699401727360 binary_sensor.state=false tamper.state=true tilt_sensor.state=null x_debug.dt={"entity_class":"Binary Sensor","match":"deviceClass.generic.key=7","description":"Z-Wave Plus Tilt Sensor","default_name":"Tilt Sensor","model":"TILTZWAVE2.5-ECO","capabilities":["tilt_sensor"],"primary_attribute":"tilt_sensor.state","values":[{"valueId":"32:currentValue:","capabilities":{"tilt_sensor":{"attributes":{"state":{}}}}}],"manufacturerId":330,"productType":4,"productId":3} x_zwave_values.Battery_isLow=false x_zwave_values.Battery_level=99 x_zwave_values.Binary_Sensor_Any=false x_zwave_values.Configuration_Basic_Sets_for_Association_Group_2=0 x_zwave_values.Configuration_Send_Reports=0 x_zwave_values.Manufacturer_Specific_manufacturerId=330 x_zwave_values.Manufacturer_Specific_productId=3 x_zwave_values.Manufacturer_Specific_productType=4 x_zwave_values.Notification_Access_Control_Door_state=23 x_zwave_values.Notification_Access_Control_Door_state_simple=23 x_zwave_values.Notification_Home_Security_Cover_status=3 x_zwave_values.Notification_Power_Management_Battery_maintenance_status=0 x_zwave_values.Notification_UNKNOWN_0x46=23 x_zwave_values.Notification_alarmLevel=0 x_zwave_values.Notification_alarmType=0 x_zwave_values.Version_firmwareVersions=["10.1"] x_zwave_values.Version_hardwareVersion=2 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=14400 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="23305:1:22057: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=1699563172708 zwave_device.manufacturer_info=[330,4,3] zwave_device.max_data_rate=null zwave_device.node_id=24 zwave_device.specific_class="Notification Sensor" zwave_device.status=1 zwave_device.status_text="asleep" zwave_device.version_info=[null,"10.1"] zwave_device.wakeup_interval=14400

Multi-System Reactor

Inovelli LZW31 / Aeotec ZWA037 switches always displaying power_switch.state = false in zwaveJSController

I have just noticed that two of my z-wave switches, Inovelli LZW31 and Aeotec ZWA037, although responding correctly to commands such as (turning on the switch, changing LED color, etc.), are not displaying the right power_switch.state when turned ON. All other attributes are showing proper values.

Example when I turn on either switches,
In Home Assistant (hass), the power_switch.state = true while in ZWaveJSController (zwavejs), the power_switch.state = false.

Reactor version 23302
ZWaveJSController version 23254
Z-Wave JS UI version 9.3.0.724519f
zwave-js version 12.2.3

Here's what the log shows.

[latest-23302]2023-11-01T21:14:00.303Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) starting evaluation; because entity-changed System#reactor_system>system [latest-23302]2023-11-01T21:14:00.304Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) trigger evaluation result is false (previously false) [latest-23302]2023-11-01T21:14:00.304Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) evaluated; trigger state unchanged (false); rule state remains RESET [latest-23302]2023-11-01T21:14:00.304Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) evaluation complete [latest-23302]2023-11-01T21:14:00.308Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) starting evaluation; because entity-changed System#reactor_system>system [latest-23302]2023-11-01T21:14:00.309Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) trigger evaluation result is false (previously false) [latest-23302]2023-11-01T21:14:00.309Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) evaluated; trigger state unchanged (false); rule state remains RESET [latest-23302]2023-11-01T21:14:00.309Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) evaluation complete [latest-23302]2023-11-01T21:14:00.311Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) starting evaluation; because entity-changed System#reactor_system>system [latest-23302]2023-11-01T21:14:00.312Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) trigger evaluation result is false (previously false) [latest-23302]2023-11-01T21:14:00.312Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) evaluated; trigger state unchanged (false); rule state remains RESET [latest-23302]2023-11-01T21:14:00.313Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) evaluation complete [latest-23302]2023-11-01T21:14:00.315Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) starting evaluation; because entity-changed System#reactor_system>system [latest-23302]2023-11-01T21:14:00.317Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) trigger evaluation result is false (previously false) [latest-23302]2023-11-01T21:14:00.317Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) evaluated; trigger state unchanged (false); rule state remains RESET [latest-23302]2023-11-01T21:14:00.317Z <Rule:INFO> Notification: Update Available - Reactor (rule-laeg075n in Notifications) evaluation complete [latest-23302]2023-11-01T21:14:03.258Z <Rule:INFO> Toggle office light LED color state between green/blue Copy (rule-lof5hpwe in Office) starting evaluation; because entity-changed Light#hass>light_office_light [latest-23302]2023-11-01T21:14:03.259Z <Rule:INFO> Toggle office light LED color state between green/blue Copy (rule-lof5hpwe in Office) trigger evaluation result is true (previously false) [latest-23302]2023-11-01T21:14:03.260Z <Rule:INFO> Toggle office light LED color state between green/blue Copy (rule-lof5hpwe in Office) evaluated; rule state transition from RESET to SET! [latest-23302]2023-11-01T21:14:03.271Z <Rule:INFO> Toggle office light LED color state between green/blue Copy (rule-lof5hpwe in Office) evaluation complete [latest-23302]2023-11-01T21:14:03.273Z <Engine:INFO> Enqueueing "Toggle office light LED color state between green/blue Copy<SET>" (rule-lof5hpwe:S) [latest-23302]2023-11-01T21:14:03.285Z <Engine:NOTICE> Starting reaction Toggle office light LED color state between green/blue Copy<SET> (rule-lof5hpwe:S) [latest-23302]2023-11-01T21:14:03.287Z <ZWaveJSController:INFO> ZWaveJSController#zwavejs performing zwave_device.set_config on Light#zwavejs>138-0 with [Object]{ "parameter": "84", "size": 1, "value": 3, "bitmask": 0 } [latest-23302]2023-11-01T21:14:03.345Z <Engine:INFO> Resuming reaction Toggle office light LED color state between green/blue Copy<SET> (rule-lof5hpwe:S) from step 2 [latest-23302]2023-11-01T21:14:03.346Z <Engine:INFO> Toggle office light LED color state between green/blue Copy<SET> all actions completed. [latest-23302]2023-11-01T21:14:05.191Z <ZWaveJSController:INFO> ZWaveJSController#zwavejs node 138-0 no value +currentValue: found for power_switch.state [latest-23302]2023-11-01T21:14:05.205Z <Rule:INFO> Toggle office light LED color state between green/blue Copy (rule-lof5hpwe in Office) starting evaluation; because entity-changed Light#hass>light_office_light [latest-23302]2023-11-01T21:14:05.205Z <Rule:INFO> Toggle office light LED color state between green/blue Copy (rule-lof5hpwe in Office) trigger evaluation result is true (previously true) [latest-23302]2023-11-01T21:14:05.206Z <Rule:INFO> Toggle office light LED color state between green/blue Copy (rule-lof5hpwe in Office) evaluated; trigger state unchanged (true); rule state remains SET [latest-23302]2023-11-01T21:14:05.206Z <Rule:INFO> Toggle office light LED color state between green/blue Copy (rule-lof5hpwe in Office) evaluation complete [latest-23302]2023-11-01T21:14:10.503Z <ZWaveJSController:INFO> ZWaveJSController#zwavejs node 138-0 no value +currentValue: found for power_switch.state [latest-23302]2023-11-01T21:14:10.518Z <Rule:INFO> Toggle office light LED color state between green/blue Copy (rule-lof5hpwe in Office) starting evaluation; because entity-changed Light#hass>light_office_light [latest-23302]2023-11-01T21:14:10.519Z <Rule:INFO> Toggle office light LED color state between green/blue Copy (rule-lof5hpwe in Office) trigger evaluation result is false (previously true) [latest-23302]2023-11-01T21:14:10.520Z <Rule:INFO> Toggle office light LED color state between green/blue Copy (rule-lof5hpwe in Office) evaluated; rule state transition from SET to RESET! [latest-23302]2023-11-01T21:14:10.529Z <Rule:INFO> Toggle office light LED color state between green/blue Copy (rule-lof5hpwe in Office) evaluation complete [latest-23302]2023-11-01T21:14:10.530Z <Engine:INFO> Enqueueing "Toggle office light LED color state between green/blue Copy<RESET>" (rule-lof5hpwe:R) [latest-23302]2023-11-01T21:14:10.542Z <Engine:NOTICE> Starting reaction Toggle office light LED color state between green/blue Copy<RESET> (rule-lof5hpwe:R) [latest-23302]2023-11-01T21:14:10.543Z <ZWaveJSController:INFO> ZWaveJSController#zwavejs performing zwave_device.set_config on Light#zwavejs>138-0 with [Object]{ "parameter": "84", "size": 1, "value": 2, "bitmask": 0 } [latest-23302]2023-11-01T21:14:10.596Z <Engine:INFO> Resuming reaction Toggle office light LED color state between green/blue Copy<RESET> (rule-lof5hpwe:R) from step 2 [latest-23302]2023-11-01T21:14:10.597Z <Engine:INFO> Toggle office light LED color state between green/blue Copy<RESET> all actions completed. [latest-23302]2023-11-01T21:14:12.441Z <ZWaveJSController:INFO> ZWaveJSController#zwavejs node 138-0 no value +currentValue: found for power_switch.state

PS I am trying to attach an image but getting "Something went wrong while parsing server response". Also, not sure if this is related to Reactor/ZwaveJSController implementation or the actual Z-Wave JS UI docker version.

Hopefully I have provided the necessary information.

Thanks in advance.

Multi-System Reactor

Rule's sustain / delay reset etc. value parameterization thru entities

Some background
I have two simple rules that will toggle my carport's down lights depending on outdoor brightness when I open the motorized sliding gate. I.e. if the brightness is 1500 lux or less and the gate is opened, the down lights will be switched on, and when the gate is closed, the lights will switch off after 3 minutes. Pretty simple 'coming home' functionality so to speak.

Here's the switch off rule showing the 'hard coded' thresholds

Screenshot from 2023-10-31 18-44-46.png

The problem
I would like to parameterize the lux and switch off delay using entities. I bet the lux threshold can be done with local expressions the same way I do my WC background music scheduling:

weekdays_enabled = (time() >= time(getEntity( "mqtt>wc-music-weekdays-enable" ).attributes.string_sensor.value )) && (time() <= time(getEntity( "mqtt>wc-music-weekdays-disable" ).attributes.string_sensor.value ))

But the since I'm using the Condition must be sustained for functionality for the switch off rule, I have no idea how to parameterize that with some entity value.

So my question is that is it even possible to do this using entities or could there some other way to accomplish the same functionality? In this example it's the sustain -value but I might need same kind of parameterization for the delay reset also.

I have to go with entities, since my own HA system will provide the threshold values for the MSR through the MQTTController.

Help would be appreciated @toggledbits
br,
mgvra

MSR latest-23302-b7def56a and MQTTController [0.1.23254]

Multi-System Reactor

Have reactor shut off a light with no motion unless I turned it on manually

So I have a strange one here and I don't know if there is a way to do this or not. I have blue iris triggering a vera virtual switch when AI detects motion on my front porch. Reactor then triggers the light, this works perfect. I want to shut the light off when there is no motion, this also works perfect. What I am having am issue with is when someone turns on the light manually I don't want it to turn off after motion is detected. Example: we are expecting a pizza so we turn on the porch light. 5 min later amazon delivers a package, trips motion. 10 min later Reactor is going to turn off the light. If I manually turn on the light before motion is detected I do not want reactor to turn it off. For the life of me I cannot figure the logic out. Does anyone have any ideas?

Multi-System Reactor

Reactor (Multi-System/Multi-Hub) Announcements

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.

Multi-System Reactor

Variable Value select array part

Hi @toggledbits

Is there any way that in the trigger the Varable Value could select the desired part of the array?

For example, I could have a global variable VarTEST$[Part1, Part2, Part3] like this: ${{ [TestText, 5, 3] }}. Use the Variable Value to validate a VarTEST[Part2] == 5 trigger.

What am I doing today? I've defined 3 global variables:

3ae76d20-ffce-4f66-9002-1b4d6cc7c3c3-image.png

And I validate each variable.

3bcc1d62-2ce1-41ca-9f00-f98578c0d597-image.png

In short, I would like to have a global variable of the array type, and be able to select which element of the array I would use for validation in a trigger.

Thanks

Multi-System Reactor

Need Some Help Using browser_mod (HA integration)

Hello all I am trying to run the service call browser_mod.popup from MSR to HA. If I enter the service data in YAML like this:

dismissable: true autoclose: false timeout: 120000 content: type: custom:mushroom-alarm-control-panel-card entity: alarm_control_panel.home_partition states: - armed_home - armed_away layout: vertical show_keypad: true target: device_id: e684ad00b76e330e57a8c915dc367bc4

For some reason the target portion of the data isn't sent and therefor the popup shows up on all my browser mod devices not the only one I had specified in the device_id. Here is a snippet of the reactor log, no errors that I see just looks like the target info isn't being passed on.

[latest-23242]2023-10-12T23:51:50.795Z <Engine:INFO> Enqueueing "Main Floor Tablet Alarm Arming Popup<SET>" (rule-lnmn8t54:S) [latest-23242]2023-10-12T23:51:50.800Z <Engine:NOTICE> Starting reaction Main Floor Tablet Alarm Arming Popup<SET> (rule-lnmn8t54:S) [latest-23242]2023-10-12T23:51:50.813Z <HassController:INFO> HassController#hass action x_hass_system.call_service([Object]{ "service": "browser_mod.popup", "data": "data:\n dismissable: true\n autoclose: false\n timeout: 120000\n content:\n type: custom:mushroom-alarm-control-panel-card\n entity: alarm_control_panel.home_partition\n states:\n - armed_home\n - armed_away\n layout: vertical\n show_keypad: true\ntarget:\n device_id: e684ad00b76e330e57a8c915dc367bc4" }) on System#hass>system succeeded [latest-23242]2023-10-12T23:51:50.816Z <Engine:INFO> Resuming reaction Main Floor Tablet Alarm Arming Popup<SET> (rule-lnmn8t54:S) from step 1 [latest-23242]2023-10-12T23:51:50.817Z <Engine:INFO> Main Floor Tablet Alarm Arming Popup<SET> all actions completed.

So I used an online YAML to JSON converter since I am not the good with JSON and it converted the YAML to this:

{ "data": { "dismissable": true, "autoclose": false, "timeout": 120000, "content": { "type": "custom:mushroom-alarm-control-panel-card", "entity": "alarm_control_panel.bar_partition", "states": [ "armed_home", "armed_away" ], "layout": "vertical", "show_keypad": true } }, "target": { "device_id": "34ae76561192c4bb0b64fb07ad0f01c1" } }

When I use this in my reaction the popup doesn't show up properly. Something pops up but it's just a grey bar. Interestingly the JSON version actually does target only the device_id I had specified. Here is the reactor log output:

[latest-23242]2023-10-12T23:52:39.875Z <Engine:INFO> Enqueueing "Main Floor Tablet Alarm Arming Popup<SET>" (rule-lnmn8t54:S) [latest-23242]2023-10-12T23:52:39.880Z <Engine:NOTICE> Starting reaction Main Floor Tablet Alarm Arming Popup<SET> (rule-lnmn8t54:S) [latest-23242]2023-10-12T23:52:40.291Z <HassController:INFO> HassController#hass action x_hass_system.call_service([Object]{ "service": "browser_mod.popup", "data": "{\n \"data\": {\n \"dismissable\": true,\n \"autoclose\": false,\n \"timeout\": 120000,\n \"content\": {\n \"type\": \"custom:mushroom-alarm-control-panel-card\",\n \"entity\": \"alarm_control_panel.home_partition\",\n \"states\": [\n \"armed_home\",\n \"armed_away\"\n ],\n \"layout\": \"vertical\",\n \"show_keypad\": true\n }\n },\n \"target\": {\n \"device_id\": \"e684ad00b76e330e57a8c915dc367bc4\"\n }\n}" }) on System#hass>system succeeded [latest-23242]2023-10-12T23:52:40.293Z <Engine:INFO> Resuming reaction Main Floor Tablet Alarm Arming Popup<SET> (rule-lnmn8t54:S) from step 1 [latest-23242]2023-10-12T23:52:40.294Z <Engine:INFO> Main Floor Tablet Alarm Arming Popup<SET> all actions completed.

My limited skill with JSON has kind of backed me into a corner here, so if anyone could help me format it correctly that would be great!

MSR latest 23242
HA 2023.10.1

Multi-System Reactor

reactor-lgtv: LG TV Controller for Reactor

Here's my second attempt at a Reactor Controller, this time to integrate LG TVs:

GitHub - dbochicchio/reactor-lgtv: Reactor controller for LG TV (webos) GitHub - dbochicchio/reactor-lgtv: Reactor controller for LG TV (webos)

Reactor controller for LG TV (webos). Contribute to dbochicchio/reactor-lgtv development by creating an account on GitHub.

Standard capabilities are provided and TV volume, mute and switch status are controllable.
There's also an action to send toast notifications on your TV.

webos 5+ is required.

Multi-System Reactor

[SOLVED] New iblind and zwaveJScontroller/MSR not communicating

I installed a new iblind this evening and it is appearing in ZWaveJS. It is operational thru Home Assistant just fine. It is operational thru the HA ZwaveJS plugin just fine.

Where it is non-responsive is in MSR for some reason. The entities are there. Adding the node to a Reaction and then attempting to run said Reaction nets me this:

[latest-23242]2023-09-08T05:33:08.454Z <ZWaveJSController:5:ZWaveJSController.js:655> ZWaveJSController#zwavejs _apply_value motion_sensor.state=false [latest-23242]2023-09-08T05:33:08.455Z <ZWaveJSController:5:ZWaveJSController.js:722> ZWaveJSController#zwavejs setting Binary Sensor#zwavejs>11-0.x_zwave_values.Binary_Sensor_Motion to false [latest-23242]2023-09-08T05:33:08.692Z <ZWaveJSController:5:ZWaveJSController.js:360> ZWaveJSController#zwavejs handling node event statistics updated entity Binary Sensor#zwavejs>11-0 [latest-23242]2023-09-08T05:40:23.960Z <ZWaveJSController:INFO> ZWaveJSController#zwavejs performing cover.open on Cover#zwavejs>20-0 with [Object]{ } [latest-23242]2023-09-08T05:40:23.962Z <ZWaveJSController:5:ZWaveJSController.js:1843> ZWaveJSController#zwavejs no implementation mapped; attempting default [latest-23242]2023-09-08T05:40:25.062Z <ZWaveJSController:INFO> ZWaveJSController#zwavejs performing zwave_device.refresh on Cover#zwavejs>20-0 with [Object]{ } **[latest-23242]2023-09-08T05:40:25.063Z <ZWaveJSController:5:ZWaveJSController.js:1843> ZWaveJSController#zwavejs no implementation mapped; attempting default** [latest-23242]2023-09-08T05:40:25.065Z <ZWaveJSController:5:ZWaveJSController.js:294> ZWaveJSController#zwavejs sending #1694151625064<9/8/2023, 1:40:25 AM>: [Object]{ "command": "node.refresh_values", "nodeId": 20, "messageId": 1694151625064 } [latest-23242]2023-09-08T05:40:26.307Z <ZWaveJSController:5:ZWaveJSController.js:360> ZWaveJSController#zwavejs handling node event statistics updated entity Cover#zwavejs>20-0 [latest-23242]2023-09-08T05:40:26.317Z <ZWaveJSController:5:ZWaveJSController.js:360> ZWaveJSController#zwavejs handling node event value updated entity Cover#zwavejs>20-0 [latest-23242]2023-09-08T05:40:26.318Z <ZWaveJSController:5:ZWaveJSController.js:667> ZWaveJSController#zwavejs update node 20 value "0:128:level:" data [Object]{ "source": "node", "event": "value updated", "nodeId": 20, "args": { "commandClassName": "Battery", "commandClass": 128, "property": "level", "endpoint": 0, "newValue": 100, "prevValue": 100, "propertyName": "level" } } [latest-23242]2023-09-08T05:40:26.319Z <ZWaveJSController:5:ZWaveJSController.js:684> ZWaveJSController#zwavejs updating attributes for node 20 value "0:128:level:"=100: [Array][ "battery_power.level", "battery_power.since" ] [latest-23242]2023-09-08T05:40:26.320Z <ZWaveJSController:5:ZWaveJSController.js:698> ZWaveJSController#zwavejs updating attribute battery_power.level with [Object]{ "entity": "20-0", "impl": { "expr": "float( value ) / 100", "valueId": "128:level:" } } [latest-23242]2023-09-08T05:40:26.321Z <ZWaveJSController:5:ZWaveJSController.js:591> ZWaveJSController#zwavejs _apply_value entity Cover#zwavejs>20-0 battery_power.level [latest-23242]2023-09-08T05:40:26.322Z <ZWaveJSController:5:ZWaveJSController.js:655> ZWaveJSController#zwavejs _apply_value battery_power.level=1 [latest-23242]2023-09-08T05:40:26.323Z <ZWaveJSController:5:ZWaveJSController.js:698> ZWaveJSController#zwavejs updating attribute battery_power.since with [Object]{ "entity": "20-0", "impl": { "expr": "time()", "valueId": "128:level:" } } [latest-23242]2023-09-08T05:40:26.323Z <ZWaveJSController:5:ZWaveJSController.js:591> ZWaveJSController#zwavejs _apply_value entity Cover#zwavejs>20-0 battery_power.since [latest-23242]2023-09-08T05:40:26.324Z <ZWaveJSController:5:ZWaveJSController.js:655> ZWaveJSController#zwavejs _apply_value battery_power.since=1694151626324<9/8/2023, 1:40:26 AM> [latest-23242]2023-09-08T05:40:26.325Z <ZWaveJSController:5:ZWaveJSController.js:722> ZWaveJSController#zwavejs setting Cover#zwavejs>20-0.x_zwave_values.Battery_level to 100 [latest-23242]2023-09-08T05:40:26.333Z <ZWaveJSController:5:ZWaveJSController.js:360> ZWaveJSController#zwavejs handling node event value updated entity Cover#zwavejs>20-0 [latest-23242]2023-09-08T05:40:26.334Z <ZWaveJSController:5:ZWaveJSController.js:667> ZWaveJSController#zwavejs update node 20 value "0:128:isLow:" data [Object]{ "source": "node", "event": "value updated", "nodeId": 20, "args": { "commandClassName": "Battery", "commandClass": 128, "property": "isLow", "endpoint": 0, "newValue": false, "prevValue": false, "propertyName": "isLow" } } [latest-23242]2023-09-08T05:40:26.336Z <ZWaveJSController:5:ZWaveJSController.js:324> ZWaveJSController#zwavejs request 1694151625064<9/8/2023, 1:40:25 AM> (node.refresh_values) success notification [latest-23242]2023-09-08T05:40:26.337Z <ZWaveJSController:5:ZWaveJSController.js:684> ZWaveJSController#zwavejs updating attributes for node 20 value "0:128:isLow:"=false: [Array][ ] [latest-23242]2023-09-08T05:40:26.338Z <ZWaveJSController:5:ZWaveJSController.js:722> ZWaveJSController#zwavejs setting Cover#zwavejs>20-0.x_zwave_values.Battery_isLow to false [latest-23242]2023-09-08T05:40:26.558Z <ZWaveJSController:5:ZWaveJSController.js:360> ZWaveJSController#zwavejs handling node event statistics updated entity Cover#zwavejs>20-0

Please note the highlighted logpart - no other iblind has this. In addition, in MSR>Entities several show as null rather than having a value as the others do.

69631fbc-db4e-4e8d-aa98-10565811cd93-image.png

I tried deleting all Entities associated with this device from MSR and then refreshing ZWaveJS in Home Assistant and restarting MSR - the Entities return but in the same state/s.

Admittedly, it's been a very long three weeks at work - I could have missed something obvious during setup but I sure can't figure what it is.

Multi-System Reactor

For those who registered but didn't received the confirmation email, please send an email to support@smarthome.community with the email you used

Latest version is installed, we are still working on some visual changes.

[Solved] Hubitat>MSR and dedicated Maker API

Locked Multi-System Reactor

4 Posts 3 Posters 183 Views

G Offline

G Offline
gwp1
wrote on last edited by gwp1

#1

I'm posting this question for a couple reasons:
*to show the world that I've probably completely missed the obvious
*just in case I'm not the only one, to share the response with all

@toggledbits - when deploying the latest build you made a point to link to the documents regarding Hubitat and I actually made a point to read them. Something I'd apparently overlooked when configuring my system all that time ago was having a dedicated Maker API for MSR in Hubitat.

Up until last night I'd used the same Maker API for Home Assistant and Hubitat to talk to MSR.

My question: what is the reasoning behind the dedicated Maker API? (ie, what have I been doing to my system all this time....?)
Hubitat C-7 2.3.6.146
Home Assistant 2023.10.5 running ZST10-700 fw 7.18.3
MSR on RPi4 bare metal Model B 2GBs, SSD
MSR latest-23302-b7def56a
MQTTController-23254
ZWave Controller-23254

T 1 Reply Last reply
0
T Offline

T Offline
toggledbits
replied to gwp1 on last edited by toggledbits

#2

@gwp1 That's a remnant of the original version of HubitatController that relied on Maker API exclusively. In these early versions, Reactor had to instruct Maker API to post HTTP status updates to a special endpoint in Reactor — when a device state changed on the hub, Maker API would post the notification to Reactor, and Reactor would respond by updating its entity. Because Maker API allows only one such endpoint per Maker API instance, if you used the same Maker API instance for two subsystems (i.e. Reactor and something else), there was a chance that the two subsystems would fight over who got to be notified when something changed. The fix for this was simply to use one instance per integration.

But for many moons, now, HubitatController has used the (not very) secret, (very) undocumented event websocket for getting update notifications. This works much better, and I wish the folks at Hubitat would just suck it up and say the websocket API is official and supported, because it works so well, and because it's actually widely used by many integrations (i.e. the outcry would be enormous if it went away).

The latest version of HubitatController now only uses Maker API for initial inventory of entities. Prior to build 22067, notice of a device change event on the websocket would cause HubitatController to query Maker API for a full device update. As of 22067, HubitatController instead updates the device with the information given in the event only, no more query to Maker API, so in effeect, Maker API is only used for the initial inventory of devices (that's not true for Modes and HSM currently, but it's likely those, too, will adopt the new approach). This has some potential side-effects, discussed in the documentation, but I think for most users and common use, it's highly unlikely you'll ever run into the cases where such incremental updates cause problems. And they are much faster, because no secondary query is required.

@gwp1 said in Hubitat>MSR and dedicated Maker API:

what have I been doing to my system all this time....?

Nothing, it's fine, at least, it has been since we started using the websocket events. And now that we're doing the abbreviated update, Maker API is used even less. It should be no problem for Reactor to share a Maker API instance with other integrations.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.

G 1 Reply Last reply
2
G Offline

G Offline
gwp1
replied to toggledbits on last edited by

#3

@toggledbits Thank you, good sir - enjoy your time away!
Hubitat C-7 2.3.6.146
Home Assistant 2023.10.5 running ZST10-700 fw 7.18.3
MSR on RPi4 bare metal Model B 2GBs, SSD
MSR latest-23302-b7def56a
MQTTController-23254
ZWave Controller-23254

W 1 Reply Last reply
1
W Offline

W Offline
wmarcolin
replied to gwp1 on last edited by

#4

@gwp1

It would be interesting when the Make Api can do as Hubitat Z-Wave Mesh Details does and give authorization to Extended Device Data, which has very useful information to further augment the Reactor rules.
1 Reply Last reply
0
T toggledbits locked this topic on

[Solved] Hubitat>MSR and dedicated Maker API

Recent Topics