LeeG

Connecting 120V Access Points to each individual phase is not same as connecting the 240v Load Controller across two of the three phases of a 3 phase service. The Load Controller has no Neutral connection so it is a true 220/240V device. It also is expecting the two 120v legs to be 180 degrees apart which is not true across 2 phases of a 3 phase service. I expect Smarthome will indicate the Load Controller is not meant to be connected to a 3 phase service. Please post the results of the Smarthome call so we call all benefit. Thanks

What 2 of the 3 phases is the Load Controller connected to? I'm pretty sure that load controller is not meant to be connected to 2 phases of a 3 phase supply. That would only produce something like 208V if I remember correctly and the phases will not be 180 degrees apart. I think a call to the Smarthome Gold Line is in order as I don't think the device can be connected as it is now.

The Insteon Engine indicates whether the device is an I1. I2 or I2CS device. I2CS is the latest Insteon protocol enhancement which requires ISY firmware that has been updated to support the protocol. The Request Failed is an indication of powerline communications problems. The Query Insteon Engine would not normally have any external result. It insures the ISY has the correct Insteon Engine information. It may be the communications problems are introducing unexpected results where I2CS is concerned. There are many users with I2CS devices that are not having the issues you are seeing. In an earlier post I suggested deleting one of the I2CS devices, doing a factory reset and adding it back with the Event Viewer running at Level 3. I still think that is a good idea. The device responses for an I2CS device are well understood so a an event trace at Level 3 of the device add should provide good diagnostic information.

That is not noise. It means the device is an I2CS device that the ISY is treating as an I2 device. If the devices were added to the ISY before going to 3.2.6 they have to be deleted and added back under 3.2.6. If they were added to the ISY under 3.2.6 click on the node, select Diagnostics | Query Insteon Engine. Is the Advanced Options set to Automatic?

An Event Viewer at Level 3 would provide more information but it looks like from the summary the thermostat is sending information, it just happens to be all 00's. The only suggestion would be to start over. Delete the thermostat, factory reset, be sure the Mode is Off and add it back using 3.3.3. Be sure Help | About shows 3.3.3 for both Firmware and UI.

Xathros Thanks for query. 3.2.6 has I2CS support. The 3.3.x beta series has additional thermostat support, resolves several problems but none that would affect the successful add of an I2CS SwitchLinc Relay. I think going to 3.3.3 is a good idea because of all the maintenance but the SwitchLinc Relays should work on 3.2.6. I suspect either the Advanced Options setting is not Automatic or the UI (Admin Console) is not at 3.2.6. The ISY is using the old Peek/Poke method to manage the link database. That cannot work because Peek/Poke commands are dropped from I2CS devices. Unfortunately Peek/Poke commands are not rejected with a NAK, they just do not function. Link management gives the appearance of working but valid link records are not created. Thus Scenes with I2CS devices do not work. Direct device control (On/Off) works because they are not dependent on link records.

Does the UI level also show 3.2.6 or some other value? Perhaps I am thinking of a different post. Was the Link Management | Advanced Options changed from the default Automatic setting? If so it has to be set to Automatic. Delete the SwitchLinc Relay. Factory reset the SwitchLinc Relay. Run Tools | Diagnostics | Event Viewer with Level 3 selected. Use New INSTEON Device, enter the Insteon Address and Name of your choice. Leave the Device Type set to Auto Discover. Post the event trace from adding the SwitchLinc Relay. When the Show Device Links Table has entries that have data such as F9 FA FB FC FD FE FF it means the ISY is treating the device as an I2 device when it is actually an I2CS device. This can be the result of the Admin Console (UI) being at the wrong level (Java cache not cleared and/or wrong URL). The Event trace will show what is actually happening. Verify that Help | About shows 3.2.6 for both the Firmware and the UI lines. That is critical.

In Insteon each Controller has a unique set of Responder On Level and Ramp Rate values. Click on the Controller node name below the Scene name. Set the Responder values for that Controller which are different from using the Scene name where the PLM is the Controller.

The 2441ZTH User Guide indicates E2 FE rather than E2 EF but I don't know that it matters as that is listed for Broadcast messages which the ISY does not use for other devices. Does the Event Viewer show any Insteon traffic from the 2441ZTH when Set Points or Mode is changed at the thermostat.

Do a Show Device Links Table for the 2441ZTH. Look for three link records E2 01 plmaddress xxxxxx E2 02 plmaddress xxxxxx E3 03 plmaddress xxxxxx

WGKirby The Show Device Links Table is from an I2CS device that is not being managed correctly. It must be added using the Automatic option. Delete the device, add it back with the Automatic option. Also before doing anything, what does Help | About show for Firmware and UI? In addition to needing to use the Automatic option the ISY and UI firmware must be late enough to support I2CS devices.

hbsh01 It makes a difference only if the powerline is not reliable. Most users see no difference between Direct and Scene command response.

WGKirby The Show Device Links Table can be saved to an XML file. Edit the file with WordPad or something similar and copy/paste the XML file. What ISY firmware are you using? Click Help | About, what is shown for Firmware and UI lines?

