Resolve text from number

General
1

Hello,

I receive a status info from my PLC in form of a number. How can I translate that number into a describing text for display?

For example, I receive "140" and the corresponding info text is "Automatic Mode". How can I display in dashboard then "140: Automatic Mode"
Is there a way to create a table in a node to make that mapping?

Thank you!

2

Check out the function node where you can write javascript to achieve what you want.

https://www.w3schools.com/js/js_switch.asp

1 Like
3

You don't need a function node for that. You can do it with a change node. the JSONata option is great for this kind of thing.

Something like:

payload & ": Automatic Mode"

will do the job.

1 Like
4

and where do i make the connection between my list and the text?

5

Sorry, I assumed that you were already getting the data through in a msg - isn't that correct?

Assuming that you are getting a message with the number in it as the msg.payload, simply add a change node which sets the payload to the JSONata formula above. The output of the change node will then have the extra text added.

6

no, I only get a number, and then I have to add the text manually

7

Sorry, not sure what you are saying now.

The outline I've given you will add the text to a number that the change node receives in a payload.

If you actually mean that there are multiple possible numbers, each of which has a text message associated then this too is possible. Create a global or flow context variable containing the mapping:

[
    [ 140, "Automatic Mode" ],
    ...
]

Then use the $lookup function in JSONata to map the incoming number to the text and add the text to the number in the way shown.

1 Like
8

got it

what would be the difference between that solution and a switch case in a function node? Performance?

And there seem to be some here who avoid global of flow context variables if possible

9

A lookup table is a perfectly good use for a flow or global context variable, especially if used in multiple places. The function maybe slightly less performant if you are doing 100s of messages per second, but the case statement may be easier to understand for a programmer. So its mostly up to personal style and what makes sense to you for your application.

3 Likes
10

Well, one at least. However the example here is not a variable, it is a constant lookup table which could, for example, be defined in settings.js.

1 Like
11

I think I might be tempted to declare an array of objects and try find() as described in this link. Not having used find() before would be a strong reason for me to try it :slight_smile:

12

The advantage to using a lookup table is maintainability. As pointed out, there are lots of ways to create such a table and lots of places it can be kept. Personally, I'm liking the new file backing for global/flow "variables" - I tend to have a simple creation flow which is very easy to maintain but I know that the data is always there and is easy to view in the admin interface.

JSONata is also easy to follow for simple transforms such as the one mentioned.

As Dave says, all depends on your experience and needs.

The easiest structure of all would be an object keyed on the number.

{
    "140": "Automatic Mode",
    ...
}

Then you can do the lookup with a simple (function example, JSONata even simpler):

msg.payload = msg.payload + varName[msg.payload]
1 Like
13

When you say creation flow, do you mean you would create the data (file backed flow var) from a flow or create the data set manually and then do the search via a flow
I like to have all flow and data in the flow itself for easy backup (export->clipboard->all flows), so working manually in files I want to avoid...

is the JSONata search a lot faster than the function with switch/case? by a factor of ...?
Other advantages?

I have created a switch/case function but I'm willing to change that for performance and/or stability reasons

14

It is a simple, manually instigated flow, that sets the global variable. Makes it easy to change from within Node-RED. Previously, I either put such data into the settings.js file as a global variable or put the creation flow on the first tab and auto-ran it when Node-RED starts up. None of that is now needed thanks to the file-based variable store.

Couldn't say personally. It should be faster but I doubt you'd notice in most cases. Not sure if anyone has done any benchmarking.

It can be a lot cleaner and it saves a bunch of time maintaining JavaScript code. But it only really saves development effort if the JSONata is reasonably easy to think up in the first place. JSONata is incredibly powerful but it does require a particular mindset as it is very different to the functional approach you have to take using JavaScript. To me, the real benefit is in all of those cases that used to require a function node to do something fairly basic. Occasionally I find it useful to completely reorganise a complex JSON dataset but that is somewhat hit-and-miss as it depends on me happening upon the right transformation.

Well, it will slightly simplify your flow which can be nice but unless any of that is bothering you, I wouldn't bother.

1 Like