apostolakisl

"Nesting" is done more or less like this If something Then Run program 2 (if) perhaps other stuff Else something Program 2 (disabled) If whatever Then whatever Else whatever

I wrote a second set of programs that uses simpler logic. See the link below. http://forum.universal-devices.com/topic/13750-i-wrote-a-new-date-variable-program/ For you, you would have an if clause that was something like If $i.month > 10 or $i.month < 4 Then do whatever.

Putting an always false statement like if 0 is 1 would push your run at startup to the else clause every time. It is 6 or half dozen, going with always true and filling out the "then" or always false and filling out the "else". But I would stick with going the true route, it just keeps the mind from spinning in circles. The basic jist is that "run at startup" is going to cause the "if" to evaluate. Really the only non-intuitive thing is that a blank "if" is evaluated as true.

1) "Run at Startup" is the same thing as saying "evaluate the if clause at boot" 2) A blank 'if" clause evaluates to true. This is true at startup or any time the "if" is asked to evaluate, regardless of what is asking it to evaluate (bootup, another program) So if you want a "then" clause to execute at boot, then leave the "if" blank or put an always true statement (like if 0 is 0) and set it to run at startup. Adding the always true "if 0 is 0" may or may not serve any purpose. At the very least it reminds you that it is true.

This is all correct. I did quite a few tests on this when writing my date programs. If you want to be certain that programs execute the "then" or "else" clauses in order, then you need the last line of the clause to call the next program. Even if you do this: If whatever Then Run program a Run program b Run program c It could happen that some of program c would execute prior to parts of program a. You just can't predict it.

I have about 70 or so insteon devices. My initial Insteon switches were all defective . . . 100%. They replaced them under warranty for the "tact switch" problem. This problem has been solved for a long time now. I have had zero Insteon switch/KPL failures since then. This is something like 5 years of use now. My PLM failed for the same reason as everyone else's (cheapo capacitors). Not covered under warranty. I replaced the capacitors myself. Supposedly this is fixed in the latest version. I had several lamp lincs fail for electrical component failure. They were covered under warranty. I am not aware of any of the current products having inherent problems. I did have a nasty power fluctuation issue a couple months ago and a separate lightening strike nearby that damaged a few things in my house . . . but none of my Insteon stuff suffered. I lost a fan on my AC unit and some relays on my Elk security panel.

Yes, I actually have that very program. I wrote it before variables existed. That program will be a trigger when it changes conditions, so in that respect, you might still prefer an integer variable for certain applications. But as far as the OP's needs are concerned, it is a no-brainer to just use the simple program.

Well, I am not sure I invented this approach. I did have to run some experiments to find out what happens when the "from" time is after the "to" time, but I was probably discovering something that was already known. To be fair, using variables for "daylight hours" has advantages as well. Mostly, it opens up when you want to have more complex conditions that don't trigger on the "from" and "to" times and also it allows you to use the else clause.

You almost had it. If On Mon, Tue, Wed, Thu, Fri From 6:00:00AM To Sunrise (same day) Then Set Scene 'Wakeup Light' On Else This program only runs true at 6am if the sun hasn't risen. If sunrise happened before 6am, it runs false at 6am. It also runs false at sunrise. So if you want to also use the else clause, keep those things in mind. In a "from to" program, if the "to" is before the "from", it will be false. Both the "from" time and "to" times will trigger the program no matter what, just at some times of the year both triggers will run false and at other times the "from" will be true.

If you are only getting an option to change the backlight level, then you are not tuning a scene on/off.

To turn KPL buttons on and off you need to create a scene and put the button in the scene. Then turn the scene off.

This should be good. I have played around with tasker and isy a bit, but pretty much have just achieved proof of concept. The wiki should help get things rolling.

I wouldn't be so concerned about controlling your garage door over the internet. Using the https connection is going to be more secure than your garage door actually is. A garage door can be opened with a crow bar in like 2 seconds, so anyone who wants in, is going to get in the easy way, not spend days trying to crack your security key.

That is a reasonable statement. And even if SH were to falter, they have a pretty big market established that is too valuable to just get ignored. Someone would buy the patents and keep it going. The only possible exception to that is if some other technology showed up that was just a huge game changer. The fact is that 99.999% of the world is already wired the way it is wired so that really only leaves performance and price as game changing categories. And at current Insteon price/performance levels, there is only so much room for improvement, probably not "game changing" room.

I don't see where this particular program would flood the lines. It is just a single command every 2 seconds. I have several programs that operate exactly the same except I only have a 1 second wait on the loop and I don't have any issues with them running. The only thing close to calling a problem is that the beep is not perfectly at 1 second intervals, presumably the reason is varying number of hops from one PLC to the next.

Unless something has changed since 4.2.8, there is no "repeat end" and using "repeat 1" is the proper way to end a repeat. Though "repeat end" would be more logical and a "repeat 0" would not even be an option.

I suspect it would be quite complex to try and update the firmware via the PLC or wireless mode. As mentioned, a direct plug into the header would easily do it, but that is not really easy since you need special equipment. A usb could be installed on the switches, but that would add cost and (unless you want your swtiches to have a usb jack showing) require that you at least take the faceplate off and wander about your house with a laptop in hand updating one at a time. But, personally, I would be sort of OK with that.

