LeeG

It is not all 2484DWH8 Countdown Timers with v2D. I had no problem adding one using 4.0.4 and it reports state changes. Used New INSTEON Device with Auto Discover

aLf Here is the beginning of the event trace of adding the Silver RemoteLinc. Likely the problem will be with the first command in the trace. Compare your event trace to this one. Mon 05/06/2013 10:03:39 PM : [11 ad cf ] Added to list of devices to link to ISY Mon 05/06/2013 10:03:39 PM : [iNST-TX-I1 ] 02 62 11 AD CF 0F 0D 00 Mon 05/06/2013 10:03:39 PM : [iNST-ACK ] 02 62 11.AD.CF 0F 0D 00 06 (00) Mon 05/06/2013 10:03:39 PM : [iNST-SRX ] 02 50 11.AD.CF 22.80.0B 2B 0D 01 (01) Mon 05/06/2013 10:03:39 PM : [std-Direct Ack] 11.AD.CF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Mon 05/06/2013 10:03:39 PM : [iNST-TX-I1 ] 02 62 11 AD CF 0F 10 00 Mon 05/06/2013 10:03:39 PM : [iNST-ACK ] 02 62 11.AD.CF 0F 10 00 06 ID-REQ (00) Mon 05/06/2013 10:03:39 PM : [iNST-SRX ] 02 50 11.AD.CF 22.80.0B 2B 10 00 ID-REQ (00) Mon 05/06/2013 10:03:39 PM : [std-Direct Ack] 11.AD.CF-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Mon 05/06/2013 10:03:40 PM : [iNST-SRX ] 02 50 11.AD.CF 00.05.35 8B 01 00 (00) Mon 05/06/2013 10:03:40 PM : [std-Broadcast] 11.AD.CF-->00.05.35, Max Hops=3, Hops Left=2 Mon 05/06/2013 10:03:40 PM : [11 AD CF 0 ] Calibrating engine version Mon 05/06/2013 10:03:40 PM : [11 AD CF 0 ] May not fully support i2, reverting to i1 Mon 05/06/2013 10:03:40 PM : [11 AD CF 0 ] Using Database Link Table offset 0x0FF8 (reported 0x0000) Mon 05/06/2013 10:03:40 PM : [11 AD CF 1 ] Start : Adding device to ISY Mon 05/06/2013 10:03:40 PM : [11 AD CF 1 ] Finish : Adding device to ISY was Successful Mon 05/06/2013 10:03:40 PM : [11 AD CF 1 ] Link 0 : 0FF8 [E20122800BFF0001] Saving [E20122800BFF0001] Mon 05/06/2013 10:03:40 PM : [11 AD CF 2 ] Start : Adding device to ISY Mon 05/06/2013 10:03:40 PM : [11 AD CF 2 ] Finish : Adding device to ISY was Successful Mon 05/06/2013 10:03:40 PM : [11 AD CF 2 ] Link 1 : 0FF0 [E20222800BFF0002] Saving [E20222800BFF0002]

I added a Silver RemoteLinc with v35 firmware using 4.0.4.

Send an email to sales@..... requesting information. There is an additional circuit board with the IR capability that you can install locally. Sales will provide information on payment and ship information.

That is consistent with what I found as well. Only certain sensors provide the ability to identify the Location and then the Location is one of approx 12 (?) pre-canned words. Better than nothing but not a nice general function available with all their sensors. I think if one wants all the bells and whistles one uses a security system designed with battery backup and zone locations.

Michel I was using the following link as the source to this topics question. It indicates the Smoke Bridge API does not provide location information which identifies which sensor sent the alarm. There would not be a method of know which sensor sent the Smoke alarm or which sensor sent the CO alarm or which sensor sent the low battery alarm. Question from dss – “Is there a way for the ISY to know which alarm is giving the low battery signal?†viewtopic.php?f=27&t=11017&hilit=smoke+bridge I am assuming users would not have a Smoke Bridge for each sensor. That seems like overkill plus the Smoke Bridge is going to react when the linked sensor alert trips which should be when any of the sensors trip. All the sensors are linked together so if any one trips they all trip. Sleeping on the third floor the third floor sensor should trip to wake sleeping residence if the sensor in the basement several floors away trips. That means every Smoke Bridge would trip if a Smoke Bridge existed from every sensor. It would be nice if location, even if it was just some burned in number, was carried along with the alert message but all indications are that is not part of the sensors. Only certain sensors provide location information and that is somewhat general in nature. I have to assume the manufacturer of the sensor made the same ROI evaluation as any business would as did SmartLabs in deciding what function the Smoke Bridge would provide. The Smoke Bridge is an augment to, not a primary functionary in the alert system. I have seen no change in the stated policy that Insteon should not be used for such purposes.

