NEVER

[Steve Q]

I did a search and did not find anything. What is the purpose of NEVER in the Event Builder. It appears as a drop down under THEN. I have no clue how it would be used or what it does!

Also, Homeseer Help describes event conditions as IF, THEN, ELSE. But there apparently is no ELSE condition. Is there a way to have an ELSE event action?

Steve Q

Sent from my iPad using Tapatalk HD

[cheeryfool]

NEVER was described as a way to end an event when troubleshooting it and not as a useful tool for day to day usage. I think there was even talk about removing it.

I believe there was also discussion on ELSE. It's not currently available and I would definitely like to see it added to make event creation even more flexible.

[randy]

NEVER was described as a way to end an event when troubleshooting it and not as a useful tool for day to day usage. I think there was even talk about removing it.

I believe there was also discussion on ELSE. It's not currently available and I would definitely like to see it added to make event creation even more flexible.

You are correct on "NEVER", it is there so that you can temporarily disable an action without removing it as you are working on an event. I know we discussed it in this thread last year. There were several other times it was brought up as well. The problem is that it is difficult to find these answers. That is why the Event Clinic forum was created. We are building a thorough discussion of the Event Management system and the next group of posts will cover Actions. If you go to that forum there is a Table of Contents post that is updated as we add content.

As far as "ELSE" goes, I'll give you the same challenge that Rick Tinker gave me - describe how you envision "ELSE" working within events as they are currently structures. I was unable to come up with an answer.

Since an "ELSE" generally is the counter to an "IF" and since an "IF" is a trigger, the "ELSE" would be true whenever there was no trigger.

In an abstract, you could consider an 'ELSE' to apply to conditions and not to the trigger then it could work, but you would still have only a single action or set of actions to execute and if there are multiple conditions it becomes problematic - does the ELSE mean that ALL of the Conditions are false. In that case it is not much more difficult to create a secondary group with an OR IF statement.

In most cases one would use an ELSE to perform a different set of actions based upon the IF (trigger) or AND IF (conditions) being false and there is no way to branch off to separate Actions within a single event. To perform different Actions, you would need a new Event.

I covered my solution in this thread, but I would be very curious how you envision an ELSE would work.

[S-F]

It's true that an ELSE isn't needed as things currently are. But, it would allow flow chart like functionality in an event. The ELSE would somehow need to be linked to one or more conditions.

For Example:

IF The Light becomes on
AND IF It's nighttime (ELSE somehow connected to this one)

THEN Turn the other light on.

ELSE Turn the third light on.

Two events in one. It would make diagnostics more complicated with the way things are currently logged.

[randy]

It's true that an ELSE isn't needed as things currently are. But, it would allow flow chart like functionality in an event. The ELSE would somehow need to be linked to one or more conditions.

For Example:

IF The Light becomes on
AND IF It's nighttime (ELSE somehow connected to this one)

THEN Turn the other light on.

ELSE Turn the third light on.

Two events in one. It would make diagnostics more complicated with the way things are currently logged.

OK, you are describing a complete and fundamental change to HS3's design. Just playing devil's advocate here, how is that much easier than

Event 1
IF The Light becomes on
AND IF It's nighttime
THEN Turn the other light on.

Event 2
IF The Light becomes on
AND IF It's daytime
THEN Turn the third light on.

Since HomeSeer has absolutely no way to branch off to different actions within an event, and as you said tracing it in the log would be impossible.

I would also argue that separate events allows you to name, group and notate the events in a way that it is easier to go back a year later and figure out what you did. You could put event 1 into a "nighttime" group and event 2 into a "daytime" group or you could put them all in a group called "first light on". You could also name the events descriptively such as "Other light on at nighttime when first light turned on" and "third light on at daytime when first light turned on".

Just sayin'

[S-F]

Yeah, I hear ya. And that's what we all currently do. It's just that it can be a little tedious making so many very similar events. While you're in the heat of creating an event you sometimes think thoughts like "Geez, it would be nice to just insert an ELSE right here so I don't have to do this all over again". Really for me though this ELSE functionality would help me keep things more organized. I have some groups which are chock full of events and sifting through them can be rather confusing. Especially when you had a few friends over one evening and made a dozen or so after after imbibing some adult beverages. Like the time when my daughter came home from school and the house said to her "Oh ****. Not you again". Woops. That day WAF = -∞

