Many users find that the IF, OR IF, AND IF structuring becomes too cumbersome with multiple paths that can be taken after a given trigger. There is a way you can have multiple OR IF branches off of a single trigger or group of triggers without having to build an unmanageably large event. You simply create multiple events with different conditions and nest them under events with still more conditions and/or triggers.
Below I will post a series of screenshots and descriptions of some nested events I use for complex thermostat programming. In our Colorado climate we have extremely cold winter temperatures and normally cold winter temperatures, plus we can see radical swings in a half a day. This affects the amount of time it takes for the heat to return from a daytime or nighttime setback. The morning may need additional time to recover from setback, but the next afternoon may not. My wife also works one of three different shifts, affecting the time we return from night and day setbacks. I also turn the heat up in her bathroom about 30 minutes before she goes in to shower on work days. We also use different setback temperatures when we are home on a normal work day. On weekends when we are housebound we disable weekend setbacks during the day. All of this is controlled by a set of virtual devices below.
The devices are just as I described above. The weekend setback allows us to disable daytime setback temperatures when we are homebound. The Schedules are Vacation, Non-Work, Work-Early, Work-Mid and Work-Late. The programming control virtual device lets us suspend automatic schedule changes, essentially locking temperatures where they are. The Extreme Cold Offset is controlled by outside temperatures to change the recovery time from setback based on how cold it is. The Thermostat Mode Override is not used in this series of events.
All of those virtual devices can be set manually, or controlled by scheduling events or by temperature changes. What we need to do is to load the correct schedules in the thermostats based upon those variables. While I am certain that scripts could be written to take care of thermostat programming changes, this is all event driven.
The first thing we need is the triggering event. It is based upon any of three virtual devices being changed. We need to detect those changes, then load the correct schedules based upon the values of those 4 devices.
You will notice that the above event has 3 separate triggers, all based on any change in status of the three involved devices. If the outside temperature changes the Extreme Cold Offset device or if we make manual or programmed changes to either of the other two devices, this event will run. We need to continually monitor these devices for change so that any change loads the new appropriate programming. The only Action in this event is to call the next event "Thermostat Programming Thermostat Programming Check". Advanced options tell the Event Engine to respect the conditions in the event being called.
The above event will then call ALL of the possible changes to thermostat programming, but since the conditions in the called events are being respected only one of the long list will be true. This makes it possible to have a bunch or "OR IF" possibilities all based upon the trigger or group of triggers in the first event.
Below are two examples of the actual program loading events used. You will note that each of them has three conditions based upon the virtual devices used in the initial triggering event.
While this is a very complex example, the illustration is still valid for a means of having multiple paths that can be taken by a single trigger. There may be a practical limit to how deep you can nest events, there really isn't a physical one. Also remembering that HomeSeer is capable of multi-threading, despite the fact that I am calling 18 events from the second one, only the ones where all of the conditions are met will actually run, the rest of the threads will end as soon as one of the conditions is not met. That means that though it looks like a lot is going on, very little processor overhead is needed.
Remember that each branch of the flow can have additional conditions, allowing for very complex evaluation of a series of conditions in a very systematic fashion.
Below I will post a series of screenshots and descriptions of some nested events I use for complex thermostat programming. In our Colorado climate we have extremely cold winter temperatures and normally cold winter temperatures, plus we can see radical swings in a half a day. This affects the amount of time it takes for the heat to return from a daytime or nighttime setback. The morning may need additional time to recover from setback, but the next afternoon may not. My wife also works one of three different shifts, affecting the time we return from night and day setbacks. I also turn the heat up in her bathroom about 30 minutes before she goes in to shower on work days. We also use different setback temperatures when we are home on a normal work day. On weekends when we are housebound we disable weekend setbacks during the day. All of this is controlled by a set of virtual devices below.
The devices are just as I described above. The weekend setback allows us to disable daytime setback temperatures when we are homebound. The Schedules are Vacation, Non-Work, Work-Early, Work-Mid and Work-Late. The programming control virtual device lets us suspend automatic schedule changes, essentially locking temperatures where they are. The Extreme Cold Offset is controlled by outside temperatures to change the recovery time from setback based on how cold it is. The Thermostat Mode Override is not used in this series of events.
All of those virtual devices can be set manually, or controlled by scheduling events or by temperature changes. What we need to do is to load the correct schedules in the thermostats based upon those variables. While I am certain that scripts could be written to take care of thermostat programming changes, this is all event driven.
The first thing we need is the triggering event. It is based upon any of three virtual devices being changed. We need to detect those changes, then load the correct schedules based upon the values of those 4 devices.
You will notice that the above event has 3 separate triggers, all based on any change in status of the three involved devices. If the outside temperature changes the Extreme Cold Offset device or if we make manual or programmed changes to either of the other two devices, this event will run. We need to continually monitor these devices for change so that any change loads the new appropriate programming. The only Action in this event is to call the next event "Thermostat Programming Thermostat Programming Check". Advanced options tell the Event Engine to respect the conditions in the event being called.
The above event will then call ALL of the possible changes to thermostat programming, but since the conditions in the called events are being respected only one of the long list will be true. This makes it possible to have a bunch or "OR IF" possibilities all based upon the trigger or group of triggers in the first event.
Below are two examples of the actual program loading events used. You will note that each of them has three conditions based upon the virtual devices used in the initial triggering event.
While this is a very complex example, the illustration is still valid for a means of having multiple paths that can be taken by a single trigger. There may be a practical limit to how deep you can nest events, there really isn't a physical one. Also remembering that HomeSeer is capable of multi-threading, despite the fact that I am calling 18 events from the second one, only the ones where all of the conditions are met will actually run, the rest of the threads will end as soon as one of the conditions is not met. That means that though it looks like a lot is going on, very little processor overhead is needed.
Remember that each branch of the flow can have additional conditions, allowing for very complex evaluation of a series of conditions in a very systematic fashion.
Comment