kclenden

That is interesting. The Device's Links Table indeed does not have the scene link that would include the PLM which explains why you're not getting status updates from the device. But the ISY Links Table for the device (your second screenshot) does. So that seems to indicate that at some point the ISY tried to, and maybe did, create the correct links in the Device. Would you try right-clicking the device and choosing "Restore Device"? If that is successful, then you should start receiving status updates from the device.

Would you post the device's Links Table? Right-click on the device choose Diagnostics->Show Device Links Table.

I suspect you've hit the nail on the head here. My guess is that since the ISY/eISY sees it as an unsupported device, it is not creating the appropriate links in the device so that it is a controller for a scene that includes the PLM. Thus the I3 device may well be acting like any other Insteon device, and the ISY does not get status updates only because the ISY did not setup the appropriate links.

Those are all commands that were initiated from the Admin Console. So I misunderstood your initial testing. I thought you were indicating that the Admin Console did not change the "Status" when you faded UP or DOWN from the device. The actions shown in your log do actually result in expected behavior. From the Admin Console, there are "Fade Up" and "Fade Down" buttons that start the action. The action continues until you click the "Fade Stop" button at which point the device stops the action and reports its illumination level. Your log only shows a fade DOWN followed by a fade UP, with no fade STOP in between. If I had known you were doing the fade from the Admin Console, I'd have asked you to put a fade STOP in between. Edit: Actually, after looking at the Insteon Command documentation for Fade STOP, it doesn't look like the device reports its illumination level after receiving the command. So I'm left assuming that the ISY/eISY is only estimating the illumination level based on the amount of time between the fade DOWN or UP command and the fade STOP command. Some testing seems to confirm this as the level reported by the Admin Console after a fade STOP is usually close, but not always the same as the level that is reported when a QUERY is done after a STOP.

Would you capture a log of communication, using the Event Viewer on Level 3, when you do an ON followed by a Fade Down, followed by a Fade Up, and finally an OFF, and then post it here?

How do you know it's running? You haven't posted the actual programs that you're using, and the pseudo-code you've provided has been inconsistent. First you say the program sets a light ON, then you say it enables another program. In any case, you should first be sure that the program you suspect is running is indeed running. Click the "Programs" tab, and then below it click the "Summary" tab. Find the suspect program in the table and look at the "Status" column. If it says "False" then it last ran the ELSE section. If it says "True" then it last ran the THEN section. Now look in the "Last Run Time" column. What time does it show? Do you ever see the "Status" as "True" with the "Last Run Time" showing a time between 5:30pm and 5:30am?

I know you know this, but just for clarity, that should read more like "Anytime the status of a trigger in the IF statement changes, the IF will be reevaluated." In the OP's first post, the program has a trigger (the status of the switch) and a filter ($Int_MotionGolf - if it's actually created as an INTEGER variable and not a STATE variable).

Again, none of my devices are in folders so I've never run into this. While the device you circled seems to be in the main folder, other devices in the scene appear to be in folders. I don't know whether that matters, but given the warning about the device not being in a folder, it wouldn't surprise me if that also goes for other devices in scenes with the device being replaced. What happens when you replace a device is that the ISY/Polisy/eISY goes through all the links in the PLM Links table and all the links in each device Links table and replaces the old device's address with the new device's address. If being in a folder affects the device being replaced, I'm not sure why it wouldn't affect any other device having its Links table update. This would seem to matchup with your experience whereby after replacing the device you can control it, but it doesn't seem to have any connection to other devices in the scene. Or it may be, as you sorta touched on, that the problem is the scenes being in a folder. I don't know, but just wanted to add to the conversation in case it sparked something from the memories of other longtime forum members. Probably too late now, but it would be interesting to have a copy of the PLM Links table, and the Links table from several of the devices in the scene both before and after the device was replaced. That would allow us to tell exactly what is, and isn't happening. Just as importantly, if you were to submit a bug report to UD, it would be very helpful to them, I think. Edit: Actually, on second look, maybe the device you circled is in a folder called "Main". On my ISY, devices that aren't in a folder have nothing in the folder column.

It appears from your screenshot that the device being replaced is in a folder. I have read in other posts that you cannot replace a device if it's in a folder, but haven't actually tried it myself.

The hex values represent the device Category and Sub Category. The best source I've found for translating a Category/Sub Category to an actual device is http://madreporite.com/insteon/Insteon_device_list.htm, though the way it's shown on that page still doesn't make it easy. You'd really need to consolidate the information from the four tabs of the table on that page and then sort by Product ID before it'll really be useful to you. If you find yourself adding another device, and curiosity gets the better of you, start the Event Viewer (Tools->Diagnostics-Event Viewer) and set it to Level "3. Device communications events" before attempting the automatic device add. Providing the log from that session may help determine why it doesn't work for you.

