Never EVER delete an Event Trigger

[randy]

HomeSeer has a bug in Event editing that will allow you to corrupt an Event by creating a non valid Trigger. Here I have built a simple Event with a single Trigger and Condition:



There are three options for deletion in this Event marked by this icon


The first will delete the entire Event, the second will delete the Trigger and the last will delete the Condition. If you delete the Trigger, the Condition below it will become the Event Trigger. Since a Trigger must always be based upon a change or setting of value, this Condition became a non valid Trigger and will never be true.

Do not EVER delete Triggers, just change them if they are incorrect. If you find you need to delete a trigger, FIRST delete all the associated Conditions, THEN delete the Trigger. Otherwise your Event will become incapable of running or will give unexpected results. Here I deleted the Time Trigger from the above Event. You can see that the Condition was moved to be the Trigger and as such can never cause the event to run.

[donstephens]

Thanks for the head's up.

[BobSpen]

Would it not be a simple software change for HS engineering to eliminate the "X" in the trigger line???

[Tillsy]

This product is full of bugs - events in particular are nasty...

For example you have an event that triggers because of x and then:
device 1 on
device 2 on
device 3 on
device 4 on
device 5 on

But let's say you have excluded device 2 from your system? You would expect HomeSeer to now list in that event:
device 1 on
device 3 on
device 4 on
device 5 on

Instead what it does is:
device 1 on
omg omg omg i'm going to die the rest of this event can go boooooooooom errrrRRRrrror maLfunCTIon nEEd iNPut

So then you edit that second item, and add another two, so you correct have:
device 1 on
device 3 on
device 4 on
device 5 on

Which is what you originally expected, but at least you now have right? WRONG... behind the scenes HomeSeer is still pissed off. What you now have is an event that LOOKS perfect in the GUI but in reality:
1. Triggers
2. omg omg omg omg i'm going to die let's get stuck for 10 seconds waaaaaaaaah waaaaaahhhhh omg omg
3. Okay I've calmed down now
4. BOOM, device 1, device 3, device 4, device 5 all instantly now on

Fix is to just delete the whole thing and recreate, then things are instant again.

Your mileage may vary because this isn't always consistent either - seems to be worse the more devices that are affected, or maybe just if HomeSeer decides to just be in a worse mood.

As for deleting the original trigger, I'm actually surprised it doesn't go even worse and maybe damage other events along the way...

[randy]

Would it not be a simple software change for HS engineering to eliminate the "X" in the trigger line???

Yes, but there may be a reason to delete a secondary Trigger (Or If). I think the approach would be to remove the X on the primary Trigger, but provide it on the additional triggers with a pop up dialogue “Deleting this Trigger will result in the deletion of its associated Conditions as well. Continue (Y,N)”. Confirmation will delete the entire block. This could be done on the Primary as well, but I cannot see the need to ever delete the Primary Trigger.

[Uncle Michael]

Would it not be a simple software change for HS engineering to eliminate the "X" in the trigger line???

Probably, but it may, nonetheless, take a while (on a geologic time scale) for your suggestion to be implemented. Much more important to aggressively (and probably repeatedly) publicize the bug.
Can you get your post converted to a sticky?

[drhtmal]

I ran into this bug and thought I was doing something wrong. Nice to know the root cause of the issue. Maybe this will be changed in HS4.

[randy]

This product is full of bugs - events in particular are nasty...

For example you have an event that triggers because of x and then:
device 1 on
device 2 on
device 3 on
device 4 on
device 5 on

But let's say you have excluded device 2 from your system? You would expect HomeSeer to now list in that event:
device 1 on
device 3 on
device 4 on
device 5 on

Instead what it does is:
device 1 on
omg omg omg i'm going to die the rest of this event can go boooooooooom errrrRRRrrror maLfunCTIon nEEd iNPut

So then you edit that second item, and add another two, so you correct have:
device 1 on
device 3 on
device 4 on
device 5 on

Which is what you originally expected, but at least you now have right? WRONG... behind the scenes HomeSeer is still pissed off. What you now have is an event that LOOKS perfect in the GUI but in reality:
1. Triggers
2. omg omg omg omg i'm going to die let's get stuck for 10 seconds waaaaaaaaah waaaaaahhhhh omg omg
3. Okay I've calmed down now
4. BOOM, device 1, device 3, device 4, device 5 all instantly now on

Fix is to just delete the whole thing and recreate, then things are instant again.

Your mileage may vary because this isn't always consistent either - seems to be worse the more devices that are affected, or maybe just if HomeSeer decides to just be in a worse mood.

As for deleting the original trigger, I'm actually surprised it doesn't go even worse and maybe damage other events along the way...

This problem can be minimized by two approaches.

1. Do not delete (or Exclude) any device until you first filter Events on the device and then remove the device from the Event or the entire Event. This is a best practice bug or not, so that you can be aware of any affected Events prior to device removal
2. Do not group a number of devices under one device control Action, instead put each under a separate action

Events are stored as individual database “blobs”, making it extremely unlikely that corrupting any one Event will affect any other Events.

[Tillsy]

Do not group a number of devices under one device control Action, instead put each under a separate action

That's a good idea. It's really nice and clean having them under the one action, but it'll be safer to separate them.

[randy]

That's a good idea. It's really nice and clean having them under the one action, but it'll be safer to separate them.

In the bad old days of Z-Wave (prior to 2017) putting a bunch of device controls in a single Action would also invariably lead to Z-Wave command failures due to launching them too rapidly.

[Uncle Michael]

Do not delete (or Exclude) any device until you first filter Events on the device and then remove the device from the Event or the entire Event. This is a best practice bug or not, so that you can be aware of any affected Events prior to device removal

Another approach that I have used successfully for several years is to change the 'Floor' designation instead of immediately deleting the device. I use 'Inactive' and 'Abandoned' as temporary parking lots for devices slated for extinction. That gives me time 1) to be sure that I really don't want the devices anymore, and 2) to modify events - and scripts - to work with the replacement devices.

[Rupp]

Randy,
Did you let the engineers know about this with a support ticket?

[randy]

Randy,
Did you let the engineers know about this with a support ticket?

Yes, I emailed Rich. I also believe I filed a Bugzilla years ago. I can submit a new ticket.

[Rupp]

Yes, I emailed Rich. I also believe I filed a Bugzilla years ago. I can submit a new ticket.

Thanks. I see where it came in so hopefully it gets pushed up the bug chain.

[jlrichar]

I wish someone from HS would comment on this. I have so many events, and they need to be changed frequently when developing a new one. This bug essentially breaks the whole concept of the event engine.--which is the main reason to use Homeseer over something else. THIS IS A BIG DEAL HOMESEER!!!!!

While I always appreciate Rupp offering some polite help, and to pass along reports to the bug queue, I think there is quite a bit more at stake with this bug, and a beta and some evidence of a forthcoming fix is needed. This bug completely erodes the confidence in the core function of Homeseer. I have seen rprade mention this bug for over a year on the forum, and there is just nothing happening. This topic is not the first time he has mentioned it.

I decided to comment today when I realized just how much time I need to spend to both validate my events that I am changing, and to recreate events that should be just a simple drop down selection change, but instead stop functioning completely due to a change.