Wondering about Spammy Devices

My Hubitat exclusively controls Zigbee bulbs, seven of which are Innr in the front of my house, and two of which are floods in the back yard.

I've gotten the following warning from my Hubitat web page:
"7 devices produced unusually high number of events: PL (403 events), PR (399 events), DL (410 events), DR (397 events),"
and the error cuts off at that point, but I'm reasonably sure this is all of the innr bulbs.

As far as operation, I've been comfortable ignoring the messages, as the timings seem to work just fine. Two rules to turn the bulbs on at sunrise and sunset. Two other rules I call "backups" to send a second on commands at 8pm, and an off command at 8am. With minor occasional hickup the automated timing has been working fine.

I have a follow-up relative to this, but didn't want to put too much in one message, first wondering if there's a real problem with what the Hubitat is reporting, and if there are obvious causes and corrections that can be made.

It's a "real" problem that for many people, ignoring is the right answer. :slight_smile:

Each device has:
Screenshot 2023-10-22 at 11.29.19 AM

and you can set that to a higher number to eliminate the alerts you are seeing. That's the 'ignore-on-steroids' solution.

The Z-Radios can only work on X number of messages (packets) per minute. For hubs with few devices, burning half the potential in packets that get ignored isn't detrimental. Once you add enough devices though, your desirable packets get swamped by the undesirable and you come back here asking why your hub's so slow. :smiley:

I have no specific knowledge of those Innr bulbs but you will, someday, want to ask each of them to stop sending so much.

1 Like

I think that this 'too many events' threshold relates to the number of events the device driver generates per hour, not the number of Z-messages sent over the air...

This is an example of a spammy device, which however works OK and does not trigger any alarms:

What driver are you using (I suppose the inbuilt one)? If you enable the Debug logs option, do you see many log lines?

1 Like

True enough but for the majority of drivers there's an Event per device message. Light on, Light Off, Light at level N, and so on. I know the Aeotec MultiSensor 6 sends a message for each of the sensors. I'll get 4 messages all at once and the driver turns each into an Event. By this I mean the most common situation is a 1:1 ratio between device messages and Events. And the OP is specifically mentioning Bulbs, which are down at the "simplest devices created" end of the spectrum. On/Off/Dim Level/Color... Are they going to include humidity or temperature? How about one message per step of dim? Light off to light on (100%) sends 100 messages? Those Linptech MM Wave sensors are certainly spammy. with a 1 message per second distance reading.

I'm agreeing it's possible, just feeling that it's not the most likely.

1 Like

Here is the device driver role, where the filtering of the unwanted messages can be done:

image

The same principle can be applied in the drivers that receive multiple level/color change messages, there is no sense in sending events for 1% brightness change.

So, my take-away is to ignore it and/or raise the threshold value.

Correct?

Do any of these devices support power/energy reporting? If so, you may want to disable that feature to see if that helps reduce the Zigbee traffic load.

Where do I go / how do I tell? And if determined to be so, how do I disable?

My advice will be to raise the 'too many events' threshold for these devices to 500 and do nothing else.
They are working just fine - the same way as they work in other home automation systems, not just HE.

Open up the Device page for your devices, and look at the settings that are available for these devices.

Look for some thing like the following

Yeah it doesn't look like I've got that in Preferences.

And it looks like this is where I'd up the threshold for events?

1 Like

agreed

Yes.

1 Like