kclenden

Behind the scenes of a program, a device is referred to by number, but that number is not the address of the device. Instead it appears to be a sequential number that is incremented as devices are added to the system. So even if the ISY doesn't automatically remove any lines referring to a deleted device from all programs when the device is removed from the ISY, it would probably be just luck if after readding the device to the ISY it was assigned the same sequential number. I certainly wouldn't depend on it if it were me.

When you refer to looking at the link table for your devices, are you using "Show Device Links Table"? If so then you should have to be putting the battery powered devices into communication mode by holding the "Set" button down for about 5 seconds. After viewing the link table for one of your battery powered devices you should click the "Compare" button. That will compare it to what the ISY thinks should be in the device links table. If the comparison indicates the tables are identical, when you know the new PLM address isn't in the device links table, then you know that the ISY version of the device links table also doesn't have the new PLM address, and if that's the case no amount of "Restore Device" will fix things.

I think @ronvond probably identified the problem. Your results are consistent with a battery powered device that hasn't had its Links Table updated after a PLM has been replaced. The motion sensor can control a scene because the scene ID has not changed so the motion sensor Links Table has the correct information about the scene. The motion sensor is not updating the ISY when it triggers because the PLM address has changed, but the motion sensor Links Table has the old PLM address. When you look at your motion sensor in the device list of the Admin Console does it have a "1011" icon next to it? If so, that means the ISY is waiting to write updates to the device.

It acts exactly like a status condition. When it changes from FALSE (time not between) to TRUE (time between) it triggers the IF to be evaluated. Likewise when it changes from TRUE (time between) to FALSE (time not between) it triggers the IF to be evaluated. And at all times it will either be TRUE or FALSE depending on the time.

When they are evaluated, ISY IF statements function just like IF statements in other languages. If they evaluate TRUE then the THEN section is run. If they evaluate FALSE then the ELSE section is run. Where the confusion begins is in understanding what causes the ISY IF statement to be evaluated. ISY programming is event based. What that means is that IF statements are only evaluated when certain events happen. Those events can include you right-clicking on the program and selecting "Run IF", a statement in a program that runs the IF of another program, an event that is included within the IF occurs, and more. When you use "From sunset to sunrise (next day)", there are two events included within the IF (sunset and sunrise). The only times you're guaranteed that program will run is a sunrise, when it will evaluate TRUE, and sunset(next day), when it will evaluate FALSE. If you want it to run at any other time, without you manually running it, you'll need to add another event to the IF. What are other events? Well usually they are devices doing something and informing the ISY. So, for example, when your light switch is turned OFF, it sends a message to the ISY telling it that it has been turned OFF. The ISY interprets that as an event. So you could add "Light is switched OFF" to your IF and now the IF will be evaluated whenever the light is turned OFF. Whenever you create a new program that has statements in the IF, you need to evaluate the IF two ways: First, will the IF correctly evaluate to TRUE or FALSE when it is evaluated Second, have the appropriate events been included in the IF so that the IF will be evaluated at the correct times

First question is whether $pumpAlwaysOn is an Integer or State variable. It needs to be a State variable. If it's not a State variable then the only time the THEN of "Coop Pump - Winter (Warm)" will ever possibly run is at 7AM, and it will only run then if $pumpAlwaysOn = 0. And running that THEN is the only way the pump will be shutoff once it has been turned on by "Coop Pump - Winter v2".

That seems unlikely. A core function of any Insteon device is to read and execute the instructions within its Links Table. Is it possible that something else is overriding the link (i.e. it goes off but then something else turns it on)? The two keypads are linked to each other. They should execute without the ISY's help. Have you tried unplugging the ISY and testing your keypads? That would insure that the results you're seeing truly are being caused by the devices themselves.

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?

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.