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.
MQTTController configuration with multiple topics per entity
-
Hi,
This post is a kind of feature request and a question at the same time.
I've just recently started to play with the MSR, thanks to friend of mine @tunnus
who recommended to try it out. So bear with me if I'm asking trivial or stupid questions.Some background information of my setup
I have a KNX bus as a hardware backbone which I'm accessing through my own KNXNet/IP protocol stack implementation. On top of that I have NodeJS based dockerized microservices which are communicating using the MQTT. Since I'm still lacking a good rule engine, I've decided to try the MSR, and so far everything is looking pretty promising.
MSR version: latest-22274-24dfd72c (tested on Ubuntu but will eventually run on RPi 4)
MQTTController version: 22260So what is the problem then?
Having well over 100 entities (62 relays alone) definitely means that I have to go with the entity template configuration. I've already succesfully POCed some simple binary and value sensors, e.g. entities that provide only state changes and are so to speak read-only. These are working just fine, but the problem lies within the switches and generally speaking
entities that have actions.But let me first explain how I do the MQTT topic mapping for the KNX group addresses, which are basically unique identifiers for the attributes and functions of the KNX devices.
For example a motion sensor has a single group address, let's say 0/6/0,
for which we the following MQTT topics:For status updates: /knx/0-6-0/status
And for the read operation: /knx/0-6-0/readThe group address 0/6/0 is formatted as 0-6-0 since it would clash with the MQTT topic.
The problem arises with swiches and gets even worse with dimmable lights.
In the KNX world we have separate group addresses for the statuses and for the write operations.
For example a simple switch would have a setup like this:
0/0/55 write (toggle on/off)
0/0/56 status (current status, can be also used to read the status)And for the dimmable light we may have:
0/0/3 write (toggle on/off)
0/0/4 write (absolute dimming value)
0/0/5 write (relative dimming value)
0/0/6 status (current status, can be also used to read the status)Now these would map to MQTT topics like this:
knx/0-0-55/write
knx/0-0-56/read
knx/0-0-56/statusknx/0-0-3/write
knx/0-0-4/write
knx/0-0-5/write
knx/0-0-6/status
knx/0-0-6/readAnd there lies the problem. Since the MQTTController configration is only interpolating the %topic% variable, it's not possible to pass those additional 'write' topics into the template.
I've tried to get my head around this and didn't find any easy solution. One that crossed mind was the possibility to interpolate all the entity's config keys into the template.
I'm open to all suggestions since I would love get on writing the rules and logic with the MSR. Anyway, keep up the good work @toggledbits !
br,
mgvra -
Is there a reason in the actions you don't just:
actions: power_switch: "on": topic: "knx/%topic%/write" payload: expr: true type: json "off": topic: "knx/%topic%/write" payload: expr: false type: json
Also, the %% substitutions will happen with any simple name from the top level on your entity configuration. So, for example:
mh3-ceiling-light: name: "MH3 Ceiling Light" topic: "0-0-56" type: Switch flavor: raspberry uses_template: knx-switch
The substitution
%raspberry%
would be valid in your configuration and template. As would %name% and %type%, if those had any use/meaning. So if you have different construction for read and write, you could just createreadtopic
andwritetopic
for your template to use instead of plaintopic
. Usingtopic
isn't required, and it isn't the only thing you can use.I think it's much more flexible than you are imagining it is, and I'm hoping this key piece of information helps you discover that.
Edit: Please don't screen shot code and formatted data like YAML. Using the fenced code block formatting available and pasting the actual text is preferable (at least, to me, so I can copy-paste from your code to modify it if necessary, rather than having to retype it).
-
Thanks for your quick response!
@toggledbits said in MQTTController configuration with multiple topics per entity:
Is there a reason in the actions you don't just:
actions: power_switch: "on": topic: "knx/%topic%/write" payload: expr: true type: json "off": topic: "knx/%topic%/write" payload: expr: false type: json
Well the problem with KNX is that you need at least two separate group addresses for read/updates and write. And the way the topics are defined in my configuration, there is no common section like %topic% in the middle. So I must do it like: /knx/%status%/read and /knx/%toggle%/write (e.g. /knx/0-0-1/read and /knx/0-0-2/write). Hopefully this makes sense in the config examples below.
I think it's much more flexible than you are imagining it is, and I'm hoping this key piece of information helps you discover that.
It definitely helped a lot and I've managed to get it working. Maybe I've just missed this in the docs. But thanks anyway!
Entity definitions look like this:
# Lights (on/off) mh3-ceiling-light: name: "MH3 ceiling light" toggle: 0-0-55 status: 0-0-56 type: Switch uses_template: knx-switch # Lights (dimmable) living-room-wall-lights: name: "Living room wall lights" toggle: 0-1-5 status: 0-1-16 absolute_dimming: 0-1-28 type: Switch uses_template: knx-dimmable
And their respective template definitions:
knx-switch: query: "knx/%status%/read" capabilities: - power_switch - toggle primary_attribute: power_switch.state events: "knx/%status%/status": "power_switch.state": json_payload: true expr: "payload.data.payload.value" actions: power_switch: "on": topic: "knx/%toggle%/write" payload: expr: "true" type: json "off": topic: "knx/%toggle%/write" payload: expr: "false" type: json set: topic: "knx/%toggle%/write" payload: expr: "parameters.state" type: json knx-dimmable: query: "knx/%status%/read" capabilities: - power_switch - toggle - dimming primary_attribute: power_switch.state events: "knx/%status%/status": "power_switch.state": json_payload: true expr: "bool(payload.data.payload.value)" "dimming.level": json_payload: true expr: "payload.data.payload.value / 100" actions: power_switch: "on": topic: "knx/%toggle%/write" payload: expr: "true" type: json "off": topic: "knx/%toggle%/write" payload: expr: "false" type: json set: topic: "knx/%toggle%/write" payload: expr: "parameters.state" type: json dimming: set: topic: "knx/%absolute_dimming%/write" payload: expr: "parameters.level * 100" type: json
Edit: Please don't screen shot code and formatted data like YAML. Using the fenced code block formatting available and pasting the actual text is preferable (at least, to me, so I can copy-paste from your code to modify it if necessary, rather than having to retype it).
My bad, should have used the formatted code section.
-
@mgvra said in MQTTController configuration with multiple topics per entity:
Maybe I've just missed this in the docs.
More likely I did, but I'll add that to the list.
-
Just checked... it is mentioned in the docs... in the "tip" right before the "Echo Capability" heading:
All topic strings will be put through substitution, and the keywords in the substititions are values from the device configuration (like
topic
). If you have devices with multiple relays, add keywords likechannel
orunit
, mirror whatever the device manufacturer tends to use, so that you effectively parameterize your template and let it work the same for multiple instances of a device's components. To help clarify this, look at the implementation of the "real"shelly_relay
template in MQTTController'smqtt_devices.yaml
file.Probably needs some embellishment to be really clear.
-
By the way, you can also access the configuration values in the expressions you use, by access through the
config
object in your expressions. For example, you could refer toconfig.toggle
orconfig.status
to access those values from your entity configuration.This was not mentioned in the docs and I'm updating it now.
-
T toggledbits locked this topic on