Hubitat Event Que Full Error

Hello All,

I was noticing lag in my system alerts and saw the event queue full errors attach in the screenshot below.

I believe these are related to the chromecast speakers using the "Follow Me" app, any ideas?

Thanks

Do you have a power reporting device that’s really chatty?

What are device 386 and apps 1196 and 354? That would at least give some clue (the apps look like Rule Machine if I had to guess). Is device 386 used in those apps? To figure this out, either click the links like "app:354" on the left, which will filter that list to just that device/app and allow you to see the name at the top, or click the "error" (or other) rectangle to go to the device/app page.

Power monitoring devices, as suspected above, are often pretty chatty and could be the cause of this. If I had to invoke my psychic powers again, I'd say device 356 is one and you're using it in two rules, apps 354 and 1196, and that toning its configured reporting interval/percentage/etc. down to a reasonable value (ideally the least report-y interval you can go while still getting whatever data you need) might help. But it's hard to say without knowing more. The error you see is one added a firmware update or two ago in the hub to help avoid slowdowns/lockups when this kind of thing happens, which, again, is usually a device (or app, possibly as the result of a device) that's going off the rails.

Yes I actually do, it is a dryer complete rule that alerts when the dryer has finished:

1 Like

Those devices are all related to the dryer.

Have you tried changing their power metering parameters to report less frequently? How you do this will depend on the specific device, but most have some preferences on the device page that you can adjust.

Yes I thought I had the metering settings lowered enough buuuut...

But what? :slight_smile: 1 watt (!!!), 10%, and 1 minute are all quite high. Consider disabling any you don't need--either watt or percent-based change may be enough, so you could get rid of one, and you could also either eliminate time or significantly increase it. Be sure to click "Save Preferences" when done. Some devices might make you click "Configure" to actually send these settings to the device, so that can't hurt, either, though I think most will when saved.

You'll have to do some experimenting with your device to see what its actual power usage is, if you haven't already. For that purpose, you may need to keep the settings closer to what they are nOw, then change them to higher ones that would stop reports you don't need once you know.

Good luck!

1 Like

While I'm glad they've added the Event Queue is Full error to reveal issues with the application bogging down due to events, it unfortunately is very telling and highlighting some underlying system flaws.

Why can a chatty device can bring this system to it's knees? The rule shown above doesn't appear very complex, but apparently enough so that the hub cannot keep up with events coming in from a device.

It appears Hubitat is showing its hardware limitations, and the software is getting too bloated.

Objection your Honor...

Argumentative and Assumes facts not in evidence

the question assumes something as true for which no evidence has been shown. ...

Good grief... I really want to like this product, I think everyone here wants to like this product and make it better. But there are enough people indicating WAF issues showing it clearly isn't up to par.

I suspect the 1 watt setting is the culprit .. set it to maybe 50W or so.

Events also get logged and backed up which manifests another problem here, aside the queue full.

2 Likes

I changed it too 10 watts and will watch it too see if the queuing still occurs.

Thanks

ALL systems, networks, and communication pathways have bandwidth and capacity limitations.

Give me 10 minutes and I can put a single device on your home WiFi that makes it unusable to all other devices.

I've personally experienced cases where a large cloud provider (with datacenters the size of shopping malls) told me "no, we can't spin up your little website in our datacenter today. We are at capacity."

3 Likes

This doesn't excuse hubitat from having these issues for such a long time.

Gonna have to respectfully disagree with you here. Events don't come from thin air. If you have a full event queue, you have a device that is DOSing your hub. Everyone complains if Hubitat doesn't support every single device and version of device out there. But if you want to hook up any random device to your hub, it's up to you to ensure they aren't spamming the system.

5 Likes

Agreed, but if Hubitat is going to allow all these devices then we as users need guidelines around what to expect.
Some examples:

  • Devices can generate events only x/min, etc.
  • Hub can process x/second events maximum
  • Rule performance/complexity metrics
  • Typical processing times for Hubitat provided apps (simple lighting, button controller)

Staff has said that the Hub CPU/Memory is not the constraint, but the amount of traffic from the networks. Traffic Rate

So clearly, there are SOME constraints the system is up against, we need to know what these are so we don't push them beyond an unknown limit, and then just complain. Our users (wife/family/guests) just want us to take it all out if it doesn't work on-time, every-time!

Yet there are no simple guidelines us users can refer to to know if what we are doing in our network is good/bad. All we see is things slow down, random events get missed, which is after a lot of work has been put in setting up our systems.

Suggestions to "buy more repeaters" or "use these devices, they worked for me!" don't help us who are frustrated trying to get existing equipment to work. We are flying blind, and throwing more money at a problem only works for so long.

We need tools/methods to monitor our systems, to know when we are hitting limits, having network problems, etc. That will go a long way to help us fix them properly.

You're not flying blind. If you are reaching the limits of the event queue, turn on debug logging on your devices. The guilty device will be plainly obvious in your logs. It's the one that is spamming your logs.

2 Likes

This is always going to be an issue on Z-Wave and ZigBee as they are relatively low bandwidth, especially earlier Z-Wave. Having a device saturating that bandwidth - like a rapidly reporting power metering is a recipe for problems.

These bandwidth specs are out there...