State node based on external timer messages

[asferreira]

Hello,

Reading the State node code I noticed that all state control is based on the node's own timer functions. It would be nice if the State note could do the state control based on an external timer, using, input messages with a timestamp attribute originated, for instance, from a Scheduler node.
My reasoning about this feature is to reuse already existent timers and reduce system's resource usage.
@jensrossbach , do you think it is feasible?

[jensrossbach]

Hi, I'm not sure if I completely understand your usecase.

State node already supports triggering state changes manually by passing a message to it having msg.topic set to "set" and msg.payload set to the identifier of the state to activate. However, this does not prevent the internal timer to be scheduled.

In the next release I plan to provide the possibility to configure states that do not have a trigger time associated and hence can only be triggered manually. But configuring only such manually triggered states removes one of the main advantages of the state node compared to e.g. the scheduler node: the possibility to restore the current state in various situations. This is only possible for states with associated trigger times as the times are the base for the restoration.

One thing I could think of is a flag/option to supress any automatic state changes based on the time (and hence, no timer will ever be scheduled internally). In this case, the states could keep their trigger time and restoration is possible but at the same time, state changes must be triggered from external (e.g., scheduler node) via a message.

[asferreira]

My basic use case is to have states change according to time events, exactly as the State node does, but instead using node’s internal timer schedules, the time information would be provided by messages that would be periodically sent by an external node (e.g. the scheduler node). Since I already have a bunch of time events generated by a scheduler occurring on my flows, I would like to reuse them as a control source of state changes, without creating more timers. I think your idea of using a flag to control that state node behavior would solve my problem. I just don’t know how difficult it would be to implement that! Anyway, if you judge this feature would be worth to add to the state node, I would be glad to test and use it. Best regards, Anderson

…

On 21 Apr 2024, at 13:09, Jens-Uwe Rossbach ***@***.***> wrote: Hi, I'm not sure if I completely understand your usecase. State node already supports triggering state changes manually by passing a message to it having msg.topic set to "set" and msg.payload set to the identifier of the state to activate. However, this does not prevent the internal timer to be scheduled. In the next release I plan to provide the possibility to configure states that do not have a trigger time associated and hence can only be triggered manually. But configuring only such manually triggered states removes one of the main advantages of the state node compared to e.g. the scheduler node: the possibility to restore the current state in various situations. This is only possible for states with associated trigger times as the times are the base for the restoration. One thing I could think of is a flag/option to supress any automatic state changes based on the time (and hence, no timer will ever be scheduled internally). In this case, the states could keep their trigger time and restoration is possible but at the same time, state changes must be triggered from external (e.g., scheduler node) via a message. — Reply to this email directly, view it on GitHub <#154 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARFIKNMQVEVLOF2WT23KODY6PQCVAVCNFSM6AAAAABGRM2FJKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TCNZZHE3DG>. You are receiving this because you authored the thread.

[jensrossbach]

Please try out the new passive trigger mode that I introduced in release 1.23.0. There is also a new command "trigger" available which should be used in combination with that mode. See documentation of state node for more information.

[asferreira]

Hello!

I already did and It worked perfectly!

Thank you very much.