Halting flow based on state of light, or better way?

Greetings. I'm a complete n00b when it comes to Node Red, but also a dedicated learner, so I'm looking forward to contributing as I become more familiar with how things work.

For my first string, I want to turn on our back light (named Doggy Light) whenever the back door is opened (named East Back Door) after dark, then turn it off again after 8 minutes. This is working marvelously with Node Red.

I see a problem in that if I turn the light on because I'm working or entertaining outside, I do not want it to automatically turn off after 8 minutes. I know that my options are to either:

Only run the string if the Doggy Light is off, OR

Halt the timer node if the Doggy Light is on

I'm unsure how to successfully accomplish this. I've included my current JSON file.

Thanks for the help!

[{"id":"3f8dba6.ff12846","type":"tab","label":"Flow 1","disabled":false,"info":""},{"id":"7bf0f92c.be28f8","type":"server-state-changed","z":"3f8dba6.ff12846","name":"East Door","server":"f4ec457f.b0c348","entityidfilter":"binary_sensor.east_back_door","entityidfiltertype":"exact","outputinitially":false,"state_type":"str","haltifstate":"","halt_if_type":"","halt_if_compare":"is","outputs":1,"output_only_on_state_change":true,"x":70,"y":260,"wires":[["2a3ed802.aca22"]]},{"id":"2a3ed802.aca22","type":"switch","z":"3f8dba6.ff12846","name":"Switch","property":"payload","propertyType":"msg","rules":[{"t":"eq","v":"on","vt":"str"}],"checkall":"true","repair":false,"outputs":1,"x":211,"y":260,"wires":[["230b21e5.789026","606542eb.27561c"]]},{"id":"7b2e78e1.a2398","type":"api-call-service","z":"3f8dba6.ff12846","name":"DogLight On","server":"f4ec457f.b0c348","service_domain":"light","service":"turn_on","data":"{\"entity_id\":\"light.doggy\"}","mergecontext":"","output_location":"","output_location_type":"none","x":566,"y":244,"wires":[[]]},{"id":"5e1f49f4.df3e18","type":"api-call-service","z":"3f8dba6.ff12846","name":"DogLight Off","server":"f4ec457f.b0c348","service_domain":"light","service":"turn_off","data":"{\"entity_id\":\"light.doggy\"}","mergecontext":"","output_location":"","output_location_type":"none","x":566,"y":321,"wires":[[]]},{"id":"230b21e5.789026","type":"time-range-switch","z":"3f8dba6.ff12846","name":"After Dark","lat":"34.95005","lon":"-89.92639","startTime":"dusk","endTime":"dawn","startOffset":0,"endOffset":0,"x":354.5,"y":254,"wires":[["7b2e78e1.a2398"],[]]},{"id":"606542eb.27561c","type":"stoptimer","z":"3f8dba6.ff12846","duration":"8","units":"Minute","payloadtype":"str","payloadval":"","name":"","x":375.5,"y":306,"wires":[["5e1f49f4.df3e18"],[]]},{"id":"f4ec457f.b0c348","type":"server","z":"","name":"Home Assistant","legacy":false,"hassio":true,"rejectUnauthorizedCerts":true,"ha_boolean":"y|yes|true|on|home|open","connectionDelay":true}]

If you haven’t already found it there’s a cookbook of common uses for certain nodes

There’s a flow there which might help you


You can set a context variable using a change node or in a function (see the page in the docs about writing functions using javascript)

Also, as a general guide, I think most of us would break that down to a number of flows. So one flow monitors the light level, another the state of the back door and the final flow that pulls all of that together.

You can retain variables from the first 2 flows and the final flow puts them together to decide the result. Typically people also use MQTT because it can be used as an event monitor. So the first 2 flows write to MQTT topics and the 3rd monitors both topics and is set going whenever one of the changes.

Here's what I did:

It took lots of playing around, but if someone had said, "Hey, check out the Trigger State node," it would have sped things up a lot. Hopefully this helps someone looking to do the same thing. The Trigger State node only sends the payload if certain conditions are met; in this case, those conditions being that the sensor is on (open) and the light I wish to control is off. If those things are true, the string runs. I'm getting the hang of this now.

There are a LOT of nodes now! Looks to be just over 2000 contributed nodes so I doubt that anyone knows all of them :slight_smile:

I can't find one called "Trigger State" actually so you might want to say which node it actually is so that other people with similar issues can find it more quickly?

1 Like

trigger: state - an advanced version of server:state-changed node

Also could be found in the UI by looking at my imgur screenshot and finding the node with the same color/icon...

Your screen shot shows three nodes. One is recognisable as the core Switch node. The other two are not core nodes so we don't know which one is the Trigger State node.

It is not a node that is installed by default with Node-RED so no, we can't just look for one with that colour and icon. What module did you install to get that node? That is the information we're asking for.

Did you click on the image? When it expands, you’ll see there are 5 nodes (one that is used twice).

The first node is trigger: state, and I did not install any additional modules when I created this. The only module I have installed other than what was there when I originally installed Node Red is Twilio.

You did install nodes:

How did you install Node-RED? Is this the Home Assistant addon? If so, that explains it - the Home Assistant packaging includes a bunch of non-default nodes.

Yes it is. If non-default nodes are included with Home Assistant, that explains it, as I absolutely did not install anything other than Twilio.

Could you please check the Manage Palette panel and tell us what nodes that are installed.

I'm happy to. I have:


I understand from previous posts in this thread that these may not be default nodes installed. Those are all I have listed.

As I suspected, it is actually the state-machine node that you are referring to.

Finite State Machines are a bit esoteric for many people so they typically aren't the thing that immediately springs to mind when we are trying to help others in this forum.

I'm certainly not upset about that at all...I'm just passing along that this was a much easier way to do it, and it's probably far less, um, esoteric than splitting such a simple automation among multiple flows. At least that's the case for me.

1 Like