How to extract object names with special characters?

General
1

Hi,
my Tasmota Temperature Sensor with two sensor devices is delivering object names with the following name:

msg.payload.DS18B20-1.Temperature
msg.payload.DS18B20-2.Temperature

Unfortunately Node-Red can neither read DS18B20-1 nor DS18B20-2 as a valid object name.

It says: Expected an identifier and saw "DS18B20-1"

Unfortunately this IS my identifier and I have no idea what I can do to get these values from these objects.

Any ideas out there ?

BR
Gawan

2

When a property contains special characters you can use the alternative syntax:

msg.payload["DS18B20-1"].Temperature
3

wow ... it really works :smiley: :smiley: :smiley:

How did you know that ???

4

It's JavaScript - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Property_Accessors

5

In addition you would make your life easier if you used underscore instead of - in the names.

6

unfortunately the naming is done by the Tasmota firmware automatically and it is creating a serially numbered ID

7

Yes you are right, there have been discussions about making it variable bit it has not happened yet. In this situation then personally I would pick up the value and immediately republish it to MQTT with a more meaningful name (home/bedroom/temperature or whatever matches your naming convention) and use that.

8

yes, that makes sense ... but nevertheless I have to read them once from MQTT with these IDs :slightly_smiling_face:

instead of republishing them, I am using global variables in Node-Red a LOT to store the values temporarily

9

You would just need a change node between the mqtt nodes, so the minus wouldn't be a problem.

A bad idea in my opinion. Just pick them up direct from mqtt. Then your flows automatically get triggered when the values change.

10

Thats not how my setup works :slight_smile:

I get MQTT messages whenever a parameter changes (or every 10 secs via Tasmota if they do not change) and store them in global variables in Node-Red (approx 200 different in total right now.)
All subsequent process steps (like writing the value to SQL database or showing them in a chart) is timewise independent and simply reads the latest value from Global Vars.

E.g. it does not make sense for me to store some figures every 10 sec into the SQL DB - there is another process that triggers every 15 mins
Linecharts get new data every 2 mins

If I need a live-trigger from a MQTT-message I connect the step in parallel to the process step that writes the Global Vars

1 Like
11

None of those are major reasons for using globals, there are ways of achieving the same same functionality without, but it is a personal choice.

12

or use an RBE node to filter out duplicates and only write immediately they actually do change.

13

Are there ?

I am using the Global Vars as "single point of information" for my whole Node-Red Installation.

e.g. I do an online-monitoring by verifying the latest UpdateTimeStamp of a Global-Var-Object - independent of the MQTT-Input side

or I compare up to 4 parameters to decide a "next process step" - independent when they were updated the last time - like if I turn on the light in the garage when its bright or dark outside
the bright or dark parameter is delivered via MQTT, but changes only twice a day, so I have to store it somewhere

14

For your scenario, your use of context values is perfectly sensible and what they are intended for.

MQTT is great if you need to trigger something when a value changes.

But if you have flows that run independently of the MQTT nodes that need to refer to the latest values, then context is the perfect solution.

15

hm ... yes, but thats what I do :slight_smile:
I use context values ... and there we have NODE, FLOW and GLOBAL

what I do is setting the global values

16

Just curious. Do you have these as separate global variables or as properties of 1 or 2 objects that are stored in global?

I do something similar where values come from many different sources - but are related & I need to know values independentantly. I pack them up into an object that I store in flow or global context - makes things easier to manage and visualise.

17

One device (e.g. sensor for water temperature) is one object consisting of a TimeStamp (in readable format), a serialized TimeStamp (for Usage in Node-Red), sometimes a devicename (for ESP8266 sensors and actors) and 0-x measured values
image
image

I really like it because it is slim and easy to use :slight_smile:

and in most cases the whole object is updated by one specific MQTT package

1 Like
18

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.