Controlling a Hot Water Recirculating Pump plus Using Conditions and Triggers

[Timon]

RPrade has corrected me on my understand on conditions. Although these events seem to work fine as is they can malfunction.

This is an updated thread on how I'm controlling my hot water recirculating pump.

I used to have our Hot Water Recirculating Pump run 24 hours a day. I didn't want to use the timer on the pump because fixed schedules don't really work well. Still I didn't like running the pump so much so I figured it was time to let HS control it.

One nice thing about these pumps is that they can move lots of water when that water is in a loop with no flow restricters. This means that once the pump is turned on it only takes a few seconds to flush the line with hot water where it can take much longer when you only turn on the tap.

My plan was to detect when anyone may want to use water. Since I don't yet have motion detectors in my bathrooms I decided to use the fact that someone turned on the lights. Once I add motion detectors I'll trigger the pump using them but for now lights are a good indication that how water will likely be needed.

I also wanted to keep track of how many times a day the pump runs plus what the total runtime was during the day.

How long does the pump run? I've set mine for 15 minutes with a 5 minute quite period when it turns off. That way the max run time in one hour would be 45 minutes. I figured after 15 minutes of running the water won't cool of that fast. I may over time extend the quite period.

So here is the entire program for my pump. Note: I used EasyTrigger however it can be done without it. I'll also note where I use both Conditions and Triggers in the same events.

This event is triggered by a virtual device so I can activate it from Alexa. This may or my not be needed when HS releases support for Alexa V3. The reason for testing from Off to On is because there is an Idle state, (value of -1) which it always returns to.


This event is the only event that changes the state of the pump to On. It uses both Conditions and Triggers to function split into two events one for conditions and one for triggers.

There are many triggers and conditions that will cause the pump to start. I keep a group which contains all devices that if turned on will cause the pump to start. Also, you can put the pump into always on, automatic or always off mode.

You'll also find the quite period where the pump will not restart.




These are the stop conditions and triggers. As with start this is the only event that will actually turn off the pump.




This event is run whenever the pump is turned on. It setup the various timers and counters needed.


This event is run whenever the pump is turned off. It stops the timers.


The last event is used to reset the usage time and count at the end of the day. It's called from another routine that sends mail with the days statistics then calls this event to clear. It also has an "Only run once in 5 minutes option set".


The devices used for this example. Oh, is nor the HVAC icon use for the pump automatic mode. I need to take the pump icon and modify it for the new automatic icon.


As I make changes to how my pump works I'll update this thread so this first post will always be up to date.

Feel free to post questions and suggestions.

[racerfern]

Thank you! I lived in Newport Beach for a few years. I'm surprised you even use H2O recirculation. Now I live in NY on Long Island and we're frozen solid. I almost have to circulate my cold water to keep pipes from freezing. Not quite, but almost.

How long a run is it to your last valve? I assume you have a dedicated return line, yes/no? Have you considered a restrictor? I suppose at some point I'll have to time how long it takes for the return line to get warm just before it enters the tank. I'm actually thinking of attaching a temp sensor to the copper pipe. Qubino makes a cool controller with t'stat activation.

I ask because I'm in the planning stages. I plan on running a dedicated return line since I have access to a crawl space. I don't like the fact that a lot of water goes down the drain just to have warm water at the faucet.

Please keep updating this as you make changes. It helps a lot!

[randy]

As you can see both conditions and timers were used. I believe what confuses people the most is just what is a trigger and what is a condition. I've found the simplest way to remember which is which is that all conditions start MUST with: "IF This event is MANUALLY triggered" followed by one or more "AND IF" conditions. Triggers MUST NOT start with that line.

As I make changes to how my pump works I'll update this thread so this first post will always be up to date.

Feel free to post questions and suggestions.

A few observations...

Triggers ALWAYS start with IF or OR IF. It doesn't matter if the trigger is specific or "This Event is Manually Triggered", they are still triggers.

Conditions ALWAYS start with AND IF.

Triggers are ALWAYS ignored when an Event is called from another Event. The second Event you posted will always run when called from another Event, because your second Trigger has no Conditions. This Event will run whenever the first Event runs.



