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:
- Multiple Luma LED compatible displays, but only 7-segment illustrated, implemented, SPI based
- Multiple sonic sensors, US-100, HR-SRF04, 05, etc.
- Basic GPIO input, output, events, to allow add of more devices, not SPI or i2c based
- Multiple PCF8574 based i2c GPIO expanders, driving an 8 channel relay board via PCF8574
- Multiple RGB 4 wire diode (R, G, B, GND) comparable, just a specific example of #3 above
- Multiple Infra Red GPIO Event trigger devices, just a specific example of #3
- 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
- The listener is multi threaded, so it drives the diodes, displays, etc. in parallel to MQTT message queuing
- 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
- 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.
- Listener responds to SIGTERM, SIGINT, SIGALRM messaging from OS as applicable or from systemd.
- Listener supports systemd notify protocol as well, so systemd gets accurate start, restart, status, stop states.
- 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.
- 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.
