Same Trigger - Different Outputs / Different Results

I have a trigger that I want to turn on a light (Homeseer Device).
If I "trigger" the trigger :slight_smile: with a timestamp inject results are expected. Light comes on for 15 seconds and then goes off.





Note the highlight in the object coming out of the trigger.

BUT! If I am using a MQQT receive. "changed" to a timestamp, then the trigger "triggers" but the object coming out of THAT trigger is a bit different and the light does not get turned on. The light object is seeing something different with this method and does not respond as expected.






Again, note the difference between the object going to the light object with only the timestamp and then the one triggered by the MQQT.
I am pulling my hair out trying to figure out how to get my MQQT to properly turn the light on and off with the trigger.
ANY assistance is greatly appreciated.

The frontDoor text is telling you that the msg topic is "frontDoor".
set the debug to complete message property and it will become clearer that msg.payload is the same in both images.
You could set the change node to delete msg.topic

Thanks so much! I have no idea why I wasn't looking at the complete message in the debug. It would have been much more evident! I guess this is how we learn! Thanks again!

What would be the best way to only have it trigger between sunset and sunrise? I kind of need to keep the MQQT message coming, but maybe trap somewhere before it gets to the light object itself?

Search the flow library for the chron plus node

You can use it to output at sunset and rise, you can then set a context variable to to day or night. you can then set a switch node in your flow using the context variables as the switch property, this will means that depending on the context variable the switch can pass the incoming mqtt message or not.

There are other nodes as well which may be easier to use. I use the sun-position nodes and have a startup flow that outputs sun and moon position every minute to MQTT so that I can use it in other flows simply by subscribing.


There may be, but the cron plus is a great node and why install 2 or 3 nodes when one node does timing events etc and does it well. It also has a great selection of examples of use.

Sure.

Well, I prefer it because I don't need to re-read the instructions to use the sun-position nodes when I often do for CRON+. :smiley: Not everyone needs or wants the complexity of CRON+ - personally, I use both but only CRON+ when I need a more complex schedule where it is worth it.

All very good suggestions, but most of those are a bit overkill for what I need. I have decided to go a slightly different way I created a node from my HomeSeer (Home Automation System) that will tell me "Day" or "Night" (msg.payload.status).
So now I guess I am asking a SLIGHTLY different question. What can I put before my trigger to either pass on my timestamp or NOT pass on my timestamp based on "Home-Front-Virtual-Night Control"?


You could use a change node downstream of the your "House Front Virtual-Night Control" AKA "Home-Front-Virtual-Night Control" node to set a flow context variable.

And a switch node upstream of the trigger to only pass messages when that variable equals "Night"

It might be a good idea to add a second test in the switch to pass the message if the flow variable is null (ie not yet set).
This will give you two outputs to the switch but you can wire both of them to the trigger.
image

If you don't like the resulting "spooky effect" without visible wires, there are contrib gate nodes which take control inputs to pass or block messages.

I use node-red-contrib-simple-gate for such tasks.

This worked great. I have to admit I am still trying to wrap my head around how "flow.daynight" works, but I kind of get the idea. But that fact that it is working is wonderful.

I don't see a node called "node-red-contrib-simple-gate", I am guessing I need to add that to the pallet if I want to try it.

Generally speaking, the data in Node-red is part of a message. It flows along the wires, is used or otherwise processed, then it disappears.

Context variables allow you to save some data outside of this transitory structure, for example so that you can use a value saved from another message to compare with a later message.

It can be confusing when you first start working with a flow based language, hard to grasp that a normal variable set in your javascript does not retain its value between messages.

Yes node-red-contrib-simple-gate. It allows you to block or pass messages by sending the node control messages.

Personally I try and avoid using flow and global context wherever practical. I much prefer to be able to see the links between nodes rather than the action in one node being changed by sending a message to another one.

Thanks for the information on node-red-contrib-simple-gate as it is VERY simple (once I loaded up and example piece of code). Both methods above are great, but in my situation I think the node-red-contrib-simple-gate was the easiest. Thanks again for all the great comments and suggestions!