LeeG

MikeBro What does the Help | About show for the 3.2.6 build date? After testing 3.1.17 I loaded the 3.2.6 Official image. The EZFlora Query is now working correctly. I had been on the 3.2.6 Beta which should have been the same as the 3.2.6 Official but something changed in moving to 3.1.17 and back to 3.2.6.

Some folks do upgrade remotely but UDI recommends doing the upgrade locally.

MikeBro I can confirm the problem. This worked at one time so I went back to 3.1.17 to test. Works correctly on 3.1.17. Something in the evolution of the I2CS support in the 3.2.x work has affected the analysis of the EZFlora Query response. I sent a note to UDI regarding this. Thanks This is a query problem only. The Zone is physically On and remains On after the Query.

bsobel The pressing of a button/paddle is seen by the PLM as that specific action. If Control ‘kplbuttonC’ is switched On Or If Status ‘kplbuttonC’ is On would be the Program statements to detect the event. The button/paddle has a Scene/Group number different from that used by the PLM for control of the ISY Scene. Every time the discussion comes up about Scene Status there is never a consensus of what that means. However, your requirement looks at from the opposite side. Something like If Control 'scenexxxx' is switched On/Off addresses the requirement without getting into the discussion of what Scene "Status" should be. With the advent of more applications using REST this type of statement becomes useful.

pikach See this link for a discussion and what Michel said about the difference between 99i and 994 viewtopic.php?f=27&t=8697&p=66321&hilit=994#p66321

rsstansbury Did you confirm with Help | About that UI shows 3.2.6? The ISY can be running 3.2.6 but the UI being at an earlier level would negate the I2CS support in the ISY 3.2.6.

rsstansbury SmartLabs is incrementally updating all Insteon devices to I2CS. Approx 12 device types have been released so far which require I2CS support in general and some require additional unique support. Unfortunately no schedule has been published so what device types are next are found as this was. The 2441TH is another tstat example which I know UDI is working on.

rsstansbury Thanks for that last trace The 2491T7E tstat is an I2CS device. Very likely needs different commands to operate it correctly. I don't have access to the SmartLabs Developer information to confirm that but the cmd2 response from two of the commands is what other I2CS devices return when they do not like the current command. Michel Can you offer any guidance here. The Query Insteon Engine shows an I2CS device and some of the commands (6B & 6C) are responding with FD in cmd2.

rsstansbury The reason for asking for the Query Insteon Engine trace is some of the responses from the tstat give the appearance of this being an I2CS device. Looking at other older traces on the forum the cmd2 response does not track to what this tstat is returning. It may be this is an I2CS device which could require different commands for accomplishing the tstat functions.

rsstansbury Can you run the same Level 3 event viewer trace, right click the Main tstat node, select Diagnostics | Query Insteon Engine and post the trace. It will only be a few lines. Thanks

You may need to delete the desktop Icon for the ISY and create it again using the 3.2.6 URL. I'm pretty sure that is why the UI was going back to 3.1.17 because the Icon was established at 3.1.17. Clear the Java cache and invoke the URL that establishes a new Icon for 3.2.6.

"So each button generates a message to both the PLM and the item it controls (or is it a scene/group message?)." Yes, a button press sends a Group/Scene message to the PLM so the ISY can maintain the current state of the device. This linkage is established when the device is initially added to the ISY. Same Group/Scene message is also sent to any devices that have been linked to the button as responders. All Insteon devices (except PLM sending Direct message) send Group/Scene messages when the button/paddle is pressed.

There is no way to do that. The only approach would be to use the "keep existing links" options. This will result in permanent communications errors every time a button is pressed because two of the three PLM Insteon addresses will fail to respond even if the broken links could be maintained.

Good choice. The MAC likes to unzip downloads. The ISY images are Zipped which MUST NOT be unzipped by the OS or Browser.

Two totally different animals. HouseLinc requires a PC running 24/7. HouseLinc has a nice communications test. Does not tell you why but does do a good job of showing what is not working. Things like ZigBee, Zwave (future) will likely never be supported by HouseLinc. I think the Programming capability of the ISY is much more extensive than HouseLinc. I don't like the idea that my house would be dependent on the PC running 24/7. I do run one 24/7, just don't want my house dependent on it.

