kclenden

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".

I don't think I understand how you wrote your program. If I code it as you indicated above, I get If 'DR-Chandelier' On Level >= 40% Then In 'DR-Chandelier' Set 'DR-Chandelier' To 100% in 6.5 seconds Else In 'DR-Chandelier' Set 'DR-Chandelier' To 40% in 6.5 seconds Not only does this not have any effect when I turn the light ON (first to 40% then with second tap to 100%), I don't see how it could fix your problem. Instead, I wrote this program If 'DR-Chandelier' is switched On Then // Must wait at least as long as Ramp Rate or ISY will get a result // before the device is fully at its set On Level Wait 8 seconds Set 'DR-Chandelier' Query Else - No Actions - (To add one, press 'Action') Now whenever the switch is tapped (either first or second time), the ISY will query the switch to determine at what percentage it is, after waiting longer than the ramp rate so that it doesn't receive a percentage from the switch before it has fully brightened.

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.

Yes. I believe it is the nature of the beast. I setup a switch exactly as you described and got the same results. So then I watched what was going on communication-wise via the Event Viewer in the Admin Console. Here's a synopsis: With Switch OFF - Tap top of switch. Light slowly comes up to 40%. In Admin Console, Status shows as 40%. In Event Viewer, I see a [DON] status received from switch which means "Device ON". With Switch at 40% - Tap top of switch. Light slowly comes up to 100%. In Admin Console, Status still shows 40%. In Event Viewer, I see a [DON] status received from switch. With Switch at 100% - Tap bottom of switch. Light slowly goes off. In Admin Console, Status shows 0%. In Event Viewer, I see a [DOF] status received from the switch which means "Device OFF" With Switch OFF - Tap top of switch. Light slowly comes up to 40%. In Admin Console, Status shows as 40%. In Event Viewer, I see a [DON] status received from switch. With Switch at 40% - Double tap top of switch. Light immediately goes to 100%. In Admin Console, Status shows 100%. In Event Viewer, I see [DFON] status received from switch which means "Device Fast ON" With Switch at 100% - Tap bottom of switch. Light slowly goes off. In Admin Console, Status shows 0%. In Event Viewer, I see a [DOF] status received from the switch. With Switch OFF - Tap top of switch. Light slowly comes up to 40%. In Admin Console, Status shows as 40%. In Event Viewer, I see a [DON] status received from switch With Switch at 40% - Press and hold top of switch until light fades up a bit. In Admin Console, Status shows 72%. In Event Viewer, I see [FDUP] and [FDSTOP] statuses received from switch which means "Device Fade Up" and "Device Fade Stop". So the issue appears to be an Insteon limitation. From the above test, it appears that when you turn ON a switch it only sends a status that says it was turned on, but not at what level. The ISY, knowing that the switch has been set to a 40% On Level, sets the status to 40% whenever it sees an DON status. I suppose they could try to be smart and monitor how many DON statuses have been received in a row from a switch, but I'm sure they had a reason for not doing that.

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

For troubleshooting purposes, it would be helpful to see a log of the communication between the ISY and the switches when you try to add them. In the Admin Console, choose Tools->Diagnostics->Event Viewer. A separate window will open. At the bottom of that window you'll see a dropdown for "Level". Click it and choose "3 Device communications events". Then click the "Clear" button to the left of the "Level". After that go through trying to add your switches. When that's done, go back to the Event Viewer window and click the "Copy to clipboard" button at the bottom (looks like a clipboard and is the left of the "Close" button. Finally paste that log into a response here. That will tell us whether the ISY is actually communicating with the switches, and if it is, what the switches are saying to it.

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. 😁

@larryllix's solution can make for a very robust system. If you're looking for something simpler and want to stay with one program, then create an integer variable (I'll call it iUsageAlertSent) and use it to filter when the notification is sent. Something like this: MBR Aux Heat On If 'Emporia / Vue 2 L / L11 MBR Furnace' Killowatts > 5.0000 kW And $iUsageAlertSent = 0 Then Set 'Notification Controller / Service Pushover polyglot' Send Sys Short With Params To all Priority=Normal Format=Monospace Sound=Pushover (default) Retry=30 Expire=60 $iUsageAlertSent = 1 Else $iUsageAlertSent = 0 This program will send one notification when the usage exceeds 5kW and won't send another until the usage drops below 5kW and then exceeds 5kW again. You want to use an integer variable and not a state variable because you don't want your program to be triggered when you change the variable value from 0 to 1 or 1 to 0. When you create the integer variable, you should set the INIT value to 0 so that whenever the ISY is restarted the variable will default to 0. If you'd rather have a time limit control when another notification can be sent, then create two programs - something like this: MBR Aux Heat On If 'Emporia / Vue 2 L / L11 MBR Furnace' Killowatts > 5.0000 kW And $iUsageAlertSent = 0 Then Set 'Notification Controller / Service Pushover polyglot' Send Sys Short With Params To all Priority=Normal Format=Monospace Sound=Pushover (default) Retry=30 Expire=60 $iUsageAlertSent = 1 Run Program 'Reset Usage Alert Sent' (Then Path) Else - No Actions - (To add one, press 'Action') Reset Usage Alert Sent If Then Wait 10 minutes iUsageAlertSent = 0 Else - No Actions - (To add one, press 'Action')

I'm actually surprised it takes 30 seconds to alternate. Your second program checks the status of the Color Christmas Tree Lights and then changes that status. If they're on, it turns them off. If they're off, it turns them on. But when you turn them on, or off, you cause the IF of the second program to execute again. So you've created a runaway program that runs the THEN, followed by the ELSE, followed by the THEN, followed by the ELSE into infinity.

I think you mean to say "are not triggered". A question and an observation: Why do you perform "$sSys.MM.DD Init To $Clock.scratch" when the program is set to run at startup anyway? Shifting the results two decimal places to the left makes it look nice except when you're comparing to a day of the month that is 10, 20, or 30. When you enter something like "1.10" into the Number field of the Condition, the ISY strips off the trailing "0" making the Then look something like this: If $sSys.MM.DD <= 1.1 Then Else Not a deal breaker, but at first glance it may not be clear whether you're checking for Jan 1st, or Jan 10th.