Events firing on their own - Solved!

[Gunneyk]

I created 2 events the other day based on a thread which talked about keeping a Cooper Master and Accessory switch in sync. The two events are identical except for the which device initially triggers them and one of them is shown directly below. It's pretty simple in that when (in this case) the value of the Switch changes or becomes set or changed (I just realized I may be able to do what I want with just a changed value and not set but that shouldn't cause what I am seeing) I run a script which looks at the values of both the master and accessory switch and if the other is not the same it sets it to what this one is. There is logic to avoid continuing recurrence when both values are the same. The other event does the same just the other way around. This has and still is working just fine. If I turn on or off one switch the status of the other is updated and HS see's the updates and all works great.




However I noticed today that the events are firing on their own as shown in the filtered view directly below. Most of this was at night with no one awake to touch any switches. And from looking at all of these triggers the last few days most (not 100%) are almost exactly 1 hour apart which happens to be their polling interval. Another odd thing is that sometimes the events fire in pairs (master and accessory) and sometimes it is one or the other as shown directly below.




If you look at the log for one of the events you can clearly see there was no manual or programmatic event associated with it that should have triggered the event.




So why is this event being triggered? It appears to me an artifact of the polling but why would polling a device trigger an event that looks for a set or change?

[mwaite]

I think the problem is 'set or changed'. The polling is updating the status of the device, even though its status isn't changing, causing the script to run. Try 'changes and becomes...' instead. You'll have to have an 'or' logic to trigger on either on or off (if device changes and becomes on OR if device changes and becomes off, then run script).

[Guest]

I would also consider turning off polling as Cooper are supposed to be instant status and not require polling.

[Gunneyk]

I think the problem is 'set or changed'. The polling is updating the status of the device, even though its status isn't changing, causing the script to run. Try 'changes and becomes...' instead. You'll have to have an 'or' logic to trigger on either on or off (if device changes and becomes on OR if device changes and becomes off, then run script).

I changed it last night to "Changed and Becomes" and the issue went away. I did not realize that polling would update the status. That just seems so counter intuitive. Is this true for all devices? I will turn off the polling as well. I think initially I had it on because the Master and Accessory were never in Sync and that was an attempt to see the current status in HS but it never seemed to make a difference anyway.

Thanks for the responses guys

[randy]

I changed it last night to "Changed and Becomes" and the issue went away. I did not realize that polling would update the status. That just seems so counter intuitive. Is this true for all devices? I will turn off the polling as well. I think initially I had it on because the Master and Accessory were never in Sync and that was an attempt to see the current status in HS but it never seemed to make a difference anyway.

Thanks for the responses guys

There is also his that was added a few months ago
.

[randy]

I use Spud's Easy Trigger plug-in to synchronize three Cooper dimmers for my yard lighting. I did use "Changed" rather than "Set or Changed". If I turn them on or adjust them from the back porch, the deck and shed lights are adjusted to match. I initially had a three second delay but checking the box described above made that no longer necessary.

[Gunneyk]

Randy, thanks for pointing out the checkbox to prohibit the update if not changed. That can be very useful. As for this below I assume that the ability to Set the Variable is part of Spud's plugin correct. If so I must check it out as that looks like a very useful feature and can greatly simplify the sync process. Thanks again

[randy]

Randy, thanks for pointing out the checkbox to prohibit the update if not changed. That can be very useful. As for this below I assume that the ability to Set the Variable is part of Spud's plugin correct. If so I must check it out as that looks like a very useful feature and can greatly simplify the sync process. Thanks again

Yes it is one of the features of a very useful plug-in.

[Gunneyk]

Yes it is one of the features of a very useful plug-in.

I actually just went and purchased the plugin and first impressions are extremely good. This looks like well worth the price of the plugin cost. Lots of good stuff in there. Thanks for pointing me to it.

[Gunneyk]

Oh wow that was so much easier and cleaner to sync the switches with Spud's plugin than the script I was using. I just have one question. I see that you used the variable tied to the RefID when setting the other switches values. I used this approach below which used the device directly. It works like a charm but I am wondering if there is a specific reason to use one over the other. I felt like using the device directly was a bit more self documenting than trying to decipher the RefID later down the road. But maybe there is something I don't know about one way or the other .

[randy]

Oh wow that was so much easier and cleaner to sync the switches with Spud's plugin than the script I was using. I just have one question. I see that you used the variable tied to the RefID when setting the other switches values. I used this approach below which used the device directly. It works like a charm but I am wondering if there is a specific reason to use one over the other. I felt like using the device directly was a bit more self documenting than trying to decipher the RefID later down the road. But maybe there is something I don't know about one way or the other .

There really is no difference. When I set up my events, Spud had not yet added the ability to set a device to another device, so I used set device to a variable.

[Gunneyk]

OK I guess I do have a 2nd question and a comment. I Originally didn't have a WAIT before setting the other value and found a situation where the lights were going on and off constantly. I think this was due to me accidently pressing the button twice very quickly. Anyway the wait solved that. My question is in your example you show the wait as NEVER WAIT 3 seconds. What does NEVER mean?

[randy]

OK I guess I do have a 2nd question and a comment. I Originally didn't have a WAIT before setting the other value and found a situation where the lights were going on and off constantly. I think this was due to me accidently pressing the button twice very quickly. Anyway the wait solved that. My question is in your example you show the wait as NEVER WAIT 3 seconds. What does NEVER mean?

"Never" is an option that was added as a diagnosis and troubleshooting tool. It allows you to disable an action without deleting it. It can be applied to any or all individual actions. For example, if you are testing triggers and conditions in an event, but you don't want the actions to be executed, change "Then" to "Never". Then look at the log to see if the event is running as expected. Then you can change it back when you want the action executed. In my event I had a "Wait" initially because of erratic behavior. When I cured it with the checkbox mentioned above, I disabled the Wait, but never deleted it.

[Gunneyk]

"Never" is an option that was added as a diagnosis and troubleshooting tool. It allows you to disable an action without deleting it.

Cool, sounds useful. I searched the help documentation and couldn't find any reference to it so thanks for the heads up.