I’d like to have a sequence run when a z-wave switch is physically turned off but not when automation turns it off. Under ST and Webcore, there was a “physically changes” option when triggering off an event state, does anything like this exist in Node Red?
1 Like
Yes there is. If the device’s state changes it can in node red initiate a flow. However… zwave device must support instant status update to trigger that. Some (mostly older) zwave devices do not have instant status updates in zwave. These must be relied upon with polling to get the status. Thus, not instant.
I’m aware that the device state change can trigger a flow. What I need to know is how the device state was changed. Was it via z-wave commands or was it via someone physically flipping the switch?
Sorry have thought about it but do not know.
Use a debug node and dump msg.data from an event node and looks for msg.context.user_id in most cases this will have a valid user id if it was changed from within HA and null if it wasn’t.
3 Likes
Brilliant!! Thank you!
watch out, state of relay might change because of other reasons than clicking HA UI. for example those might interact with other devices or because of power loss after repowering. they can have internal logic etc.
Try to find out if your switch reports button presses next to relay changes
Thanks for the heads up! Using the events: all node doesn’t show any additional events when the switch is toggled. I’m not super concerned about power restoration events. I’m only dealing with events that change the light from on to off or vice versa so I’m not sure what internal logic would affect that. Do you have any examples of these I should look out for?
A way I have overcome this, specifically for light automations, where I wanted to disabled any motion sensor automations when I turned the light on manually, was to use input booleans, and integrate them into the automations.
Not sure if this is what you’re trying to accomplish or not.
Interesting, can you please elaborate on the how inout booleans help achieve this?
@onkytonk you don’t need to create input booleans for that, see my blog post (shameless self-promotion 
).
This is a very elegant solution. 
My implementation came from my early days in NodeRed, where I tried to recreate the yaml automation I had created, by utilising input booleans.
@iderdik
I guess @mbonani flow might be more suitable, and tidier, but nonetheless, I used input booleans that got triggered as part of an automation, and the secondary part of the automation checked that state of the input boolean before proceeding.
EDIT: @mbonani
I’ve just realised your solution utilises a separate switch/binary sensor to control the light.
You still need input_booleans if the light is being controlled not by a switch, but the entity itself.
1 Like
I agree. I don’t like doing that because, for me, it feels like unscrewing and screwing the light bulb back in. But don’t mind me, I’m just a weird person. 
1 Like
Since you’re already in node-red, it would be easier to use its context instead of the workaround via input_*
I have z wave in wall switches, so there is a separate binary_sensor/switch to control these.
So I can’t use your solution.
You actually just made me rethink my flow, and utilise a traffic node.
I don’t know much about the context node, but I’ll look into it - it could be another suitable solution.
Context is another word for variables, which you can set and use at 3 different levels: within a node, within a flow, and globally for all your flows. In your case you’d probably use the flow context.