Best practices: concurrent update values on a device and receive the current ones on the same input control

Dashboard
1

Hi,
i am developing a ui to control a device. The device is sending me by mqtt every sec the current values saved in its registers. I am showing these values on the ui, but i need to allow the user to change them and save the new values into the device. So for example i am showing a temperature but i want my user to change the value and save it back. Now a problem occurs:

  1. if i show the current value on a numeric input control, when the user is choosing his value, the input value is reset before his submit. unusable, because the current value is sent every second.
  2. if i used an rbe node, to stop updating the input control, i would have on the ui the value selected by the user only, but not what is actually stored into the device.
    I have thought three solutions to tackle these problems. i would like to know if they can be considered good practice or if some of you had a similar experience and can suggest me new ideas or hints.
  3. showing only the current value on the ui and editing the values on a modal dialog, then submit them to the device. The user can check if his values are really saved waiting for the ui update. minus: a lot of additional code, to manage the dialog and the form there in a template node.
  4. a trigger node, with a timeout. the ui will show the user chosen value for a certain amount of time then it resets back to show the current value. minus: dirty solution
  5. showing the values in a text node, and updating them using input controls which are not related to the current values. minus: a lot of values flooding the ui, and duplication for custom visualizations.

every comment and idea is appreciated.
thanks.

2

Perhaps send the value back via MQTT on a separate topic. Get the device to listen to that topic and use local processing to change the value on the device.

While you might still get some old values after the use has updated - maybe 1 depending on the exact timing - the device can easily have the logic to change the local value without conflict.

3

@TotallyInformation thanks for the reply. yes it's already like that, i am sending the commands to set the values on the device on a different mqtt topic. the problem is that or the user don't click the submit button or for some reason there is an error in communicating with the device the ui will show a different value than that one saved on the device.

4

I don't understand why that is the case. As soon as the user enters a new value it will go round the loop and get through the RBE the first time.

5

Well that would seem to be a UI design issue rather than anything else. Perhaps you should remove the submit button?

7

as soon as the user enters a new value it will go round the loop and get through the RBE the first time.

yes this is correct. but if the user don't submit the values to the device, with the submit button, the ui will show his choices for ever without any updates. in this case i thought of a trigger timeout to 'clean' the ui and reset the rbe, so the ui could be updated., if the user didn't click the 'submit values' button

8

@TotallyInformation and so i have to update the device silently when the user change a value on the ui? there are numeric input controls, so at every click on up and down buttons should i update the device?
it's an idea but a bit heavy.

9

You could buffer the value in the flow and send it to the device when it has not changed for a few seconds. Then it will not change till the user has finished entering. You can do that with a Trigger node (send nothing then send latest message after an interval).

10

yes this is a solution for not updating at every click, but in any case, if there is a problem updating the device, i should reset the values chosen by the user by a trigger node timeout.