The first Program is all that is needed. If the Status of 'Closet Lights' changes to Off while in the Wait the If is reevaluated as False which runs the Else clause and terminates the Program. The next time the 'Closet Lights' are turned On the Program is invoked again starting a fresh 30 minute Wait.

There are more Insteon devices that function as Responder Only devices. You can know this in advance by checking the device User Guide for instructions on linking. If the User Guide does not include instructions for linking as a Controller it is a Responder Only device regardless of whether it has a local switch. Even this approach can be misleading. The I/O Linc User Guide has instructions for linking as a Controller but that applies to the Sensor part of the I/O Linc which happens to be Controller Only. The I/O Linc Relay part of the I/O Linc is a Responder Only. The I/O Linc automatically turns the Relay Off in Momentary mode which State change is NOT sent to the ISY. Bottom line is do not assume anything about a specific Insteon device. Just because a KeypadLinc and SwitchLinc as examples function as both Controller and Responder, not all Insteon devices do even when they can be controlled with a local switch. Some devices are Controller Only, some are Responder only, and some (probably most) are Controller/Responder devices.

You are absolutely correct that most Insteon devices send an updated Status when controlled locally. Would need to know the other device types you mentioned but it is normal for most devices to function as both a Controller (send updated Status change message when changed locally) and Responder. This has nothing to do with REST. The OutletLinc Relay DOES NOT function as a Controller. It is a Responder Only device. The state change that occurs by pressing the local button on the OutletLinc Relay DOES NOT send a state change message to the ISY. Again, having nothing to do with REST. The REST command that retrieves the current information in the ISY about the OutletLinc Relay WILL NOT reflect any local state change that has happened from pressing the local button. Again, the OutletLinc Relay is a Responder Only device. There is a REST command (mentioned in my previous post) that will send a Query command to the OutletLinc which will determine the current OutletLinc state. This REST Query command must be issued against the OutletLinc Relay before issuing the REST command that returns the current information in the ISY.

andyf0 Does Help | About confirm UI is at 4.0.4?

Only one Smoke Bridge is needed. A single Smoke Bridge will not identify which Smoke/CO/Low Battery device alarmed.

Right click the primary device node and select Delete. The better approach assuming the device is being replaced with a functional one is to add the new device under a temporary Name. The Right click the old defective device node, select Replace xxxx With ..... and select the new device Name. The ISY will replace all references to the defective device Insteon address with the new device Insteon address, leaving the original device Name in Programs and Scenes unaffected. The old Insteon address is not sent commands so the old device can even be removed and physically replaced with the new device before invoking the Replace xxxx With .... function.

This REST command returns the information the ISY currently has. It does not physically Query the device "http://192.168.1.50/rest/nodes/18%2039%2081%201" This REST command actually sends a Query command to the device. http://192.168.2.2/rest/query/1A%2084%20BB%201/ After this REST command is issued the first REST command can be issued to return the current state of the device.

Run the event viewer at LEVEL 3. Then issue the REST command. Is a command being sent to the OutletLinc? It sounds like the REST command is pulling the current State the ISY knows about which would not reflect that it is On. What actual REST command is being issued? Unfortunately nothing you post here about how the device works versus how you would like it to work has any influence over the manufacturer (SmartLabs). There is a topic on the Smarthome forum for posting product requests.

OutletLinc does not have Controller capability so it cannot be added to a Scene as a Controller. Same with the ApplianceLinc. EDIT: refer to the OutletLinc User Guide. It describes how to link it as a Responder but no instructions on how to link it as a Controller. Some Insteon devices are Controller Only, some are Responder Only, and some can be Controller and Responder. The OutletLinc is a Responder Only device.

That is the FilterLinc. It can be plugged into the same circuit as the PLM. The UPS, surge power strips, other electronics plugged into the filtered outlet of the FilterLinc. Those are the Access Points and two are all that is needed for good phase coupling, one plugged into each 120v leg. The 4 tap Set button test will positively show they are installed correctly. Need for additional Access Points is usually determined by RF coverage for RF only devices such as motion sensors, remotelinc2, etc. Some folks have used an Access Point plugged into a problematic circuit to improve a specific circuit. Did unplugging the UPS and other electronics have a positive effect on the Insteon network?