The third Event does not have the same problem, but it is important to note that ALL Triggers are ignored when an Event is called from another Event. This means that your third Event (and your second Event) will run if any of the Conditions are true, regardless of the triggers. In an Event called from another Event ALL triggers can be considered to be functionally equivalent to "This Event is Manually Triggered". The Triggers will still allow it to run autonomously when the Trigger and affiliated Condition(s) is/are true.

[Timon]

Now I'm confused again.

You're saying that conditions following a qualifying trigger are also used when called from another event marked to check conditions. I must say that I am having a hard time wrapping my head around that as it could totally cause events to malfunction because they are bing executed when the qualifying trigger was not true. That's the reason I thought that the Manual trigger was added so only those would be checked when the event was called manually from another event.

I'll have to test some more of my conditions which are combined with triggers in the same event as I don't think I've seen the action that you described but then maybe it's just never happened.

[randy]

Now I'm confused again.

You're saying that conditions following a qualifying trigger are also used when called from another event marked to check conditions. I must say that I am having a hard time wrapping my head around that as it could totally cause events to malfunction because they are bing executed when the qualifying trigger was not true. That's the reason I thought that the Manual trigger was added so only those would be checked when the event was called manually from another event.

I'll have to test some more of my conditions which are combined with triggers in the same event as I don't think I've seen the action that you described but then maybe it's just never happened.

It had always been that way, except for a couple of releases. Rich did briefly change it just before 3.0.0.170, but changed it back in 3.0.0.170. Read this thread carefully and it might make more sense.

As I wrote in that thread "This means that if you expect to manually call an event that is triggered by a device action, you should also put a condition based upon the value of that device being true". So you would follow your trigger with an identical condition. In the case of your second event it would be

OR IF Controls Laundry Recirculating Pump Mode changes and becomes On
AND IF Controls Laundry Recirculating Pump Mode has a value equal to On

This way it could be run from another Event or run autonomously from the Trigger.

[Timon]

Thank you! I lived in Newport Beach for a few years. I'm surprised you even use H2O recirculation. Now I live in NY on Long Island and we're frozen solid. I almost have to circulate my cold water to keep pipes from freezing. Not quite, but almost.

Even though we live in a nice climate we still have to wait for the hot water lines to be cleared of the cold water. That wastes water and I'm trying to not waste water.

How long a run is it to your last valve? I assume you have a dedicated return line, yes/no? Have you considered a restrictor? I suppose at some point I'll have to time how long it takes for the return line to get warm just before it enters the tank. I'm actually thinking of attaching a temp sensor to the copper pipe. Qubino makes a cool controller with t'stat activation.

I added a return line during our remodel but you could do close the same thing with the temp deserter at the end of the lines.

You don't want any restricters in the loop as you want the water to flow as fast as possible. You also do't want to over size lines as that makes more water to move to clear the lines of cold water.

To get to the last valve we go about 50' with at least 40' of that under the slab. When the pump used to run full time you could feel the heat above the lines,

I ask because I'm in the planning stages. I plan on running a dedicated return line since I have access to a crawl space. I don't like the fact that a lot of water goes down the drain just to have warm water at the faucet.

Please keep updating this as you make changes. It helps a lot!

Make sure you insulate the return line as well. You want to keep heat loss to a minimum so the water heater doesn't run too much.

You also have to be careful when using this with instant hot water heaters. You need to have a small holding take that feeds the hot water lines and the return must come back to the holding take. You then need a second pump to loop the instant hot water heater to the holding tank and it has to be triggered by the temp in the holding tank. This way when water is running it goes through the holding tank to the hot water lines. When no water is running the recirculating water doesn't go through the instant hot water heater, If the water in the holding tank gets too cold then the instant will turn on and warm it up. If you have a boiler then you already have a hot water holding tank.

Basically the plumbers should get the whole thing working with the pump in timer mode. Then you can add the HS control once it's all working.

[Timon]

It had always been that way, except for a couple of releases. Rich did briefly change it just before 3.0.0.170, but changed it back in 3.0.0.170. Read this thread carefully and it might make more sense.

As I wrote in that thread "This means that if you expect to manually call an event that is triggered by a device action, you should also put a condition based upon the value of that device being true". So you would follow your trigger with an identical condition. In the case of your second event it would be

