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)
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: 2I 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-CPlease, can you advise me on what I should do to solve the problem?
Thanks.
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:
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
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
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.
@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
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.
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" endBut this will end up with syntax error:
case when condition == true: "This is true" else "Something else" endUsing build 23242 on Docker
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
@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
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.statePS 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.
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:
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]
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?
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
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
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: e684ad00b76e330e57a8c915dc367bc4For 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
Here's my second attempt at a Reactor Controller, this time to integrate LG TVs:

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.
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-0Please 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.
Need advice building templates for MQTTController
-
Two thoughts I'm struggling with:
- Regarding the
lwt
key "If this implementation isn't appropriate for your device, don't use the lwt key and handle the device's LWT topic and the x_mqtt_device.online attribute explicitly in your configuration."
Could you elaborate on how I would do this?
I've tried
my_shelly_uni: capabilities: ['power_switch', 'toggle', "binary_sensor", "x_mqtt_device"] primary_attribute: power_switch.state requires: [topic, channel] events: "shellies/%topic%/relay/%channel%": "power_switch.state": expr: 'bool(payload)' "shellies/%topic%/adc/0": "binary_sensor.state": expr: 'int(payload) < "1"' "shellies/%topic%/online": "x_mqtt_device.online": expr: 'bool(payload)'
for Shelly UNI which sends
true
/false
in theonline
topic.- Is there a way to group templates in one "brand" file in the
mqtt_templates
folder? For example aìkea_tradfri.yaml
that hold templates forcontrol_outlet
,light_bulb_e14
,light_bulb_e27
etc.?
Bare-metal install Reactor latest-22343, MQTTController-22340.
- Regarding the
-
@Crille said in Need advice building templates for MQTTController:
I've tried
Sigh. "I tried X"... and...? Config looks right. Not doing what you expect? What have you done to confirm that the topic is being sent by the device (e.g. visible in MQTTExplorer), and received by MQTTController (e.g. turn on topic logging for
shellies/
)? If it's being received by MQTTController (can be seen in the topic logs), what else is in the reactor.log file? If there's nothing standing out in the log, have you upped the log level for MQTTController to 5 to see in detail how the topic is being received and handled?@Crille said in Need advice building templates for MQTTController:
Is there a way to group templates in one "brand" file in the mqtt_templates folder? For example a ìkea_tradfri.yaml that hold templates for control_outlet,light_bulb_e14,light_bulb_e27 etc.?
Any file in
mqtt_templates
can have multiple templates defined in it. It simply uses thetemplates:
top-level key and has the template IDs and specifications indented below that. The templates can also be packaged in a ZIP file for easy distribution as a set, if there are multiple files.But... your template names must include some kind of namespace identifier. Don't name your template
control_output
orlight_bulb_e14
, but rather (for example)tradfri_control_output
andtradfri_light_bulb_e14
to prevent collisions with other (perhaps future) templates in the community.Documentation: https://reactor.toggledbits.com/docs/MQTTController/#publishing-templates-for-the-community
@Crille said in Need advice building templates for MQTTController:
expr: 'int(payload) < "1"'
Comparing numbers to strings is at least bad style, and definitely a bad habit that will bite you some day.
-
@toggledbits said in Need advice building templates for MQTTController:
Config looks right
Thank you, wasn't sure about that.
Sorry for posting in a hurry, here's the rest of "show your work":
This is the entity in reactor config:
entities: "poolvarmepump": name: "Poolvärmepump" topic: "shellyuni-C45BBE6C6DE8" channel: "1" uses_template: my_shelly_uni
The actual device is disconnected from power so I used MQTT Explorer to manually publish in that topic
This is logged in the topic log
2022-12-16T18:57:49.593Z "shellies/shellyuni-C45BBE6C6DE8/online" 0 false false
This is log level 5
[latest-22343]2022-12-16T19:09:47.346Z <MQTTController:5:MQTTController.js:834> MQTTController#mosquitto-mqtt handling shellies/shellyuni-C45BBE6C6DE8/online for poolvarmepump: false [latest-22343]2022-12-16T19:09:47.346Z <MQTTController:5:MQTTController.js:934> MQTTController#mosquitto-mqtt setting Entity#mosquitto-mqtt>poolvarmepump x_mqtt_device.online=false
This is log level 7
[latest-22343]2022-12-16T18:11:20.082Z <MQTTController:6:MQTTController.js:389> MQTTController#mqtt message packet=[Object]{ "cmd": "publish", "retain": false, "qos": 0, "dup": false, "length": 47, "topic": "smartreader/sensor/voltage_phase_3/state", "payload": 232.7 } [latest-22343]2022-12-16T18:11:20.098Z <MQTTController:6:MQTTController.js:389> MQTTController#mqtt message packet=[Object]{ "cmd": "publish", "retain": false, "qos": 0, "dup": false, "length": 45, "topic": "smartreader/sensor/current_phase_1/state", "payload": 6.8 } [latest-22343]2022-12-16T18:11:20.103Z <MQTTController:6:MQTTController.js:389> MQTTController#mqtt message packet=[Object]{ "cmd": "publish", "retain": false, "qos": 0, "dup": false, "length": 45, "topic": "smartreader/sensor/current_phase_2/state", "payload": 0.9 } [latest-22343]2022-12-16T18:11:20.109Z <MQTTController:6:MQTTController.js:389> MQTTController#mqtt message packet=[Object]{ "cmd": "publish", "retain": false, "qos": 0, "dup": false, "length": 45, "topic": "smartreader/sensor/current_phase_3/state", "payload": 4.0 } [latest-22343]2022-12-16T18:11:23.377Z <MQTTController:6:MQTTController.js:389> MQTTController#mosquitto-mqtt message packet=[Object]{ "cmd": "publish", "retain": false, "qos": 0, "dup": false, "length": 45, "topic": "shellies/shellyuni-C45BBE6C6DE8/online", "payload": false } [latest-22343]2022-12-16T18:11:23.377Z <MQTTController:6:MQTTController.js:422> MQTTController#mosquitto-mqtt dispatching shellies/shellyuni-C45BBE6C6DE8/online to poolvarmepump [latest-22343]2022-12-16T18:11:23.377Z <MQTTController:5:MQTTController.js:834> MQTTController#mosquitto-mqtt handling shellies/shellyuni-C45BBE6C6DE8/online for poolvarmepump: false [latest-22343]2022-12-16T18:11:23.377Z <MQTTController:6:MQTTController.js:854> MQTTController#mosquitto-mqtt template in context is [Object]{ "capabilities": [ "power_switch", "toggle", "binary_sensor", "x_mqtt_device" ], "primary_attribute": "power_switch.state", "requires": [ "topic" ], "events": { "shellies/%topic%/relay/%channel%": { "power_switch.state": { "expr": "bool(payload)", "attribute": "power_switch.state" } }, "shellies/%topic%/adc/0": { "binary_sensor.state": { "expr": "int(payload) < \"1\"", "attribute": "binary_sensor.state" } }, "shellies/%topic%/online": { "x_mqtt_device.online": { "expr": "bool(payload)", "attribute": "x_mqtt_device.online" } } }, "actions": { "power_switch": { "on": { "topic": "shellies/%topic%/relay/%channel%/command", "payload": "on" }, "off": { "topic": "shellies/%topic%/relay/%channel%/command", "payload": "off" }, "set": { "topic": "shellies/%topic%/relay/%channel%/command", "payload": { "expr": "parameters.state ? 'on' : 'off'", "type": "raw" } } } }, "__source": "/home/homebridge/reactor/config/mqtt_templates/my_shelly_uni.yaml", "name": "Poolvärmepump", "topic": "shellyuni-C45BBE6C6DE8", "channel": "1", "uses_template": "my_shelly_uni", "entity": { "id": "poolvarmepump", "canonical_id": "mosquitto-mqtt>poolvarmepump", "controller": "mosquitto-mqtt", "type": "Entity", "name": "Poolvärmepump", "lastchange": 1671214268458, "lastupdate": 1671214268458, "can_delete": true, "can_rename": true, "capabilities": { "x_mqtt_device": { "attributes": { "online": { "type": "boolean" } }, "actions": { "poll": { } } }, "power_switch": { "attributes": { "state": { "type": "bool", "values": { "true": "on", "false": "off" } } }, "actions": { "on": { }, "off": { }, "set": { "arguments": { "state": { "type": …, "values": … } } } } }, "toggle": { "actions": { "toggle": { } } }, "binary_sensor": { "attributes": { "state": { "type": "bool" } } } }, "attribute_meta": { "x_mqtt_device": { "online": { "type": "boolean", "last_modified": 1671214268458, "previous_value": false, "previous_last_modified": 1671214268458 } }, "power_switch": { "state": { "type": "bool", "values": { "true": "on", "false": "off" }, "last_modified": 1667398843973, "previous_value": --null--, "previous_last_modified": 1667398843486 } }, "toggle": { }, "binary_sensor": { "state": { "type": "bool", "last_modified": 1667398843973, "previous_value": --null--, "previous_last_modified": 1667398843486 } } }, "attributes": { "x_mqtt_device": { "online": true }, "power_switch": { "state": false }, "toggle": { }, "binary_sensor": { "state": false } }, "actions": [ "x_mqtt_device.poll", "power_switch.on", "power_switch.off", "power_switch.set", "toggle.toggle" ], "primary_attribute": "power_switch.state", "primary_value": false }, "system": { "id": "system", "canonical_id": "mosquitto-mqtt>system", "controller": "mosquitto-mqtt", "type": "System", "name": "Mosquitto MQTT", "lastchange": 1671214263406, "lastupdate": 1671214263406, "can_delete": false, "can_rename": true, "capabilities": { "sys_system": { "attributes": { "state": { "type": "bool" } }, "actions": { "restart": { }, "purge_dead_entities": { "arguments": { "age": { "type": …, "min": …, "default": … } } }, "delete_entity": { "arguments": { "entity_id": { "type": … } } }, "rename_entity": { "arguments": { "entity_id": { "type": …, "sort": … }, "new_name": { "type": …, "sort": … } } } } }, "x_mqtt": { "attributes": { }, "actions": { "publish": { "arguments": { "topic": { "type": …, "sort": … }, "payload": { "type": …, "bigtext": …, "uiclass": …, "optional": …, "sort": … }, "qos": { "type": …, "values": …, "default": …, "required": …, "sort": … }, "retain": { "type": …, "default": …, "required": …, "sort": … } } } } } }, "attribute_meta": { "sys_system": { "state": { "type": "bool", "last_modified": 1671214263406, "previous_value": false, "previous_last_modified": 1671214255282 } }, "x_mqtt": { } }, "attributes": { "sys_system": { "state": true }, "x_mqtt": { } }, "actions": [ "sys_system.restart", "sys_system.purge_dead_entities", "sys_system.delete_entity", "sys_system.rename_entity", "x_mqtt.publish" ], "primary_attribute": "sys_system.state", "primary_value": true }, "payload_raw": "false", "packet": [object Object], "payload": "false", "value": "4.12" } [latest-22343]2022-12-16T18:11:23.378Z <MQTTController:6:MQTTController.js:857> MQTTController#mosquitto-mqtt events for Entity#mosquitto-mqtt>poolvarmepump: [Array][ { "expr": "bool(payload)", "attribute": "x_mqtt_device.online" } ] [latest-22343]2022-12-16T18:11:23.378Z <MQTTController:7:MQTTController.js:861> MQTTController#mosquitto-mqtt entity poolvarmepump attribute x_mqtt_device.online source [Object]{ "expr": "bool(payload)", "attribute": "x_mqtt_device.online" } [latest-22343]2022-12-16T18:11:23.378Z <MQTTController:5:MQTTController.js:934> MQTTController#mosquitto-mqtt setting Entity#mosquitto-mqtt>poolvarmepump x_mqtt_device.online=false [latest-22343]2022-12-16T18:11:23.460Z <MQTTController:6:MQTTController.js:389> MQTTController#mosquitto-mqtt message packet=[Object]{ "cmd": "publish", "retain": false, "qos": 0, "dup": false, "length": 42, "topic": "shellies/shellyix3-98CDAC2F5883/input/0", "payload": 1 } [latest-22343]2022-12-16T18:11:23.460Z <MQTTController:6:MQTTController.js:422> MQTTController#mosquitto-mqtt dispatching shellies/shellyix3-98CDAC2F5883/input/0 to ljussensor [latest-22343]2022-12-16T18:11:23.460Z <MQTTController:5:MQTTController.js:834> MQTTController#mosquitto-mqtt handling shellies/shellyix3-98CDAC2F5883/input/0 for ljussensor: "1" [latest-22343]2022-12-16T18:11:23.460Z <MQTTController:6:MQTTController.js:854> MQTTController#mosquitto-mqtt template in context is [Object]{ "capabilities": [ "binary_sensor" ], "primary_attribute": "binary_sensor.state", "events": { "shellies/%topic%/input/%channel%": { "binary_sensor.state": { "expr": "bool(payload)", "attribute": "binary_sensor.state" } } }, "name": "Skymningsrelä", "topic": "shellyix3-98CDAC2F5883", "channel": "0", "uses_template": "my_shelly_sensor", "entity": { "id": "ljussensor", "canonical_id": "mosquitto-mqtt>ljussensor", "controller": "mosquitto-mqtt", "type": "Entity", "name": "Skymningsrelä", "lastchange": 1671214263452, "lastupdate": 1671214263452, "can_delete": true, "can_rename": true, "capabilities": { "x_mqtt_device": { "attributes": { "online": { "type": "boolean" } }, "actions": { "poll": { } } }, "binary_sensor": { "attributes": { "state": { "type": "bool" } } } }, "attribute_meta": { "x_mqtt_device": { "online": { "type": "boolean", "last_modified": 1671214263452, "previous_value": false, "previous_last_modified": 1671214263009 } }, "binary_sensor": { "state": { "type": "bool", "last_modified": 1671201570383, "previous_value": false, "previous_last_modified": 1671176239276 } } }, "attributes": { "x_mqtt_device": { "online": true }, "binary_sensor": { "state": true } }, "actions": [ "x_mqtt_device.poll" ], "primary_attribute": "binary_sensor.state", "primary_value": true }, "system": { "id": "system", "canonical_id": "mosquitto-mqtt>system", "controller": "mosquitto-mqtt", "type": "System", "name": "Mosquitto MQTT", "lastchange": 1671214263406, "lastupdate": 1671214263406, "can_delete": false, "can_rename": true, "capabilities": { "sys_system": { "attributes": { "state": { "type": "bool" } }, "actions": { "restart": { }, "purge_dead_entities": { "arguments": { "age": { "type": …, "min": …, "default": … } } }, "delete_entity": { "arguments": { "entity_id": { "type": … } } }, "rename_entity": { "arguments": { "entity_id": { "type": …, "sort": … }, "new_name": { "type": …, "sort": … } } } } }, "x_mqtt": { "attributes": { }, "actions": { "publish": { "arguments": { "topic": { "type": …, "sort": … }, "payload": { "type": …, "bigtext": …, "uiclass": …, "optional": …, "sort": … }, "qos": { "type": …, "values": …, "default": …, "required": …, "sort": … }, "retain": { "type": …, "default": …, "required": …, "sort": … } } } } } }, "attribute_meta": { "sys_system": { "state": { "type": "bool", "last_modified": 1671214263406, "previous_value": false, "previous_last_modified": 1671214255282 } }, "x_mqtt": { } }, "attributes": { "sys_system": { "state": true }, "x_mqtt": { } }, "actions": [ "sys_system.restart", "sys_system.purge_dead_entities", "sys_system.delete_entity", "sys_system.rename_entity", "x_mqtt.publish" ], "primary_attribute": "sys_system.state", "primary_value": true }, "payload_raw": "1", "packet": [object Object], "payload": "1" }
and this is a hard refreshed view of the entity
Totally missed the docs for publishing templates, my bad!
Thank you for spotting my mistake, I've corrected the expr for the binary_sensor.
-
OK. I just posted MQTTController 22350 that has a fix to keep from overriding your custom value (it will still try, but yours will prevail).
-
@therealdb My use case for the Shelly uni template is not very generic so I won't publish that to the community but I'm working on some other templates for IKEA Tradfri, Tuya smart plugs and Xioami sensors that might be published later on.
But this fix would be a great addition to your existing templates for Shelly devices.
-
@Crille yeah, I'm just writing some guidance for Shelly Uni, since it's just a dual input/output device and we have template for that. I have template for Shelly Button 1 already in my test environment, and I'll write something for i3 as well, probably using a scene controller as the base (it could be already mapped today as 3 separate devices).
Thanks for the contribution!
-
@toggledbits A few more thoughts:
-
I would like to parameterize
primary_attribute:
andtemperature_sensor.units
to give the user the oppurtunity to choose between for example temperature or humidity and C or F. Before I show you all my failures, is it supposed to be doable in current release? (I'm now doing it by having the same templates in one file but with differentprimary_attribute:
and id's) -
I'd like to suggest more aliases for
value_sensor
for exampleatmospheric_pressure
andsignal_strength
both with.units
. Is that something you would consider or is there another way to accomplish twovalue_sensor
in one entity? -
Before I show you all my failures, is it possible somehow to predefine values for
light_effect
?
Thank you for your patience and let me know if you need me to provide more info if the answer isn't just yes or no
-
-
T toggledbits locked this topic on