kclenden

At their very basic, Insteon scenes are a relationship between one controller and one or more responders. For each device activated by that controller, you define the desired ON value and Ramp Rate. This allows you to send out one command, scene ON or scene OFF, and have many devices be activated at the same time. With the ISY, a scene can have many controllers, but at the low level it's still a bunch of one controller to multiple responder scenes. So in your programs, you need to specify the scene, controller and device to adjust ON and Ramp Rate. You might think, but I have only one controller in my scene - the Motion Sensor - so why should I have to specify the controller? That's because you really have two controllers in your scene - the motion sensor and the ISY. To set what happens when the scene is activated by the ISY the scene name and controller name will always be the same. I don't remember whether the ISY tried to write scene updates to the MS's in V4, but you're not the first one to have this recollection, so you're probably right. It is normal in V5 though. If your MS's are battery operated, you really should update your scene change program to only run when the MS is awake. This will prevent a host of possible undesirable consequences later, but is problematic as your MS's probably won't be awke at the time you want to change your scene, and really the only way to know your MS is awake is to wait until it sends out an ON or OFF command.

In which case, I start to wonder if it is even worth automating. I might argue that it's the rare case that is most worth automating because you are most likely to not check for it manually. Both of my switches are only acted upon by my "All Off" keypad button that we hit on the way out the door. So programs will only change the state of these switches if they are in the ON state when the "All Off" button is pushed. That doesn't happen very often because my wife and I are very good at turning the lights OFF when we leave those rooms. It generally only happens when we have guests over and they venture into one of these rooms and exit without turning the light OFF.

Yep. That scenario would require me to flip the switch UP and then DOWN again to actually turn the light OFF. Both modes will result in the switch being out of sync if a program or scene acts on the device. In the 3-way mode my switch will be out of sync until a program or scene again acts upon the device, nothing I do at the switch will get it back in synch, but with the 3-way mode disabled the switch is back in sync as soon as I use the physical switch again. In the case of both switches, they are acted upon by a program or scene probably less than 2% of the time, so the way I have them set up means they'll be in sync the vast majority of the time whereas having them in 3-way mode would result in them being in sync for long periods of time followed by them being out of sync for long periods of time.

That's how my switches are programmed. They come programmed for latching mode by default. They also come programmed for 3-way toggle mode by default whereby they act like they're in a multi-switch setup. I turn the 3-way toggle mode off so that the switch being UP means ON and the switch being down means OFF.

Doesn't really seem like a feature request to me. Seems way too simple to be considered a feature. Not really a bug either since the FASTOFF being sent seems to be undocumented.

Smarthome sells the Micro On/Off Module (2443-222) which you could put in the ceiling box and then use the wires running to the wall switch as "sense wires". This allows the Micro On/Off Module to sense the position of the wall switch and act accordingly. I use this for a couple of switches in my house - once because of the exact situation you describe, and once because there was a set of existing switches that I wanted to match. The only real downside to the Micro On/Off Module is that there is a perceptible delay between the switch changing state and the device responding. I haven't actually timed it, but my guess is that it's about a half second. This manifests itself mostly when new people in the house try to turn on the guest bathroom light switch. They flip it on, notice nothing happens, and switch it off before the light has come on. Then they move to the next switch which turns on the fan, so they turn it off. Finally they move to the third switch which turns on the shower light and they use that for illumination. Once they know that the first switch does indeed turn on the bathroom light, they're good going forward.

I just checked one of my devices that has a heartbeat and indeed the only CONTROL options I can choose are ON and OFF. Looks like you'll have to request that UDI add FASTON and FASTOFF as control options for heartbeat nodes. Have you confirmed that your device is sending a FASTOFF by leaving the Event Viewer open on Level 3? @Michel Kohanim - What's the proper avenue for @Derek Atkins to request additional CONTROL options for a device?

If they're sending a FastOff, can't you just change your heartbeat program to not only look for On and Off but also FastOn and FastOff?

