Goose66

It might help to know what you are trying to accomplish. I use my EZFlora like this (there are three of these programs for three different schedules): If On Sat, Mon, Wed Time is 5:30:00AM Then Set 'Irrigation / Front Yard 1' On Wait 30 minutes Set 'Irrigation / Front Yard 2' On Wait 20 minutes Set 'Irrigation / Front Yard 2' Off Else - No Actions - (To add one, press 'Action') I don't know what advantage there would be to having each zone execute in a seperate program. My way, all the zones and run times are right there in the schedule, and not spread out over seperate programs. So, to answer your questions, it would better help to understand the functionality you desire.

Alternatively, put the KPL button in the 'Ceiling Fan Scene' as a controller and the fan in the scene as a responder. Then write a program: IF 'KPL Button' is switched On AND 'KPL Button' is not switched Off THEN WAIT 1 hour Set Scene 'Ceiling Fan Scene' Off ELSE - No Statements- Since the KPL button is a controller, the LED will turn off when the scene is turned off. This also allows you to turn off the fan with the KPL button (thus cancelling the 1 hour wait program) without having to write a seperate program for off.

That would work as well. Either a variable or a dummy device that could be placed in a scene would be nice. I think you are right that adding a state variable in a scene may be a feature even easier to implement than a dummy device.

No need, you just trigger the program with the same controllers assigned to the scene. That defeats the purpose of the exercise, and doesn't account for all the times you invoke the scene from a program. To use a variable (or a status program, which is how I do it currently), you would have to write a program to set the variable for the controllers of the scene, as well as go through your existing programs and set the variable everywhere you set the scene. The point was (I think) to be able to determine the status of the scene without having to maintain something else in parallel to the scene. In other words, allow the scene to reflect its "state."

