Where in the NR code is the logic that generates the message ids?

Where in the NR code is the logic that generates the message ids?

For example, af10dd8.1ca072. I want to mimic this format versus using typical uuid format in my python NR listener, so I can track each message in the log file, from subscribed to published, as applicable.

Reason for this question? I am finally working on my universal python NR listener. This is a mimic of some elements of flows I created that just tend to flood or overload Pi model 1 devices and sometimes Pi Zero devices.

I plan to publish the listener in GitHub as example of how a python script as a systemd compliant service can act as a responder to NR. Basically it is a MQTT responder, subscribing and publishing as needed to/from NR, that can drive some devices by default, and almost any i2c device, or GPIO pins as needed. It even illustrates SPI device support via the Luma LED example.

This universal listener will support the following:

  1. Multiple Luma LED compatible displays, but only 7-segment illustrated, implemented, SPI based
  2. Multiple sonic sensors, US-100, HR-SRF04, 05, etc.
  3. Basic GPIO input, output, events, to allow add of more devices, not SPI or i2c based
  4. Multiple PCF8574 based i2c GPIO expanders, driving an 8 channel relay board via PCF8574
  5. Multiple RGB 4 wire diode (R, G, B, GND) comparable, just a specific example of #3 above
  6. Multiple Infra Red GPIO Event trigger devices, just a specific example of #3
  7. Multiple/any attached ambient sensors that can be found via hwon or device paths via dtoverlay i2c configuration in Pi /boot/config.txt file. Listener illustrates interfacing to BMP280, SHT3x sensors as examples
  8. The listener is multi threaded, so it drives the diodes, displays, etc. in parallel to MQTT message queuing
  9. Eliminates the need to use PiGPIOd, which frankly is nice, but it just freaks out at times, dropping pin connections just enough to be frustrating on flow deployments, a long standing bug/issue
  10. Listener can run as service, or standalone, not unlike NR. Listener can be configured via command line or service ExecStart parameters, so NR flows don't have to use configuration nodes to setup listener for use. NR flows can just establish a control node and the listener will create the GPIO or device setup needed, for defined device types.
  11. Listener responds to SIGTERM, SIGINT, SIGALRM messaging from OS as applicable or from systemd.
  12. Listener supports systemd notify protocol as well, so systemd gets accurate start, restart, status, stop states.
  13. This lets me respond to the various requests from people, of how to integrated existing python hardware control with NR in a logical and structured way, rather than just having NR drive a python script directly, load even more JS modules.
  14. To add hardware to the listener, you just need to add a subscriber, a publisher, and add a function for each, and done, unless you want to do more, of course.

By removing explicit flows and NR as direct hardware driver, I reduce the CPU load by over 90% on the smaller devices. And, with a bit of effort, I should be able to migrate this python listener to ESP8266/ESP32 devices as well, say via MicroPython, which is the plan next. As much as I love Tasmota, it is over kill for some projects, and creating custom templates and even binary images can be a chore.

The idea for this was that I wanted to use my older Pi 1 as the core of my Garage door, lighting and sprinkler system, basic home security monitor, but NR flows were driving the CPU load at times over 100%, and memory was always an issue, driving swap space, just too much NR overhead and code logic for the hardware, then I setup same on PiZero, and realized I was driving the Pi Zero over the top as well. But doing all of the flows in comparable logic via straight python, my original setup, was well below 20% on Pi 1 and less on Pi Zero.

At first, the python code was also split into multiple listeners I used with NR, and figured it was time to stream line, consolidate, standardized, etc. to one universal more flexible listener. The added benefit was that the NR flows on the back end are smaller, simpler , so NR is doing more collection and displaying, than NR on the front end, driving hardware components. And of course, fewer NR modules needed even on the back end.

The relevant code for 2.0 is here: node-red/nodes.js at e16ab2a0fd79f4d3faf783b3548f5f08aaefa929 · node-red/node-red · GitHub

It has changed slightly from 1.0. It is now a fixed length (16 chars) of hex - eg 1fdabbbb6d8618d9.

Thanks! As always appreciate the assistance.

It isn't clear to me what you want to use the id for, but be aware that there can be multiple messages in existence with the same id at the same time.

I noticed the code can allow duplicate ids at the same time, which surprised me at first. This is really just to minic the format of the id. So my python listener uses a familiar format for the id. There is no overlap or link or relationship between what NR ids are and what the python message ids will be. The benefit is that anyone that audits NR logging, will instantly recognize the concept of id tagging in the python logging. My belief is that the message id is really just a way to trace flow sequence of a message in the logs or elsewhere. I have done similar in other code design I have done at various times as well. Is really nice when you writing raw C code and tracing logs for, say memory leaks, when you can search for explicit memory allocation and release statements because you tagged each pair (alloc, release) with the same value.

The message id is also very useful in other situations where you for instance will ensure that a browser is not using cached data. As simple code example I have web pages with video streams and images where the content in my case is using msg.url. Like this:

<td style="text-align: center; transform:rotate({{msg.rotate}})"><img src={{msg.url}}?{{msg._msgid}} class=img onclick="SendMessage('snapshot')" title="Click for snapshot"></td>

Instead of just using {{msg.url}} adding ??{{msg._msgid}} forces the browser to update the content

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