Never EVER delete an Event Trigger

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

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

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

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

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

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

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

See post #19. I now have an event with a broken trigger, but I can't change it to make it work. I can however, create a new event with a new trigger with that changed device that does work.

[Uncle Michael]

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.

I totally agree, and this is only one example.

Unfortunately, reality is seldom ideal. In the case of HS, "tribal knowledge" as you so aptly termed it, is a critical part of making the most of the application. The problems arise from incomplete and obsolete documentation, bugs and other 'undocumented features', as well as inconsistencies in nomenclature. I have taken the approach of considering all of these "quirks" to be part of the overall learning curve.

It is puzzling, though, that HST does not consider these problems to be of any urgency. But that is the reality.

[Uncle Michael]

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.

Not to quibble, but I would consider this a separate bug. If there is an option to "replace" a device, it should do just that, replace the device in any events where it is referenced. (I have had instances where I've deleted a device, so an event trigger no longer has a valid device in it, but I could still change the trigger without issue.)

[joegr]

Not to quibble, but I would consider this a separate bug. If there is an option to "replace" a device, it should do just that, replace the device in any events where it is referenced. (I have had instances where I've deleted a device, so an event trigger no longer has a valid device in it, but I could still change the trigger without issue.)

Yes, it is another bug, but it is a bug that is harder to work around due to this delete trigger bug. Two bugs don't make a right (though three lefts do). Anyway, there are lots of bugs and quirks that long time users have learned to deal with, so much so that it seems normal. This delete trigger bug seems worse than most to me. If HS wants new users, they would do well to concentrate on this stuff instead of ignoring it and jumping to the next version.

[Kitar]

Anyone know if the jon00 EventViewer utility can test for this type of broken trigger ? HS3 lacks a good set of troubleshooting utilities.

[devanb]

I have an event where if I modify the trigger (which day of week my morning alarm should go off), the event no longer runs.

Jon00 Event viewer will report the event broken.

If I reboot the homeseer Pi, the event runs normally and Jon00 reports it unbroken.

The error can be reproduced if I modify the trigger again.

Luckily I have a backup work alarm!

Is this error the same error reported in this thread? My log doesn't show any errors upon modification of the event.

Thanks,

Devan

[sparkman]

I have an event where if I modify the trigger (which day of week my morning alarm should go off), the event no longer runs.

Jon00 Event viewer will report the event broken.

If I reboot the homeseer Pi, the event runs normally and Jon00 reports it unbroken.

The error can be reproduced if I modify the trigger again.

Luckily I have a backup work alarm!

Is this error the same error reported in this thread? My log doesn't show any errors upon modification of the event.

Thanks,

Devan

Your trigger is "If the Time is at 04:00:00". The days of the week is the condition, not the trigger. If you delete the day of the week condition, and then re-add it, does it then run normally? Either way, I would recreate the event manually and then delete this one if it's given you trouble. On an unrelated note, I would typically recommend using delayed event actions (created by filling out the "After Waiting..." portion of the actions), rather than using long waits in the event.

[randy]

To add to what Al stated, a "Wait" action, pauses a running Event, but it is still in memory, waiting for the time to elapse. From this thread:

"For short delays of a few seconds a Wait is generally more reliable and efficient than Delayed Events or Delayed Device actions."

And from this thread about delayed Device Actions:

"As you can see there are several steps involved in this process, making it somewhat inefficient for very short delays. For a short delay of 1-10 seconds a Wait Action is preferable as it saves the database writing and subsequent deleting of the delay Event. For longer delays, the Delayed Device Action is usually preferable to suspending an Event. It is important to understand that the Delay applies only to a specific Device. All actions are performed at the instant the Event is run, with delays built in to the Actions. In this Event Device1 will be turned on in 5 minutes, Device2 immediately and Device 3 after 1 minute. The Delays are independent and do not affect anything else in the Event."