OR IF Controls Laundry Recirculating Pump Mode changes and becomes On
AND IF Controls Laundry Recirculating Pump Mode has a value equal to On

This way it could be run from another Event or run autonomously from the Trigger.

Ok, I see where you're heading and I'll do some more reading on those other threads. I guess so far I've just been lucky they haven't false tripped.

However, if you only want a condition with no trigger then you still start it with the "Manual Event". If you want only a trigger you have to qualify the trigger in such a way that the condition will not occur when the trigger is false.

I see why non-programmers pick this up quicker as this is somewhat counter intuitive to programmers.

[randy]

I see why non-programmers pick this up quicker as this is somewhat counter intuitive to programmers.

True, but the Event engine is really not a programming language, it is Trigger driven conditional Events. While the rules may be confusing, just as English would be to someone who converses in French, you will find that it is very powerful and flexible once you learn it. Once one stops expecting it to behave like a programming language and learns its nuances, there is little which cannot be accomplished.

A Trigger is "a moment in time, while a Condition is a state. While "This Event is manually Triggered", may not seem like a Trigger it is only going to run at the moment in time that another Event "triggers" it.

[Timon]

A few observations...

Triggers ALWAYS start with IF or OR IF. It doesn't matter if the trigger is specific or "This Event is Manually Triggered", they are still triggers.

Conditions ALWAYS start with AND IF.

Triggers are ALWAYS ignored when an Event is called from another Event. The second Event you posted will always run when called from another Event, because your second Trigger has no Conditions. This Event will run whenever the first Event runs.



The third Event does not have the same problem, but it is important to note that ALL Triggers are ignored when an Event is called from another Event. This means that your third Event (and your second Event) will run if any of the Conditions are true, regardless of the triggers. In an Event called from another Event ALL triggers can be considered to be functionally equivalent to "This Event is Manually Triggered". The Triggers will still allow it to run autonomously when the Trigger and affiliated Condition(s) is/are true.

I've read and reread these and still have questions. on the above so let's go through it line by line.

The first IF time followed by a AND IF, your saying that the AND IF will be evaluated if this event is called and if the pump is off it will be turned on because the IF The time is sunset was not ignored. My test confirms this to be as you say which IMHO sucks.

Since there are many test conditions you can use in an OR IF that you can use in the following "AND IF", such as any device change test, there is basically no way this can work in those cases. My second OR IF group is one suck case. There is no way to qualify the conditions based on a change of device state. This is not only true of Easy Trigger but even standard change or set tests.

Now I do have a solution which will absolutely NOT break anything and still allow both the current way and the way I expected to work.

Create a new AND IF test condition call, "And IF Not called from event" . If you add this in to the group of AND IFs, normally it would be the first one, it would always return false if the event was called by and event and true it wasn't called from an event.

Now the users have control of which way they want it to work. If you don't add the line everything works just as it does now but if you add the line then it keeps the conditions in that group from ever being true if called from another event.

I am assuming that an event knows that it's been called from and event because of the "If the Event Conditions are True" flag which I assume is passed to the called event.

Example:

OR IF Any device in group RecirculatingPumpTriggers has its value changed
AND IF Not Called from EVENT
AND IF Any device in group RecirculatingPumpTriggers has a value that is not equal to 0
AND IF Outlets Mechanical Recirculating Pump Outlet has been Off for at least 5m, 0s

By adding the one line the Trigger and condition will work as expected when triggered but will never execute when called from an event.

I see everything to gain and nothing to loose by adding this test. I see it as making a great product even better.

What are your thoughts?

[randy]

I've read and reread these and still have questions. on the above so let's go through it line by line.

The first IF time followed by a AND IF, your saying that the AND IF will be evaluated if this event is called and if the pump is off it will be turned on because the IF The time is sunset was not ignored. My test confirms this to be as you say which IMHO sucks.

Since there are many test conditions you can use in an OR IF that you can use in the following "AND IF", such as any device change test, there is basically no way this can work in those cases. My second OR IF group is one suck case. There is no way to qualify the conditions based on a change of device state. This is not only true of Easy Trigger but even standard change or set tests.

Now I do have a solution which will absolutely NOT break anything and still allow both the current way and the way I expected to work.

