Goose66

Michel, The WAIT is to "de-bounce" the switch. It seems that the statuses of the devices in a scene as reflected in the ISY change from on to off, for example, in a somewhat random order when you scene OFF is received (from the All-Off KPL button). This was causing the program to be performed multiple times and leaving the light in an incosistent state. By placing the WAIT in program, it will be preempted by the subsequent program runs and the last run of the program should evaluate the conditions in their final state. I left the Admin console running last night and the light worked this morning. Also, my slow fade-up of lights (my alarm clock) worked this morning, it did not work Tuesday. I may have comm. issues on my PLM, but would the Admin console running make a difference in the comm. issues?

I have the following program intended to keep the status light for a KPL button assigned as a controller for an All Lights scene in sync when the lights are turned on or off individually: If Status 'Master Suite / Left Sconce' is not Off Or Status 'Master Suite / Right Sconce' is not Off Or Status 'Master Suite / Fan Light' is not Off Then Wait 1 second Set Scene 'Master Suite / Keypad-All Lights (Status)' On Else Wait 1 second Set Scene 'Master Suite / Keypad-All Lights (Status)' Off The "Master Suite / Keypad-All Lights (Status)" scene is a scene with just the KPL button and is used to turn the status light for the button on and off. Inevitably, when I go to bed at night, my wife has turned off all the lights, but that button is still On. I will turn on a light from the bed, then turn the light back off a few seconds later, but the KPL button remains lit. However, if I get up and go sit at my computer (which is not in the Master Bedroom), start the ISY Admin console, clear the log, and then travel back and forth between the computer and the bedroom to perform tests, checking the status of the lights, the KPL button, and the program periodically, and then review the log, it is all perfect. Everytime it works. Every test combination I can conceive of works. It is almost like this only works if the Admin console is running and I am moving back and forth between the rooms. But the next night, when I go to bed, all the lights will be off, but that damn KPL button will be lit. Can anyone see an obvious flaw in the program that I am just missing?

I submitted the problem through your website, under support, through the "Contact Us" link. I submitted the problem both Sunday night and last night (Tuesday). Also, I did not receive any automated responses, as I have in the past. I guess I should have just emailed support@universal-deivces.com. Good to know about the 24/7 phone line, too. Thanks.

Oops. RTFM, right. Indeed that was the problem. I unplugged the PLM for 15 seconds and plugged it back in (as suggested by the manual) and everything appears to be back to normal. I even backed-up my ISY this time! While a locked-up or bad PLM makes perfect sense for no status/comm. errors, what threw me for a loop was the fact that my programs disappeared. This seems like an odd symptom for a PLM communication problem and was, instead, pointing to a SD card or some other problem in the ISY-99 itself. Oh, well. Thanks a lot for the info!

For the past week, I can access my ISY-99 website and admin console, and see my devices, but there is no status of any the devices. Queries for status result in a communication error. Also, all of my programs appear to be gone. Soft and hard resets and power cyclyes of the ISY-99 did not resolve the issue. The PWR and RX lights on the front of the unit are on constantly. I submitted a support issue through the "Contact Support" on your website on Sunday, June 27, but have not heard anything. I am dead in the water, here. I have no lawn irrigation, no wakeup function in the morning, no management of my thermostats and lights while on vacation, no motion sensing lights, nothing. What is the best way to receive individual support from Universal Devices for dead hardware?

I guess what i meant to say is that queying (in the Admin Console) changes the value of the humidity from a reasonable value (37%) to an unreasonable value (150%) in my case. I had always assumed that the thermostat was just responding to the poll with errant data. However, if you are saying that refreshing does not poll the thermostat, then there is a problem in the ISY that misinterprets the current state data to provide the unreasonable humidity value when the query is initiated.

Rand, The Refresh button does change the readings, however. So, while that data may not be coming from the thermostat itself, i.e. refresh doesn't poll the thermostat, refresh does do something to cause the humidity value displayed to change.

Sorry for my previous post, I just couldn't help myself. As far as humidity readings from the T1800, I have the same thing on two different thermostats. The humidity at the thermostat itself seems to read fine, and it controls my humidifier in the winter. As far as reading through the Insteon adapter, it is hit and miss. Most of the time, when I first login to the ISY Admin Console, the humidity shows correctly (say 37%). But if I query the adapter, it will come back 150%, query again, 97%. The query seems not to work at all. If I wait for a status update, it will return to 37%. I have a v2 Insteon Thermostat adapter.

