LeeG

The suggestion by oberkc is a good way to test for communication issues at a particular location. If you do decide to test this be sure to Restore the KPL link database before testing. Insteon devices must have a Controller link record for every button and the PLM must have a Reeponder link record for the same buttons. Without these you will not see any traffic from the KPL button press in the Event Viewer at change level 3. The easiest way to insure links are in both devices is to Remove the KPL from the ISY and add it back. The ISY will write the necessary link records in the KPL and the PLM.

Do not mess with the backlight levels. They apply to all button LED backlight levels, not an individual button and Backlight level is not used to turn an individual LED On or Off. A Secondary KPL button (C in this case) cannot be controlled directly like the Primary load button. Define a Scene with KPL button C as the only responder. The additional line to be added in the list of Then control statements is to turn OFF the new Scene. This will turn Off KPL button C LED.

This looks to be a device question to be resolved with Smarthome Support. Do not use the Smarthome forum as that is a user to user forum not monitored by the product owner as the UDI forum is. It is likely they will want to know the frequency of the flicker, does it happen at full bright or only when dimmed, is there anything operating in the 900 MHz frequency range such as a cordless phone, and are there other devices besides Insteon/X10 devices using the powerline for communication.

Setting Zone 8 as Pump Control can be done with the Set button which is not available to you. It can also be set using the free download SimpleHomeNet Utility Suite program. This program requires a PLC, PLM or EZSrve as a powerline interface to issue commands to the EZFlora. Does not seem likely this is an alternative available to you either. The Admin Console does not have an option for setting up Zone 8 as a Pump / Master Valve control.

Are the all incandescents also flickering every ~60 seconds. Is the flickering happening at full bright or only when dimmed. Are other Insteon dimmers working without the flickering. Is there something else using the powerline that operates every ~60 seconds.

richardl007 Are they low voltage halogen devices? Lee

Insteon dimmers are rated for incandescent loads only.

When the Program changes the status of 'office', either On or Off, the Program If is reevaluated because of the Status change. It is now Off if it was On or On if it was Off. The Program runs over and over each time the Status is reversed.

The On Only Motion Sensor option suppresses the Off commands. The next On command still waits until the Motion Sensor Timeout interval has expired. The (Occupancy) Sense mode is the option that generates an On command for every motion detected regardless of the Timeout interval. Someone else will have to cover how the If reevaluation may or may not interrupt execution. I posted how I thought it worked and someone else said that was not correct so I think it best for someone who actually knows post the impact of additional commands. Since the Control On you are using in the IF never changes True/False state that may have a bearing on the results you are seeing.

Paul, The conflict between multiple Scenes has always been there. In a pure hardware situation (no automation) there is generally no visible result of hitting a second paddle/button while one Scene is in progress. The hardware Group protocol initiated from a paddle/button press starts with a Group Broadcast message which all responders react to nearly simultaneously. At this point all the visual changes from the first paddle/button button press have been initiated. After that the Group protocol generates a Group Cleanup Direct message to every responder device in the Group (Scene) which requires each responder to send back an ACK to the controller where the paddle/button was pressed. This Group Cleanup Direct/ACK message exchange sequence can take some time depending on the number of responders in the Scene. The follow up Group Cleanup Direct message exists for the rare case where all responder devices failed to receive the initial Group Broadcast message. Normally all responders see and react to the Group Broadcast message so if the remainder of the Group protocol, the issuing of the Group Cleanup Direct messages, is canceled as a result of a second paddle/button press there is no adverse visual effect. With Home Automation it gets more complicated. With Programs being initiated by the Group protocol generated with a paddle/button press and that Program initiating a new Scene, what was a rare conflict between multiple paddle/button presses can now be a common occurrence. Another area is a Program initiating multiple Scenes in a row. Without HA pushing multiple paddle/buttons in a row was rare. With HA it is more common to initiate multiple Scenes. Timing is everything. Depends on whether there are multiple responders to a paddle/button press. If so, where is the ISY PLM in that list of responders. In other words, where in that series of powerline messages is the ISY PLM notified of the paddle/button press. I tend not to think of these potential problems when writing automation. Only if something is unreliable or just “should work†but does not then think about where a conflict might exist and if a Wait could resolve it. Sorry for the long winded response. It is necessary to know how the Group protocol works to see what and where potential conflicts can arise. HTH Lee I see from Rand’s post that the ISY will handle these conflicts. I defer to the expert.

