Request: set close state on first message

[woytekbode]

Hi! Really like this node, very useful for home automation stuff where you want to block repeating messages from sensors and switches.

Was wondering if it is possible to implement a new feature into this node. I'd like to have an option (check box) to set the node state to closed after receiving a first message.

In my example, I'm using a Hue Wall Switch Module that has two inputs. It gives an event on button press, quick button release, hold button (repeating every 800ms) and hold button release. I want to use the hold button event to trigger a repeating message for dimming a Hue light and use the hold button release to stop/reset the trigger. Therefore, I only need the first hold button event for my example and ideally have the gate closed automatically after receiving the first message.

Let me know what you think!

[colinl]

Do you mean you want it to close after any message or only the very first one it ever receives?

[drmibell]

I suspect that the gate node may not be the best choice here. The filter (formerly rbe) node is designed specifically to eliminate repeated messages. You haven't said whether all of your messages are exactly identical. If the press, hold, and release messages can be distinguished, it should be fairly easy to get the sequence you want.

[woytekbode]

@colinl any first message it receives after starting or after re-opening with a reset command.

@drmibell thank you! I haven't come across the filter node yet, I will try it and see if it helps in this particular case. The messages have the same topic (deconz_event) but their payload is different. They have payload.event.id (device id) and payload.event.event (event id) so those can be used with a switch node to filter.

[colinl]

You can do what I think you want very easily just with a Change node (and the gate).

[{"id":"b10d142b.cec088","type":"inject","z":"eaa304df.eba478","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":150,"y":1200,"wires":[["88590618.ffb2f8","8f8323b1.4a8d28"]]},{"id":"8f8323b1.4a8d28","type":"change","z":"eaa304df.eba478","name":"Close","rules":[{"t":"set","p":"payload","pt":"msg","to":"close","tot":"str"},{"t":"set","p":"topic","pt":"msg","to":"control","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":310,"y":1240,"wires":[["88590618.ffb2f8"]]},{"id":"88590618.ffb2f8","type":"gate","z":"eaa304df.eba478","name":"","controlTopic":"control","defaultState":"open","openCmd":"open","closeCmd":"close","toggleCmd":"toggle","defaultCmd":"default","statusCmd":"status","persist":false,"storeName":"memoryOnly","x":470,"y":1200,"wires":[["9ced743a.f6222"]]},{"id":"9ced743a.f6222","type":"debug","z":"eaa304df.eba478","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":590,"y":1280,"wires":[]},{"id":"7391588c.712768","type":"inject","z":"eaa304df.eba478","name":"Open","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":180,"y":1340,"wires":[["2328d32c.424294"]]},{"id":"2328d32c.424294","type":"change","z":"eaa304df.eba478","name":"Open","rules":[{"t":"set","p":"payload","pt":"msg","to":"open","tot":"str"},{"t":"set","p":"topic","pt":"msg","to":"control","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":310,"y":1340,"wires":[["88590618.ffb2f8"]]}]

[woytekbode]

You can do what I think you want very easily just with a Change node (and the gate).

[{"id":"b10d142b.cec088","type":"inject","z":"eaa304df.eba478","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":150,"y":1200,"wires":[["88590618.ffb2f8","8f8323b1.4a8d28"]]},{"id":"8f8323b1.4a8d28","type":"change","z":"eaa304df.eba478","name":"Close","rules":[{"t":"set","p":"payload","pt":"msg","to":"close","tot":"str"},{"t":"set","p":"topic","pt":"msg","to":"control","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":310,"y":1240,"wires":[["88590618.ffb2f8"]]},{"id":"88590618.ffb2f8","type":"gate","z":"eaa304df.eba478","name":"","controlTopic":"control","defaultState":"open","openCmd":"open","closeCmd":"close","toggleCmd":"toggle","defaultCmd":"default","statusCmd":"status","persist":false,"storeName":"memoryOnly","x":470,"y":1200,"wires":[["9ced743a.f6222"]]},{"id":"9ced743a.f6222","type":"debug","z":"eaa304df.eba478","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":590,"y":1280,"wires":[]},{"id":"7391588c.712768","type":"inject","z":"eaa304df.eba478","name":"Open","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":180,"y":1340,"wires":[["2328d32c.424294"]]},{"id":"2328d32c.424294","type":"change","z":"eaa304df.eba478","name":"Open","rules":[{"t":"set","p":"payload","pt":"msg","to":"open","tot":"str"},{"t":"set","p":"topic","pt":"msg","to":"control","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":310,"y":1340,"wires":[["88590618.ffb2f8"]]}]

Absolutely right! Actually, that is the exact solution I'm using now. I think this might be a fairly common use case and the added functionality will reduce the addional change node and thus clutter. For one flow that's fine but for many switches in a typical home setup it would be a nice quality of life change.

@drmibell I just tried the suggested filter node and I think you are right. This node is a better fit for my purpose, thank you for pointing it out to me, I haven't come across it during my search for a good node. With the (rbe) filter node I can replace the change and gate nodes. And more importantly, I can use the filter node much earlier in the flow by placing it in front of the initial switch that filters the messages!

[colinl]

If you happen to have a function node immediately prior to the gate then, instead of the change node, you could replace the return msg at the end with

node.send(msg)
return {topic: "control", payload: "close"}

[drmibell]

I am glad you have found ways to resolve your issue. I see the reason for your suggestion and feel that I should explain why I would rather not modify the gate node. First, I think I would be stepping onto a slippery slope. There has already been a request to close the gate for a specified length of time after passing the first message. I would also expect interest in keeping it closed for a certain number of messages after the first, and so on. All these cases can be managed easily with external logic, while modifying the node would add complexity to the user interface and to the node itself. Second, today's "clutter" is tomorrow's (or next year's) readability. I think that troubleshooting or modifying flows is much easier if the logic is exposed in the wiring and messages rather than buried in options that are visible only in the node's edit dialog. Finally, I have used a design approach for gate and its sister node queue-gate that I think has made them more useful and easier to troubleshoot. The messages that control the state of the gate are kept completely separate from the message traffic that is being controlled. This makes the state of the gate fully predictable and reproducible. This would not be case if messages passing through the gate, over which the user may have no real control, were allowed to change its state. This is a long comment, but I hope it helps you understand my thinking.