matapan

Does anyone know if the new Insteon thermostat adapter update clears up any issues with using the Venstar Thermostat with an ISY controller? Specifically, does ISY's admin console always display the most up to date thermostat settings when it is brought up? Is there still a requirement to change the thermostat mode out of Program to manual setting to adjust a setpoint beyond the preset one for the time of day? These were some of what I consider to be the glaring deficiencies of the adapter in v.1.0.

I haven't played around with my Insteon motion sensor much, as it has been problematic to work with. That said, I thought about some of the scenarios you presented: Would it be possible to have a program that is activated when the light is turned off manually, whereby the motion sensor state is turned off or reset after a few seconds (enough for the user to leave the room and not set it off)? If the user leaves the room leaving the light on, the motion sensor will take care of it after the inactivity period is reached. As I said, I didn't do a whole lot with my motion sensor yet. Just brainstorming here...

The GE CFL's I installed are a lot warmer in color than the older dimmer generation of CFL's they replaced. There is still a color difference, especially after the bulbs have been on for a while, but the difference is smaller than it used to be.

Thanks Chris. I used your suggestion about employing the 'Last Run' condition to specify a countdown period for some secondary event to occur: If X10 'A1/On (3)' is Received and From Last Run Time for 'test' For 15 seconds Then Set 'Light A' On Else - No Actions - (To add one, press 'Action') This program gets called by the primary program, which detects the initial state change. The second state change has to be detected within a certain time period after the initial state change to be valid. In the example, looking for a X10 command within 15 seconds to turn Light A on. Thanks for the tip!

Actually, the problem I encountered was all due to some old program triggering the IOLinc as well when the sensor state changed. Removing the old program addressed the issue. The programs described work correctly now. It might be a handy to have a search feature to look for device references in a group of programs, just to make sure one doesn't have some old references lying about!

Recently, Smarthome started advertising Switchlinc kits that work with CFL's. I was surprised by this, because the CFL's I've installed were all noisy and caused all sorts of problems on my Insteon network. I emailed them to comment on their kit. I thought it was somewhat deceptive to create a kit that purportedly worked with CFL's, and aired my sentiments. The reply I received stated that the company found that GE brand CFL's work well with Insteon. Keeping an open mind, I tried replacing a set of noisy CFL's with the GE bulbs. I could "see" all the noise showing up on the nearest Lamplinc indicator. To my surprise, they actually were free of the noise that the old CFL's produced. I will see if this hold true over time, if the circuitry in the CFL bulbs remain "quiet" as they age. But for now, is is definitely an improvement over the old TCP and Phillips brand CFL's they replaced!

I am proposing the following: - The program will only run if all conditions are satisified. - There are multiple conditions. - The initial condition can be set up as part of the folder condition - The other conditions are satisifed relative to when the folder condition was satisified. Examples: - Directional sensing and keypad activation: + Two sensors placed in different areas of a space detect presence. + The sequence in which each sensor is activated provides directional information. + The third input is a keypad button activation. + The directional information provides context for the button activation. (examples: which lights to activate, for how long, etc.) - Optional supplemental input to garage door opening and closure. + Garage door is opened using opener. Pressing an X10 or Insteon keypad button within 3 minutes of the action will trigger a macro One can currently specify a specific time or time range for a folder to be active. There is no way to specify time relative to an action or program condition change. Or is there one I've overlooked?

I would like to set up certain actions to occur on a specific input sequences. These input sequences are in a certain order, but not necessarily triggered within tight time sequences. Example: Opening garage door, pressing an RF command, evaluating time of day. Is there a way programmatically to open a time window to wait for input, and to run the Then or Else branches based on input, or lack thereof?

I have a very simple garage door program that isn't working the way I envisioned it would work. It is opening and closing the door after the initial Keypadlinc button press. I think it has something to do with the way the Keypadlinc button status is set up. Configuration: I'm using an IOLinc to control the garage door. When the sensor is ON, then door is closed. I have one scene containing two Keypadlinc buttons that I use to check if the door is open or closed. If the button is ON, the door is open. The IOLinc relay is set up for momentary contact. Finally, I have three programs that deal with the garage door: Garage Door Open Garage Door Close Garage Door Status Garage Door Close: If Status 'Garage Sensor' is Off And { Control 'Keypadlinc 1 Button D' is switched Off Or Control 'Keypadlinc 2 Button D' is switched Off } Then Set 'Garage Relay' On Else -- No actions -- Garage Door Open: If Status 'Garage Sensor' is On And { Control 'Keypadlinc 1 Button D' is switched On Or Control 'Keypadlinc 2 Button D' is switched On } Then Set 'Garage Relay' On Else -- No actions -- Garage Door Status: If Status 'Garage Sensor' is On Then Wait 1 second Set Scene 'Garage KPL' Off Else Wait 1 second Set Scene 'Garage KPL' On The door opens and closes properly when the open and close programs are enabled, but when the status program is also enabled, the door partially opens and closes on its own. I don't understand what this is happening, since I am assuming a 'Switched' action is different from a 'Set' action. Setting the Keypadlinc button state seems to trigger the open and close programs as well. How can I prevent the status change from triggering the other programs? Thanks!

What are some of the best programming practices to avoid race conditions? You know that there is always someone in your circle of family and friends who are button pushers. The ones that like to turn things on and off, on and off in rapid succession before they ask: "What does this do?" My simple, sequential programs for turning things on in delayed sequence go to h*ll when this happens. What's a straightforward way to prevent race conditions from occurring, allowing the first press to complete before listening to any other events? Are events pushed into a queue? Or, maybe it's better to stop running a program associated with an event if a newer event supercedes it. Is that safer, especially when dealing with electrical switches?

