kclenden

Interesting. I tried to simulate what you setup with two of my 8-button keypads. I'm lazy though, so I only added two buttons from each keypad to the same scene. Here it is: Then I set about changing all of the ON levels appropriately: Next I looked at the Button Grouping: And I thought that looked similar to what you had (i.e. FR-Keypad only had FR groupings and FY-Keypad only had FY groupings), so figured things wouldn't work like they're supposed to. But they did. When I pressed FR-Keypad Button C it lit up, and FR-D, FY-C and FY-D all went out*. Likewise pressing FR-Keypad Button D made it light up, and FR-C, FY-C and FY-D all go out*. Pressing FY-Keypad Button C made it light up, and FY-D, FR-C and FR-D all go out*. Finally pressing FY-Keypad D made it light up, and FY-C, FR-C and FR-D all go out*. * when I say all the others go out, only one of them was ever lit (i.e. the last one I pressed) so in reality one went out and the others stayed OFF. The bad news is that I'm not able to replicate your results. The good news (for me) is that I'm not able to replicate your results. I'm not sure what to tell you, but I'm happy to test other things if it will help. FR-Keypad (2486D) KeypadLinc Dimmer 8 Button v.41 FY-Keypad (2486D) KeypadLinc Dimmer 8 Button v.41 I'm running firmware V.5.0.15A (been too lazy to upgrade since most of the updates seem to be for Zwave)

What version of the firmware are you running. The copy scene settings ability was removed at some point. I think it was starting with v5. As confusing as it sounds, for each scene where you want a keypad button backlight to be off, you have to set its ON level to OFF. So for each of the three controller settings that control each scene, three keypad buttons should have an ON level of ON, and six keypad buttons should have an ON level of OFF.

I'm guessing you've only set the ON levels for the what happens if you activate the scene via an ISY program. You do that by clicking the scene name in the left-hand navigation. Have you clicked on each of the nine real world controllers (3 per scene) that appear indented and in red in the left-hand navigation and set the ON levels for each device in the scene when controlled by that controller?

I believe "Reason 10" means that the Device Category and/or Sub Category aren't found in the ISY device database. If I'm reading your Event Viewer Log correctly, when the ISY sends out a Device ID command, the device returns a Category of FF, a SubCategory of FF and a version of 39. The documentation I've scratched together over the years seems to indicate the Cat and SubCat of FF means that software will assign the category and subcategory to the device. Your best course of action is probably to open a ticket with UD. If the device category and subcategory truly aren't recognized by the ISY, it could mean that Smarthome has made a change that UD is unaware of.

Changes to state variables also appear in the Event Viewer.

You shouldn't have to do anything for the program status color to change in the Admin Console. So a couple questions. In the cases where you manually run the THEN or ELSE and the program color doesn't change, does the Last Run Time change? In your six programs that check for a zone violation, the last statement of both the THEN and ELSE seems to change the value of a state variable (e.g. $S.FH.Zone.Count += 1). Could that variable be part of the IF of another program that does something to halt the zone violation program? It seems most likely that a strange interaction between your set of programs is the cause of the issues you're seeing, so you may have to post all of your programs.

