Long press before release

I use MQTT for that as I find it makes it easier to keep flows logically organised. So for example there are Input flows that just deal in reading sensors etc and writing the values to MQTT, there are output flows that get data from MQTT and drive relays etc, then there are UI flows that handle the user interface and again interface only via MQTT, and finally control logic flows that drive the whole system.
It doesn't make a big difference to what you are doing except that to add the next requirement you will need to take account of the current relay states and, for example, use a Join node to combine the button press and the current states and decide whether to feed the events to the existing set of nodes or to a new set of nodes that just switches the relays off. If you were using MQTT then the existing flow would publish the required relay state where we currently have the debug nodes. Then you could subscribe to those same topics at the left hand side to Join the current states with the button states. Since you are not using MQTT you can do the same thing with Link Out nodes on the right hand side linked to Link In on the left, which saves having wires all the way from the right crossing back to the left.

Thanks a lot for those tips. I will try that - to tidy up in general. I have used MQTT before but that was mainly to communicate from Rpi to another Rpi.

I think the way I myself would approach this (and this is just my personal preference) would be to take one of the flows above but to change it so that instead of directly driving the relays directly it passes the messages on, either via mqtt or via link nodes, to another flow. If using mqtt you might use something like coffeebutton/shortpress and coffeebutton/longpress as the topics. Note that you only need to detect the press event, not both open and close the relay.
Then on another flow subscribe to the current relay states (maybe coffee/relay1 and cofffee/relay2) and the two button press event topics and feed them all into a Join node (in key/value mode). Make the relay states Retained topics in MQTT so they will automatically get injected into the Join node on startup. Set the Join node to output on two messages and every message thereafter. When used in that mode the Join node message out topic is the topic of the most recent input message so if you feed that into a Function node you can test the topic for shortpress or longpress (ignore relay state change topics) and then combine that with current relay states in the message to determine what to do. So your latest requirement to switch relays off on short or longpress can easily be achieved by checking whether either relay is already on. If both relays are off then whether it is short or long press determines which relay to switch on. Then the function can send one or two messages with appropriate topics (coffee/relay1 or cofffee/relay2) to open or close the relays.
Then on a third flow subscribe to the relay topics and drive the output pins.

That keeps the inputs, gui and control logic nicely separated which, for me anyway, reduces the brain strain when developing the system.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.