Brian is right on with his conclusions about the OutletLinc. See page 1 of the multi page topic for the link posted. The list of devices that are now I2CS is growing by the week. The OutletLinc has been shipping as I2CS for quite some time. Over time all Insteon devices will be shipped I2CS viewtopic.php?f=30&t=8434&hilit=i2cs+partial

The thermostat did not add correctly. There should be additional nodes which are missing. Delete the device and following the procedure in the UDI Wiki for adding the thermostat. Thermostat has to be Off and use Start Linking as described in the Wiki. http://www.universal-devices.com/mwiki/ ... Thermostat

Dusk/Dawn node depends on the current ambient light for a minimum of 3.5 minutes compared to the Dark setting. Motion Sensor node should indicate On when Motion is sensed. Once On it will stay On when in Occupancy (Sensing mode). Verify Jumper 5 is On. Move a Dual Band device closer to the motion sensor Run Tools | Diagnostics | Event Viewer with Level 3 selected. Create motion and post anything the event viewer traces in response to motion.

If that is a new motion sensor the ISY needs to be at 3.2.6 with the motion sensor added to the ISY under 3.2.6. Also with Sensing Mode checked, On Only Mode should not be checked.

oberkc makes a good point. ICON switches are Off when the single yellow/orange Status LED is On. When the ICON switch is turned On either with the paddle or with a command from another device the single Status LED turns Off. SwitchLinc switches have a lower blue/white LED that indicates the switch is Off. For a Relay SwitchLinc there is only one additional blue/white LED at the very top of the LED array which is On when the Relay is On. Again, with the above convention, the Status LED cannot be separated from the state of the Relay. There is no command, no option, no linking configuration that can change the relationship between the device Status LED and the device Relay.

"When I would manual flick switch 1 on, I would hear the relay click in and the status LED would change along with the staus LED of the other switch. If I would then walk across the room to the other switch and flick it on (even though the LED already shows it as on) I would then hear the relay click in. So I guess even though the LED shows on the device itself really isn't. Am I correct in assuming this?" This is a defective switch (or wiring problem). The Status LED must follow the relay. If the LED says it is On but the Relay is Off the switch is defective or wired wrong. There is no means of separating the physical state of the relay from the status LED. What type of switch is it, ICON, SwitchLinc, ToggleLinc, etc? The above could be an error in how the normal 3-way wiring was converted to use Insteon switches in a multi way circuit. Don't worry about being argumentative. It is never a problem getting a situation clarified. I've been doing this along time and still put in the wrong information at times. What I was going to post here is an example of a Program using If Control. If Control 'ICON Dimmer 1' is switched On And Control 'ICON Dimmer 1' is not switched Off Then Set 'ICON Relay 1' On Else Set 'ICON Relay 1' Off

Not sure what you are trying to accomplish with the Programs. When they are correctly cross-linked manual operation at either switch will cause the other to follow. Operating the Scene either in MobiLinc or the Admin Console will cause both switches to operate together. In Insteon if you programmatically control just one switch the objective is for that switch only to respond. That is the way Insteon is architected to work. It seems like the Programs are trying to override the Insteon architecture. If that is what you are trying to accomplish try using If Control rather than If Status. If Status causes a Program to be triggered any time the Status changes. This means that when Program 1 changes the Status of a device it can cause Program 2 to trigger because the Status has changed. Using If Control triggers the Program when a specific command is received from the device, not a state change. Changing the Status of a switch does not trigger the Program that is checking for a specific command (If Control) from that device. Again, it seems like the Programs are trying to defeat the way Insteon is designed to work. Certainly can be done, just not sure why. Also note that Java 7 is known to cause problems. I would go back to Java 6. At least make sure the latest Java 7 build is installed.

What level of Java? What does Help | About show for Firmware and UI?

What is being used for AV? Avast and Kaspersky are two that often block updates from being pushed out from the ISY to the Admin Console.

"so doesn't that mean that the ISY does know about the links" Yes. Below the device entries in the My Lighting tree are Scenes. There should be a Scene with a name such as "Scene 4" for example. The ISY creates these Scene definitions based on links it finds in devices during the device add process when the "keep existing links" option is selected. Find the Scene xxxx that represents the two referenced switches. Click on one of the device nodes in the My Lighting tree. To the right side of the node display in the right Membership pane is a list of Scenes the switch is a part of. Use this Scene to turn both devices On/Off together. Update: suggest spending some time renaming the generated Scene names to something meaningful.