As others have suggested, perhaps different firmware versions. It's also possible that there is still a physical problem with the devices and they're just reporting it as "No load detected". In the docs that I have, there are only three possible error codes that can be returned via a NAK, so perhaps it's some other problem for which an error code was never created. Have you tried plugging in a load and then commanding them ON to see if their status changes? I'm also curious what happens if you command the device ON from the Admin Console and then follow that up with a manual query of the device. Does the status change to reflect the ON status?

That log indicates your device is communicating with the ISY just fine. Here's what each line means: First Line says that the ISY sent an "On at 100%" message to the PLM that is intended for device 01.05.19. Second line says that the PLM received the message and passed it on to device 01.05.19 Third line is a NAK response from device 01.05.19 to device 52.64.60 (presumably your PLM) that says the message was received but that the device encountered an error. If no error had been encountered, the response would have been an ACK. The last byte (FE) in the response from device 01.05.19 indicates the error that the device encountered. FE stands for "No load detected". So your ISY (via the PLM) is having a successful two-way communication with your device. The ISY does not change the status of the device because it receives a NAK instead of an ACK from the device. The device sends a NAK because it cannot detect a load.

So you command them ON and/or OFF from the Admin Console, and they go On and/or Off, but their status does not change in the Admin Console? This would imply one-way communication, but not two-way. I suppose that could happen, but it seems like an unusual failure mode, especially for two devices to fail in the same way. Have you watched communication between the devices using the Admin Console Event Viewer (Tools->Diagnostics->Event Viewer)? Set the Level to "3. Device communications events".

You'll also want to look for instances where you see an [INST-TX-I1] in the Event Viewer, but don't immediately see a following [INST-ACK] with the command echoed back with an "06" appended. In these instances, the device shouldn't have reacted to your command from the Admin Console because the PLM never received the command from the ISY to send onto the device. While I really suspect your PLM, I suppose you might try disconnecting the cable between the PLM and the ISY (looks like a network cable but isn't) and reconnecting it just in case it is somehow loose.

There are PLM repair services available online. I think Insteon itself even offers this service. That would be much cheaper than replacing your entire setup. 🙂 Additionally, the last I heard new PLMs were slated to be available by March, I think. Though there will probably be a run on them right off the bat since they've been unavailable for so long.