Is $PRECIP_TODAY defined as an integer or state variable? If it's defined as a state variable then every time you change the value of $PRECIP_TODAY, as you do in the THEN and ELSE, the IF of the program will be reevaluated. So what likely happened is: You executed the ELSE. This caused the value of 'OpenWeatherMap / OpenWeatherMap' Rain to be added to $PRECIP_TODAY Since the ELSE changed the value of $PRECIP_TODAY, the IF was reevaluated which caused the ELSE to run again (back to step 1) When you rebooted the ISY, the value of $PRECIP_TODAY would return to 0 and thus 'OpenWeatherMap / OpenWeatherMap' Rain would likely be greater than $PRECIP_TODAY and thus the THEN would execute. When the THEN executes, it changes the value of $PRECIP_TODAY so the IF would be reevaluated and then the ELSE would run and you're back in the two step infinite loop above. Edit to add: The difference between your THEN and ELSE is that the THEN always assigns the value of 'OpenWeatherMap / OpenWeatherMap' Rain to $PRECIP_TODAY while the ELSE increments the value of $PRECIP_TODAY by the value of 'OpenWeatherMap / OpenWeatherMap' Rain. As far as the ISY is concerned, if you execute a statement that assigns a value to a variable that is the same as the value already held by the variable, then the variable has not changed. So the first time the THEN assigns 'OpenWeatherMap / OpenWeatherMap' Rain to $PRECIP_TODAY it causes the IF to reevaluted, but a second assignment of 'OpenWeatherMap / OpenWeatherMap' Rain would not change the value of $PRECIP_TODAY and the IF would not be reevaluated. So there's no chance the THEN will cause an infinite loop (unless 'OpenWeatherMap / OpenWeatherMap' Rain is constantly changing). But the ELSE is always adding to the value of $PRECIP_TODAY so it always causes the IF to be reevaluated and thus causes the infinite loop.

If you're not concerned about receiving individual alerts, then you could combine them together and have the alert display the status of each sensor. That would allow you to have a single program as well as a single alert form.

Are you sure you got the alert as a result of the "sunrise" program? I ask because your "sunrise" program runs the IF (as opposed to the THEN) of your "Coop Door Open" program. Are there actually conditions in the IF of the "Coop Door Open" program and could they be the reason you get an alert on reboot?

When you setup a scene you must do several things: Define what happens when the scene is activated by the ISY (that's what your image above shows) Define what happens when the scene is activated by each of the controllers (e.g. when a switch is turned on) So in your case you should have defined what each device does when it's activated by five different controllers (the ISY, Dimmer1, Dimmer2, Dimmer3, Dimmer4). Have you done each of those steps? Edit: One other thing, if you turn a device ON, that is a controller in a scene, by using the Admin Console, that does not activate the scene in which the device is a controller. The only way to activate a scene is by either turning the scene on using the Admin Console (or program) or by physically turning on the device.

Clever. Still, it really shouldn't be necessary in this case.

So the "Last Run TIme" showed "Sunset + 10 minutes" and the "Status" showed "True"? If that's the case then I would make sure I had the Event Viewer open and set to 3 shortly before Sunset + 10 minutes. That will let you see what device communication happens at the time the program fires. Or you could change the "From" and "To" times to do some quicker testing.

Switched off refers specifically to receiving an "Off" command from a device so it won't matter whether the garage door is already open. I doubt it's a bug, but just in case I created a test program to see what happens on my system: New Program - [ID 00A2][Parent 0001] If From Sunset + 4 hours and 43 minutes To Sunrise - 10 minutes (next day) And ( 'ST-Overhead Light' is switched Off Or 'DR-Chandelier' is switched Off ) Then $sTest = 0 $sTest = 1 Else $sTest = 0 $sTest = 2 It worked exactly as expected - at 10:15PM the ELSE was executed even though one of my devices was already OFF. So my guess is another program is the culprit.

I don't think there is a way to make the time range not a trigger when used in a program. Creating a folder that uses the time range as a condition would in theory do what you want, as the state of a folder going from FALSE to TRUE does not trigger the programs within (i.e. the programs are now allowed to run, but won't until one of their own triggers fire). Why do you care if the program triggers every day at 10 minutes after sunset? Since you're using "switched Off" and not "Status is Off", it will just run the ELSE which is blank.