Honestly I think the best solution, and one I believe we discussed in a very similar thread some months back, would be the ability to have sub groups.

[randy]

Yeah, I hear ya. And that's what we all currently do. It's just that it can be a little tedious making so many very similar events. While you're in the heat of creating an event you sometimes think thoughts like "Geez, it would be nice to just insert an ELSE right here so I don't have to do this all over again". Really for me though this ELSE functionality would help me keep things more organized. I have some groups which are chock full of events and sifting through them can be rather confusing. Especially when you had a few friends over one evening and made a dozen or so after after imbibing some adult beverages. Like the time when my daughter came home from school and the house said to her "Oh ****. Not you again". Woops. That day WAF = -∞

Honestly I think the best solution, and one I believe we discussed in a very similar thread some months back, would be the ability to have sub groups.

Yes, if I could campaign for changes there would be three

1. The ability to create one or more "child" groups - each with group conditions, and optionally group conditions on the parent group.
2. Group conditions are automatically applied to all events within that group, with an advanced option on the event to "ignore group conditions".
3. Events called from another event ALWAYS observe conditions in the called event with an advanced option to "ignore conditions in called event". Ultimately I would prefer that triggers always be ignored and the option would ONLY apply to conditions. If you are running an event from another, observing the trigger would keep it from running 99.999999% of the time. The rationale is that you could do clean up on events that might have missed their trigger, but you still want to observe their conditions. I have at least a couple of dozen events that could benefit from this ability

(unknown) - Scotland

[ORNVM]

I think a lot of it stems from some preconceived notion that multiple events are somehow bad. I know I was frustrated when not able to find a way to fire "else" events, but then once I got out of my mindset of single events and just created multiple events based on whatever triggers I wanted, my need for it went away.

It just follows so closely to traditional logic of IF/THEN statements that it should be there, but really isn't needed.

[Steve Q]

I raised the question about ELSE because I am in the process of converting my HS2 events to HS3. I have about 100 small vb.net scripts that I use in HS2. Many of the HS2 scripts are triggered by device status changes. They are simple IF, THEN scripts without conditions. For example, I am tracking my power useage; whenever appliance A turns ON or OFF, write that Time to a data file. So I have a clone of the script for every appliance. To create the scripts I use a text editor to copy and paste. It's fast and easy.

In HS3, I can create events to do the same things but it appears that I will need 2 events for each script. I am not very good at creating HS3 events. It takes me a long time to get them working properly. I am finding it easier and much faster to convert my existing HS2 scripts to HS3. The unfortunate consequence of this will be that my HS3 system will continue to be a highly customized setup that will be very difficult for someone else to operate and maintain. I was hoping for a more "off the shelf" implementation with HS3.

Steve Q


Sent from my iPad using Tapatalk HD

[Steve Q]

I think I now understand the purpose of NEVER when building an HS3 event. I have created many complex events to control my security cameras. One event is: "Take a snapshot with all cameras at 8AM". I have 5 cameras. So the event must have a minimum of 5 lines. And there needs to be a wait time between each camera command. So when building the event one line at a time, each line can be tested independently from the others by using NEVER. Once the event line for the first camera is finished and working, it can be marked NEVER. Subsequent lines can then be added and tested without rerunning all of the previously tested lines. This greatly speeds up the time it takes to create an debug an event. When all of the event actions have been added and tested, they can be easily changed from NEVER back to THEN.

When using event actions such as getURL and Wait, NEVER really comes in handy!

Steve Q


Sent from my iPad using Tapatalk HD

[randy]

I think I now understand the purpose of NEVER when building an HS3 event. I have created many complex events to control my security cameras. One event is: "Take a snapshot with all cameras at 8AM". I have 5 cameras. So the event must have a minimum of 5 lines. And there needs to be a wait time between each camera command. So when building the event one line at a time, each line can be tested independently from the others by using NEVER. Once the event line for the first camera is finished and working, it can be marked NEVER. Subsequent lines can then be added and tested without rerunning all of the previously tested lines. This greatly speeds up the time it takes to create an debug an event. When all of the event actions have been added and tested, they can be easily changed from NEVER back to THEN.

When using event actions such as getURL and Wait, NEVER really comes in handy!

Steve Q


Sent from my iPad using Tapatalk HD

That is the reason it was included as an option.