# Reading a value in a number input dashboard node
**URL:** https://discourse.nodered.org/t/reading-a-value-in-a-number-input-dashboard-node/37448
**Category:** General
**Created:** [13 December 2020 16:43 UTC](https://discourse.nodered.org/t/reading-a-value-in-a-number-input-dashboard-node/37448 "2020-12-13T16:43:47Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@Wingnut](https://discourse.nodered.org/u/Wingnut)
#### Post date: [13 December 2020 16:43 UTC](https://discourse.nodered.org/t/reading-a-value-in-a-number-input-dashboard-node/37448/1 "2020-12-13T16:43:47Z")
I'm currently reading values from UDP messages and displaying values in Input Number dashboard nodes. I want to be able to change these numbers and then commit them back through a UDP message.
The only way I can seem to do it is by creating globals in a Function node before displaying them, keeping the globals up to date every time a number is changed with a function on each of the Inputs, and then another Function triggered by a Commit button node that then reads all the globals before constructing the UDP message.
This all seems a bit of an overhead. Is there a way that the 'commit' function can just read the values stored in the Input nodes (like you would do in Visual Basic)?
---
### Author:  [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)
#### Post date: [13 December 2020 17:58 UTC](https://discourse.nodered.org/t/reading-a-value-in-a-number-input-dashboard-node/37448/2 "2020-12-13T17:58:23Z")
Not sure I really understand.
```auto
UDP-in -> Dashboard number input -> UDP-out
```
Why do you need more than that? Perhaps because you want to retain the last incoming number I'm guessing?
```nohighlight
UDP-in -> Change Node (save to var) -> Dashboard number input -> ...
... -> Change Node (save to var) -> UDP-out
```
What else do you need?
Remember that there is no real direct connection between the Dashboard (which runs in a browser window) and Node-RED (which runs on the server). Other than the websocket comms.
---
### Author:  [@Wingnut](https://discourse.nodered.org/u/Wingnut)
#### Post date: [13 December 2020 21:40 UTC](https://discourse.nodered.org/t/reading-a-value-in-a-number-input-dashboard-node/37448/3 "2020-12-13T21:40:09Z")
The incoming message has many values in it. I need to display them and allow the user to change one, several or all. Then the outgoing message must contain all the values including the unchanged ones.
This is a constraint I have to work with as that is how the Owl Intuition works and I have no control over that. I'm trying to work out the optimal way of dealing with it.
Thanks for trying to help.
---
### Author:  [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)
#### Post date: [14 December 2020 01:40 UTC](https://discourse.nodered.org/t/reading-a-value-in-a-number-input-dashboard-node/37448/4 "2020-12-14T01:40:03Z")
The principle should be the same. Either take all of the properties to the Dashboard and back - probably using a Dashboard tempalte - or push everything to the var then to the Dashboard and only send changed properties back. Because you have everything in a saved var, you can simply send everything back via UDP.
---
### Author:  [@Wingnut](https://discourse.nodered.org/u/Wingnut)
#### Post date: [14 December 2020 10:56 UTC](https://discourse.nodered.org/t/reading-a-value-in-a-number-input-dashboard-node/37448/5 "2020-12-14T10:56:27Z")
Thanks.
I've got is set up now with a function that splits the incoming CSV string into its components and passing each (19 in total) property/element to a Numeric Input node which passes the original and any changes to a Change node as you suggested. Then on the commit button, another function reads all the flow vars and assembles them into a CSV string for sending back out over UDP.
---
### Author:  [@system](https://discourse.nodered.org/u/system)
#### Post date: [28 December 2020 10:56 UTC](https://discourse.nodered.org/t/reading-a-value-in-a-number-input-dashboard-node/37448/6 "2020-12-28T10:56:27Z")
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.