Never EVER delete an Event Trigger

[Uncle Michael]

Yes it is possible to make an event that works. It is also highly likely that as you use the product over time even people quite aware of this bug will still break events.

Agreed. It's a landmine for sure.

And you can’t ignore that events have to be deleted and remade if you need to change the trigger (assuming the bulk of an event is above the action).

I still don't understand your point here. I've never run into a problem changing an event trigger. Can you give an example case?

[joegr]

You are correct that deleting\recreating the event is not always required. ...

I think that you may have quoted the wrong post. My point was that sometimes there is a reason to need to delete the primary trigger, and that now I know that I have to delete the whole event instead.

[jlrichar]

Never say never.
I have an event. The device in the primary trigger (non-dimming switch) failed, and was replaced by a dimming switch (used the "hidden" replace device feature). This resulted in the trigger statement looking very weird, and I could not fix that, even by changing to another device and then back. At least I now know that deleting and replacing it is not an option. The whole event has to be deleted and re-created. It's on the to-do list.

You are correct that deleting\recreating the event is not always required. To my point though we (and I really mean mostly Randy here) are just documenting the parameters around this bug that work.

There are situation where everything works. There are also many situations that result in events that don't work and no way to tell the difference between the two except spending time testing.


One thing I tried in the past is to set the primary trigger to "This even is MANUALLY triggered" . That should never need to be changed. Not sure if this is a fix, or if this is something that could be hard coded into every event to fix this problem. Randy, I think you suggested this in the past. That raises the question though about what deleting an OR If trigger? Does that also nuke the event?

What would be best is having a fix so that you don't need such a large amount of tribal knowledge to work with events. Everyone not reading this thread will have non-functional events if they continue to use HS and they will not know why.

[joegr]

... You do not ever need to delete a primary trigger.

Never say never.
I have an event. The device in the primary trigger (non-dimming switch) failed, and was replaced by a dimming switch (used the "hidden" replace device feature). This resulted in the trigger statement looking very weird, and I could not fix that, even by changing to another device and then back. At least I now know that deleting and replacing it is not an option. The whole event has to be deleted and re-created. It's on the to-do list.

[randy]

Yes it is possible to make an event that works. It is also highly likely that as you use the product over time even people quite aware of this bug will still break events. And you can’t ignore that events have to be deleted and remade if you need to change the trigger (assuming the bulk of an event is above the action).

This is not true. Triggers can be changed without breaking an Event. You do not ever need to delete a primary trigger.

[jlrichar]

Yes it is possible to make an event that works. It is also highly likely that as you use the product over time even people quite aware of this bug will still break events. And you can’t ignore that events have to be deleted and remade if you need to change the trigger (assuming the bulk of an event is above the action).

This is a big deal because events break in non-transparent ways, and it takes a lot of time to make simple changes and to troubleshoot broken events. If I was homeseer and cared about customer experience I would be in a panic to fix this. At this point I not sure anyone at HST other than Rupp knows about this bug. Hoping rjh is aware and has a plan!!




Sent from my iPhone using Tapatalk Pro

[Uncle Michael]

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.

While I find the bug disturbing and a bit unnerving, it seems more like a trap for the unwary than a structural problem.
I've not found it to be a problem as long as I do not delete the trigger. I've never had trouble changing an event trigger to something else. Is there an aspect to this that I'm missing?

[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.

[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.

[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]

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

[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.

[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.

[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]

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.