There is a positive test for phase coupling. The 4 tap Set button test is one of the few things in Insteon where successful phase coupling can be seen. Put one of the Dual Band devices into test mode and watch the others for being in RF range and on the opposite phase. Wired Dual Band devices buried inside a junction box do not have the range of Access Points. If they happen to be in metal boxes they are very restricted in terms of range and direction of coverage.

Unplugging all electronics and any power strips with surge suppression on the PLM circuit is a good test. Any of these can be reducing the level of the Insteon signal on the power line. PLM should be plugged directly into an Outlet. Also check that the Access Points used for phase coupling pass the 4 tap Set button test described in the Access Point User Guide.

Michel The reason for suggesting a Ticket was the hope that since this is an I2CS 2441ZTH it might have some other way of obtaining the cat/subcat information since the Broadcast message is not in the form one would normally expect.

Devices that never show a state change could be a link record problem in the PLM. Could be a device problem but with many devices developing the problem it would more likely be a PLM link record problem. Electronics can change over time. The UPS along with other electronics should be isolated with a FilterLinc. A Restore Modem (PLM) will restore the PLM link database. A general sense of how well Insteon is working is to run the event viewer at LEVEL 3. Turn various devices On/Off a few times with the Admin Console and watch the Hops Left=x count. Hops Left=2 is best, Hops Left=1 is okay so long as consistent, Hops Left=0 is the worst. Past that the device will not respond.

Wow, from the phrasing it sounds like I'm being lead to the slaughter. I have not tried what is being suggested but I cannot think of a reason a single Scene could not be used. Each Controller in an ISY Scene has a unique set of Responder values which allows the needed buttons to be set to 0% On Level to achieve the Radio button aspects and of course the FanLinc Motor speed can be unique for each Controller. Have you tried this and run into problems?

Fan speed cannot be controlled from the ISY with a single Scene.

The paper sticker has the hardware revision V1.6 and date code 5212. Devices at the same hardware revision can have different firmware levels as the firmware for that particular hardware evolves over time. As Brian has already noted the firmware level is displayed on line 2 which is v.0B

It is a change to HouseLinc, not the PLM. When HouseLinc was fee based it required a 2413xH which had support for HouseLinc license management. Now that HouseLinc is free the product has been updated to accept a standard 2413 or 2412 PLM.

The device is responding as though it was not factory reset. The response to the command that is asking for the device type is returning 00.00 which matches the ControLinc. The area in Blue is what should contain device type. The trace below is the beginning of a New INSTEON Device of an I2CS KeypadLinc that was not factory reset. Fri 05/03/2013 10:34:12 PM : [22 8b e0 ] Added to list of devices to link to ISY Fri 05/03/2013 10:34:12 PM : [iNST-TX-I1 ] 02 62 22 8B E0 0F 0D 00 Fri 05/03/2013 10:34:12 PM : [iNST-ACK ] 02 62 22.8B.E0 0F 0D 00 06 (00) Fri 05/03/2013 10:34:12 PM : [iNST-SRX ] 02 50 22.8B.E0 22.80.0B 2B 0D 02 (02) Fri 05/03/2013 10:34:12 PM : [std-Direct Ack] 22.8B.E0-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 05/03/2013 10:34:12 PM : [iNST-TX-I1 ] 02 62 22 8B E0 0F 10 00 Fri 05/03/2013 10:34:13 PM : [iNST-ACK ] 02 62 22.8B.E0 0F 10 00 06 ID-REQ (00) Fri 05/03/2013 10:34:13 PM : [iNST-SRX ] 02 50 22.8B.E0 22.80.0B 2B 10 00 ID-REQ (00) Fri 05/03/2013 10:34:13 PM : [std-Direct Ack] 22.8B.E0-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Fri 05/03/2013 10:34:13 PM : [iNST-SRX ] 02 50 22.8B.E0 01.1C.41 8B 01 00 (00) Fri 05/03/2013 10:34:13 PM : [std-Broadcast] 22.8B.E0-->01.1C.41, Max Hops=3, Hops Left=2 This is from your trace Fri 05/03/2013 10:08:49 PM : [iNST-SRX ] 02 50 22.0C.7C 00.00.35 8B 01 35 (35) I suggest trying the factory reset again. If the device returns an 02 (in Red) rather than a FF it is acting as though it has not been factory reset. If the device type information (in Blue) continues to be 00.00 I suggest opening a Ticket with UDI. I do not have access to the I2CS information for the 2441ZTH.