This has been brought up before, and the solution that seems to make the most sense to me is the idea of a dummy device. You would put the device in the scene, and when the scene was turned on, the dummy device would turn on, and when the scene was turned off, the dummy device would turn off. You could always check the "status" of the scene via the status of the dummy device (although, as discussed, the status of a scene doesn't really mean much). You could also set a program to trigger on a status change of the dummy device. IMO, adding a dummy device, i.e. a device with no Insteon address, to the ISY device lists would be simpler than changing the programming architecture to allow trigger of programs on scene "status" changes. I don't know what ever happened to the idea of dummy devices though -- I think it is a low priority or they said they didn't want them.

I don't know if you are like me, but I always have my iPhone in my pocket. Why not write a program that runs on an always-on PC in your network that periodically checks the DHCP server to see if your phones preferred IP address is active on the Wi-Fi, and, if so, send a REST command to the ISY to changes a status program to true if you are active, and false if you are not.

What about an oldfashioned mechanical alarm clock with wires soldered to the clapper and bell and connected to an I/O linc for configured to detect contact closure

There use to be an X10 alarm clock (not the mini-timer), although I can't find it now, that would send an X10 command in conjunction with the alarm. It also had buttons on it to manually control X10 devices. A search for one of these may give you what you want, although I think you would have to buy the X10 module for the ISY to get it to run a program on an X10 command.

Ah. That explains why no such device is available, I guess. Unfortuantely it brings up some code violations for me. I have numerous places where I have replaced a switch with Inseton dimmers that switches both a ceiling fixture and outlets (at least the top portion) in the room. Got to keep that in mind when I sell the house.

Why would a dimming OutletLinc be a code violation? What's the difference in having a dimmer in a J-Box as a switch vs. having it in a J-box as an outlet?

Once you can read property values into variables and compare them to property values, you will start seeing some cool programs, I imagine. IMO, variables as they are in this first incarnation aren't good for much more than counters. We've been assured that more is coming, however.

The Insteon 220V Load Controller doesn't require a neutral connection and could be installed in the pump house upstream of the pressure switch. This device is dual-band, as well, so it would act as an RF receiver for the TriggerLinc and put the TriggerLinc signals onto both phases of the A/C so that your ISY could detect it. And the TriggerLinc uses a battery and so also doesn't need a neutral connection, and it has terminals to hook up a contact closure to activate it. So, that just leaves how to detect that the pump is running and connect it to the TriggerLinc, for which I don't have a solution. EDIT: Wow! Don't know how I missed LeeG's post. Well, for what it's worth.

If you right-click on the device and choose "Diagnostics->Show Device Links Table," you should see at least one link with the address of your PLM and a 00 group code. Without that entry, my understanding is that the device will not brodcast any information when it is locally controlled.

You don't need the parenthesis in your simple program. In the following program without parenthesis: If Control '.Lights / Bathroom - Master' is switched Off Or Control '.Lights / Bathroom - Powder' is switched Off And From 10:00:00PM To Sunrise (next day) Then Set Scene 'Bathrooms - All' On Else - No Actions - (To add one, press 'Action') the program condition will evaluate to true, i.e. run the then path, if the Powder Room lights are switched off between 10 PM and sunrise, but also will evaluate to true anytime the Master Bath lights are switched off, because of the AND being evaluated first in the condition before the OR. Again, you may want to get independent verification of that fact, but that is my understanding.

Sorry I missed this one earlier. On the lower right-hand side of the GUI, there are buttons to add "And ( )" and Or ( )." Using them is a bit of an art: 1) select the button to add the parenthtical into your top level condition with an And or an Or as needed, 2) add you conditions for the parenthetical in the normal fashion (this will append them to the bottom of the top level condition, and then 3) use the "Move Line Up" button to move the conditions into the parenthetical one-by-one. You may then need to select the lines and adjust the OR or AND for the condition to get it to read the way you want. Note that without the parenthesis, I believe the order of operations is AND and then OR.

I can't set a 0 initial value for a variable. It will take a 1 or 2, but not 0.

Check the links. If the switch has no links in its link table, then local operations will not be broadcast. If there is at least one link, such as that to the PLM, then every local operation should also be broadcast, followed by clean-up events. Someone check my facts on this.

A couple of ways: 1) Just watch the log. If the switch has at least one table entry, it will broadcast the Off. If the PLM has the entry, it will receive the Off and show it in the log. If I am not mistaken, if the links are missing from either the switch or the PLM, then no entries for the switch will show in the log. 2) Right mouse click on the switch in the Admin tool, select "Diagnostics," and then select "Show Device Links" and/or "Show PLM Links" (or something along these lines. This will show the links in the device's link table as well as the links in the PLM link table for the device.

Just to be clear, by "Sending an off command to the powder room," you mean mean tapping the switch off, right? Sending an off from the ISY to the device will change its state, but will not trigger the program condition "IF Control '.Lights / Bathroom - Powder' is switched off." Only local control of the switch will trigger the program. If local control doesn't initiate the program, then you may want to delete and re-add the switch. If the switch doesn't have the PLM in its link table (and, I think, vice-versa) then the ISY will not see the switched off event for the switch.

Ah, yes. Removing the thermostat and adding it back with "Auto Discover" did the trick. I had forgotten that step. Thanks!

Well..., that's a pretty basic program. Have you check the program status page to see if the program is even running when you turn off the powder room light? The program status page shows the date/time of the last program run, and the status indicates the outcome of the IF statement: True (THEN branch executed) or False (ELSE branch executed). Also, the "." in front of the name of the device. I am not familiar with this syntax, but perhaps someone else could speak up with regard to whether that may cause problems in programs in the ISY? Do other programs with "." in front of the device name run correctly?

I just added a Venstar thermostat with an older v2 adaptor to my system (it had been sitting in the box for a year or so). When I added it, it added a single device called 'Thermostat.' My previous Venstar thermostats when added had 4 devices: 'Thermostat - Main,' 'Thermostat-Cool Cont,' 'Thermostat-Heat Cont,' and 'Thermostat-Fan Cont.' Is having just a single device 'Thermostat' the new way that it works after an updated firmware, or should all 4 devices have been created when the thermostat was added?

Can you paste your program into a post? If you right-click on the program in the admin console, you will get a context menu that has "Copy to Clipboard." Then paste it between "[ code ]" and "[ /code ]" tags in your post. This may have something to do with operator precedence in your IF statement. Below is a sample program. No WAIT should be necessary -- since the light switches are only responders, there should be no scene cleanup in the process that you need to wait for before restoring the scene lighting levels. Also, there is an inherent one second wait in executing the program. If ( Control '.Lights / Bathroom - Master' is switched Off Or Control '.Lights / Bathroom - Powder' is switched Off ) And From 10:00:00PM To Sunrise (next day) Then Set Scene 'Bathrooms - All' On Else - No Actions - (To add one, press 'Action') Adding the parenthesis around the ORed control statements may straighten things out. Let us know.

The light switch you are tapping off, is that the direct control of the light (the actual device) or is it a linked switch?

Current State It may be easier if you could set all your levels through programs. For example, instead of being able to set the dim level of your light from the remote control, you could have 4 specific scenes: Off, 45%, 80%, 100%, for example. Each of these scenes could be linked to a KPL button or RL button. In addition, you could have 4 programs 'StatusScene1', 'StatusScene2', 'StatusScene3', and 'StatusScene4' that keep state for the scences. For example: StatusScene1: If Control 'KPL A' is switched On Then Set Scene 'Scene1' to On (if not directly linked to the button) Run Program 'StatusScene2' (Else Branch) Run Program 'StatusScene3' (Else Branch) Run Program 'StatusScene4' (Else Branch) Else -- No Statements -- and so on. So of the four programs: 'StatusScene1', 'StatusScene2', 'StatusScene3', and 'StatusScene4', only one would be true at any particular time reflecting the currently set scene. So to accomplish what you want, you need four more programs: 'RestoreScene1', 'RestoreScene2', 'RestoreScene3', and 'RestoreScene4'. For example: RestoreScene1: If Control 'Motion Sensor' is switched Off (your trigger event) And Program 'StatusScene1' is True Then Set Scene 'Scene1' to On Else -- No Statements -- and so On. So, you have eight programs to support 4 scenes, but its less than what you were looking at. Future State What you need here is variables. And I am not talking about the variables coming in 3.1, but variables into which you can read real-world values, such as the current illumination level of your device, and then use that level variable to restore the light when the motion state is over. It looks like there will be several evolutionary steps in the ISY programming model before we get to that level of variable support (it requires not only variables, but data types and an object model from which to read the real world values), but hopefully we will get there soon.