Edit: After posting the response below, I decided to retry my experiment and put more time between my first tap of the switch and second tap. In the new test I waited 30 seconds between taps so that it would be clear which taps were responsible for which messages. It turns out that both the first tap, and the second tap resulted in exactly the same two messages from the switch to the ISY: 02 50 24.74.B7 00.00.01 CF 11 00 02 50 24.74.B7 11.00.01 CF 06 00 Based on this, since the ISY is seeing the same two messages from the switch after the first and second taps, there is a temporal element that the ISY would have to keep track of to know that it should treat the second tap differently than the first. I think that could get very complicated and thus why UD chose not to go down that alley. Also note that any programs that look for a SWITCHED ON from the switch will treat the first and second tap as a switched on event. I'm not sure this is actually the case. I tried one of my SwitchLinc dimmers and observed the same behavior (first tap gives correct status in AC, second tap seemingly ignored in AC. I had the Event Viewer open while I was doing this and here are the two messages the ISY received from the switch: First Tap 02 50 24.74.B7 00.00.01 CF 11 00 This can be decoded as: 02 50 - Indicates standard message received 24.74.B7 - Message originator (my dimmer switch) 00.00.01 - Message addressee (I think this a group that the ISY and all linked devices belong to) CF - Flags indicating this is a Standard Group Message with 3 retransmits remaining out of a maximum of 3 retransmits 11 - First Insteon command meaning Light ON at saved On-Level and Ramp Rate 00 - Second Insteon command which I think is not used in this case Second Tap 02 50 24.74.B7 11.00.01 CF 06 00 This can be decoded as: 02 50 - Indicates standard message received 24.74.B7 - Message originator (my dimmer switch) 11.00.01 - Message addressee (the docs I have seem to indicate that the 11 can't exist for a broadcast message and thus I don't know if the message addressee is recognized by the ISY) CF - Flags indicating this is a Standard Group Message with 3 retransmits remaining out of a maximum of 3 retransmits 06 - First Insteon command - none of the documentation I have tells me what this command is 00 - Second Insteon command - since I don't know what the 06 command is, I don't know what the second command might be So the first tap of the switch seems to result in a normal standard message from the dimmer to the ISY. The second tap sends a message the docs I have seem to indicate isn't valid, so I can certainly understand why the ISY might ignore it. Hopefully UD has better documentation than me, and it is a simple oversight on their part not to process the second message. @Michel Kohanim - do the details above help any?

Yes, the ACK is from the PLM. Both of your log sections show attempts to communicate with device 24 2B DF with absolutely no response from the device. It could be that the device has gone bad, or as @larryllix hypothesizes, it's possible the communication from the PLM is never reaching the device because a garage door opening is blocking the signal. To test that, you could always just unplug any garage door openers and try communicating with the IOLinc again.

When you purchased the new ISY, did you ask ISY to transfer any subscriptions that your old ISY had to the new one? I assume that's necessary, but having never replaced my ISY I don't know for sure.

No, your old PLM is not too old to work with the new ISY. The ISY and PLM communicate via a serial connection. So long as you have the correct cable connected between the two, they should have no problem communicating with each other. At this point, I'm not sure which problem you're trying to fix. Is it that you can open the Admin Console but can't seem to get the ISY to communicate with any of the modules? If so, I'd suggest opening the Event Viewer and set it to Level 3. Then try to control a module from the AC. Do you see communication between the ISY and PLM?

Have you tried disarming the alarm while the Admin Console is open and running the Event Viewer at level 3? That will allow you to see if any insteon commands are sent out by the PLM when the alarm is disarmed.

Like I said, I have no experience with the SynchroLincs so having a single E2 record in the Device Links Table is probably normal. An E2 record is a "controller" record which indicates the device is a controller of the device whose address is in the 3rd-5th bytes. So in this case, it controls the PLM which makes sense. When its status changes it should send a message to the PLM (i.e. control the PLM). So I don't think the Device Links Table is the problem assuming when you restored (and also readded) it the Device Links Table looks like the ISY Links Table. So it looks more and more like @larryllix nailed the problem right away.

The Device Links table looks totally wrong. Besides the fact that both rows show "Record mismatch", the data looks wrong. Where I would expect to see the address of your PLM, I see the address for the SynchroLinc, and where I would expect to see option data, I see the address of your PLM. The fact that the records seem so totally wrong could lead credence to @larryllix's theory about a possible failing power supply. Doing a restore should have gotten rid of the totally wrong records, but... The ISY Links table for the SynchroLinc doesn't look right to me either. For pretty much every device I've ever added to my ISY, both an E2 and an A2 record (i.e. two rows) have been created. I have no experience with a SynchroLinc, and have no reason to believe that the ISY Links table is wrong (other than my experience with E2 and A2 records). Having said that, if I were having this problem, I would try removing the SynchroLinc from the ISY and then readding it. However, you'd have to fix any programs and scenes it was used in after you readd it.

