apostolakisl

The program I quoted above would do absolutely nothing if the temp updated in 30 seconds. I think you need to take a closer look at what is happening.

I don't know what worked, but this: If 'ZW 125.8 Multilevel Sensor' Temperature > 10.0°C Then Repeat Every 2 minutes Wait 40 seconds $Int_4_ensuite_shwtemp_slow = 'ZW 125.8 Multilevel Sensor' Temperature °C Else - No Actions - (To add one, press 'Action') won't work. Temperature change is a trigger. So every time the temp changes by (I assume .5 is the increment), the program will cancel out and start over. Your repeats and waits will not execute in any predictable fashion.

This will never shut the fan off unless the temp is both above 25 and steady for 15 minutes. If it drops below 25, it will trigger false, and assuming it didn't first sit at 26 for 15 minute straight, the fan would not turn off. It also would turn the fan off if say you took a 16 minute shower where the pipe temp hit its max and stayed constant for 15 minutes. That would also be counter to your desires since you would want the fan to keep running.

This won't work. Every time temp changes your first program will re-trigger and the wait/repeats will reset. The program I wrote is how to do that. If you want it posted to a variable then use the then/else clause to set a variable. But there should be no need for that as you can reference program state the same as variable state.

1) PGM 1 (this is a modification to your first program you already have) If 'ZW 125.8 Multilevel Sensor temp' > 0 Then $State_old = $State_1 $State_1 = 'ZW 125.8 Multilevel Sensor' Temperature °C run 'if' PGM Temp Up vs Down Else - No Actions - (To add one, press 'Action') 2) PGM Temp Up vs Down (set this program as disabled) IF $State_old < $State_1 Then blank Else blank The above program 1 is a tweak to your program you already have. Program 2 will be "true" if temp is going up, false if it is going down. Also, you should add the below program in case you start the shower and don't let it get to full temp IF status fan on Then wait 30 minutes (or whatever) set fan off stop program 'fan on off' EDIT: Also, if you don't like having to drop below 25 to reset things, just change it. You can make it higher, just remember you will also need to make the "click on" temp a couple degrees higher than the reset temp. Like maybe the fan clicks on at 35 and the reset happens at 33.

Do it the way I did it the first time. No need for variables. The "repeat while" only works with variables. Just copy my first set of programs. But FYI, the reason your variable never updates is because "responding" is not a trigger. That program will never run. Also, the "repeat" repeats what is under it, not above it. And finally, you have a "enable fan on/off" line in your program that should be a "run then". If you want to keep your current programs you need to 1) Fix the "enable .. . " to "run then. . ." 2) Change the "if" clause of your first program from " . .. responding..." to if 'ZW 125.8 Multilevel Sensor' is >0 Then $State_1 = 'ZW 125.8 Multilevel Sensor' Temperature °C The above program will trigger every single time the temp changes

You are basically catching temp going up or down by testing for one temp, disabling, then testing for a higher or lower temp with a different program. It is crude, but for this application it is sufficient. ISY doesn't do calculus. Larryllix makes a point about some features of v5. Though the specific example isn't what you wanted since it only runs then fan after the pipe hits 48. I'd have to think about it for a while to see if turning the fan on at 25 and keeping it on until it hits 48 then drops to 45 can be done in fewer steps using v5. Maybe using a couple of "repeat while" consecutively. Below is an idea, I haven't really fully thought it through. 1) pgm 1 if -blank then set fan on repeat while temp < 48 wait 1 second repeat while temp > 45 wait 1 second repeat 1 time set fan off repeat while temp >25 wait 1 second repeat 1 time enable pgm 2 2) pgm 2 If temp >25 Then run then pgm 1 disable pgm 2 Not sure the above is simpler, but it is fewer programs.

You have to have your shut down program become active after the temp exceeds 45. In fact, you would want some hysteresis in there. Something like over 47. You would also need to disable the program that turns the fan on at 25. pgm 1) If temp above 25 then turn fan on disable pgm 1 pgm 2) If temp above 48 then enable pgm 3 pgm 3) If temp below 45 then turn fan off disable pgm 3 pgm 4) If temp below 23 then enable pgm 1 pgm 5) (added in to fix things if your temp goes above 25 but never makes it up to the other temps, like you turn the shower on then the phone rings?) If status fan on Then wait 30 minutes (or whatever) turn fan off EDIT: Though this set of programs won't work right if you don't let the shower get all the way up to temp.

So you'll need to consider the status of the tree. If the tree changes status during the 5 minutes that will also kill the program. The best way to manage that is to use a second program that is disabled. The first program runs the "if" on the second, disabled program. This program checks the status of the tree and contains your "then" stuff above. A disabled program only runs when called, it never runs on a self trigger. So in other words, the only thing that can kill the 5 minute wait is something in the "if" of the first program. Alternatively, you could have a program that shuts the light off if the tree turns on. This might be more to your objective of not having both the tree and light on at the same time since it will shut the light off immediately, not waiting for the 5 minute timer.

Because the front door "status" open is probably closing before the 5 minutes, which resets the program since all status items trigger on any change. "control" items trigger strictly on the designated action and no other. I have no idea what is monitoring your front door, but if it has a "control" option use it. If not, you'll need two programs.

But did you watch the variables change on the variable page? This will tell you if the program is passing through all the steps and what values it is giving you at each step. The 1, 2, 3 lets you know the full program ran. If the temp number never changes, then there is a good chance the "number" contains non-numeric info.

