apostolakisl

There is no "for" in the if clause on any version of firmware I'm aware of. The only "for" is in the then/else clause as part of a "repeat for x times" first introduced in the 5.x firmware.

You don't need a wait and you don't need two programs And a long wait is more susceptible to a reboot, but reboots of ISY don't happen spontaneously except, as I have learned on DST switch day (and unfortunately not just at 2 am). I have mine on a ups so the only reboots I get are when I update firmware or on DST day. If Time is from Sunrise + 30 minutes to Sunrise +12 hours Then Set 'Lime Tree Lights' On Else Set 'Lime Tree Lights' Off

True, but only of value when the "many different inputs" aren't Insteon devices that could just be set as a scene controller. The only caveat being if the insteon controller isn't always doing the same thing. Like maybe in the morning the Insteon device does one thing, and in the evening it does a different thing. Setting the Insteon device as a direct scene controller will increase response time to nearly instant and cut Insteon traffic by half and reduce the potential points of failure by more than half.

If something like a kpl button always turns on the lights, then you have gone about making something of a rube goldberg machine by having it set a varialbe whtich then runs a program which then turns a scene on. You would be much better off simply putting the kpl button in the scene as a controller. The response would be essentially instant and editing it in the future would be much more obvious. Say 2 years from now you decide to change it . . . you might just spend a half hour trying to remember how you had set this thing up.

Stop just means stop. It just stops. Right where it is. If you stop a program that isn't running, then you stopped something that was already stopped, so it is non-thing. No, the program summary page does not tell you that a program was stopped. It changes from "running then/else" to "idle" and the finish time updates to the current time.

Just to re-iterate, the only thing that is different about a disabled program is that it does not SELF trigger. To cause a program to stop a wait or repeat you can 1) Execute the other clause (run then/ run else) provided the other clause is blank (or does something that you want) 2) CHANGE a program from enabled to disabled (from another program/REST/manually) 3) Execute a "stop"command (from another program/REST/manually) 4) Execute a "run if" provided the if section is going to evaluate to the other clause, and provided the other clause is blank (or does something that you want) Typically, if your interest is strictly to terminate the wait/repeat, you would use the "stop" command.

What you say is not true. A "run if" can be executed manually, from another program, or from a REST command. In other words, it can be run every possible way, except for a self-trigger.

Disabling a program only stops it from SELF triggering. Ending/resetting a wait/repeat happens whenver a program clause is executed for any reason (if, then, or else). Also, I believe the act of changing a program from enabled to disabled terminates a running wait/repeat. It sounds like you want the wait to terminate if the variable changes to not-0, but don't want it to run true if it changes to 0. You need mutliple conditions in the if clause to do this. Or, alternatively, use other programs (which just means you have put the other conditions into other programs). Alternatively, you could use version 5.x firmware which has a "repeat while" option. EDIT: My idea on using repeat while doesn't work. I had never tested this before, so I did. Repeat while does not "self trigger" on a disabled program, much like things in the if clause don't self-trigger. In other words, repeat while is useless in disabled programs, it will keep repeating, I assume, forever unless some outside entity calls the if/then/else.

You asked if you can only check the status of a device, you did not state it. By answering that the status of a scene does not exist (and elaborating on why), I assumed you would make the connection that, yes, you indeed can only check the status of a device.

This is the approach you probably want. It does exactly the same thing as the two separate programs. So if the two separates fit your needs, then this will too.

There is no such thing as a scene status in ISY. Some 3rd party software allows you to define a scene satus based on the status of devices in the scene. But that is quite arbitrary. What does it mean for a scene to be on, 50%, etc? Is a scene with 4 devices where two of them meet scene criteria 50% on? Or maybe all 4 devices are on at 50% of the scene level? Frankly, it just makes no sense to define the status of a scene. I suppose you could say "on" when all devices are exactly as defined in the scene and "off" when all the devices are off, and "other" when something else. Of course you also have to contend with the fact that the scene on level of a device could be to have that device off. So, again, I say, scene status makes no sense.

I'm pretty sure their isn't "something like this" that doesn't draw similar power. The only thing I can think of that is battery powered that is constantly listening are those "tile" devices (and similar). If you could hack one of those to control the relay, then you would be in buseiness. Those things have a battery that lasts over a year, and if you used a battery bigger than the little coin battery it would last several years.

That pulls 80ma in standby. So, lets say you decide to use 4 AA batteries. You'll be changing the batteries about every 6 days. I would be shocked if you can find anything that "listens" on any radio frequency that won't pull too much power ro reasonably run on batteries. Maybe you could use rechargables and put a solar panel on it? I have no idea what your situation details are.

