LeeG

With a 2412U USB PLM connected to the PC you can run the SimpleHomeNet Utility Suite (designed to run on XP, tested on 32 bit Vista successfully and may run on Windows 7 but not tested) and set the EZFlora Configuration register option that makes Zone 8 a Pump/Master Valve controller. There are drivers available from Smarthome that are required for a 2412U PLM. Although connected to a USB port, the Smarthome device driver makes the USB connected PLM look like a Serial connected PLM and will assign it a COMx number. Usually starting with COM4 or COM5 but it can vary from system to system. The ISY with its Serial PLM has no problem coexisting with another PLM on the same powerline. The ISY cannot physically connect to a USB PLM as the ISY is using a true Serial connection. It is correct that the EZFlora does not allow two Zones to be turned On together. Turning on Zone x turns all the other Zones Off. The initial screen of the Simplehomenet Utility accepts a COMx number for a PLM, select the Use PLM radio button and then click on Connect. If the COMx number is correct the SHN Utility will connect to the PLM with a status message at the bottom left of the SHN Utility screen saying Connected to the PLM with the device address and PLM revision level. Select the EZFlora tab, enter the device address of the EZFlora device in the Insteon ID: field which should then show a Connected message just under the Insteon address field. Click on “Zone 8 is a Pump†button. This will cause the EZFlora to energize Zone 8 when Zones 1-7 are turned On. When all Zones are Off Zone 8 will turn Off. Do not control Zone 8 from the ISY. EDIT: missed one. yes, once the Zone 8 is a Pump option is Set you can use the ISY to turn each Zone On/Off and Zone 8 will turn On/Off automatically. You can also use the SHN Utility to manually turn on the Zones either for testing or for actual watering. Don't suggest trying to use both at the same time as they will not know each other is controlling the same device. The EZFlora will respond but the ISY nor the SHN Utility will be aware of the others activity.

Between when the Remove device option was presented as an option and when it was not did you initiate some activity such as removing the device from one or more Scenes? It may not present the Remove device option while the ISY is performing other tasks related to that device. The status at the bottom of the ISY window may say something other than Ready if it is working on something. The links necessary for the ISY to be aware of a button press so that a Program can be triggered with a Control On for example are established when the device was originally added to the ISY.

I have no suggestions regarding how the Admin Console is operating. It still sounds like the link records are not correct either in the KPL itself or the PLM. Using Tools | Diagnostics | Event Viewer, set the change level to 3 and press button C. I expect you will not see messages in the Event Viewer window. The Remove is still the suggested next step. Someone with more insight into the Admin Console will have to address its current operation. It is not necessary to remove the device from Scenes before doing a Remove device. The ISY does this automatically. It does not delete the Scene, simply removes the device from each Scene before removing the device entry itself from the My Lighting tree. What level firmware are you running in the ISY?

In the My Lighting tree, right click on the device and select Remove.

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.