fitzpatri8

Last time I tried it, I found that changing numbers caused the program to reevaluate even if the change didn't alter the outcome. If I set the program to trigger if the light level was less than x, and the light level changed from x-2 to x-1 or x-3, the program would evaluate again as true and execute the Then branch.

Do you have 220 volts available at the subpanel? If so, you could use this: http://www.smarthome.com/2477SA1/INSTEO ... and/p.aspx then connect a 120 volt load to just one of the load controller outputs and a neutral to get 120.

The program will evaluate once every time the WeatherBug station is queried (you set the Weatherbug Polling Interval on the Configuration...Climate screen). I normally AND some other limiting condition (program status, current status of a light or relay, or time) and avoid using ELSE actions in order to avoid undue system load. What actions are you planning in response to the temperature condition?

detrotdr, Tim was suggesting you replace the IF statements in your program. You currently have: and Tim is suggesting you change those to read: If Control 'ControlLincA-5' is Switched OFF Or Control 'ControlLincB-5' is Switched OFF Using the Control trigger will run the program each time you press OFF, while using Status will only run the program if the state changes from On to Off.

x10 'security' consoles use a different wireless protocol designed for 'security' sensors. Rather than use standard x10 messages where you can manually set a house and unit code, the sensor randomly picks a unit id which you can then program into a security console. Consoles use regular x10 power line signals only to flash a specific house/unit code when you arm or disarm or flash all lights on the same housecode in the event of an alarm. What that means, in short, is that they can only trigger an ISY program to respond to arming, disarming, and alarm events. The ISY cannot, by itself, arm or disarm the alarm, nor can it indicate open or closed sensors or trouble codes. There are some potential work-arounds but I recommend against them. Those sensors might be fine for scaring off kids breaking into your house while you aren't home, but they are simply not up to modern standards for actual health and safety monitoring.

I've got a couple of programs set to trigger before sunrise, at sunrise minus 20 minutes and sunrise minus 15 minutes, that haven't been firing since moving to 2.8.13. Is anyone else using a negative sunrise offset with 2.8.13 having trouble, or was this just coincidental timing?

What do you see in the Tools...Diagnostics...Event Log if you watch until the interval expires?

You created a 'manual link' between the ControLinc and the light switch. When you press the ControLinc button, it now has a 'private' conversation with the switch without involving the ISY, so the ISY doesn't know to update the light's status. Delete that manual link by holding down said ControLinc OFF button for 10 seconds until the LED starts to blink. Now hold in the switch's set button for 3 seconds until it double beeps and both units' LEDs stop flashing. Now if you press the ControLinc buttons they should no longer control the switch. In the future, to establish a control relationship between two devices, create a scene in the ISY and add all devices using the ISY. That way, the ISY will be able to track the state of devices without having to query them.

The request has not gone unheard, but apparently making it happen is more complicated given the current system architecture than we might otherwise think. See http://forum.universal-devices.com/view ... hp?p=41863 .

You can presently combine dates in different years using AND and OR and (), such that you'd only need to edit them every several years.

After you click on the Schedule button, remove the checkmark from the Daily box to reveal a date selector. Change the Time Is to From to get both a start and an end date.

I had the same trouble with short battery life for a couple of versions of HouseLinc 2 but wasn't using the beta firmware on an ISY at the time. I still have the same RemoteLincs, but once I updated to a newer version of HL2 the problem disappeared.

Didn't that short battery life issue involve a communications or software issue not reactivating the battery-saving timeout? Seems to me the problem only happened with certain versions of software, regardless of the RemoteLinc's firmware or manufacture date.

An accidental factory reset on battery change would erase the link database, and of course select hardware and software capable of remotely manipulating the link database can edit links during the time the RF receiver is active after the RL sends a command. I haven't been able to damage links any other way. More often, a low battery or RF range issue is mistaken for a link database problem. You can see the difference in LED behavior. If you haven't disabled the LED, with no link records each button press will blink the LED just once, whereas a low battery or RF communications problem would flash it a few times.

