In order to not have to investigate this from scratch, I just want to ask, what EXACTLY are the limits? With 2.2.3 this limit broke the Recovery feature of my Zigbee drivers (I've disabled that feature when running my drivers on 2.2.3 for now):
I understand it is there to protect against incorrect high-volume events being sent and to decrease hub-load, but in the case of my driver it is on purpose and ONLY when needed. Besides, when it did kick-in, instead of helping it basically knocked out the hub it happened on.
@mike.maxwell could you please share the specifications for this limit?
Thank you, that is good to know. That is a strange thing then, it sends an event every 15 seconds at worst. Should not even get close to those limits. I will check some then.
Ah, then that could explain it, if many devices went down at the same time this would be multiplied by that number of devices, the thing is, I've tested this on earlier platforms with 6 seconds between calls and sending out to 60 devices at once. No platform complaints. Besides, what I'm talking about here is sending zigbee commands, I'm not sending events to the db in the methods referenced in the error message.
I am now seeing this and use Xiaomi / Aqara devices.
To be honest I have been toying with the idea of replacing them and this might be the push to do this...
I have alternative motion sensors in the Iris ones which also read temperature. need to find a suitable contact sensor in the UK as we currently have a Xiaomi on every window...
Are you on 2.2.3? To be clear, this isn't a device or driver issue. It's something playing up inside the platform. The exact reason is not yet known to me, I've not had the time to investigate, but suspect it can be related to the many platform changes. About 1 hour after first having this reported I published new versions disabling this feature in all my 18 Zigbee drivers when on 2.2.3 just as a precaution.