If you can't even run power wires, than no. You can't do that. Nothing insteon that runs on batteries "listens". That would kill the battery. I am not aware of any battery powered wifi device that can "listen" either.

If changing the time made the program work, then I doubt there is anything fundamentally wrong with the program or how it was saved. I had an odd situation where a program that was supposed to run at a specific time (I think it might have been 1am) did not work. I changed it to 2am and it did work. Changing back to the old time and it still didn't work. This program's job was to send me an email with the values of a bunch of variables and then reset the variables. The variables were getting reset, but the email wasn't getting sent. ????? My program was a bit different in that it was a specific time. Sunset of course changes every day, so your program will run at a slightly different time each day. Since sunset -30 seems to not work, but sunset plus 2 hours does, maybe try sunset -20 minutes and see what happens. Just out of curiosity, are there any other programs that are also running at sunset -30?

You keep saying the same thing. PROGRAMMING ON-THERMOSTAT IS COMPLETELY UNNECESSARY IF YOU HAVE AN ISY ISY programs are fully capable of doing everything you might do with the on-thermostat programs plus, for all intents and purposes, infinitely more things. And it is all done from a computer which could theoretically be anywhere in the world. EDIT: And putting a "backup" program on the thermostat in the event that something happens to the ISY doesn't really work. If the ISY goes down, the thermostat will not revert to its own program, it will continue however it was last set by ISY. So unless the last thing ISY did was set the thermostat to use its own on-thermstat program (which ISY can do), it will just keep right on as ISY last set it until something changes that.

From the program summary page, the program ran true at ~4pm. True means the "then" executed. How the lights did not turn on is a mystery to me. One explanation is that you have another program that turned them off in an unanticipated way. I doubt resaving the program is going to do anything. The if section clearly is correct which you can see from the program summary page. The then section is correct since you can manually do a run then and get the correct result. You could debug it by a program such as this. If status of a light in the scene is off Then send me an email Else send me an email This program will send you an email every time your designated swithc in the scene changes status.

What Stu said. To complete the story 1) all red = currently running "else" (repeat or wait for the most part, a simple else clause will just blink red more or less) 2) all green = currently running "then" (same idea as above) 3) half green = not currently running, but last time it ran, it ren then. 4) half red = not currently running, but last time it ran, it ran else. 5) no color = hasn't run either then or else since last save. The "if" clause does not need to have ever triggered. Above applies regardless of how the "then" or "else" was made to run. In other words, a manual run then/else will do it, or if another program runs the then/else. But back to the matter at hand. Look at your program summary page and see what it says happened.

That program is not running. The half green means it last ran true, not that it is currently running true. If it is just a simple "at x time then do such" it will always be that way. There is no false.

That program should work. What does the program summary page say? It should list the next run time (whatever sunset minus 30 is). It should also say the last time it ran and whether it ran true or false. Of course, if you have a done a manual run on the program then it will tell you those times. But come next sunset minus 30, see what it says.

No, you can't do that. However, you can easily log into your ISY from a remote location after the installation and program it from there. It would be possible to add your devices at a work bench, one a time by temporarily hooking them up to power adjacent to your ISY/PLM. Once you add them all, you will have errors on each device, but you can still put them in programs and add them to scenes. I don't think you need the ISY pro, but you might. I think it will still store all the device writes until they come back online (for setting up scenes)

Any "if this" can result in a "then that" where the "that" is a web request. The web request (webhook) takes the standard http format detailed in the ISY wiki for submitting REST commands. You can run a program, set a variable, changes the status of an insteon device, etc.

Based on my reading 1) IFTTT can track nest. Since IFTTT can send REST commands to ISY (assuming you have port forwarded/set up https or are using the portal), then you can set a variable in ISY that tracks the state of your nest. 2) To the best of my knowledge, you can not tell google home to play music from anything but a voice command to it. Maybe I'm wrong. So, you can easily have a program run when the nest variable in ISY is set to some value and the garage door insteon device sends an opening command. That in turn can turn lights and stuff on, but I don't think the google home music is a possibility.

It's all in the thread. Yes, that is what he said.

He isn't saying that nothing happens when he uses Alexa/Portal, he is saying the scene gets messed up. "ok, a follow-up. The switches work fine, UNTIL I use Alexa to turn the scene off. Once I do that, they all get out of sync. I have to go to the main switch (the one that is hooked up to load), pull the tab, wait 5 seconds, then push it back in. Once I do that, they work fine again as a 3-way, until I turn them off using Alexa. Any ideas? Dismania"