Everything in the first log segment looks normal. "Hops Left" is either 3 or 2 which seems to indicate good communication between PLM and Device. Here's an interpretation of the log segment so you have an idea of what things mean: Thu 01/19/2023 14:18:08 : [INST-TX-I1 ] 02 62 57 65 64 0F 11 4D 02 = Start of Command 62 = Send Message 57 65 64 = Address of Device the Message is being sent to OF = Message Flags (OF means Direct Standard Message, Hops Left=3, Max Hops=3) 11 = Command for Device to Execute (11 means GO ON) 4D = LEVEL (Level is in HEX 00-FF so 4D/FF which is 77/256 is 30%) Thu 01/19/2023 14:18:08 : [INST-ACK ] 02 62 57.65.64 0F 11 4D 06 LTONRR (4D) PLM echos back to ISY the command and appends 06 to indicate that the message was successfully sent Thu 01/19/2023 14:18:08 : [INST-SRX ] 02 50 57.65.64 40.53.13 2F 11 4D LTONRR (4D) 02 = Start of Command 50 = Message Received 57 65 64 = Address of Device the Message is from 40 53 13 = Address of Device the Message is being sent 2F = Message Flags (2F means ACK Direct Message, Hops Left=3, Max Hops=3) 11 = Command for Device to Execute (11 means GO ON) 4D = LEVEL (Level is in HEX 00-FF so 4D/FF which is 77/256 is 30%) Thu 01/19/2023 14:18:08 : [Std-Direct Ack] 57.65.64-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Thu 01/19/2023 14:18:08 : [D2D EVENT ] Event [57 65 64 1] [ST] [77] uom=100 prec=0 Thu 01/19/2023 14:18:08 : [ 57 65 64 1] ST 77 (uom=100 prec=0) Shows ISY interpretaton of received message ---------- Thu 01/19/2023 14:18:15 : [INST-TX-I1 ] 02 62 57 65 64 0F 13 00 02 = Start of Command 62 = Send Message 57.65.64 = Address of Device the Message is being sent to OF = Message Flags (OF means Direct Standard Message, Hops Left=3, Max Hops=3) 13 = Command for Device to Execute (13 means GO OFF) 00 = Means nothing just default for command 13 Thu 01/19/2023 14:18:15 : [INST-ACK ] 02 62 57.65.64 0F 13 00 06 LTOFFRR(00) PLM echos back to ISY the command and appends 06 to indicate that the message was successfully sent Thu 01/19/2023 14:18:16 : [INST-SRX ] 02 50 57.65.64 40.53.13 2B 13 00 LTOFFRR(00) 02 = Start of Command 50 = Message Received 57 65 64 = Address of Device the Message is from 40 53 13 = Address of Device the Message is being sent 2B = Message Flags (2B means ACK Direct Message, Hops Left=2, Max Hops=3) 13 = Command for Device to Execute (13 means GO OFF) 00 = Means nothing just default for command 13 Thu 01/19/2023 14:18:16 : [Std-Direct Ack] 57.65.64-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 01/19/2023 14:18:16 : [D2D EVENT ] Event [57 65 64 1] [ST] [0] uom=100 prec=0 Thu 01/19/2023 14:18:16 : [ 57 65 64 1] ST 0 (uom=100 prec=0) Shows ISY interpretaton of received message For the second log segment. I didn't break out the meaning of each log line since they could be interpreted using the same method as above. "Hops Left" is always 2. This indicates good communication between PLM and Device, but the fact that it's always 2 could mean that the device is always depending on another device to relay its messages, or could just be a function of limited data. If it's the former, it could be a Device that is on a different power leg than the PLM, or an RF only device that is out of RF range of the PLM and needs a power line device to receive its message and forward it. Here are some comments on things that look strange. I also ignored the first four lines since they seemed to be two different commands colliding in time: Thu 01/19/2023 14:28:22 : [INST-TX-I1 ] 02 62 54 A0 07 0F 13 00 It doesn't appear that the ISY received an acknowledgement from the PLM ---------- Thu 01/19/2023 14:28:35 : [INST-TX-I1 ] 02 62 54 A0 07 0F 13 00 Thu 01/19/2023 14:28:35 : [INST-ACK ] 02 62 54.A0.07 0F 13 00 06 LTOFFRR(00) Thu 01/19/2023 14:28:37 : [INST-SRX ] 02 50 54.A0.07 40.53.13 2B 13 00 LTOFFRR(00) Thu 01/19/2023 14:28:37 : [Std-Direct Ack] 54.A0.07-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 01/19/2023 14:28:37 : [D2D EVENT ] Event [54 A0 7 1] [ST] [0] uom=100 prec=0 Thu 01/19/2023 14:28:37 : [ 54 A0 7 1] ST 0 (uom=100 prec=0) Log indicates OFF was successful ---------- Thu 01/19/2023 14:29:09 : [INST-TX-I1 ] 02 62 54 A0 07 0F 11 FF It doesn't appear that the ISY received an acknowledgement from the PLM ---------- Thu 01/19/2023 14:29:24 : [INST-TX-I1 ] 02 62 54 A0 07 0F 11 FF Thu 01/19/2023 14:29:25 : [INST-ACK ] 02 62 54.A0.07 11 FF 00 02 62 54 A0 07 0F 11 FF 06 02 50 54 A0 07 40 (00) The PLM's acknowledgement back to the ISY seems to be corrupted. It seems to be a partial acknowledgement, a full acknowledgement, and a partial received message all crammed together. Thu 01/19/2023 14:29:29 : [D2D EVENT ] Event [54 A0 7 1] [ERR] [1] uom=0 prec=-1 Thu 01/19/2023 14:29:29 : [ 54 A0 7 1] ERR 1 The ISY recognizes the acknowledgement as an error ---------- Thu 01/19/2023 14:29:37 : [INST-TX-I1 ] 02 62 54 A0 07 0F 12 00 Like above, it doesn't appear that the ISY received an acknowledgement from the PLM ---------- Thu 01/19/2023 14:29:50 : [INST-TX-I1 ] 02 62 54 A0 07 0F 12 00 Command 12 is a Fast ON Thu 01/19/2023 14:29:50 : [INST-ACK ] 02 62 54.A0.07 0F 12 00 06 LTON-F (00) Correct acknowledgement from the PLM Thu 01/19/2023 14:29:50 : [INST-SRX ] 02 50 54.A0.07 40.53.13 2B 12 00 LTON-F (00) Thu 01/19/2023 14:29:50 : [Std-Direct Ack] 54.A0.07-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 01/19/2023 14:29:50 : [D2D EVENT ] Event [54 A0 7 1] [ERR] [0] uom=0 prec=-1 Thu 01/19/2023 14:29:50 : [ 54 A0 7 1] ERR 0 Thu 01/19/2023 14:29:50 : [D2D EVENT ] Event [54 A0 7 1] [ST] [255] uom=100 prec=0 Thu 01/19/2023 14:29:50 : [ 54 A0 7 1] ST 255 (uom=100 prec=0) Log seems to indicate Fast ON was successful. Not sure what ERR 0 means. ---------- Thu 01/19/2023 14:29:57 : [INST-TX-I1 ] 02 62 54 A0 07 0F 14 00 Command 14 is a Fast OFF Thu 01/19/2023 14:29:57 : [INST-ACK ] 02 62 54.A0.07 0F 14 00 06 LTOFF-F(00) Thu 01/19/2023 14:29:58 : [INST-SRX ] 02 50 54.A0.07 40.53.13 2B 14 00 LTOFF-F(00) Thu 01/19/2023 14:29:58 : [Std-Direct Ack] 54.A0.07-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 01/19/2023 14:29:58 : [D2D EVENT ] Event [54 A0 7 1] [ST] [0] uom=100 prec=0 Thu 01/19/2023 14:29:58 : [ 54 A0 7 1] ST 0 (uom=100 prec=0) Log indicates Fast OFF was successful Given that there are log entries that seem to indicate the PLM didn't acknowledge messages from the ISY, and log entries that seem to indicate the PLM sent corrupted data to the ISY, my guess is that your PLM is failing. I suppose it could also be that the RS232 port on the ISY is failing, but I've never read of that happening.

