Open macinspak opened 4 years ago
Maybe have it also "publish" a collection of state changes to simplify flows. Then users do not need to "trigger" a check if they want to get the new state whenever one of the nominated lights changes?
For the flow, I would say it registers as a listener if it acts as a publisher on deployment, all these nodes get a notification of new state for ANY change, then they decide if they are interested in it. If so, then maybe they then retrieve relevant state? Or should this be done centrally? Probably better to do it only once and collate and send to each listener based on lights they are listening for.
Add a node to allow someone to query current state of one or more lights (similar to api call) then we can return multiple keyed light states as an object in, say, msg.lights?