Diagnosing Full Event Queue

📢 Feedback
20

A good place to look. Device 2161 is a hubconnect remote server, so I imagine that reflect the combination of all ~25 devices coming from (or maybe it's going to?) that hub. I'm going to analyze all the chatty devices and apps tomorrow.

It's hard to manage an event ceiling when I have no idea what that ceiling is. Is there some way to know what the max is? I wonder if the new hub mesh service that was discussed on the recent Hubitat Live would essentially eliminate these "events" as there only purpose is to keep the shadow device in sync with the physical one.

21

Best of luck with your daughter.

1 Like
22

Two questions with these hub status -- wonder if anybody knows.

  1. what's the unit of measure with runtime? millisecs?
  2. if you have multiple hubs in your LAN environment, how does this decide which hub to measure?
23

i believe you can replace hubitat.local in the url with the ip of the hub you want to analyze.

24

Yes

Yes

25

So I analyzed the hub stat data carefully this evening, and learned a bunch of interesting things. Thought I'd share them here in cause others experience the same problems. And hoping the wise people in this community would share their interpretation of some of these findings. Without further ado, the Top Ten Discoveries from hub stats......

10 I had eight apps whose average runtime was in the 25-45 secs. That's seconds, not milliseconds. They were all child apps of Tile Master 2 by the prodigious @bptworld. Very sad, because I Iove what this app does for my dashboards! Will have to figure out how to make these more efficient. Giving up TM2 would be depressing.

9 Sonos is very slow, both the app (1.8 sec avg runtime) and the device (200-300 ms avg). Is this normal?

8 I've been using the Darksky.Net weather driver with impunity evidently, averaging nearly half a second every time that baby hits the cloud. Will have to cutback there.

7 I had a couple RM4 apps that were long running (1-2 secs), but they are efficiently written. Could a wait or a delay in RM inflate these runtime metrics?

6 The main dashboard app had an average runtime of nearly half a second. All my dashboards use selected devices, but I do have individual 42 dashboards. Any suggestions?

5 A couple of my wired Konnected devices--a piezo buzzer and a screen-break sensor--were in the 200-300 ms range. Should I be concerned?

4 I was using the Average Temp and Average Humidity apps from Hubitat. I've learned that (duh) if you add too many sensors to the average, you get an app that takes 500+ ms to run, and it's running every minute or so......translated, don't be stupid like me.

3 I'm using RM to monitor the active/inactive status of about a dozen motion sensors in the common areas of my home to sync a virtual whole-house motion sensor--it's what allows me to put the house to sleep at night when the house has gone quiet (i.e., no motion). This is a total resource hog -- it takes >1 sec to run and it runs every time any sensor is triggered or reset. Would one of the virtual motion apps be more efficient than RM for this purpose? I suppose I could dial it back so it's only running once every few minutes regardless of motion in the house.

2 I use Hubconnect to feed devices from my 4 other hubs. Two of the high runcount devices were virtual remote hubs. One of them was averaging 6 events per second across a 5 minute test. So, just for giggles, I reran the hub stats on that hub. There wasn't anything generating lots of events. The chattiest was the LiFX app; it produced 120 events in 10 minutes. Not sure how to reconcile a chatty remote hub with a non-chatty actual hub?? I do know that the remote hub in question is where I keep all my custom cloud connected and wifi apps (e.g., Ecobee Suite, CoCoHue, LiFX, Netatmo)

1 Re: HubConnect, there was also a remote hub app that had an average run-time of >300 ms. Not sure what's going on there or how ridiculous that would be. I wonder if this Hub Mesh announcement from Hubitat Live the other night will operate more efficiently than HubConnect?

26

for the same functionality is use event engine.. (easier to do with a delay in there than rm) but only within a certain time range.. Im not sure it is more efficient or not. If you want that functionality you need to trigger on every motion sensor.

Screenshot 2020-11-09 223828
Screenshot 2020-11-09 2238281886×932 54 KB

also my ecolink motion sensors only fire/reset every 3 minutes you dont really need more often for this functionality.. i am not sure how yours are set.

27

That's good idea. I wonder which approach has the optimal performance profile:

  • Event Engine cog (@kahn-hubitat's approach above)
  • Built-in app Zone Motion Controller
  • Rule Machine -- what I'm doing currently:
Rule Machine combo motion sensor

Screen Shot 2020-11-12 at 5.45.31 PM
Screen Shot 2020-11-12 at 5.45.31 PM819×213 36.4 KB

If no one has done the comparison, I may try out each approach and see.

1 Like
28

Would be interesting to see the difference. My hunch is Zone Motion.

29

There isn't a one size fits all. Each of those apps has its place in certain situations. Event Engine is a more flexible RM4 but is a large app much like RM4. The zone motion controller provides ways to aggregate motion sensors or extend the active window without having to modify the device settings so you can use different settings with multiple applications. Combined with simple automation, you can make some powerful lightweight rules. RM4 is well-rounded for conditionals but some people find it hard to set up rules properly. Motion lighting is great for quickly setting up simple motion lighting rules. I tend to go for the most lightweight app and simplest combinations of rules that will suit the goal I am trying to achive.

1 Like
30

Yeah I hear that. My search is really about the specific use-case in question (see RM example above). That was one of the event spammers that I'm trying to tame. So I'm curious to find out, for that specific situation, which is the most efficient approach. I'm going to try each this weekend and see. BRB.

1 Like
31

For a whole home motion sensor I'd use zone motion controller using motion aggregation. Configure it with a long window so it's not constantly flipping back and forth from active to inactive.

1 Like
32

So I ran the test this morning and here's what I learned about relative performance. All three methods were configured for the "Things Have Quieted Down" use-case using 16 motion sensors (all inactive). Each method was run three times and the results were averaged. Since the runcounts per minute (fire frequency) were basically the same across the three methods, I've reported the average runtime below. I don't know that runtimes are a perfect proxy for hub load, and I appreciate that capacity is not a simple issue, but still I find the results illuminating.

ZMC was the clear winner, proving the old adage that one should always use the simplest approach for the job at hand.

Rule Machine (using code from msg #27 above): 1,282 ms
Zone Motion Controller (built-in app using Motion Aggregation): 52 ms
Event Engine Cog (see msg #26 above): 1,356 ms

We have a winner.

Make that two winners.

1 Like
33

in order to get the rule dont you have to use zone motion controller in conjunction with either rule machine or some other app.. just stating times on the aggregation of the motion is not the same as the total implemenation?

34

Do I get a prize?
:trophy:

Phunny. :smile_cat:

True. But it looks like motion aggregation is all that his Rule Machine rule above did.

35

Curious what you tested with this? All it does it combine sensors, doesn't actually control any lights, send a message or anything else that the two other options offer.

Seems like apples and oranges.

There are plenty of apps out there that only combine sensors including mine, Simple Groups. That would be a much better comparison to ZMC.

2 Likes
36

exactly what i was saying

1 Like
37

The way I attempted to control for the apples & oranges problem across the 3 methods was by only doing motion aggregation. That's it. No other actions. With RM, this was strictly true (you can see the rule code up in message #27 in this thread). With ZMC, it's true by definition. With Event Engine, I had to add some action, so I added a pushover message as I assumed it was very light weight.

In that sense, the Event Engine was probably taxed a bit more than the other two, but I'm not sure that changes the fundamental findings.

1 Like
38

Yes, actually you get two of 'em.
Here you go:

  • my appreciation
  • my admiration
    :crazy_face:
39

except you can still use the app to do the motion aggregation and then one of the other apps for the rules.