Create a new AND IF test condition call, "And IF Not called from event" . If you add this in to the group of AND IFs, normally it would be the first one, it would always return false if the event was called by and event and true it wasn't called from an event.

Now the users have control of which way they want it to work. If you don't add the line everything works just as it does now but if you add the line then it keeps the conditions in that group from ever being true if called from another event.

I am assuming that an event knows that it's been called from and event because of the "If the Event Conditions are True" flag which I assume is passed to the called event.

Example:



By adding the one line the Trigger and condition will work as expected when triggered but will never execute when called from an event.

I see everything to gain and nothing to loose by adding this test. I see it as making a great product even better.

What are your thoughts?

There is currently no condition as to whether an Event was called from another Event. You can ask for it as a product enhancement, but I really don't see the need.

I guess I will never understand the aversion to multiple events. While I am not trying to proliferate Events my system Events: 1582. They are well organized and named and very easy to find and change. Many, if not most of my events have been in place since they were created and remain untouched.

Instead of trying to put 10lbs of potatoes in a 5lb bag, why not have a separate autonomous event with all of the Triggers and Conditions for it to be a stand alone Event, then have a separate Event designed to be nested within another Event for branched logic. The branched Event (which can have multiple manual triggers and affiliated conditions) will always be run from another event. Once you have created your Event structure and have everything running, you might be able to add a trigger to the branched event to let it serve both Autonomous and branched roles.

Not to but it is always important to understand that a Trigger is but a moment in time. Your first example where the trigger is "Sunset", this trigger is EXACTLY 4:58:27 PM. The time is actually calculated out to milliseconds, but Even if the resolution was ONLY seconds, what would be the odds of another Event calling the Event at EXACTLY 4:58:27 PM. The reason Triggers MUST be ignored when calling an Event from another Event is that it would be nearly impossible to call an Event at the exact moment a

• Light changes to On
• Virtual device changes or is set
• A thermostat reaches its setpoint (not to be confused with when it is at its setpoint)
• An exact time or timer value

I could go on and on, but the point is that in all but a couple of examples a Trigger is only true for a millisecond.

Your first Trigger "IF The time is sunset (4:58:27 PM)", is clearly something you only want to occur once a day, so it should be in its own Event. If you are adamant upon trying to put all of this in a single event you could put a Condition on it "AND IF the time is Sunset" preventing that section from running the actions, except at sunset. To me it is eminently easier and more manageable to separate branched and autonomously launched Events, except in cases where there is only a single Trigger with a stack of conditions and you wish to run the Event at a time other than the time it would Trigger on its own.

IMHO, HomeSeer Event logic doesn't suck, it has a set of rules that it follows, which are different rules than a programming language follows. It is simply a boolean logic Trigger which can be filtered with boolean logic Conditions. Above all, the Events are designed to be launched by a Trigger. When they are called from another Event the calling Event IS the Trigger, or more accurately it is ALL the Triggers as they are all (necessarily) considered to be true. Once one understands the rules and doesn't get hung up on Event counts, it does everything very well.

[Timon]

Actually I think this has been a good discussion. Back in my engineering and programming days this is exactly how we worked out issues. Some times it went quick and sometimes not but in the end our products were better for it.

Triggers with attached conditions have never been the issue. They work great with conditions attached when needed. It's about having the conditions that are attached to triggers, other than MANUALLY triggered, being executed when the event is called from another event. Those are the ones mess things up because of the unexpected actions. They were always meant to be part of the whole IF and AND IF sequence but when the event is called part of the conditions that make it True is ignored so the entire logical entity is no longer valid you get unexpected consequences.

Personally, I don't understand why they should have ever been included when attached to a trigger, other than MANUALLY triggered, and how doing that caused problem unless someone actually wanted it that way.

However, that's the way it is and I have to accept that but at the same time have suggested a clean way to ignore conditions tied to real triggers.

We'll just have to see if HS thinks my idea is worth looking at.

Anyway, I can, and likely will, split up these events with Triggers with conditions attached and Conditions into two events with almost the same name only so I don't have to worry about calling an event with that has some triggers then having unexpected happen. So in this case I'll have "Recirculating Pump - Stop - C" and "Recirculating Pump - Stop - T". It just means that to events have the same Then to be maintained unless I want yet another event. I just hate making two or three events where one would do.