Using the new Dashboard 2.0 UI groups have focus events? I have a use case where I need my flow to query the status of a device and update a button group based on what the device returns as configuration state. This is needed because the device may change state independently of the Dashboard based button group, for example, a IR remote control may change the device state, and I need the Dashboard to reflect.
Just hate to create a default loop to query the device over and over if I can avoid it. Was thinking if the Dashboard had hover or focus events? When ever someone navigates to/hovers over the given UI group, that would be event/trigger I could then query the configuration state of the device.
You can add your own event handlers to Dashboard elements, that is "just" normal HTML event handling.
It wouldn't be sensible to add event handlers to everything just to cover a relatively rare need as this would impact the performance in the browser quite significantly for no gain for the majority of use cases.
Assuming that Node-red gets some notification that a device state has changed, it should be possible to feed it into the node to keep the dashboard in sync.
I'm not sure of the details with a button group.
Not updating a dashboard component unless you hover over it sounds very confusing.
The device is a 16 port HDMI switch, 16 in 1 out. The device has a Windows application but it frankly horrible and using NR would allow control via almost any platform/OS/etc.
The device has 4 different ways that the state can change, pushing a button on the device its self, using an IR remote or via RS232 serial, or RS232 like bytes string via socket/port via LAN port.
All 4 methods do sent state back to the flow. But the scenario of when the device is powered off, a simple tcp ping of the port number would work to emulate no state available.
But if the device is turned on, discovery of the state is no so straight forward. Because the device does NOT send a state initially on power on. Don't ask my why the device does not send initial state out the LAN interface for the assign IP and port (via TCP), But it does not, so even the Windows application has to stopped and started if the device is power on after the application is already running... not a great design.
So, in the old dashboard you could 'watch' for when the operator selected the given dashboard tab, and that could trigger flow logic to get device state. Not perfect, but was thinking a step in the right direction. Or maybe some other event?
But thinking just using a ping node which will 'fire' once a ping is successful I could use for initial power state test, then send query command over socket, and if successful I have a result to take action on. That is still a type of loop is it not? Even if the details are hidden.
It looks like you will have to poll the device, yes.
Your dashboard is liable to be out of sync until you send a ping and it times out, or a socket query errors, whichever is less.
You can mitigate it by having an "Unknown" status display, but it's not ideal.
If you have an MQTT broker I guess you could have a separate device such as an ESP do the polling and publish the result as a persistent MQTT message.
A small Raspberry pi could run Mosquitto and also Node-red to ping the device.
That way Node-red on your PC would know the latest status immediately on startup.