I think your thermostat is just very humble

A program to track the status of the X10 B4 signal would work. You would want to reset the program at midnight, or you could let the Sundowner reset it if it sends an X10 "Off" at sunrise. The other option is to purchase the X10 add-on module. Then you could track the status of the X10 B4 address in the ISY and put a Status condition in your program. In this scenario, you would have an if statement much like above: If ( X10 'B4/On' is Received And From 6:00:00PM To 11:59:00PM (same day) ) Or ( Time is 6:00:00PM And Status X10 'B4' is On )

What about one program with this If statement: If Time is Sunset + 30 minutes And From 7:00:00PM To 11:59:00PM (same day) Or Time is 7:00:00PM And From Sunset + 30 minutes To 11:59:00PM (same day) Then Set 'Dining Room' On Else - No Actions - (To add one, press 'Action') Haven't tested it, but logically it should work, right?

If you refrech your ISY from these devices, what scenes does it show? If you can set it up manually, there should be a way for the ISY to reflect the setup with the devices and scenes. I would imagine there are two scenes with the LampLinc, one with the SwitchLinc as a controller, and the other with the RemoteLinc and ControlLinc.

"Run Program '' (Then Path)" is what you select for the action in your first program.

I see a number of problems here. First, the "Control 'Garage-Sensor' is switched Off" condition is ORed with the Sunset to Sunrise condition. So, the Kitchen light will turn ON at Sunset - 30, regardless of whether the garage is opened or not. Is this intended? Also, anytime the garage opens during Sunset-30 to Sunrise, the light will turn on full because the conditions are ORed. Second the condition "Control 'Kitchen' is not switched Off" is a control condition, not a status condition. This essentially means that no OFF command was received from the Kitchen switch concurrent with whatever other condition kicked off the program. What you want here is (I think) "Status 'Kitchen' is Off," in other words not On or dimmed. If your intention is to turn the kitchen light ON whenever the garage door is opened between Sunset-30 to Sunrise as long as the Kitchen light is not already On or dimmed, then your program should look like: IF Control 'Garage-Sensor' is switched Off And From Sunset - 30 minutes To Sunrise (next day) And Status 'Kitchen' is Off Then Set 'Kitchen' On Else - No Actions

By the way, here is what the other poster meant by "latching" a second program. In your first program, instead of the THEN branch containing: Set 'LR Table Lamp' On Wait 20 minutes Set 'LR Table Lamp' Off change it to: Run Program 'LampOn20Minutes' (Then Path) The program LampOn20Minutes would contain no ?IF conditions and the following in Then branch : Set 'LR Table Lamp' On Wait 20 minutes Set 'LR Table Lamp' Off The LampOn20Minutes program would be executed by the first program when the conditions were met and run independently of the first program. Therefore, it would not be preempted by subsequent runs of the first program when the conditions change. When I do this, I often put a "Set 'LR Table Lamp' Off" or the like in the Else branch of the second pgoram as well, just to have a cleanup branch of the program to call, if needed.

A running program in a WAIT will be prempted (i.e. old instance stopped in favor of the new instance) if the trigger conditions for the program occur again, thus causing the program to execute again. You are using status conditions for both the garage door sensor and the lamp. Status conditions will trigger the program any time the status changes. So, assuming between sunset and sunrise, the lamp is OFF, and the garage door is opened (garage-house-sensor is turned ON), your program will run the THEN branch. The first thing that your program does is turn the lamp ON then enter a WAIT. But, hold-on a second, the status of the lamp has now changed to ON, which will kick-off a new instance of the program, causing the old instance of the program in the WAIT to end. The new instance of the program will run the ELSE branch (the lamp is ON) and thus nothing will happen. Your program never makes it to the Set Lamp OFF command. Also, the same thing would happen if somebody closed the garage door in the 20 minute interval, because the status of the gargage-house-sensor would change to off, thus re-running the program and killing the WAIT, thus never turning off the lamp. There are all kinds of convoluted solutions to this issue that you will find all over these forums. My recommendation is to remove the Lamp is OFF status condition, and change the garage-house-sensor condition to a control condition, i.e. "If Control 'Garage-House-Sensor' is turned On." This way, if the garage door is opened between sunset and sunrise, the lamp will turn on and then turn off in 20 minutes, even if the garage door is subsequently closed or the lamp is turned off in the mean time. You are still left with the boundary condition of Sunrise. If Sunrise occurs during the 20 minute interval, i.e. while the program is in the WAIT, the program will again be pre-empted by a new instance, and the lamp will not be turned off. Note that I have long advocated seperating trigger conditions for a program from the conditions in an IF statement. This comes up again and again in programming questions. I wish others would take up the cause and we could get this changed.