Using a Scene is the only way to get a group of responders to react simultaneously. A Scene (Group as far a hardware is concerned) starts with a special Group Broadcast message that causes all responders of the Group to react at the same time. Individual Direct device commands must be ACKed by the device before a Program can proceed with the next Direct command. Insteon cannot handle multiple Direct commands on the powerline at the same time. The reason the delay is required is that Insteon architecture will cancel a Scene execution if another Scene execution overlaps.

When I turn the Scene On the IO Linc Relay turns Off. When I turn the Scene Off the IO Linc relay turns On. The Event Viewer shows the correct Scene On and Off commands are being issued. Do not know at this point why the relay is responding opposite to the Scene On/Off commands. Admin Console On/Off directly to relay work as expected. On button turns the relay On, Off button turns the relay Off. Thanks for the second post. That explains the reverse behavior I was also seeing.

The more complex the IF the longer it takes to evaluate. A bigger problem is the changing of the Scene responder Bright level and Ramp rate before turning On the Scene. All the Bright level and Ramp rate information has to be written into the responder device using powerline commands before the Scene is turned On. That all takes time and is redundant after the MS has signaled On within a given time period. Perhaps something like the use of a Folder for each time period with a Program in each folder that invokes a different Scene that has been defined with the responder characteristics you want for that time period. That approach would eliminate all the setting of responder characteristics on the fly and simplify the Program If statements. This is one of those questions that has many different solutions. I am sure others will have more ideas. The objective is to reduce the complexity of the If statements that have to be evaluated every time the MS turns On and eliminate all the dynamic changing of Scene responder characteristics, particularly on every MS On.

The first Condition has nothing to be Anded or Ored to because it is the first. The next Condition specifies whether the next Condition is Anded or Ored to the previous Condition.

The Query result is not affected by the "Trigger Reverse" option so the Query results will be the opposite when moving from Red NC to Green NO. The next time the IO Linc status is not changing see if the Green LED on the IO Linc is changing as the door is opened and closed. If the Green LED does change as the door is opened and closed, run the Event Viewer with Change Level 3 in effect and see if any messages are traced as the door is opened and closed.

When you changed the wires on the magnetic switch you changed from NO to NC (or maybe the reverse of that) which reverses the Open/Closed state of what the IO Linc is sensing.

It is likely that when you switch wires you are unplugging the IO Linc. Try just unplugging the IO Linc for 1 minute without changing any wiring and see if that restores function. Is the Green LED changing state when the door is opened and closed?

kaplansa Switching between the Red and Green wires simply changed the magnetic switch from NO to NC operation. The magnetic switch included with the kit has both a NO and NC reed switch built-in. Most magnetic switches are only NO or NC, not both. The only difference between using the Green and Red wire is that the IO Linc Sensor turns On when the garage door opens or turns On when the garage door closes. That could have reversed the logic but not whether you were getting Sensor signals from the IO Linc. Either wire should have shown up as a Sensor node status change under the Admin Console. Maybe the opposite On/Off to what you wanted but the state change should have been seen with either wire. It could be the NO (green wire) part of the magnetic switch is not working do to a bad reed switch or broken wire. There should be no reason to have to switch back to the green wire unless you just want to see if you continue to get status changes reflected in the Sensor node. There is an IO Linc option under the IO Linc Sensor node which the ISY supports that allows the On/Off commands to be reversed if needed. Lee EDIT: as a follow up for folks not familiar with the magnetic switch Smarthome includes with the IO Linc garage kit, it is two magnetic switches in one enclosure. There is a NO switch (Green wire) which is open until in proximity of the magnet at which time it closes (makes the circuit). There is also a NC switch (Red wire) which is closed until in proximity of the magnet at which point it opens (breaks the circuit). Smarthome Quick Start guide directs the use of the Green wire NO contact. This arrangement results in the IO Linc Sensor being On when the magnet is in proximity to the magnetic switch. Using the Red wire NC contact would operate in the reverse. The IO Linc Sensor would be On until the magnetic is in proximity to the switch at which point the switch opens and turns the IO Linc Sensor Off. Either of these configurations will result in the IO Linc sending On and Off commands to the ISY. It is simply a matter of whether you when you want the On command sent when the door is open or when the door is closed. Just to make things complex (if not already) the IO Linc has an option to reverse the On/Off commands. This means that no matter what wire is used (Red or Green) the On command can be made to represent whatever door condition you want it to represent, open or closed.