AC motors RPM is based on the AC hz, not voltage. A dimmer will effectively drop the voltage but makes no change to the hz. So the motor keeps spinning at the same speed until the voltage is insufficient to push through the load at which point it will spin unpredictably or stop and possibly over heat and catch fire or burn up the windings. The multi speed AC motors I know of work by having more than one takeoff of the power wires into the windings resulting in different magnetic configurations that change the speed. I am not really sure how fanlincs work, maybe someone else knows. But they seem to somehow tap into the same built-in speeds of the fan without physically changing which wires are connected to what inside the motor. Just recently some of the new ceiling fans have DC rectifiers and DC motors in them and are thus infinitely variable. They are also more efficient. But they cost more. My HVAC unit runs on fans like that. One of them burned out at 5.25 years (warranty 5 years) and the new fan motor was $800 (just the motor) (compared to about $125 for a similar AC one). I bitched and they covered it under warranty. . . but you get the idea. So I have to commend Carrier on covering it, but not on having it fail after 5.25 years.

He said humidifier, not de-humidifier. There are lots of different kinds of humidifiers. Most of the ones I am familiar with don't use much electricity, so load won't be an issue. Without knowing exactly what humidifier you are dealing with it is hard to say. But, in general, no, you can't use a dimmer on an AC motor, which is almost certainly what is running the fan on your humidifier. You could look into the compatibility of the fanlinc, but I am doubtful.

In the few and far between cases that I wanted an "If" clause to always be true, I have done something like that (see my first post). It would appear that leaving it blank is functionally equivalent. I doubt UD would change the fact that blank evals to true when triggered. My speculation is that the "logic" is more of how ISY works rather than logic of the program as written. In other words, my bet is that once a program is triggered, it must result in a true or false outcome because of how the code was designed.

I'll look into this. I maybe wrong. Perhaps a blank "if" defaults to running "then" if you force a run. I just assumed that a blank "if" does nothing since it is neither true nor false. The logic of a blank "if" being true escapes me. EDIT: Indeed a blank if is somehow "true" Don't ask me how that logic works. No less, there still doesn't need to be 2 programs. The repeat every 30 minutes would take care of it If blank Then Repeat every 30 minutes $Climate_Outside_Temperature = $Thermostat_Great_Outdoor_Temp $Climate_Outside_Temperature Init To $Thermostat_Great_Outdoor_Temp Else - No Actions - (To add one, press 'Action')

Nope. Running at startup means it will trigger the "if". So a blank if does nothing. Just do a "repeat every 30 minutes" and include an "if" clause that is for sure true and set it to run at startup. If variable x is >= 1 or variable x is < 1 Then repeat every 30 minutes your stuff.

"not switched off" behaves the same as "switched off", except it is false. For example if control device x is not swithed off Then do x Else do y Is the same exact thing as If control device x is switched off Then do y Else do x Yes, you are correct that if you blink the lights, then the "status" line would screw it up. Using "beep" does not. In my case, that switch does not change status except from that switch or from ISY programs. I included the fade up and fast on commands so that any action on that switch would start the timer over. "status" would fail to reset the switch if someone did a "fast on" or "fade up" when the light was already at 100%. On the way down, the "status" line catches everything. You could easily get rid of the status line and add "fade down". You will also need to add a "not switched off" and "not switched fast off" to drive the else clause, otherwise the timer will still run if someone turns them off. The one problem would be if someone fades to off. The timer would still run and they would blink at the end of that timer. The only way to fix that would be to have 2 programs.

Here is an example of a program I wrote that is quite similar. If Control 'Alexis Room / Alexis BR-Overhead L' is switched On Or Control 'Alexis Room / Alexis BR-Overhead L' is switched Fast On Or Control 'Alexis Room / Alexis BR-Overhead L' is switched Fade Up Or Status 'Alexis Room / Alexis BR-Overhead L' is not Off Then Wait 29 minutes Repeat 60 times Wait 1 second Set 'Alexis Room / Alexis BR-Overhead L' 14 (Beep Duration) Repeat 1 times Set 'Alexis Room / Alexis BR-Overhead L' Off Else - No Actions - (To add one, press 'Action') The program allows the light to stay on 30 minutes since the last time the light switch was touched leaving the light in a "not off" situation. During the last minute, it beeps to warn you that it is going to shut off. If you want to reset the timer, any action on the switch will reset the timer from any condition, to any condition (except off). Personally, I agree that the repeat 1 time or 0 times is confusing. Repeat 0 times should just not be an option, and repeat 1 times should be replaced with "end repeat". It would then be quite obvious what is going on.

No, a scene is one command. When a device is programmed to be part of a scene, that device (along with potentially many others) then responds to that one command. For example, if a switch is set as a controller of a scene with 3 devices, when you turn the switch on, 2 things happen. 1) The switch turns itself on based on its "applied locally" settings (which may or may not be the same as it responds to a scene, this you define when programming the scenes and local settings of that switch) 2) it broadcasts a "scene <scene address> on" command. The other 2 devices "hear" that one command and do whatever you programmed them to do. Turning a scene on does not send multiple independent commands specific to each device.