Option to store state in other node contexts

[yoiang]

Users potentially want to be able to store the LED's state in other contexts, such as global, and have that state retrained further than a single session.

There is the argument to keep a UI element dumb and only represent outside state, however in practice it isn't always worth the work to build a set of flows that robustly manage state in this way and a simple solution would get folks there sooner.

So we can have it both ways whatever this ends up being should be optional.

[colinl]

Just as a bystander this doesn't seem like a good way to go. If the LED was capable of remembering it's state then the same could be said of many other dashboard items such as switches, text display, and so on. A good way to handle this is to use MQTT with topics for each item that has state. Connect an MQTT In node to the LED to display the state, and when setting it feed the required state to an MQTT Out node. Then when the system is restarted the LED will automatically be set to the previous state as it will get fed the current statee from MQTT. A similar thing can be achieved using global or flow context in persistent memory but then you need the additional logic to feed all the variables to the dashboard items on startup.

[yoiang]

Yea, I agree wholeheartedly! That is a proper, robust, safe way to accomplish this.

Realistically tho there are folks and times where quicker is needed or where one doesn't want to spin up the other systems to accomplish it.

If this feature goes in it would definitely have to be optional.

[yoiang]

For the excellent reasons @colinl brought up I'm closing this issue until someone can justify a strong case to make this an optional feature.