I had some under the counter kitchen halogen "hockey puck" lights which I wanted to control using leftover Appliancelinc modules I had. If you have similar low voltage lights, they are typically powered by cheap, electronic transformers that are made in China. These transformers generate a fair amount of line noise; for me, this meant that when the Appliancelinc module controlling these transformers were turned on, there was enough line noise generated by the combination to interfere with the operation of other Switchlinc and Keypadlinc modules in the apartment. I noticed the noise by looking at other Appliancelincs and Access Points on walls - their indicators were flashing very very rapidly. When the light was turned off, normal operation of other Insteon switches was restored. To get rid of the noise, I plugged transformer into a Filterlinc, then plugged in the Filterlinc into the Appliancelinc. When this setup was plugged in, the Appliancelinc started to toggle itself in rapid succesion; I think the Appliancelinc was sensing some residual voltage from the Filterlinc, enough to trigger the Appliancelinc. I was able to get this filtered line setup to work by plugging a power strip into the Appliancelinc's controlled plug, then plugging the Filterlinc into one of the power strip outlets, and plugging the transformer into the Filterlinc. Somehow, creating a bit of distance between the Appliancelnc and Filterlinc allowed the setup to work.

The Venstar thermostat has a Program Mode which enables one to set up 4 time periods during a day and how the area covered by the thermostat should be controlled. I use the Program Mode and let the thermostat run this independent of the ISY. I use the ISY and a Keypadlinc button to run the exception case, like the 60 degree continuous setting you described. The Thermostat must be taken out of Program mode to override a temperature setting through ISY. The setpoint override is in effect until the thermostat is placed back in Program mode, at which time the program setpoint will be in effect when the next period starts.

I have the same issue with sprinkler controls. I disable the summer folder during the off months, and wait till the summer season starts. I've been toying with the idea of using a Keypadlinc button activation to signal the start of the season. That way, there are no coding changes required.

Is there an official documented way to unit test Insteon components, like the: PLM SwitchLinc ApplianceLinc Motion Sensors When a component fails for any reason, is there a way to determine from the Event Log if the component has indeed suffered a failure? Versus a communication issue? Thanks!

Not directly related to your question about variables, but you can set up folders which contain programs to be run between specific date ranges.

Thanks, everyone. I assumed incorrectly that the scene state is evaluated every polling cycle. I modified my program to use scene status and it works well. Any way to obtain scene status and display it in My Lighting (as opposed to the Admin Console)? [/code]

I'm relying on the Keypadlinc button state change (e.g. If Control 'Keypadlinc Button' is switched On) as the trigger to run a program. If the Keypadlinc button is added to a Scene, and the scene is used to control the button state, the state change doesn't appear to trigger the program to run. It just changes the state of the Keypadlinc button's LED. Is there a way to trigger the program to run? I am dependent on the state change, so I don't think using 'Status' will work. Any thoughts? Thanks!

OK, thanks for the explanation. Here's a follow on question: If you add a non-load Keypadlinc button to a scene, and the Keypadlinc is the responder, how can one determine the button state from My Lighting?

I recently noticed that the A - D button for my Keypadlinc device do not show up in the Devices list under My Lighting. The Keypadlinc's load device (on/off) does show up in the list. Is this by Design? The buttons do show up in the Admin Console. I am running ISY99i/IR PRO with version 2.7.0 firmware. Thanks!

Just added an IOLinc to my Insteon network today to turn a PC on and off remotely. I can control the relay, but I don't think the status is showing up correctly for the sensor. I have a 5 volt relay which closes a circuit when the relay is energized. The circuit is connected to the IOLinc Sense and Ground connections. The 5 volt relay is powered by one of the pigtails on an ATX power supply, whose supply is switched. When the Admin Console opens up initially, the sensor state reads correctly; it is "On". However, the sensor reverts to "Off" when the sensor is queried. It doesn't change after that. What's wrong here? I'm assuming that the IOLinc's sensor will have an "On" state if the circuit is closed. As long as the circuit is closed, the sensor should keep that state. I'm also assuming that the input and output ports are independent, unless someone specifies that they're linked in some way. State info is really important. It ensures that extra button presses on a Keypadlinc button won't inadvertently turn a PC on or off when it doesn't need to be. Any help would be appreciated!

Does anyone know anything on the ATX PC motherboard that can be used for state checking to determine if the PC is on or not, using an IOLinc? This is my first project using a device like this - the momentary contact part is pretty straightforward, but the state determination isn't as easy as I thought it would be. At first, I thought all you had to do was to measure the voltage across some circuit for the presence of +5 or +12V DC. Apparently, this isn't what the IOLinc inputs work off of. One has to look for something else, the presence of a "closed" circuit (how is that different from looking for 0V or 5V?). This is the part I'm a bit fuzzy on. Anyone with more electrical experience than I (probably most people!) care to take a shot at this? I'd be much obliged!

Turning a PC on using Insteon and the ISY may be useful if you are using a PC as a media hub. Imagine setting up a Keypadlinc button as a macro for turning on a PC, which boots without a login screen and runs your favorite media application (e.g. iTunes and Airtunes, in my case). This is probably straightforward to implement. In looking at the way the switch on an ATX computer case works, it looks like an Insteon-compatible I/O controller like EZIO2X4 or the IOLinc can be used as a means to close the momentary contact circuit signalling the PC power supply to turn itself on. The ISY program mapped to the Keypadlinc button could also used to turn on an audio component and set it up in the correct mode for the playback of audio from the computer.