Context: I want to use NodeRed to visualise and control my KNX home automation system. I added dashboard and KNX-ultimate to the palette, otherwise it is freshly installed.
Myself: I am an absolute beginner in NodeRed and just created my very first flow. This question is about dashboard switch, I believe.
Problem: I want to visualize ONE switch on the dashboard UI, corresponding to one light that can be on or off. The light is supposed to be switched on/off by either clicking on the dashboard UI switch or by using physical switches in the house or any automated functions like time or whatever. Since the light can be switched from multiple points, it is standard KNX method to use one status message (reporting back after the state changed for whatever reason) and one switch command (instructing the actor to switch on/off and respond with the new status).
Flow: Mostly it works fine. I have a very simple flow with three nodes: KNX-read status > connected to dashboard switch > connected to KNX write on/off.
What works: Using the UI switch, everything works out fine. Exactly one switch event is fired, one status returned and the switch and light fit. No superflous messages.
Problem: When the read status node is fired by an external event like a physical switch, the switch changes correctly its position and fires the write node which in turn sends an unnecessary switch message (e.g. writing "on" to the "on" light). The overall result is correct, i.e. switch and light fit, but one too many switch messages is fired.
Possible solution: If the switch node could distinguish manual UI interaction (then: do the output to the write node) from being triggered by the input connection (then: just switch UI state), this would solve the behaviour.
Is this possible or can such a behaviour be created/programmed?
Yes, configure the switch to not pass through messages and set the switch icon to show the state of the input. Then when you click the ui switch it will send the On/Off signal and the status will come back showing the state changed. When the external switch is operated the ui switch will follow but will not send a message.
The solution Colin proposes also has the advantage that the state of the switch only changes if the real switch is actually turned on and reports its status back (under the assumption that the status report works :-))
Personally I would rather want instant feedback from the UI than this kind of "safety" . Especially if we assume the system is robust enough to work >99% of the time.
I find that the turnaround is so quick that you can't tell the difference. I suppose it will depend on the comms to the external device though. I don't like the possibility that the switch on the ui does not show the physical state of the device, even if only 1% of the time.
Do you have an alternative solution that updates the ui if the external state changes, but also changes the ui switch immediately on touching it? I suppose one could loop the switch output back to the input.
I guess best of both world would be an intermediate state indicating the button is pressed, and then change to the actual on/off state when the state packet arrives.
Check! Great, works as desired. Thank you very much for the rapid response. The problem is solved, the flow behaves exactly as wanted.
Yes, exactly, and that is the necessary and desired behaviour. KNX is extremely robust and reliable and the status is absolutely true. The actor always delivers the real state of the actual hardware switch.
The dashboard UI visualises the real state by listening to the status read node.
Well, the response is very quick and I strongly prefer that the UI represents the real state. Imagine two users accidently interacting at different locations with the same switch.
Agreed. KNX is reliable and I want the visualised states to match that.
Yes, that would be nice, particularly for slower reactions. In my case the reaction time is so fast, that the users does not wonder what happens.
Just as a short additional note: I started with RedNode today and didn't have as much time as I would have wished for -- but RedNode is really excellent and setting up the three-node-flow for the light switch and as simple two-node flow with a chart visualizing the brightness (lux) sensor was so easy and straight-forward, it's a pleasure. I guess, I will use it a lot.
I believe it is possible to change the icon/colour of the switch dynamically so that could be used with a bit of additional logic to show the intermediate state if required.
Ah yes, that could be nifty. All status reads reset the default color of the switch, all output actions make it the intermediate state.
I don't think this is really necessary at the moment, but would certainly be a really professional feature to show off. To visualise the sending and execution is a great idea.
I agree it's overkill if the system reacts in under maybe 250ms. I've got WiFi connected lights (LIFX) which communicate over UDP. With a fader control of brightness a light can get overflowed with packets causing the responses to be delayed or representing a prior position of the fader. For an on/off signal (especially on a wired system) this likely won't be an issue.
. Especially if we assume the system is robust enough to work >99% of the time.