EasyTrigger High CPU Usage

[numgis]

Not sure what is going on but lately I've noticed a lot of lag in HS3 running on Linux Debian. Looks like my CPU is maxed out most of the time.

I've traced it down to EasyTrigger, if I disable the plugin the CPU drops down to very reasonable level and my events run very snappy. But with EasyTrigger running, the CPU is very high and everything is laggy. Not sure if it is related to the latest EasyTrigger update or the fact that I've created more events based on EasyTrigger conditions? Perhaps I have some events that are too complex using EasyTrigger or if I'm doing something else wrong but would really like to be able to use EasyTrigger effectively. Right now I can't use it at all...

I've attached screenshots of EasyTrigger enabled vs disabled and the effect it has on CPU and processes running using Linux top command.

[numgis]

Digging further it looks like this event is the culprit.. when I disable it the CPU usage drops to normal levels. I realize this event trigger fires repeatedly after 20m of no motion and causes the EasyTrigger conditions to be evaluated repeatedly as well.. but I have other events based on no motion after a certain time (albeit without EasyTrigger conditions) and those don't cause high CPU. So guess I just can't use EasyTrigger in these types of events, or I'll have to incorporate a timer or something with slave events? How do you guys recommend I handle this? Or is there a way to restructure this event so that EasyTrigger doesn't get called every second?

[randy]

Digging further it looks like this event is the culprit.. when I disable it the CPU usage drops to normal levels. I realize this event trigger fires repeatedly after 20m of no motion and causes the EasyTrigger conditions to be evaluated repeatedly as well.. but I have other events based on no motion after a certain time (albeit without EasyTrigger conditions) and those don't cause high CPU. So guess I just can't use EasyTrigger in these types of events, or I'll have to incorporate a timer or something with slave events? How do you guys recommend I handle this? Or is there a way to restructure this event so that EasyTrigger doesn't get called every second?

Is there a chance that the Event “Garage Garage lights Off” has fewer lights turned off than are in the group”Garage Lights”? An event repeatedly evaluating conditions which are false should have very little processor overhead. As soon as the event runs, it should render the second condition false, unless not all lights in the group are turned off with the secondary event.

Even if that is the case, changing your trigger to “Garage Motion Sensor HS2 Motion Sensor has been No Motion for Exactly 20m, 0s” will stop the event from triggering more than once.

[spud]

As Randy said changing the trigger to "for Exactly" would be a good idea.

That being said I checked the code for group conditions and I think I can make it more efficient so that it takes less CPU. I will make the change in the next version.

[numgis]

Thanks guys. The issue with using an exact time for the motion is that if all the doors aren't closed at the 20 minute mark, the lights will never get turned off.

Currently if a door is left open for say 1 hour, when the door is finally closed the event will still fire if no motion for 20 minutes and all the other doors are closed.. ensures the lights get turned off if they are on.

Great spud if you are able to optimize this, look forward to the next version.

[scorp508]

May I ask what benefit your second AND IF is providing by checking if any bulb is !=0 ? Is there harm in just issuing the off command even if the bulbs are already off?

[randy]

May I ask what benefit your second AND IF is providing by checking if any bulb is !=0 ? Is there harm in just issuing the off command even if the bulbs are already off?

It is checking if any lights in the group are anything other than Off. Without that condition the event would run once a second after 20 minutes of no motion and garage doors closed, whether lights are on or not. That would really consume resources. With that condition the event will run once, turning all lights off rendering that condition false. If the trigger was changed to Exactly 20m, 0s, it would only run once.

[numgis]

It is checking if any lights in the group are anything other than Off. Without that condition the event would run once a second after 20 minutes of no motion and garage doors closed, whether lights are on or not. That would really consume resources. With that condition the event will run once, turning all lights off rendering that condition false. If the trigger was changed to Exactly 20m, 0s, it would only run once.

Yes correct, would consume a lot of Zwave bandwidth and HS3 resources to turn off lights every second when they are already off.

[scorp508]

Yes correct, would consume a lot of Zwave bandwidth and HS3 resources to turn off lights every second when they are already off.

Right... of course. I read it a bit too hastily earlier and thought you were specifically only sending the off command if the lights were on, but it's part of the overall event firing logic.

I love how there are a million ways to skin a cat with this stuff. Would it be a better/worse/indifferent use of resources to create a virtual device that represents the garage lights and only has Off/On states and key off of it? For example...


IF Any device in group GarageLights was set and has a value that is not equal to 0.
AND IF GarageLightStatus-vD has a value equal to OFF
THEN control a device 'GarageLightStatus-vD' to ON


Then your other event would be...

IF GarageLightStatus-vD changes and becomes ON
AND IF Garage Motion Sensor HS2 Motion Sensor has been No Motion for at least 20m,0s.
AND IF All devices in group GarageDoors have a value equal to 0

THEN Run Event Garage Garage Lights OFF

