I am an absolute beginner with Node-Red but I have had some success with the help of Open-AI to suggest how things should be configured.
What I am trying to do is populate an Influx Database from a MQ_TT source and it works fine as long as everything is fields. My fields are value_num, value_str and topic. Topic will be populated by a string similar to "meteorcams/nz0014/starcount". As I said, this all works if all three are fields but I want topic to be a tag for indexing and sorting. But no matter what I have tried, the tag will not populate in the database. The function I am using is as follows:
// ---------- Node-RED Function: MQTT → InfluxDB v1.x ----------
//
// Input examples:
// meteorcams/nz0014/nextcapstart : "2025-10-26 07:11:02.642132 UTC"
// meteorcams/nz001p/meteorcount : 123
//
// Output for InfluxDB v1.x Out node:
// msg.measurement = "messagesV5"
// msg.tags = { topic: "meteorcams/nz001p/meteorcount" }
// msg.payload = {
// value_num: 123, // if numeric
// value_str: "2025-10-26 ..." // if string
// }
//
// ------------------------------------------------------------
let topic = msg.topic || "";
// Normalise to lowercase, keep the FULL topic path (no truncation)
let topicTag = topic.toLowerCase();
// Build the field payload
let payload = {};
if (typeof msg.payload === "number" || (!isNaN(msg.payload) && msg.payload !== "")) {
payload.value_num = Number(msg.payload);
} else {
payload.value_str = String(msg.payload);
}
// Assign InfluxDB v1.x message structure
msg.measurement = "messagesV5";
msg.tags = { topic: topicTag };
msg.payload = payload;
return msg;
I need some human help. Open-AI just goes around in circles
Look at the help text for the influx node in the right hand pane in the node red, that tells you how you need to construct msg.payload for fields and tags. If I remember correctly you need it to be an array of two elements, the first being an object containing the fields and the second being an object containing the tags. Check that though, I am not at my PC at the moment. If you ask AI how to build such a payload you may get better results
First, though, I recommend watching this playlist: Node-RED Essentials. The videos are done by the developers of node-red. They're nice & short and to the point. You will understand a whole lot more in about 1 hour. A small investment for a lot of gain. AI can be very helpful, but it is much more helpful if you understand better what you want to do.
Thanks Colin.
Excellent advise. The notation used in Node-Red is only about 2 days old in my experience. I have relied on OpenAI to write me the code and have got good results so far. However it has been stubbonly difficult with this one. It goes in circles and even tells lies.
I am aware of what you say about the two elements and looking back at the code I posted, I see
might be the wrong way around. When I get back to this I might try that. I'd kick myself if it is that simple.
Thanks for the link. I will watch that.
Peter
If you feed the output of the function into a Debug node then in the debug pane you need to see , in message.paylad, something like [{field1: 32, field2: 7}, {tag1: "tag1_string", tag2: "tag2_strings"}]
Note that that is an array not a string. Also make sure the the fields are numbers (not strings) and the tags are strings.
For example, this is what one of my messages looks like
Thanks Colin.. I solved it. You helped me focus on the array of 2 elements and I could see that msg.tag was outside the payload. The notation is still a bit too dense for me at this stage so I copied and pasted the help into ChatGPT which came up with this
and it works. I now have the tag topic in the database. It is still reporting a NaN error but I think I will ignore that for the moment as it has no effect on what I am doing. I will deal with that when I start to understand this notation a bit better.
Thanks for the HUMAN help!!
I just tried to reproduce it but I can't. Looks like I fixed it somewhere along the line, or maybe looking at an older log entry. My feed contains values that are mostly numbers but are occasionall strings, so I have to write then to different fields in the database. The error was there when I was writing the string. It mentioned something about "value", when my two fields are "value_num" and "value_str".
Anyway, it's all good now.
Thanks for asking
Peter
Do you mean that you have a Measurement with two fields (number and string) and only write to one of them at a time. That is not efficient as you have lots of holes in the db. It would be better to send them to different Measurements.
What are the fields that you are writing as strings? That is unusual I think.
Looking back at your example, I think your db schema may not be ideal. It appears that you are writing different 'things' to a measurement and using a tag to indicate what it is. This is not considered good practice. You would be better to use different measurements for the different things. Tags are to allow the same type of data to be recorded for different machines or places etc. For example, I have a Measurement room_temperature which contains the temperature, and a tag which contains the room name, which identifies which room it is for. There is another Measurement room_humidity which works in a similar way.
My case is a group of meteor cameras that I manage. I have a mqtt setup on them that a programmer in the UK has written and I am testing. The data comes down from the broker as a series of topics. Some is real time data, which a crontab send every 10 minutes and some is daily data which comes in once a day at the end of processing. That is a wee bit complex because the meteor software allows for 1 python script to be run at the end of processing and it passes some arguements to that script. Anyway I have replaced the python script with one that runs my shell script and then runs the original python script with what ever arguements are passed to it. This thing only runs once a day so isn't ideal for testing.
I hadn't given a lot of thought to database structure when I started this. I come from using Informix4GL back in the 1990s so using the old sql commands is nostalgic. I don't know who came up with the term "measurements". back in the day we called them "tables".
So what you are suggesting is that I should have separate measurements for each topic. That certainly makes sense. I had this working with all data in fields but when I saw that fields weren't indexed, I could see that was a problem. The data that is strings only comes in once a day and I realise now that I might need a retention polcy of weeks for that, wheras I only need a day or so for the other stuff.
I am retired so don't have and time limits. My brain is a bit dead at the moment while I am working with how to get this data out of the meteor cameras so I am probably going to take a pause.
But thank you very much for your suggestion, that certainly solves the retention issue and I can certainly see why that is more efficient. It'll be a chance for me to look a bit deeper into the programming issues.
I started watching the video you suggested and learnt a few things from the basics. I started a course on JavaScript a while ago, until my head began to spin. This takes it to another, but more, practical level.
I found this webinar from Influxdb about Schema Design for IoT to be extremely helpful. It's 9 years old, but is applicable here and since you are using InfluxDB v1, it's all still the same syntax. Watch it all the way through, then think about your own data. Write down your field names & tag names (both the ones you know of now, and maybe others you expect down the road).
I agree that the terminology (measurements, values, tables, fields, etc.) can get confusing depending on what one is most accustomed to.
