A simple event - what am I doing wrong?

[dbrunt]

I have frequently run events manually just to test &/or forcefully execute the actions; i.e. close my blinds even though it is not sunset (trigger) or nighttime (condition). If the conditions were enforced I might not be able to do that. However, it would be nice to have two options: run manually with conditions to test the condition logic despite not having the event trigger occur (i.e. run out into the back yard to trigger motion) and run the event without conditions (like it does now) to test &/or just execute the actions. Knowing the logic behind how a manually run event currently behaves though is important information...

[SteveMSJ]

I have frequently run events manually just to test &/or forcefully execute the actions; i.e. close my blinds even though it is not sunset (trigger) or nighttime (condition). If the conditions were enforced I might not be able to do that. However, it would be nice to have two options: run manually with conditions to test the condition logic despite not having the event trigger occur (i.e. run out into the back yard to trigger motion) and run the event without conditions (like it does now) to test &/or just execute the actions. Knowing the logic behind how a manually run event currently behaves though is important information...

Good point, it can be useful to run without conditions, it’s just the default should be to honour them. When calling from another event you have the option but the default should be to honour conditions.
Steve

[Uncle Michael]

HST must have had their reasons but have never suitably justified them to my knowledge. They have also resisted many calls to change the behaviour.

I agree the behavior is illogical and not intuitive. As I reconstruct the situation, I believe that originally, it was not an option to check conditions at all when one event called another. When the capability was added (HS2?), the option to do so was - well - an option so as not to break events that had been previously constructed. Unfortunately, with each new version, that same (il)logic has been maintained. Given the blow-back HST gets for even small changes, I think I understand the reluctance to fix it, but it does seem like it's time to bite that bullet.

[TC1]

I agree the behavior is illogical and not intuitive. As I reconstruct the situation, I believe that originally, it was not an option to check conditions at all when one event called another. When the capability was added (HS2?), the option to do so was - well - an option so as not to break events that had been previously constructed. Unfortunately, with each new version, that same (il)logic has been maintained. Given the blow-back HST gets for even small changes, I think I understand the reluctance to fix it, but it does seem like it's time to bite that bullet.

Exactly. We get that all the time in tech world, the product team wants to deprecate an API function call and replace it with something better... only to get push-back from the API consumers "but, but... I don't have time right now to update my code... we'll get to it next quarter" And then the quarter comes and goes... then the years go by....

Sometimes you have to draw a line in the sand for the greater good.

[randy]

I started with HomeSeer at the beginning of 2014. It took a couple of weeks to learn how HomeSeer’s Event engine worked, including many things that were not articulated in the manual. That is the reason I requested they create the Event Clinic Forum and subsequently created a ton of content for the forum explaining much of the operation in detail. I would start with the Table of Contents post. I am able to solve almost any automation need now that I understand it. I rarely complain about how Events are structured, but I frequently suggest changes to HST. The honoring of Conditions in a Manually Triggered Event is one I have addressed several times.

There is one rule that cannot change: Triggers must always be ignored. It is virtually impossible to manually trigger an event at the exact moment the Trigger becomes true.

As far as manually triggering from the Event Management page, I am ambivalent. I cannot see any reason to test Conditions when manually running an Event. I do manually run events to test actions such as testing if the dim level of a lighting control is correct. If I ever did want to test conditions, it takes only a few seconds to put together another Event for testing to have the Conditions in the tested Event honored.

The change I would make would be for the default behavior to honor the Conditions in the called event. The best way would be to change the choice to “Ignore Conditions in Called Event: [ ]”. The default would be for this to be not selected. While that is easier to understand, functionally it is no different than the current, except for the default behavior. Once one knows the default behavior, it can be considered each time the Action is used, regardless of the way it is communicated. This different structure of the Action could be done in an update without affecting anyone’s existing Events.

It would also be nice to have Conditions honored when an a Event is run by voice command, it might be possible to add that as an advanced option on each Event

[TC1]

, you make many good points.

My one criticism of HST that I would vigorously defend: The documentation (that I am aware of) is abysmal. This is not some plug-n-play product that one purchases from Walmart, hence the functionality of the software should be pretty well spelled out. Instead they rely on a user supported forum where newbies, such as myself, as the same tired questions, over and over.

And the users that don't ask questions here either get frustrated or open a help desk ticket... which in turn stretches out already limited HST resources... whom are busy squashing bugs. It's a no win situation unless they commit to better documentation so that more users can empower themselves.

[Dan-O]

, you make many good points.

My one criticism of HST that I would vigorously defend: The documentation (that I am aware of) is abysmal. This is not some plug-n-play product that one purchases from Walmart, hence the functionality of the software should be pretty well spelled out. Instead they rely on a user supported forum where newbies, such as myself, as the same tired questions, over and over.

And the users that don't ask questions here either get frustrated or open a help desk ticket... which in turn stretches out already limited HST resources... whom are busy squashing bugs. It's a no win situation unless they commit to better documentation so that more users can empower themselves.

No offence intended on this newbie comment towards you but you will RARELY if ever have someone reply for you to RTFM - I clicked the Help button in HS once a million years ago, it was not of much assistance.

I do agree with your comments - seems that crowd-sourcing for assistance is the norm nowadays here. Was not always that way.
The forums are a great way to seek out other's opinions and ideas for sure and I learn something new all the time with a, "Why didn't I think of that?"

No kidding, I've been using HS since 1999, not many can say that (there are a few here that can) and just when you think you have it set and done, you come up with another idea to implement. This has truly been a hobby for me and I enjoy coming up with solutions to problems I never knew I had.

[TC1]

I enjoy coming up with solutions to problems I never knew I had.

Exactly... I want to spend time coming up with SOLUTIONS... not figuring out the undocumented idiosyncrasies of the tools I'm using.

I've been doing tech at both the hardware and software level for 40 years now... I can recognize something good right away and I have to give kudos to the HS event engine, there's a lot going on under the hood that helps keep things running smoothly. But HST has to stop shooting itself in the foot in terms of running its product development and support. I've invested my money, and slowly my time, so I want the product to succeed.

[dbrunt]

No kidding, I've been using HS since 1999, not many can say that (there are a few here that can) and just when you think you have it set and done, you come up with another idea to implement. This has truly been a hobby for me and I enjoy coming up with solutions to problems I never knew I had.

I can! Well almost...
Summer of 2000 for me when I discovered the world of Z-Wave after having dabbled with X10 for a few years.

[Dan-O]

dbrunt , I have a similar box of HA parts too.

[ewkearns]

, you make many good points.

My one criticism of HST that I would vigorously defend: The documentation (that I am aware of) is abysmal. This is not some plug-n-play product that one purchases from Walmart, hence the functionality of the software should be pretty well spelled out. Instead they rely on a user supported forum where newbies, such as myself, as the same tired questions, over and over.

And the users that don't ask questions here either get frustrated or open a help desk ticket... which in turn stretches out already limited HST resources... whom are busy squashing bugs. It's a no win situation unless they commit to better documentation so that more users can empower themselves.

Randy is the only one that has provided useful documentation for HS3 and I still have that .pdf file, which I use in lieu of the worthless help file mess. At least one can take the printed media and make notes and highlight the easter eggs and errors...

One wonders if there will be a downloadable manual for HS4?