KNX-Bus stuck with version > 3.1.9

[evazzoler]

Hello Supergiovane, how are you???

I'm opening this issue to continue #393 after a long time. I apologize for this, but I've changed jobs and schedules. I need to perform these tests during the day (otherwise my family remains in the dark, since 90% of my bulbs are HUE), and unfortunately, the sun sets before I get home during this period. 😬

The problem still exists: Node-RED loses a lot of packets, and those that arrive do so very late (1 or 2 minutes). It also seems that the node occasionally disconnects and reconnects. 😟

The CPU doesn't seem to be heavily loaded, except during the startup phase, but that's normal.

This problem has existed since the "delay between each telegram" parameter was introduced, which I set to 30 during tests, as you indicated.

I've discovered that the situation improves significantly if I deselect the checkbox "Echo sent message to all nodes with the same Group Address" and it becomes almost acceptable but I loose some functionalities I implemented. However, I'm very concerned because you've written in the documentation that you'll remove this option and have it selected by default. In that case, I won't be able neither to test the latest version of knx-ultimate and will have to definitively revert to the last version that works for me: 3.1.9. 😰

My architecture is ARM (Raspberry), but the device is mounted on industrial hardware (it was quite a significant investment...) that I don't want to change to make knx-ultimate work. The fact is, if we don't resolve this problem, I'll be forced to. 😵

Do you have any ideas on how I can help you help me?

Thanks in advance!

[Supergiovane]

Hi
That's not an expected behaviour. KNX-Ultimate must run flawlessy. How many KNX Ultimate nodes do you have in place on your flows? You can check it here (this is my home)

Registrazione.schermo.2025-02-09.alle.12.45.59.mov

[evazzoler]

Hi Max, and thank you for the prompt reply!
Here we are:

[Supergiovane]

Hi
91 nodes are 1/4 of the quantity of mines.
38 hue devices are fine.
What type of raspberry is installed? What is the make/model of your industrial device?
And.. i don’t remember your node version.

[evazzoler]

Hi,

• NodeRed 4.0.5 (same issue with previous versions)
• Node v22.11.0
• My Raspi: https://sferalabs.cc/product/strato-pi-cm/
• 91 nodes are not so many, in fact 3.1.9 works like a charm

[Supergiovane]

Wich option have you choosen?

[evazzoler]

4S - 1GB RAM - 32GB eMMC

But... Why investigate the hardware when an older software version has no problems?

[Supergiovane]

Hi
1 GB Ram is way too low. It’s swapping to the MMC.
The older version was using an old Node.js timing mechanism that is deprecated starting v. 20.x, so i need to keep the things up to date with a new timing mechanism.
HUE rest API are also hungry in terms of system resources (RAM).
I suggest you to buy a new CM to replace the old one in the sferalabs. Buy the one with many ram possible.

[evazzoler]

This is very bad news.
This raspberry does everything it is supposed to do, and it has always done so with the old version of knx-ultimate. I wonder if changing modules and having the latest version really gives me advantages.
It is possible that the best choice form me is keeping the old version...
With the old knx-ultimate version I have 220 MB of unused RAM...
I will do a test with the latest version to see if the RAM is actually at 100%.
Thanks.

[Supergiovane]

Be aware, that at certain point in time, you will be forced to upgrade the hardware. The ram you see free, is because your CM is probably already swapping to the eMMC.
If you have a spare well equipped raspberry laying unused, or if you can spin up a VM with debian or raspbian, you’ll see node-red run smoothly.
Otherwise, you can live with the old knxultimate version, if it fits your needs.
Anyway, I’ll investigate further in the event emitter (as you wrote, the performances improves by unchecking that “echo” option).

[Supergiovane]

Hi Enrico
just took a look at the matter.
"Echo sent messages" doesn't really do anything special and it has been forced to "true" in the knxengine module, long time ago. In the knxultimate itself, it takes care of simulating some behaviours.
Please check that the loglevel is set either to "Silent" or "Error" in the knx config node and restart node-red.
I've an unused RevPI3 (industrial grade, like yours, with din rail mount) laying around. I've upgraded the CM Module on that, but i cannot recall the specs (it's a rPi3). If you wish, i can send it to you.
Anyway, the CM module in your device is a SODIMM one, so you if you wish, i can send you only the CM and not the whole RevPI3. You can swap it by yourself, just by opening the Sferalabs.

OR (better), you could buy a standard RaspberryPi 4, with at least 4GB RAM and use an industrial SD Card (you can find it even on amazon). Such SD Cards are built to have a very long MTBF, for use in industrial environments. This, for example, has 1920 TBW with a duration of 526 years (calculating a write rate of 10GB per day).

[evazzoler]

I ordered a CM with 8GB RAM, 32GB. Extimated delivery 24/04/2025... 😆

The standard RaspberryPi 4, compared with the Sferalabs product, misses the sferalab control unit with the hardware wahtchdog (with both soft and hard reboot) connected with a GPIO where nodered sends a keepalive signal. It reboots if nodered freezes.
It's not a simple CM din rail case... I never found a real industrial SD Card. All "industrial" SD are declared industrial (but it seems are the same as non industrial) and are note safe as the DOM of the CM module... Industrial CF are instead really safe.

[Supergiovane]

Good!
I also had that revPi3, with watchdog and so on.
At the end, after many changes, i’ve opted for a Supermicro server with ecc Ram. Low power consumption (30w max)
It runs 3 Node Red VMs, an Homebridge VM and other Stuffs i use for my work.
Backed up by a little UPS.

Please let me know when it arrives. For now, i move this thread to a discussion.