Goose66

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.

Why even check the status of the fan. Just make Fast On for the fan mean "give me 5 minutes of ventilation from now" regardless of whether the fan is running or not. So the program would be simply If Control 'Shop Fan' is switched Fast On Then Wait 5 minutes Set 'Shop Fan' Off Else - No Statements - Note that if you double-tap On (Fast on) one time, and then double-tap On again a couple of minutes later, the wait timer will reset to 5 minutes.

Here's another take with an eye towards simplicity. No ELSE branches in any of these programs (of course). Program 1: RainNotifyFlag (no code) Program 2: SendNotitifcationOnRain If Module 'Climate' Rain Today > 0.2 " (some reasonable threshold) Then Send Notification to 'e-mail' Run Program RainNotifyFlag (Then Branch) Program 3: ResetRainNotifyFlag If Time is 12:10:00 AM (sufficient time for module to reset values to 0) Then Run Program RainNotifyFlag (Else Branch) In my mind, simple is the most elegant.

Setting the scene ON turns on all devices to their preset ON levels and preset ramp rates. Setting the scene OFF turns off all devices.

Is there a PC in your vacation home? You could add a program to the PC that when the phone rings 6 times (or get distinct ring feature), turn around and connect to the Internet via a modem and register the IP address through dynamic DNS service. So you would call your house, wait a minute or two, and then access the PC and/or ISY over the Internet through a registered DNS name.

A little less clumsy may be to put a "Run Program 'DoSomething' (Else Path)" as the very last statement of your THEN branch. That way, the Status of program 'DoSomething" will only be True if the THEN branch is running.

Short answer: No If you don't want to use the programs as states (i.e. call their ELSE branch to set them as false), then you are out of luck. With a variable, you could just set the variable to an increasing value for each program, with the variable indicating the current state. But the ISY doesn't support variables.

I definitely recommend changing your ports, at least as far as the outside world sees them. I always set ports up in my firewall anywhere from 20,000 to 64,000 randomly and port forward them to internal IP addresses and ports. Sure the open ports could be discovered by a complete port scan of my firewall. But that would take time and mean that someone was targeting me directly. Hard core hackers scanning ports on the Internet may only scan the first 1024 ports, and most simply scan the 20 or so well-known ports, including 443. If they get no response from the well-known ports, they move on (quickly) to the next IP address.

Why not set the local On level to 30% and the ramp rate to 1 sec. Then add the following program: If Control 'Son's Room Lights' is switched On And Sunrise + 30 minutes To 8:30 PM (same day) Then Set 'Son's Room Lights' Fade Up Else -- No Statements -- in the one second that it takes the light to go to 30%, the program should run and start the light fading on up to 100% at the same ramp rate. Should be fairly smooth. Alternativey, in the program you could just Set 'Son's Room Lights' Fast On to take it immediately to 100%.

I think your question revolves around the fact that while WAITing, if the program is triggered again, the WAIT is cancelled and any following actions are not taken, in favor of the entire program running again with a reevaluation of the IF statement. What this thread is about is what will actually cause the program to run (or run again). So for instance, in your example, if the light is turned Off and the fan is running, the program will wait 10 minutes and turn the fan off. However, if someone manually turns the fan off, i.e. the Status of 'Kid's Bathroom Vent' changes, the program will run again, cancelling the pending WAIT and the subsequent Off command. This time, the program's IF condition will evaluate to FALSE, because the Off for the 'Kid's Bathroom Light' was not received, and the ELSE branch will be executed. In your example, this is not a bad thing, since the fan was turned OFF, cancelling the WAIT and subsequent OFF command doesn't affect anything. However, I am sure you can imagine examples where having the program execute when the Status of a device changes would be a bad thing. That is what we are talking about. We want to be able to tell the ISY to run the program when the OFF for the 'Kid's Bathroom Light' is received, and then check the status of the 'Kid's Bathroom Vent' in order to decide whether to run the THEN or ELSE branch, but NOT run the program when the status of the 'Kid's Bathroom Vent' changes. In other words: When Control 'Kid's Bathroom Light' is switched Off If Status 'Kid's Bathroom Vent' is On Then Wait 10 minutes Set 'Kid's Bathroom Vent' Off Else - No Actions - (To add one, press 'Action')