1) Try putting a wait 5 seconds as the first line of "then" (before everything else) 2) Increase other waits to 2 seconds 3) Add a testing variable at each step and just have it count 1, 2, 3 ie $test = 1 after the wait 5 seconds, then $test = 2 after the second wait, etc. 3) Right click on program in tree and hit "run then" 4) Go to variables page in less than 5 seconds, watch the variable change values and see where it goes astray. The only thing I can think of is that you have another program modifying the value midstream or stopping this program. The 1, 2, 3 will assure you that it kept moving through each step, and then the values of TempC will show you what math is happening.

He means what ISY calls "integer" variables. There are 2 tabs on the variables page. Whenever a state variable changes value, any program containing that variable in the "if" clause will trigger. Integer on the other hand or only tested inside an "if" clause when the "if" clause is executed for some other reason.

This was a topic a very long time ago. Could be about 7 or 8 years ago. LeeG who used to be a constant on this forum but for some reason is no longer around pointed it out. Lee seemed to be someone who was privy to ISY firmware code and was often referenced by Michel for answers. He clearly was more than just a "user". The thing is that usually things are executed top to bottom, but it is not guaranteed. The fact that almost 100% of the time it is top to bottom leads most people to believe that it always is top to bottom. I do believe at the time we had found some examples of things that ended up not going top to bottom. As far as I know, ISY code has not changed this behavior in its current iteration.

While I did not have any mis-behaving programs during my migration to 5.x firmware, I have seen other people say they had a few programs that needed to be re-created. I did have some problems, but those programs turned yellow indicating that ISY knew there was a transfer issue allowing me to fix them.

I'm not following exactly what the input value and output value you are getting are. However, ISY does not necessarily do sequential steps of a program in order. The only way to be certain of steps happening in order is to put a "Wait" between them. Otherwise, all items in the "then" clause are presented for processing simultaneously and the first thing may not be first done. So, try putting waits between each step and see what happens.

As Larry mentioned, yes, you can have as many programs as you want have the same trigger within the "if" clause. However, I would recommend simply putting all the "then" items into a single "then" clause rather than a bunch of programs. The exception to that would be if you have multiple triggers/conditions and some of them apply to one "then" item and some apply to a different "then" item. Like maybe some of the "then" items might be shut down at night.

That is pretty clever. And I love all their other stuff that pretends to be a person pushing buttons. Looks like $179 gets you what you need delivered for a typical two sided set of curtains to be on the internet. It appears they use bluetooth, so that would be why the hub is needed. For the $179 you also get two add-ons, but I can't find a list of add-ons. I do see they have a little remote control and a solar panel as add-ons, not sure what else they may have.

Best reason yet to not have your house filled with wifi enabled devices: https://english.madhyamam.com/en/science-technology/2019/oct/23/smart-light-bulbs-may-be-used-hack-personal-info-study Each one of those is a security risk. Unlike Insteon which can only be hacked by actually being very close to your home, and even then, can only control Insteon devices, a IoT device can be hacked from anywhere in the world and provide access to all connected devices in your home. With a hub, only the hub is a security risk, much easier to manage that and also update with patches and so on.

I wonder what people actually do with many of these devices that they just dabble in? Most of them seem to focus on "Look turn your light on from your phone". For me, that is like .001% of what I use HA for. I basically never need to control a light from my phone and only about 1% of the time use google or alexa. 99% of what I do is use logically constructed programs to make the house respond to me without me actually doing anything or doing very little. Basically, lots of programs that takes input from motion sensors, cameras, alarm system status/events, time of day, season, weather, and so on to just do what I would be doing manually. To me that is what it is all about. I would never mess with any of this if all it offered was remote control or some rudimentary timers. But I don't know. My daughter wanted to turn her bedside lamp off without leaning over to the switch. I said, sure, I'll make it so you can tell your alexa. That was too involved for her, she actually bought a clapper. That's right, my teenage daughter gen whatever the heck they call them uses 1980 technology to turn her lamp off. And then, when I was installing some shelves in her room, my drill was triggering that clapper like a strobe light.

But the earlier argument is that people are ignorant and that is why they wouldn't want Insteon.

Back to the actual point of this thread. It occurred to me, a while ago I got ubiquiti stuff and decided to a bunch of ssid's, vlans and what not. I needed to change a bunch of devices ssid/password. That was a pain. Now imagine if I had 50 or 100 more devices. Just for example, if I changed my living room cans to wifi bulbs, that would be 6 devices for just one "light". Most people don't do what I did, but most people do change isp's, get a new ap, and don't have a clue that they can just put out the same ssid/password and thus would end up changing all the devices. Or if you needed to keep your kids off the network, again, I would know how to control that from my router, but most people would again be changing passwords. Or maybe your neighbor starts stealing your wifi?

OK, but there are 100 ways to do that. In my house, when a leak detector goes off it is an actual security event. Central station gets a call, audible alerts go off, and the water valve shuts off. If I had red lights, I could do it when someone pulls into my drive (now that I have blue iris figured out for that), but instead I have my Insteon switches do a little chirp-chirp-chirp. Just out of curiosity, do any other brands have chirping switches? I really like the chirps, I use them for lots of things, and they don't alter your working conditions by changing the lighting. I use the chirps to warn you when a light is about to time out, I use it to get my kids out of the house at the right time in the morning, cars pulling in the drive, and a few other things.

I have seen colored accents lights that look good, but that is because it isn't the functional light. It is meant to light up a wall or patch of ceiling, as if it were artwork. When the light you use to actually see what you are doing is mono-chromatic, it is poor.

Was that because you could make that green growth you have disappear? Oh, I kill myself.