I’m running HA on as rpi4B 4GB for 2 months now (switched from zwave.me) with some integrations and Zwave with zway UZB gen5 controller stick
I have around 120 zwave nodes, almost all of them zwave+
Alls is kind of ok, if I look at cpu/mem load of the Rpi then I don’t see any high values, temperature also ok.
But, now here’s the thing, from time to time, on very simple automations , it takes like 8 seconds before a light turns on. for example, I have a fibaro multisensor and fibaro dimmer2 switch close to the controller, I created an automation to turn the light on when motion is dected however, I can see an 8 seconds delay between the motion detection and the “turn on” of the light.
I can’t figure out why, is it zwave, is it HA, is it the hardware…
So, my question, if you like at my zwave network (amount of nodes) , is the RPI the right solution ? is the delay all “in the network” or can cpu power , hardware latency (internal) also be a factor here ? would switching to an intel NUC for example solve this ? (tough question, I know)
Like to hear your experiences, especially from the ones with over 100 zwave nodes as well.
Well, I “only” have 47 Zwave nodes, so I’m a little boy in comparison.
But my experience is, that when I’ve switched from RPi4 to a SFF intel celeron PC with 4GB, the difference was night and day. On Zwave side everything reacts just instantly. No exceptions.
That said, no guaranties, that it will solve your problem. But hope, yes…
yes, but, I never did enough research about it to say 100% sure, that the problem was not somewhere else. So, maybe this was the solution, maybe it was the rebuild of the Zwave network. (Yes, with that hardware migration I took the chance and made a total new start).
But well, I see a lot of improvement. Database readout is also way, way faster…
No. RPi4 4GB with ~ 50 Zigbee devices, HA container, MQTT container and Zigbee2MQTT container was exhausted and unreliable. After all - it’s still based on a mobile phone platform. And of course, after two years SD card became corrupted.
Changed to a cheap x86 based PC (Minisforum N40) with embedded eMMC SSD and never experienced any issues again.
If you go into debugging in ZWave2MQTT can you see the motion detection is triggered and then the command coming back out to the dimmer? Does it take 4 or 8 seconds to arrive into the host or is it the CPU on the Pi which is taking so long?
@m0wlheld , I don;t use any containers or anything like that, also not MQTT. alsu using USB3 instead of SD (I learned from that in the past… ;-))
The system does not look “exhausted” (well, at least not in RAM or CPU) but there are more aspects in a computer which can bring latency off-course.
I don’t use Zwave2MQTT, just ZwaveJS UI (but I think that’s the new name right ? anyway, it has “MQTT” disabled)
But I can clearly see (also in the automation) that the motion detection arrives instantly, then there is a “stall” for 8-9 seconds in which nothing happens (the automation is waiting for confirmation light is on at that moment) , then light is turned on and then automation continues.
I originally installed my network at a time before ZwJSUI defaulted to no security and unwittingly joined over 40 nodes as S0 security (they’re pre S2). S0 has 3x the overhead for communication. (it’s bad if you have a lot of them)
I went through two weeks ago and rejoined all the nodes that don’t need security (about 40 of them) and the network is now lightning fast. The update for ZWaveJSUI that came out yesterday highlights S0 nodes in the security column in orange instead of green…
Yep, I’m also checking if any weird associations at the moment, but I’m not so sure how that exactly works in the GUI, it looks a bit strange compared to other systems I think.
Anyway, only the 1st association group “lifeline” should be set, nothing else, so , should also the 2 in this screenshot be removed ? (Node 205 is my controller)
