So I have a lot of devices, most of them on my 2 dashboards that are visible on tablets around the house, so I need to konw their states...
Some of them don't report correctly (Shelly devices), even though I've tried everything possible, so I've figured out that I can periodiscally poll/refresh these to get my states correctly...
I've ben polling 2 devices every 5 seconds, but I now have "App 639 generates excesive hub load" warn in my logs and this gets reported 40x plus per second...
Is there a workaround to my workaround? How do I stop exerting my hub in order to get two devices data somewhat "live"?
If you go to the device’s settings page, you can edit the “Too many events alert threshold” from the default of 300/hour to a value as high as 2000/hr.
@DrRomca - What exact driver are you using for the Shelly devices? Also, what command are you calling every 5 seconds? Can you post a screenshot of the rule or alike you have setup to run every 5 seconds?
One of the devices is probably taking too long to refresh. Or maybe the driver you are using is asking for too much information on a refresh. The older Kasa devices need to be polled to get any status updates and those can be set down to 5 seconds, supposedly without any ill effects.
I think its going to come down to the driver being used.
Turn on debug logging on the device and then see if that gives any clues as to how long the refresh takes and what the driver is doing exactly.
Post a link to the driver being used, if its not the system driver.
Can you create a second rule and run them independently? That could lock the issue to a devices/driver. If both generate the alert then it may be a process thing. I can see allot of ways this problem could be generated. Heavy/fast polling is generally not a hub friendly activity. This is part of the advantage of Zigbee/Zwave since they send updates to the hub when they occur you can simply react to the event and not have to poll.
Shelly devices have a way of reporting back as well, but for one of these it does not work.
The other device I'm polling power in Watts, which the driver does not support "live", only upon refresh.
However seing all the possible causes of this now, I've connected to my Hubitat from here and deleted the rule, then created the same rule again and there are no issues now...
It's been up nearly 5 minutes with no warn so far. Before there were 40+ warns a second...
It appears to be solved for now!
If you did not reboot the hub at all, that would have probably gotten you the same result.
I see the ShellyPlus driver has a refresh built in which goes down to 1 minute as the lowest option, there is probably a reason for this.
In this driver the "Refresh" command is doing a full refresh of the device, Wifi Status, Configuration, Check for Firmware Updates, etc... the full works. It is sending 5 http calls to the device and parsing all the results.
Even the driver scheduled refresh does the same thing, as well as the poll command. This is a poor design choice in the driver IMO. Personally I would make the "poll" command only do the minimal request to get updated states. The Full refresh is probably only needed every few hours at the most, or even just once a day.
If you turn on debug logging you will see when Refresh is run all of the tasks it is doing, I can see the debug logging lines in the code.
The RGBW driver only has 3 http calls but for some reason it is calling the Setting refresh function twice? Also seems silly to poll the device settings every refresh, let alone twice.
If your devices are supported by these drivers: [RELEASE] Shelly Device Drivers (NO MQTT NEEDED) . I would try switching over to those, I know the code from that dev will be well written and efficient without even looking at it.
Thanks! I didn't know so much data is being transmitted at every refresh, good to know.
I will try those other drivers!
Or perhaps I could modify the driver and modify the poll command so it only polls what I need. Then calling the poll request instead of refresh...
I've modified another driver so it sends temperatures from shelly plus add-on, so this shouldn't be impossible even thought I'm not a programmer...
Thanks for all the insight! It is greatly appreciated!
Especially the drivers, it could help me a lot as I have over 80 shelly devices throughout my home!
I would honestly try those other drivers first, if your devices are supported I have no doubt they will work great. I dont even have any Shelly devices but I sort of follow threads about them because they are interesting and I may have a use for them some day.
If those drivers do not work for your devices then yes the next thing to do would be to modify the Poll command so it just does a minimal state refresh. Currently it just calls the entire "refresh" function I screenshotted above.
Oh, for sure I will try those first! Way less work than writing my own commands
I have so many shelly devices and didn't even know about those drivers...
As Jeff mentioned, the Shelly (No MQTT NEEDED) drivers are much more efficient on the hub and Daniel is very pro active and committed. I've moved the few shelly devices I had and could not be more happy and no more polling
Well, so going through the repo, I realized he also wrote drivers I use However sadly I'm having issues with the two devices that don't have Webhook / websocket support - aparently.
Shelly RGBW2 in White mode and Shelly Plug S Plus EU version
Yes, both are wifi devices. I think pinging them would not help me as the reason I'm polling these two devices is that they consistently DON'T report status changes. WiFi is good, I've tried re-booting these, re-setting with all new settings etc. and nothing has worked so far - that is with the RGBW2.
The other one I read power value, which is not a change, so it is not triggered and I have no other way of refreshing my readout.
)