Listing the links in the PLM table is a looping process where the ISY asks the PLM for the next row in its Links Table over and over until the PLM says there are no more rows. If there is activity on the powerline, it can interrupt the ISY, and if that interruption is long enough, the looping between the ISY and PLM will timeout. So what you know is that your PLM has at least 426 links. You can try running the Show Links again at a time you're pretty sure the powerline should be quiet to see if you get a number higher than 426. Both the Query and the Restore of your IOLinc are showing the same thing - no response from the IOLinc. In each case, the ISY sends a command and waits for an acknowledgement from the IOLinc. When it doesn't get one, it sends the command a second time and waits. When it still doesn't get an acknowledgement it sends the command one more time, and then when it doesn't get a response it quits trying. So the question is why the IOLinc isn't replying. Weak signal? You can try moving the IOLinc closer to the PLM. Corrupted Links Table in the device? You can trying factory resetting it followed by a restore device. If none of those work, I'd try removing it from the ISY; factory resetting it; adding it back to the ISY. If you do remove it from the ISY and try adding it back, I would have the Event VIewer open at Level 3 to see what was going on. If that continues to show no response from the IOLinc when it's close to the PLM then I'd consider the IOLinc as dead.

As @Bumbershoot mentioned, that error often is a result of doing a firmware upgrade (especially from v4 to v5). What happens is that some of the commands in the earlier version don't translate to the new version so you have to open the program and minimally save it, but sometimes you actually have to make a change in the program (even if just in a comment) before you save it. Another thing that sometimes causes this error is a mismatch between the Firmware and UI versions. You can go to Help->About to see version numbers.

The PLM has a 1000 link limit. If I recall correctly, the non-Pro versions of the ISY limit nodes to something like 255, but I don't know if that includes links. You can see how many links are currently being used in the PLM by going to Tools->Diagnostics->Show PLM Links Table, and then clicking the "Start" button. You should run that a couple times as it can be interrupted by powerline activity. Here's a link to a really old forum discussion on how to estimate the number of links a system will use:

Not sure if it applies to your situation, but here's a link to a conversation in 2018 about a noisy Ezio 2x4.

Just looked at my PLM and the light is ON solid green.

I'm sure there are other reasons, but one reason is because the PLM has a limited number of links that it can hold. Every scene that a device is in counts as a link. So if you have enough devices, and use enough scenes, eventually you'll run out of links in the PLM table. Another is because a device can only be a controller for one scene. So let's say you have a motion sensor directly linked to a light. In the daylight you want the light to come on at 100%, but at night it want it to come on at 20%. The only way you can accomplish this, if you leave the motion sensor directly linked to the light, is by using Adjust Scene.

A couple thoughts. Is it possible that you've reached the limit of links for your ISY? While I can't explain why reaching the link limit would affect only the old devices and not new devices, strange things happen when you reach the link limit. In the Admin Console, goto Tools->Diagnostics->Show PLM Links Table, then click "Start". What's the highest numbered row returned? You should try running the "Show PLM Links Table" multiple times to see if you get the same number. You could also try watching what happens when you try to query and/or add one of the old non-responding devices. Goto Tools->Diagnostics->Event Viewer. Then set the Level to 3. Now try querying or controlling one of the non-responding devices. Also try adding one of the non-responding devices that you removed. The results in the Event Viewer might give you some idea what's going on. You can click "Save Log To..." and then post the results here if you want input on what the log shows.

The PLM Link Count consists of a loop whereby the ISY keeps asking for the next link in the PLM Link Table until the PLM says there are no more. Any activity on the powerline whether from the ISY or other devices may interrupt this loop. So assuming there is activity on your powerline while you're doing the count, what you're seeing is normal and I wouldn't be concerned. Try doing a count when you know there aren't any ISY programs that will run and there's a low probability that devices on the powerline might send status updates.

Indeed! Happy New Year!!!

Do you have filters on your two garage door devices? If not, it's possible that although things have worked for four years, the communication between the IOLincs and the PLM was marginal such that adding devices in other parts of the house eventually upped the noise level so that the marginal communication became no communication. @larryllix has a post somewhere on the forum that talks about his experience with garage door openers and eventual communication loss.

It's likely the ISY had the same IP address even when you weren't able to find it with the AC finder. If you move it to the farther switch, you can try opening a Command Prompt window (assuming you're using Windows) and then issuing a ping command for that IP address. If the ISY responds, then you know that the ISY can communicate on the network, and that the issue is with the network topology. To find the the ISY, the AC finder sends out a certain kind of broadcast message that some switches aren't configured to pass along. Here's a link to a discussion about this topic, though your issue is with a switch and the discussion is about a separate VLAN:

Generally moving the ISY will not cause any network issues. How are all the devices on the network connected? Do you have multiple routers or multiple switches?