search

lutzer / node-red-contrib-finite-statemachine

A finite state machine implementation for node red.
MIT License
16 stars 5 forks source link

feature request: set the state manually? #14

Closed ihaettypo closed 3 years ago

ihaettypo commented 4 years ago

Hi, Thanks for this great node. I was wondering if it's possible to allow us to set the state manually, e.g. msg.topic=[statename]? This will be handy when you want to jump / restore / sync the state.

QED-Associates commented 3 years ago

I second both of those points (great node, and can we set state manually please)!

In my use case - I track status of an external machine with a FSM in NR. Unfortunately, the link between the machine & NR is unreliable. This results in non-valid transitions between states from when comms goes down to when comms resumes. Trying to work around this with current constraint of only being able to reset to a single pre-determined state multiplies the state machine's complexity horrendously.

Being able to simply re-sync to any state when connectivity is resumed would be fantastic.

Thanks again!

lutzer commented 3 years ago

hey, sorry for taking so long to respond to this request. i will slowly try to work on the requests that were made. I added a sync functionality to the next version 1.0.5. It will be released tomorrow. So you can send a msg with the topic "sync" to set the state manualy to one which is present in the transition table. What i dont like about this change, that there will be one additonial topic reserved now, that cant be used for transition names (reset and sync).

TheOriginalMrWolf commented 3 years ago

That's awesome, thank you! Comment noted 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 :)

lutzer commented 3 years ago

yeah. that could be a good solution. I might change that on the next release, but then it might break some flows that are currently using it. thanks!

TheOriginalMrWolf commented 3 years ago

Cool.

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! :)