That would be my first choice, too. The trouble with a sequence of commands is that I haven't found one that would do the toggle (reverse things when repeated). It might not be hard to make flush vs reset a user option, just tricky to make clear what it all means.
I thought the toggle options being proposed were open/closed and open/queuing which would necessitate a deploy (and thus reset) in between. To go queuing to closed would only be via a āspecialā msg , in which case doing a sequence wouldnāt be much harder.
I can't guarantee clarity, but here goes. The toggle command between open and closed already exists. (See the toggleCmd payload in the documentation.) I think what @cymplecy would like is a new control payload (perhaps qtoggleCmd) that would toggle the gate between open and queueing in a similar way. Presumably, that command would have no effect on the gate if it is closed.
Just to see if I could, I've made some mods to add a toggle action option
Seems to work OK on my machine
Done a pull-request from my fork
1 Like
Thanks. I'll take a look.
I've discovered an edge-case issue with this philosophy 
Assuming that restore from saved state is in use...
-
If gate in open/close mode and actually closed:
Then if you configure it to open/queued mode and deploy - you can't control the gate with just a toggle command.
It will stay closed
I propose that in this case, a received toggle command should switch the gate to queued (as likely to cause least disruption to any messages arriving)
Then next toggle would cause gate to goto open mode as usual -
Same happens if gate in open/queued mode and actually closed:
The gate will stay closed on a toggle command
I propose that in this case, a received toggle command should switch the gate to queued (as likely to cause least disruption to any messages arriving)
Then next toggle would cause gate to go to open mode as usual
I've done code changes to implement this so will do a PR if your happy to proceed
Interesting... I would not call this an edge case, since the node has actually had this behavior from the beginning. If you create a new instance and set the Default State to queueing without making any other changes in the node edit dialog, the node will not respond to toggle commands. This is as designed and seems not to have caused any issues in the past. The recent introduction of the alternative toggle definition merely changes the unresponsive state from queueing to closed when that option is selected.
If I understand your proposal correctly, you want the toggle command to force the node out of the unresponsive state. If that state is closed, it would go to queueing. If it is queueing, the safest option would presumably be closed. The choice of which state to enter in these cases is somewhat arbitrary and might not be obvious to the user.
I am not clear how the current behavior becomes a problem for the user. There are only two ways that the node can enter the unresponsive state. One is if that state is the Default State, and the other is if it is entered via a control message. In the first case, the node can be made responsive by selecting one of the other two states as the Default State. In the other case, the user presumably wants the node to be in the unresponsive state and restored to it if persistent context is used. The flow could easily be designed so that response to the toggle command could be restored when needed.
If I am missing something here, or there is an important use case that would be enabled by this change, I would be happy to continue the discussion.
1 I did say it was an edge case 
2. I only setup my gates with a toggle inject so if it doesn't respond to the toggle I have to go back into the node config
3. It happened to me in real life So I investigated it and came up with solution to avoid in future
Did I mention it was an edge case?
