apostolakisl

?? Seriously, I added the word "the". In the US, baseboard is whatever you pick. Period. And no, I can't say anything to Larry because I have no idea what code may or may not exist in Canada. Feel free to research it if you like. My house has 5/8 thick baseboard. My neighbor has no baseboard at all. So no, in the US baseboard has no defined thickness. End of story.

You said "in the US baseboard is 1/2 inch" Since there is no code for baseboard thickness, then you are just making stuff up.

He is talking about an iolinc, so I assume it is the wire between the iolinc and whatever it is monitoring/controlling.

Baseboard is whatever you pick. There is no code that says 1/2 inch thick. I have been in modern homes with no baseboard at all.

I wouldn't let anyone pull off my baseboards. They would be trashed. You'd need all new ones. If you have anything uniqe it would be very difficult to replace. Assuming your baseboards are caulked and painted to the wall, you'll have buggered up your wall and need to float it and repaint the walls (or I guess you could get taller baseboards). It's already enough of a mess to have the floors refinished, why make it that much worse. Personally, my hardwood floors do not have quarter round. They were finished and then the baseboars were installed new construction. But when the day comes to refinish, I'll have quarter round installed. Quarter round is just one more detail to your baseboards. I guess you find it offensive, but I think most people don't and in fact I bet a lot of people like the extra detail.

If you have ever had the floor refinished, typically you need the quarter round since you can't sand the last mm against the baseboard, especially in the corners.

well the half naked women thing is nice, this is nicer. https://sewelldirect.com/ghost-flat-led-extension-25-ft?stm_type=ppc&stm_source=adwords&product_id=SW-32874-25&campaignid=201733323&adgroupid=15135391923&creative=64184576403&gclid=Cj0KCQiA4bzSBRDOARIsAHJ1UO4LkqGO1eboG7yWAiB2yGVCCdkyTe3X_ysffw5YJ7EgfWUa6jXdpusaAtHOEALw_wcB OK, maybe not nicer.

Unless you only want some of the programs in those folders to stop, then there is no need to nest folders. Just add the condition to each of those folders. For example, create a state variable "s.stop.programs" In each of those folders put If s.stop.programs is 0 Then allow programs to run *Note that if you already have other condtions for the folder, use an "or" to connect this condition. Now create a program (that is not in any of those folders) If (whatever conditions you want to cause the programs to stop) Then set s.stop.programs to 1 set s.stop.programs to 0

Yes, that is true. "for" terminology also allows you to change only the "from" time of a program if your intent is to still have it run the else clause at the same interval of time later. So, it would be slightly easier to edit the program if that is your intent. But, those two things are fairly insignificant in my book.

No, "for" does not keep the programming running and available for a stop. As I mentioned, the program executes twice and is idle between. While I did not actually do what you say, I don't see a "stop" command on a program that ISY lists as "idle" causing anything to happen.

STOP DISABLE Two different commands. Stop ends a repeat/wait without affecting the programs next trigger event Disable blocks an "if" clause from self triggering (and also causes a "Stop") In the context of common English, there could be some confusion, but in the context of ISY, different things.

No, you can't stop it (either one). While I did not actually try it, the program lists as "idle" during the interval with a "next run time" 15 seconds (in this example) after the original run time. A stop command issued to an idle program has no affect. I also did not test a reboot, but per ISY operations, all programs are evaluated at boot, true/false status is set (when possible), programs that fall into the "catchup" time frame trigger, and next run time set (when possible). I don't see any reason why it would not apply here the same. Meaning that a reboot during the interval should still trigger the else clause at the end of the "for" period.

I just tested it. It is two triggers. I did from 12:10:00 for 15 seconds Then set variable 1 Else set variable 2 And it first set the variable to 1, then 15 seconds later it set it to two. The program summary page alos listed the program as having completed at 12:10:00 with a true stats, and had a next run time of 12:10:15 during the interval. After 12:10:15 it showed the status as being false with the next run time of tomorrow at 12:10:00 So it is identical to From 12:10:00 To 12:10:15 Not sure what the point is of having both.

I stand corrected. I assume it is identical to what I did, however, which would explain why I never noticed it. Though you would need to confirm this, I assume it is two triggers independent of any sort of internal "waiting". In other words, when it compiles something like From 1pm for 1 hour It compiles to two triggers, 1pm and 2pm making it independent of a reboot. If not, then I would not use that when I could use From 1 pm To 2pm which is for sure two triggers.

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.