Never EVER delete an Event Trigger

[randy]

What the %$^&*?!? Wowsers, that's got to be one of the most unobvious things I've heard in my entire life. Guess that explains the occasion frustration I've had with making a few changes here and there, then finding bits and pieces missing/not working. There should at least be a line of text warning of this if it can' be fixed - then again 4761 customers would have to report it to them before that would even be considered

I'm only the messenger

[Tillsy]

Try collapsing the condition. I think on multiple choices, the condition needs to be collapsed to write it to the DB. It is a best practice to fully collapse an Event after editing.

EDIT: I just confirmed this to be true.

What the %$^&*?!? Wowsers, that's got to be one of the most unobvious things I've heard in my entire life. Guess that explains the occasion frustration I've had with making a few changes here and there, then finding bits and pieces missing/not working. There should at least be a line of text warning of this if it can' be fixed - then again 4761 customers would have to report it to them before that would even be considered

[pcburcham]

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

So, instead of setting the "control a device" action and then picking through the dropdown lists and turning on/off a number of devices, it is better to continue with THEN after each device/action for the sake of event integrity, correct? Any drawbacks to that or does HS3 execute the commands just as efficiently one way as the other? I've always stacked my devices under a single action and starting to reconsider that practice after reading this thread.

[randy]

You are a genius!

I wish I knew that you have to collapse conditions in order to effectively save them.

It works now and I've replaced the Wait statements with delayed device actions.

Sorry to hijack this thread.

Not a genius

On most events, when you complete a Trigger, Condition or Action, they will automatically collapse. The days of the week, being multiple choice, give no clear indication you have completed selections, so they do not automatically collapse. I suppose HomeSeer could write changes as you select/deselect boxes, but I could see that giving undesirable delays on slower systems.

[devanb]

You are a genius!

I wish I knew that you have to collapse conditions in order to effectively save them.

It works now and I've replaced the Wait statements with delayed device actions.

Sorry to hijack this thread.

[randy]

Try collapsing the condition. I think on multiple choices, the condition needs to be collapsed to write it to the DB. It is a best practice to fully collapse an Event after editing.

EDIT: I just confirmed this to be true.

[devanb]

Thank you for responding,

Regarding Sparkman's question, If I remove the trigger condition Day of the Week, Jon00 still reports the event broken.

I've made a simple event asking to lower the temp to 74 on Monday and Wednesday at 4am and it's still broken.





Now I'm getting worried my installation became corrupted somehow.

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

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

[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

[Kitar]

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

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

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

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

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