The final step of the "Garage Garage Lights OFF" event would be to set GarageLightStatus-vD to OFF to kill the logic.


This way you're only ever doing analysis against one EasyTrigger group, to set the virtual device to ON. Only after that group condition is satisfied and the virtual device is on does your larger event doing additional analysis on the motion detector and doors kick in.

I suspect it's more complex and no more efficient since it's just sort of recreating the EasyTrigger group logic using a virtual device and separate event.

[numgis]

Would it be a better/worse/indifferent use of resources to create a virtual device that represents the garage lights and only has Off/On states and key off of it? For example...


IF Any device in group GarageLights was set and has a value that is not equal to 0.
AND IF GarageLightStatus-vD has a value equal to OFF
THEN control a device 'GarageLightStatus-vD' to ON


Then your other event would be...

IF GarageLightStatus-vD changes and becomes ON
AND IF Garage Motion Sensor HS2 Motion Sensor has been No Motion for at least 20m,0s.
AND IF All devices in group GarageDoors have a value equal to 0

THEN Run Event Garage Garage Lights OFF

The final step of the "Garage Garage Lights OFF" event would be to set GarageLightStatus-vD to OFF to kill the logic.


This way you're only ever doing analysis against one EasyTrigger group, to set the virtual device to ON. Only after that group condition is satisfied and the virtual device is on does your larger event doing additional analysis on the motion detector and doors kick in.

Yeah been thinking of how to handle this, currently my garage lights don't turn off at all as I've disabled the current event while waiting for Spud to update the plugin. I have 5 garage doors and 3 lights hence using the EasyTrigger groups makes the event much more streamlined.

The problem with your logic above is that it only triggers once when GarageLightStatus-vD changes and becomes ON. If the other conditions aren't true at that point, it never fires again.

[spud]

optimization has been implemented in version 3.0.0.43 available in the beta section of the updater.
the optimization is limited to the groups defined from the config page, and not the ones based on device name, location, etc

that being said, if I were you I would still try to avoid the "for at least" trigger which results in conditions being evaluated every second

I think the following would be equivalent:

IF Garage Motion Sensor has been No motion for exactly 20m
AND IF All devices in group GarageDoors have a value equal to 0
AND IF Any device in group GarageLights has a value that is not equal to 0

OR IF Any device in group GarageDoors changes and becomes 0
AND IF All devices in group GarageDoors have a value equal to 0
AND IF Any device in group GarageLights has a value that is not equal to 0
AND IF Garage Motion Sensor has been No motion for at least 20m

THEN Run Event Garage Lights OFF

[numgis]

Great thanks Spud. Yes think your logic will achieve the same results, I have updated my code for the garage accordingly and it seems to work well so far. I have a bunch of similar logic throughout the house where I shut down lights when no motion is detected, so likely makes sense to not use "for at least" at all to avoid excess processing. Surprised HS even gives us a "for at least" trigger when they have gone to the extent of separating triggers and conditions just to avoid extra processing.

How do I install your beta plugin, haven't dealt with betas before?

[spud]

Great thanks Spud. Yes think your logic will achieve the same results, I have updated my code for the garage accordingly and it seems to work well so far. I have a bunch of similar logic throughout the house where I shut down lights when no motion is detected, so likely makes sense to not use "for at least" at all to avoid excess processing. Surprised HS even gives us a "for at least" trigger when they have gone to the extent of separating triggers and conditions just to avoid extra processing.

How do I install your beta plugin, haven't dealt with betas before?

totally agree, "for at least" shouldn't be available as a trigger

to install the new version, go to the PLUG-INS > Manage page > Additional Interfaces > Beta

[numgis]

to install the new version, go to the PLUG-INS > Manage page > Additional Interfaces > Beta

Got it, thanks. Installed your beta .43 along with the new Z-Wave beta .184, seems a lot of fixes in the Z-Wave plug-in since the .130 release.

[randy]

Great thanks Spud. Yes think your logic will achieve the same results, I have updated my code for the garage accordingly and it seems to work well so far. I have a bunch of similar logic throughout the house where I shut down lights when no motion is detected, so likely makes sense to not use "for at least" at all to avoid excess processing. Surprised HS even gives us a "for at least" trigger when they have gone to the extent of separating triggers and conditions just to avoid extra processing.

How do I install your beta plugin, haven't dealt with betas before?

"For at least..." is a valid trigger when used correctly. It is very useful as a housekeeping tool in some circumstances. There is a responsibility to make sure your events have protections to keep it from retriggering too frequently. The first line of defense is to make sure that a device used as a condition is controlled by the event rendering the condition false when the event is run. The second line of defense is to set "Cannot re-run for:" in the event's options. I prefer to use both protections for events using that trigger.

"Exactly" is a better trigger unless you absolutely need it to be valid beyond the timeframe of the trigger due to conditions that may not be true at the exact time of the trigger.