Closed TheOriginalMrWolf closed 3 years ago
Hey, as i said in the other post: I would rather not add more reserved topics to the input of the statemachine. But if you add a query transition to each state pointing to itself, and enable "always send state change" it should basicly do what you requested. Here is an example flow:
[{"id":"c386ce05.778d7","type":"tab","label":"Flow 3","disabled":false,"info":""},{"id":"5e3d180c.e7c2f8","type":"finite-state-machine","z":"c386ce05.778d7","name":"","fsmDefinition":"{\"state\":{\"status\":\"IDLE\",\"data\":{\"x\":5}},\"transitions\":{\"IDLE\":{\"run\":\"RUNNING\",\"query\":\"IDLE\"},\"RUNNING\":{\"stop\":\"IDLE\",\"query\":\"RUNNING\"}}}","sendInitialState":true,"sendStateWithoutChange":true,"showTransitionErrors":true,"x":440,"y":300,"wires":[["c177e365.d61aa"]]},{"id":"e0d0689f.56cae8","type":"inject","z":"c386ce05.778d7","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"run","payload":"","payloadType":"date","x":190,"y":300,"wires":[["5e3d180c.e7c2f8"]]},{"id":"c177e365.d61aa","type":"debug","z":"c386ce05.778d7","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":740,"y":300,"wires":[]},{"id":"515f067c.ed62d8","type":"inject","z":"c386ce05.778d7","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"query","payload":"","payloadType":"date","x":180,"y":360,"wires":[["5e3d180c.e7c2f8"]]},{"id":"dc635137.c22c9","type":"inject","z":"c386ce05.778d7","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"stop","payload":"","payloadType":"date","x":180,"y":240,"wires":[["5e3d180c.e7c2f8"]]}]
Hi, I really appreciate you getting back to me!
Sounds like a good suggestion, however with a state machine with 50+ states & lots of complex state transitions, adding even more states & transitions is a frightening idea...
If I may make a counter-proposal - as per my comment in the other issue - re polluting the transition namespace - maybe you can make a 'reserved' namespace instead (just as an example - topic = "_fsm:sync" or "_fsm:reset" etc) which would help a lot.
Thanks again for considering this!
Hi,
Also, as I say in the other issue -- of course, this is all 'in-band' management.
Another approach - 'out-of-band' - would be to use another msg attribute instead of topic, eg: fsmControl, and send control messages via that. In this case, your 'in-band' topic remains completely untouched.
Also pretty easy to migrate - you deprecate but continue to support the current methods, and implement the new ones on top, with a plan to do the breaking change at a later stage.
Hope this helps! :)
hey, i will add your idea to the next release. thanks for your suggestion.
sorry for all the delay, but i added your suggestions now. Version 2.0 adds an additonal control msg property that can receive either 'reset', 'sync, or 'query'. These words can now also be used in the transition table
sorry for all the delay, but i added your suggestions now. Version 2.0 adds an additonal control msg property that can receive either 'reset', 'sync, or 'query'. These words can now also be used in the transition table
That is awesome, thank you! I will have a look at this later today.
Cheers!
Hi,
Thanks for a really useful node - more people should know about this!
In the spirit of request https://github.com/lutzer/node-red-contrib-finite-statemachine/issues/14 - can we please also get the ability to query the node for current status (that is, send node status query and node emits current state and data just as it did when moved to current state).
This would be very helpful in allowing downstream systems to maintain sync.