Here are some things you can try: In the Admin Console start the Event Viewer (Tools->Diagnostics->Event Viewer). Set the Level to "3. Device communication events". Now try commanding devices from the Admin Console. Look in the Event Viewer log for "Std-Direct-Ack" lines. This is an acknowledgement from the device to the ISY (via the PLM). Note the "Max Hops" and "Hops Left" values. The higher the "Hops Left" value the better. It's a measure of how many times a message was repeated by another device as it traversed from the sending device to the receiving device (each repeat causing hops left to go down one). The more times a message has to be repeated, the harder the network it working to get the message to its intended destination which generally means there is some interference on the line. Try connecting a device to the same circuit as the PLM and repeat #1. You should see "Max Hops" and "Hops Left" always being equal. Some people wire switches to a three-prong plug and put the PLM and switch on the same power strip. Shutoff all circuit breakers but the one for the PLM. Turn on a single circuit breaker for another device. Try commanding that device as in #1 above. If communication is good, then turn on another circuit breaker. Test and repeat until turning on a circuit breaker significantly degrades communication

So I followed my own suggestion and submitted a message via the Insteon contact form saying that I was excited about the new products but could only buy them if they were supported by the Universal Devices ISY and thus I hoped that Insteon would fully support third-party controllers. Within 24 hours, I received the following reply: I'm not sure that Ken's reply really means that he thinks that the ISY will support the new products, or just more generally Universal Devices. While I hope the ISY supports them, it wouldn't be the end of the world if I had to upgrade to an eisy.

My sentiments exactly. Perhaps each of us should send that message to Insteon via their contact form: https://www.insteon.com/contact-us

Yeah, but the Nokia stuff was never released, so it seems new to me. 🙂

According to a post on the Insteon Users Group page on Facebook, there are new Insteon products on the horizon! "Isaac Sanz announces new products "redesigned inside and out". This will be the "i3" range with new hardware and firmware. Insteon i3 Dial is a rotary lighting control - tap button to turn on/off, rotate for brightness. i3 Outlet - tamper-resistant, dual-control outlets, 15A capacity. Product pages at insteon.com soon."

How are you trying to add the devices? If you're manually entering device addresses, make sure you're not misreading digits (8 and B, 0 and D are often confused). If you're trying to have have the ISY find the device, then try factory resetting the device (per the manual), then choose Start Linking on the ISY and then press and hold set button on the device for three seconds.

My time choices are always grayed out like that but I am able to make selections by clicking them. Have you tried shutting down your Admin Console and then restarting it?

I see that aartech.ca now has some Insteon products in stock (switches, 6-button keypad, hub). Looks like Canada gets to rejoin the party. 😄

Yeah, that's what happens when I try to program on the fly without testing. Many a prof in college used to notice the same kind of thing. 😁