I have a bunch of Zooz Z-wave dimmer switches model ZEN77. I’d like to use Node Red to write a flow that lets me set a 10 minute timer if the lights come on via a motion sensor, BUT I’d like to disable the timer if the lights are turned on by someone physically clicking the button itself. So I guess my question to you all is; “Is there a way to determine HOW the switch was turned on?” The 3 options would be:
Physically touching the switch
Via Node-Red flow
Via Lovelace
I found this post, which is nearly there, but unfortunately my Z-Wave switch does not have a binary_sensor, so I’m not sure if there is a mechanism to accomplish this with Z-wave devices. I hope I’m wrong as these seems like a pretty simple requirement when it comes to home automation. So does HA have a standard way to know when a device has been interacted with, such as with my case, when someone touches the switch?
Yes, look for this message in the payload: data.new_state.context.user_id. Use a debug node (set it to complete message) and look at the output. It shows the user_id of the user that changed the state. If you go to the users in your HA (/config/users) you’ll see all the users, including Supervisor. Click on them and you’ll see their respective user_id.
If it’s physically by touch, most likely the user_id will be empty. If it’s by Node-RED Flow it uses the Supervisor user_id. If it’s through Lovelace you’ll see the user_id of the user that’s logged in. Use this with a switch node and you can determine if a Flow can go through depending on the user (so if it’s 1, 2 or 3).
Thank you that’s very helpful. But as someone new to Node-red I do not see a way to use that data portion of the message. Everything seems to be limited to the payload. I’ve been searching through Google and the list of nodes trying to find one that lets me either read the data…or move it to the payload. Sad that I can see the data portion of the msg…but cannot seem to use it.
That did not work for me, but I was finally able to figure it out, though it might not be the most efficient way. I was able to create a State node and I altered it’s output properties to be msg.payload = event data…so moving the event data into the payload…THEN the switch was able to see and use it. The property in the switch was msg.payload.new_state.context.user_id
You are correct I had unfortunately configured the state node to only output the payload. I was looking at the Debug console information…seeing the data and wondering why the switch could not use the Data information. It was the difference between what the node was outputting and what the debug node was seeing that had me confused. This works great as long as you don’t make the same mistake I made. Now as ASNNetworks said; you can use data.new_state.context.user_id in a switch to see the difference between an automation affects a entities state, or if a person physically touched the switch.
I had a need to find the same information today - whether a switch was turned on by a physical button (input from an ESPHome ESP32 device), the Lovelace UI, or from a Node Red flow.
I started to try to use the events:state node, but wasn’t getting the information as I expected - new_state.context.user_id was always returning a “” and not the correct value. old_state.contect.user_id did have the correct value for the prior method that changed the switch though. Odd.
I ended up using the events:state node when the switch is turned on that then fed into a current state node to get the user_id. In my case, the physical button returned a null, Lovelace gave me the right user id, and Node Red returned the Supervisor ID.
Yes like I mentioned. Btw you can also just use one debug node and set it to complete message. Then you’ll get all information in one go. You only need the events:state node and debug node.
Also if you leave the state:events node state part empty, it sends a payload on all event changes (also attribute changes). Saves a lot of time with debugging.
Seems like this would be a cool node by itself. This is a lot of work to do something that I’d think should be easier. It would be cool if either the state node could have that info right in it’s own UI…or if I could drop some sort of switch node after a state node that gives me 3 outputs, one for each user option.
You use debug node to find the message structure. Once you get more familair with it you don’t even need it, since you’ll know that the message structure is. Debug node is just that, to debug. You use switch node where you can set three (or more) outputs, that switch to either 1, 2 or 3 bases on the message, flow or global states.
I use switch node in many places where an automation changes its route based on what I put there (like entities states, or user interaction like this example).
I understand and I have it working too. I’m just saying it seems really well hidden. We’re lucky the community has experts like you to help us find this sort of data. I’m just impressed with simple solutions like the State nodes “FOR” property. That is REALLY powerful and allows users to not use some convoluted timer nodes in their flows. I was thinking it would be cool if the State node had another property called something like “Created by” and you could multi-select what users you cared about. But what do I know, I’m just started to learn Node-Red so you can ignore me.
Trust me, I’m not an expert. I think I’ve started to use it a lot more advanced like 6 months ago. I just learned a lot by doing and testing, asking around and looking at the Node-RED documentations of the nodes. They have great examples. If highly recommend playing around with the messages, payloads etc. Once you really use those more, you suddenly understand the way Node-RED works a lot more and then a lot of things make sense. The payload structure is so powerful, the more you work with it the more advanced and simple your flows become. I managed to shorten certain FLOWS from 4-5 nodes to 2 nodes.
And then there are stuff like subflows which will introduce a whole new dimension. I find the HA Discord extremely helpfull. Have gotten a lot of help there wich helped me in understanding Node-RED a lot better.
