@djmvt said:
Checked some stuff this morning:
There are still some errors reported, both socket hangup errors and the uncaught error but they are less frequent.
The socket hangups I haven’t tackled yet, so that makes sense. On the uncaught error: is it still exactly the same error, or is it subtly different now? Still slider methods, etc?
What I did notice is a higher cpu usage than before I was using this plugin (used the hue branch from pimatic led light before).
My pi went from idling between 5% and 15% to idling between 15% and 25%.
That’s quite a lot indeed. On my RPi2 it doesn’t make a dent next to running pimatic-homeduino with an unfiltered RF receiver, but I’ll look into this more.
So it looks like hue-zll is doing a lot of polling or something like that.
Also the socket hangup errors are reported even when there is no status change, pimatic just running, no switches pushed or anything.
So there is something happening "under the hood
Yes, for sure. It polls every light, by default every 5s but you can change that with the global “polling” configuration option. So if you have 11 lights configured, it will send 11 separate requests every 5s even if you do nothing else. And currently that probably means they are sent very closely after each other, which the Hue bridge may not like. That’s where the hangup errors are coming from.
If you enable debug logging, you can see some more of this happening.
I’ll see if I can improve this. If you have many lights it’s probably more efficient if the plugin requests the state for all lights in one request, so I’ll add that. Alternatively, I can add a poll interval per light, so the polling can be reduced for lights for which this is less important.
Unfortunately the Hue API doesn’t offer a way to subscribe to events and be notified of them as they happen, so some polling is necessary.