It's not different. "Between" is just another way to refer to the "From/To" programming construct which allows you to accomplish you're initial goal - turning two programs into one.

He also indicated that he uses them to trigger video/image capture so that's probably why he has them trigger during the day. Our cat causes my MSII to trigger the hallway light in the middle of the night while we're in bed. I think I'll try the masking method Larry posted above to see if I can cure that problem.

Most people new to the ISY don't think of using the "Between" condition. I think this is because they want something to happen at sunset and something else to happen at 11pm, but they don't want anything to happen in between those times. The reason "Between" works in this case is because the ISY has two types of conditions. The first are "trigger" conditions and the second are "evaluation" conditions. "Between" is both of those kinds of conditions. A program will only ever run if it is triggered to run. In the case of "Between" there are two triggers: sunset and 11pm. So at sunset the THEN will run (unless there are more conditions in the IF) and at 11pm the ELSE will run. At any time between those two, the program will not be triggered - so in this case if the program turns the light on at sunset and you turn it off at 8pm, the program will NOT be triggered to run and turn the light on again. Once a program is triggered by a trigger condition, evaluation conditions will impact whether the THEN or ELSE is executed. Integer variables are evaluation conditions. Their value can impact whether the THEN or ELSE is executed, but a change in their value will not trigger the program in the first place. "Between" is also an evaluation condition. If some other trigger causes a program to run, a "Between" will impact whether the THEN or ELSE is executed.

Good point. Though in my case, if it's an outside door, I almost always immediately close the door after opening it so ON and OFF would basically be the same. ?

I think I'm misunderstanding the problem. It appears that you're trying to add "Garage KL-A Yard Lite" to a second scene as a controller and the pop-up is telling you that "Garage KL-A Yard Lite" is already a controller in the "Back Yard Lite" scene and since a device can't be a controller in more than one scene, the pop-up is asking you whether you want to add "Garage KL-A Yard Lite" as a responder to the second scene. If you click "Yes", the ISY should go ahead and add "Garage KL-A Yard Lite" to the second scene as a responder. Is it not doing that?

I don't think he'll have a problem. His test is "And Control 'Front-Door / Front Door-Opened' is switched On". While "Status is ON" and "Status is OFF" are opposites "switched ON" and "switched OFF" are not. So the WAIT won't be interrupted when the door is closed and a "switched OFF" is generated. It's this nature of "switched ON/OFF" events that causes people to test for "switched ON AND NOT switched OFF" when they want the THEN to execute upon a "switched ON" event and the ELSE to execute upon a "switched OFF" event. So net, no need to switch to two program instead of one.

The issue with your AM Program is that you change one of the IF criteria (bolded above) within the THEN. You then execute a WAIT which allows the IF to be reevaluated, and upon reevaluation it transfers control to the ELSE. You really don't need to check whether the 'Front Lights and Porch / Front Lights' are OFF before turning them ON. Remove that test from both your AM and Evening programs and remove the two statements in the ELSE of the AM program and you'll be good to go.

Using State variables can be very useful for debugging purposes. Whenever a State variable changes values it is recorded in the Event Viewer log. Thus by watching the Event Viewer you can follow all changes to the variable. But, as you mentioned, you need to make sure the State variable isn't being used to trigger other programs that might mess up your calculations. And, after debugging, I'd definitely recommend converting the State variable to an Integer variable if you're not going to be using it to trigger programs. Besides avoiding unexpected program interplay, I'd think fewer State variables would place less stress on the ISY's computing resources.

That doesn't sound strange to me. All I see in my "Event Viewer" is raw numbers. You can divide by 255 if you want to know the %. Now in the "Log" I do see % and not raw numbers.