Good to hear. However, there is still the fact that running the THEN path of the Disarmed program will not cause programs located in a folder with an "If Program 'Disarmed' is True" condition to run, unless the programs also have the status of the Disarmed, Armed Away, or Armed Stay programs in their own If conditions. I think it is important to point that out for future readers of this thread.

Mitch, I setup a test scenario to test this functionality, and I can confirm Darrell's comments. I established a status program Test Status with no code, a folder Test Folder with the following IF statement: If Program 'Test Status' is True Then Allow the programs in this folder to run. and a program Test Program inside of the folder with the following: If From Sunset To Sunrise (next day) Then Set 'Outdoor / Front Lanterns' 65% Else Set 'Outdoor / Front Lanterns' Off I then set the status of Test Status via the REST interface with the following: http://isy//rest/programs/0011/runThen (or runElse) I can confirm that setting the Test Status program True or False via the REST interface does enable the folder Test Folder and schedules or unschedules a Next Run Time for the program Test Program in the Test Folder. However, the Test Program is not executed. Perhaps if you post your actual code, we can find the reason why your program is executing upon change in status of the parent folder.

I don't think I understand the problem. You say "every time a Run Program is sent, the ISY re-evaluates the Folder that is True and resets all the devices to their programmed settings." What is "the Folder that is True," and are you suggesting that the ISY sets the status of the devices in this folder to some defaults without a specific command or function request to do so, i.e. "every time a Run Program is sent?" If so, sounds like a bug in the REST interface. I would suggest logging a support bug.

So you are saying that the ISY is single threaded and you want a WAIT 0 to allow the ISY to run other programs at the same time your program is running? My understanding is that all the WAIT will give you is the ability for the ISY to preempt your currently running program in favor of a new instance of the same program becuase the trigger conditions have occurred again.

Only that IMO Insteon traffic is better than X!0 traffic, in both reliability and bandwidth usage. I rely on Insteon for home automation traffic. I wouldn't want such traffic on my ethernet network, for example. But as we can see from the start of this thread, I prefer to follow the KISS principle in each aspect of my implementation. If you have an Elk or other security system, perhaps you could use that to monitor your motion sensors out-of-band from the Insteon network and communicate with the ISY over the REST interface (does not require the network module).

The EZx10RF does not put any X10 traffic on your powerlines. It receives X10 RF from the motion sensors and sends Insteon commands over the powerline.

I went through my 8 KeypadLincs and gave all the buttons fancy names for their eventual functions (in my dream world). Now I am implementing some of those functions, but I can't figure out which buttons (B, C, D, E, F, G, H) map to the fancy names I provided. The ISY Admin Console lists them in alphabetical order and shows the Insteon address for each, but not the group number corresponding to the button. Anyway to find this in the Admin Console?

All I can say is: Damn! I can't even tell what you are trying to accomplish, but if it takes all that, then there is definitely something wrong with the ISY programming model!

Sorry, I forgot that no post is good unless there is a solution: I would suggest two programs, one with the condition: (Control 'Mbed ceiling floods' is switched off or X10 'B5/off (11) is recieved) And (Status 'Fam Rm Tbl Lamp' is on or Status 'Curts office" is on) and one with the condition: (Control 'Mbed ceiling floods' is switched off or X10 'B5/off (11) is recieved) And Status 'Fam Rm Tbl Lamp' is not on And Status 'Curts office" is not on) Put the THEN branch of your original program in the THEN branch of the first program, and the ELSE branch of your original program in the THEN branch of the second program. Note that I have advocated for the seperation of trigger conditions from IF conditions in the ISY. The way that it is now is very different from other automation controllers and software. Maybe if enough people are confused, some changes can be made.