I'm looking for a way to switch an mqtt node on for 5 minutes and off for 25. Anyone have any ideas?
You may need to explain what you mean.
Do you mean the node or the server/broker?
Two very different beasts.
MQTT nodes cannot be switched on and off. If you mean you want to send one value to the node then later send another you can use the Trigger node to send the On message then 5 minutes later send the Off message. If you trigger that from an inject node set to fire every 25 minutes then I think that should do the job.
Or if you want to stop sending / receiving in your flow for that time. You can use a flow as Colin suggests to save a context value,
Then in your MQTT flow have a switch that is open or closed depending on the state of the context value.
I had not thought of that interpretation of the question, but if that is indeed the requirement then a trigger node as I suggested but use it to drive a node-red-contrib-simple-gate to let mqtt messages through or not.
Might I recommend my node:
You use it with mqtt topics.
You might also look at Pete Scargill's BigTimer:
I need a continuous loop that sends a payload of 1, waits 5 minutes, sends a payload of 0, waits 25 minutes and starts the loop again.
I think you need to re-think what you are doing and why/how you want to switch the mqtt node on/off
I think if you look at my first post it will do exactly what is needed.
@Colin - being picky - the inject should fire every 30 minutes... and the trigger set for 5 mins.
So you need...
time | signal |
---|---|
00:00 | 1 |
00:05 | 0 |
00:30 | 1 |
00:35 | 0 |
01:00 | 1 |
01:05 | 0 |
and so on? |
Breaking that down, you need 2 events...
Start time | Repeat | signal |
---|---|---|
00:00 | 30 | 1 |
00:05 | 30 | 0 |
How about this...
The node...
node-red-contrib-cron-plus - A flexible scheduler node for Node-RED
The flow...
[{"id":"bd87bd54.f4266","type":"cronplus","z":"5eb10c8e.48d604","name":"","outputField":"payload","timeZone":"","options":[{"topic":"5","payload":"1","type":"num","expression":"0/30 * * * * "},{"topic":"30","payload":"0","type":"num","expression":"5/30 * * * * "}],"x":560,"y":280,"wires":[["c9c8cb3.a050d38"]]},{"id":"c9c8cb3.a050d38","type":"debug","z":"5eb10c8e.48d604","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","x":710,"y":280,"wires":[]}]
Thank you
Absolutely right of course.
Also I like the cron-plus solution more than my suggestion.
The inject plus trigger is just two of the core nodes.
I often advocate using core nodes and even in this instance I'm torn between my own offering and core nodes.
However in this instance, I feel the use of a contrib node fit the problem very nicely and that it permitted me to reply in a manner that helps people understand how we break a problem down to smaller, more manageable parts. more so than the contrib node itself.
Indeed it's a great fit for this solution, and indeed does help to explain the complexities of cron, which are not for the faint hearted.