kaplansa I am using a different magnetic switch. Whether you use the NO or NC contacts built into that magnetic switch is really just personal choice. Do you want an On command to indicate the door is Open or the door is Closed. Having worked with a number of users that have SHN EZIOxx devices monitoring garage doors (like an IO Linc but more Sensors and Relays in one device) some want it one way some want it the other. I think that is why Smarthome ships that combined magnetic switch. That way the one switch can be wired to support either situation (On Open or On Closed). Lee

kaplansa I just added an I/O Linc to my ISY using 2.8.4. The Admin Console shows the Sensor node changing status as the Sensor connection is opened and closed against GND. What ISY firmware level are you using. Did you use Auto Discovery when adding the I/O Linc What I/O Linc revision does the Admin Console display for the I/O Linc Does the Show Device Links Table function under Diagnostics show an entry for the I/O Linc that looks like this .... 0FF0 : E2 01 12.9F.E4 FF 1F 01 The 12.9F.E4 is my PLM address so these values will be different Using the Event Viewer with Change level 3, do you see any trace activity as you open and close the Sensor circuit. Wed 10/20/2010 12:15:35 AM : [iNST-SRX ] 02 50 15.BB.5A 00.00.01 CB 11 00 LTONRR (00) Wed 10/20/2010 12:15:38 AM : [iNST-SRX ] 02 50 15.BB.5A 00.00.01 CB 13 00 LTOFFRR(00) Lee

Each responder to a given Scene can have its own specific Bright level and Ramp rate. Each responder to different Scenes can have its own specific Bright level and Ramp rate. The Bright level and Ramp rate are maintained in the responder's link record so every Scene controlling Device A can have Device A respond with a different Bright level and Ramp rate. In fact within the same Scene, the Bright level and Ramp rate can be different when the ISY Program controls the Scene versus when another controller device controls the Scene. So long as there is a unique responder link record involved the Bright level and Ramp rate can be unique.

Correct on both counts.

The mutex capability of the KPL applies only when a button is pressed on the KPL. The KPL firmware does not apply the mutex relationship for commands sent to the KPL from a different controller (the ISY in this case). Also the technique of using an On command to turn a device Off by setting the Bright level to 0 does not work for Secondary KPL buttons. Again, a limitation of the KPL firmware. To turn a Secondary KPL button Off you have to have that button as a Responder to a Scene and turn the Scene Off.

I have confirmed the LED does not light under ISY and does light under HL2. Using the following setup with ISY and (HL2) ... (Occupancy) Sense - Checked (On) On Only - Checked (On & Off commands) Night Only - Unchecked (Night Only) Timeout - 1 minute (1 minute) LED Brightness - 125 (49%) Dark Sensitivity - 74 (29%) low storage ISY - 50100134 127D014A low storage HL2 - 50100134 1A7D014A Byte 4, which I think is a flag byte, is the only difference between when the LED lights and does not light. HL2 is using the Extended Set 2E to set the LED Bright level so there could be other differences beyond storage locations 0-7. The actual LED Bright level value of 7D is the same for both.

Steve, You defined the Motion Sensor as Controller of the Scene. This means that the MS will send On and Off commands directly to the list of responders as motion and the timeout interval expires independent of what your Programs are doing. If you want all responder On/Off reaction to be under Program control rather the direct Motion Sensor control remove the MS as a Controller of the Scene. Then turn Off On Only mode. Whether you let the MS directly control the responders for On/Off ( MS as Controller of the Scene and On Only mode Off), let the MS turn On the responders and the Program turn the responders Off ( MS as Controller of the Scene and On Only mode On) or let the Programs do all the responder On/Off (MS is NOT a controller of the scene) is completely a user choice. I am not familiar with the examples in the Wiki. It sounds like from the results of the Programs you have chosen you do not want the MS as a controller of the Scene and you need On Only mode Off. Perhaps the Wiki explains the MS options that must be in effect for each group of Programs. There are many choices. You just have to set the MS options according to the Program requirements you have chosen to use. When the MS is a Controller of the Scene the responders turn On instantly and may or may not turn Off under MS control depending on the On Only mode. When the MS is NOT a controller of the Scene then there is a slight delay turning the responders On as a Program has to run which turns On the Responders and also turns them Off. The advantage to this approach is that you do not have to access the MS physically to set Link mode to change the Off timeout because it is all under control of the Program. Lee