Event Queue is Full Error

Last night I got many errors that the "Event Queue is Full" for a rule and the associated device prior to the hub locking up. Here is the rule:

image

It is used to set a global variable used in this rule:

image

I just installed CSP watchdog to try to prevent this from happening, but would prefer to find out what is actually causing it. Thanks.

Your TV Power Monitor is probably spamming the hub with events.

2 Likes

The "Power Reporting Interval" is 30 seconds. Is that too often? Everything else is 1 Day.
Looking at it I realize that I can change that and rely instead on the "Power Report Value Change" to accomplish what I want. As a result, I changed "Power Reporting Interval" to 5 minutes.

The trigger event is *changed* so every power event it receives is triggering the rule.. which is also then setting a variable ..

Not entirely sure on the internals.. but it could also be constantly triggering your next rule variable becomes .. with *changed* ..

This could be causing a ton of activity on every report.. And some of these devices report quite frequently ..

But I am no expert on RM.. This is just an educated guess..

1 Like

What kind of device is TV Power monitor? If it is truly monitoring power out to 3 decimal places, I'm not surprised the hub got bombarded with messages. With something like a TV, going down to 5w or 10w granularity would be fine. That way, you only get a message when the wattage changes at least 5 or 10 watts. There's a selectable option on some of the drivers, like the ones for the Generic Zigbee Outlet driver.

Side note...you should really clean up the end of your rules with END-IFs just to make them finish off correctly.

I have a question about your second rule also. Why are you using the power monitor level as a condition rather than the GV? You already know if it's below or above based on the GV being true or false. Also, your second rule should not be triggered on Changed for the global variable. It should be changes to False. That way you only need the conditions of the time of day and presence. That will prevent extra rule firings also.

2 Likes

Thanks. The interval was 30 seconds, but it is now 5 minutes or if the power changes by more than 50 watts.

I'm not a RM expert either. Glad we have some here.

The device is a Monoprice wall plug
https://www.monoprice.com/product?p_id=15654
It is not accurate, but it is consistent (which is all that I need). I don't understand why it reporting power out to 3 decimal places increases the number of messages to the hub. I did change the reporting frequency to 5 minutes or anytime the power changes by more than 50 watts. I can see in the logs when it reports, and it is as scheduled.
Thanks for the tip for the END-IFs. I did some reading up on them and have added them to all rules as applicable.
The short answer as to why I'm using the power level as a condition is simply because the rule evolved through trial and error until it seemed to work. I am still thinking through all that you said and will probably make some changes based on that. The biggest reason for all of this convolution is to make sure the rule only fires when the TV is turned off during a certain time period. If the TV is already off, I don't want the rule to fire.
Thanks again for your help. I'll post another update after I've made some more changes and tested them out.

1 Like

That is why you trigger based on the variable only going to false. That means that they tv has turned off (variable has gone from true to false). You could also consolidate this into one rule using Private Boolean (PB) as follows:

Trigger:  Power Level Changes

Action:  
    IF Power level is > 50 and PB is True THEN
         Set PB to False
    ELSE IF  Power is <=50 and PB is False THEN
         Set PB to True
         If time is between X and Y and Phone is Present
              Then turn on light and turn off other lights.
          END-IF
    END-IF

Using the PB to determine if you you were already previously within that range prevents that action from firing if the value was already below that level. And if you want to get REALLY fancy, you can build in delays of a few seconds to prevent accidental firings if you accidentally turn the TV off but then quickly turn it back on again.

For example, if the power level is currently 10 because the TV is off and the PB is Trrue. You turn on the tv so the power jumps to 75 and the PB is still True. The rule triggers based on the power change, the power is above 50 and PB is true so PB is changed to false. Now the TV is still on and another reading comes in, this time at 85. When that value is sent to the rule, nothing will happen because the reading is above 50 but the PB is false. So, the rule doesn't make any changes. That continues until a reading comes in that is below 50, and PB is not false so it changes the PB to true. It then evaluates the time and decides whether to turn off the TV. I think that will be a lot easier to manage than the two rule system you have.

2 Likes

Ryan, Thank you again! It took me a little time to wrap my head around everything that you gave me, but I think I actually understand it.

Here is my updated Rule:
image

I did make a small change so that the bedroom light is only turned on if the phone is present. Putting in the END-IF's really helped me see each IF statement more easily. I probably will add some of the tweaks you suggested once I'm confident it all works as expected.

Yup...looks good. Remember, if you have only one action that you want to be conditional on one thing, you can also use the "Simplified Conditional action. That would allow you to enter the line about Wayne's phone all on one line (and with less clicks). But yeah, I think you've got it.

1 Like

Ryan, I just wanted to give you an update. I added the function for it to not turn on my bedroom light if the light was already turned on that evening. And the best news of all is no hub lockups or slowdowns. Thank you again for your help.

1 Like