With nearly all Insteon devices, you can control the reaction to On commands but all other reactions are hard-coded. So far as I've been able to discern as an ISY user, if you want to create a unique reaction to an Off, Bright or Dim command you'll need to employ an ISY program.

Create one thermostat scene for the On button and add the button as controller of the scene. That will establish the relationship between On and the original scene as well as allowing you to adjust the thermostat (using the r2 adapter) in one degree increments using bright & dim. Next, create a second thermostat scene for the Off button, but don't add the button as controller. Instead, create a program: If Control 'RemoteLinc 1 Button A' is switched Off Then Set Scene 'Thermostat Scenes / Therm Heat 66F Scene' On Else - No Actions - (To add one, press 'Action')

Have you checked into the various wireless Internet options? Sprint, ATT, T-Mobile, Verizon and Virgin Mobile all offer Internet over the wireless phone network now. Even if your vacation spot doesn't have cable or DSL access, you may still be able to connect to the web.

Exactly. Plug-in modules including Icon modules, ApplianceLincs and older LampLincs don't transmit a control signal when their set button is pressed or local control (toggling the switch built into the load) turns on power to the load.

Sure. Create a scene that has just the keypad button as a responder and a program that watched for a change in status and turned off that scene. For instance: If Status 'Lamp 1' is 40% And Status 'Lamp 2' is 60% And Status 'Overhead Light' is Off And Status 'Deck Light' is Off Then Wait 2 seconds Set Scene '~ Keypad Status Scenes / Foyer B Status Scene' Off Else - No Actions - (To add one, press 'Action') For this to work, you have to make settings changes via an Insteon switch rather than using local control with a module. Local control changes are not reported back to the ISY, so they wouldn't trigger the program.

Were you accessing the Administrative Console on a different computer (perhaps with a different version of Java or one that you didn't clear the Java cache after updating your ISY version) or a different method (navigating via the web vs. using the desktop icon)?

Based on the Smarthome user-to-user forum post, I made that recommendation. I don't know if he actually made contact with Smarthome or not. The original message was difficult to comprehend. The keypad hardware only applies a 'flash' when manually linked, so since he already swapped the keypad with another and found the symptoms to persist, I was comfortable ruling out a keypad malfunction. The ISY was the only device mentioned that offers anything close to a 'flashing' feature in normal operation--you can set up two programs, intentionally or unintentionally, that will force a device to 'flash' by sending on and off messages in sequence. I've also seen where a ISY restore event can cause odd malfunctions. That, and the fact that he was having other ISY issues led me to point him toward this forum. I hoped that a rewritten post would offer additional clarity, but instead the identical info was pasted here. Taking the ISY out of the loop by powering it down would test the 'competing ISY program' theory. A wiring problem or faulty bulb could cause an irregular flicker but not a regularly-paced flash. What I failed to consider was a non-Insteon transmitter influencing the triac directly. Is there a TED device, or some other technology that communicates over the power line, installed in the house?

There's no need to reply. If you look at the bottom, left of a page when you are logged in, there's a link to Watch this Topic (or Stop Watching this Topic, depending on whether you are already watching). It's below the Page x of y message.

Sure, if you aren't interested in a minimum time, you can use just one Wait Random.

You may be right in the case of sunrise/sunset, I haven't spent the time testing it. I do know my way works.

When an ISY program hits a Wait or Repeat statement, it will normally abort the program without completing if the trigger conditions become false. This housekeeping both gives the user a way to stop a program in its tracks and avoids the ISY running duplicate instances of the same program if the trigger action occurs multiple times. (An example of this might be a bathroom light timer--you wouldn't want the light to turn out if someone is still moving around in the room when a timer expires, nor would you want the light to turn out if someone went in, activated the timer, left the room, then someone else went in and just turned the light on as the first timer was about to expire.) In your case, however, this logic presents a challenge. If you trigger the program with a time, then the program hits a wait statement, the time will be different so the program would abort. By splitting the program in two, there's no wait in the first program and the second program has no conditions that will cause it to abort while waiting.