“I woul think that if I can control the individual switches communication "should not" be an issue.†That is not a correct conclusion as the Scene On/Off messaging is very different from device direct control messaging. However, Scene Test messaging (separate from Scene On/Off messaging) is similar to direct device control messaging. Since the Scene Test is producing a solid failure it raises some other variables. The Scene Test is dependent on link records both in the PLM and the devices themselves. From the Scene Test results the PLM is okay. The following part of the post I prepared earlier before seeing the last post. Devices 1B.E1.15 and 1E.ED.CD did not respond to the Scene Off request. This is indicated by the NAK flag byte E1. Right click one of the nodes in the My Lighting tree. Select Diagnostics | Show Device Links Table. When the display completes click Compare button which will indicate if the link records read are what the ISY expects. Run the Show with the device OFF as florescent ballast could interfere with Insteon signals. Wed 10/10/2012 10:59:48 AM : [iNST-SRX ] 02 50 1B.E1.15 1C.FC.58 E1 13 FF LTOFFRR(FF) Wed 10/10/2012 10:59:49 AM : [iNST-SRX ] 02 50 1E.ED.CD 1C.FC.58 E1 13 FF LTOFFRR(FF) If the Show and Compare indicate the link records are correct there is a communication problem with that device. Could be a coupling problem, could be interference from the fixture itself. Disconnect the Red load wire on both devices, cap them and run the Scene Test. A successful test indicates a load issue. If the Scene Test fails then something else is causing the problem. Could be a coupling problem or something else is causing interference on that circuit. If the Show and Compare do show a link record problem (other than the last record which will be labeled [ignore} run Restore Device to rewrite the device link database. EDIT: regarding the Query about Scene On/Off versus device direct control On/Off, a Scene On/Off is not ACKed and has no retry associated with it. The ISY marks the devices as it expects the devices to react to the Scene On/Off, not necessarily how they reacted or failed to react if there are communications or link record problems. The Scene Test failure indicates either a link record problem and/or a communications problem. The above procedure will determine if the link records are correct.

For a Scene Test right click on the Scene name, select Diagnostics | Scene Test. It will take several seconds for the Scene Test to run and report the results in an Event Viewer window.

The ISY cannot access a custom Insteon device. The ISY is strongly typed to each device it supports. The REST interface is IP based. Not associated with any Insteon device. The REST API is described in the WSDK which can be downloaded

“BUT I have yet to find anyone that can tell me if those INSTEON user data bytes (there are 14 bytes) are usable as variables in the ISY macro logic.†No, not in a generalized way. “NOW is it possible for the ISY to access those USER DATA BYTES?†The ISY has physical access to the data but has no understanding what to do with it. There is no general Insteon device type that allows a free form use of the 14 bytes. An alternate approach would be the ISY REST IP interface. Over the LAN REST messages can be sent to the ISY to set Variable data. Currently Variable data is limited to Integers.

Makes perfect sense. A simple approach is to use a Fast On (double tap) from the SwitchLinc to trigger a Program which sets a Variable value that blocks the turn Off process. Hard to go into detail without knowing how the ISY Program is coded which turns the lights Off. It is more complex but ISY Programming can count the number of On commands within a given amount of time and set the a Variable to do the suppression.

If they will not cycle manually with the Set button it is time to contact the Smarthome Gold Line. It sounds like both units have failed.

Secondary KeypadLinc buttons have to the controlled with a Scene. They do not respond to Insteon Direct On/Off commands. Define an ISY Scene with KeypadLinc button B as Responder. Turning the Scene On will turn On the button LED. However, that does not turn On devices that have been linked to button B. Insteon does not work that way. Button B would normally be a Controller of a Scene. If that Scene is turned On button B will be turned On along with the Scene Responders. If button B has no Responders but is used as a Condition in a Program, the first answer is the approach. Define a Scene with the button as a Responder and turn the Scene On. The only issue that could arise is if a Program condition is using If Control ‘kplbuttonB’ is switched On. That is checking for a command coming from the KeypadLinc so turning the button On will not trigger the Program. Sorry for the long winded response. Trying to cover all the bases.

87squirrels They are listing in the Wiki. They cannot be transferred to regular ISY Variables. See the link below http://www.universal-devices.com/mwiki/ ... _Variables

chamnic I think the issue is the firmware level of the SwitchLinc. It is too old to support the technique that does not require a powercycle. After setting the Local On Level and Ramp Rate power cycle the SwitchLinc.

I don't think it is a cable problem. Problems communicating with the PLM in general but not related to X10 powerline traffic. I have so little X10 left and it was always unreliable. That is why I moved to Insteon years ago. Are any of the X10 devices pluggable where they could be moved to the same plug point at the PLM. That would show if the PLM to X10 is functional.

There was some button problem corrected at 3.3.3. Try a Restore Device of the KeypadLinc. I think I have seen other posts that suggest it might be necessary to delete the KeypadLinc and add it back under 3.3.3. Not sure if the symptom was related to controlling the load from a secondary button. What is the KeypadLinc firmware level? I will try and recreate if I have a KeypadLinc with the same firmware.

The length of time depends on how many devices, how many Scenes. Every link record in every Insteon device that contains a reference to the old PLM has to have the address changed to the new PLM address. For all but the newest I2CS devices link database memory is changed one byte at a time. It takes a minimum of two command executions for each byte of memory changed. There is nothing the ISY does to X10 devices. Replacing the PLM would have no affect on X10 devices. Perhaps something has changed on the powerline that is affecting X10 signal strength. What aspect of X10 is not working. RF such as a key fob for X10 commands not reaching the PLM to not reaching the X10 device from the PLM, ….