NR 3.0, Node 16, Pi 3B, 11 IoT devices, using node-red-contrib-tuya-smart-device modules, load consistently over 100%?

[Jibun-no-Kage]

NR 3.0, Node 16, Pi 3B, 11 IoT devices, using node-red-contrib-tuya-smart-device modules, load consistently over 100%? Anyone else seeing something similar? The Pi is running 64 bit OS 11, BTW. Just a sanity check question.

Pi is doing no other work, only NR environment, 1 single flow as noted above, 11 IoT switches. I disable all the IoT control nodes to 1, the 100% loading still occurs still.

Then switched off 64 bit kernel via /boot/config.txt via #ARM_64bit=1. Still load over 100%.

Memory loading is always around 15 to 16% in all tests.

Disable of the TUYA Smart based flow. And of course NR loading disappeared.

So then enabled another flow, which happen to be a WiFi scan audit using exec node to use iwlist linux CLI. Still using the 32 bit kernel. During wifi active scan, loading can go from 10% to 50% but once the scan is done drops almost to 0 for NR process(es).

So the way I see it, the node-red-contrib-tuya-smart-device modules are load intensive, so asking if anyone else seen similar or comparable behavior?

[msillano]

I've been using two Android servers 24/7, with no problems for at least a year (NR+ MySQL + Apache). The problem, in my opinion, is not the processing load, which is always acceptable: in a benchmark process 448 / 10s ( zeroTask) messages, but rather the reliability of the WIFI communications. I use two levels of recovery in case of disconnected devices and UPS for the server and the main devices. Best regards m.s.

[Jibun-no-Kage]

Thanks for the information. You suggest an interesting point. I have not yet, setup a test to watch the WiFi behavior per se. I did watch my WiFi routers, and did not see any obvious issues, such as frequent disconnects/reconnects. But to qualify your suggestion, I would of course have to setup deeper level of monitoring. I will get back to this in due course, at the moment I am working other issues.

[msillano]

As a starting point I use a simple algorithm:

1. if one or more devices are disconnected, the default is to wait: it can be physiological (e.g. mobile plugs or devices) or accidental (e.g. the passage of a car). One caveat: for mobile devices I randomly increase the request timeouts (dynamic timeout: from 2s to 10 min).
2. If all WiFi devices are disconnected and if there is electricity on the grid, then an alarm siren sounds. The causes are either the Router breakdown or an attacker uses a jammer: immediate action is required.
3. After some time without grid power, (n.b. server and router with UPS) a message is sent to my phone. Enjoy

[msillano]

Another observation came to mind, to avoid load peaks: in dynamic timeouts I use numbers created randomly at the moment, while in static timeouts I use all different prime numbers: this is to prevent 10+ devices from trying to connect all together, and then there are a few seconds of quiet with then another peak ... Furthermore, I queue the messages and send them to tuya-smart-device nodes spaced in time: the node 'delay node' grants a rate of 30messages/10 sec. enough for me (in benchmarks a message requires 100-250 ms) on Android and 100-150 ms on WIN11 dev PC, to go and back to tuya-cloud.

[Jibun-no-Kage]

I don't have a UPS, but I am familiar with them, I am still debating such, given if the grid is down, all realistic communication external that is, down.

I use a different method to sample the traffic, that is randomized and smoothed for sampling of local devices, for my wifi scan/polling. Also, I have a dedicated Pi device with a rather strong receiver antenna, which I scan with, and upload the results to database and then parse the results. The interesting thing is, that given the time of year, and ambient temperature (I live in a desert) the scan results change significantly. Nothing like catching Google scanning the street in real time.

As for my IoT devices, they are isolated, but I now have a better/non-consumer wired router, that will let me setup various VLANs so that is the next be project on the list. Once I have the VLANs set, monitoring and control will be almost painless and I can identify exceptions with specific ease.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

Auto closing the issue