kclenden

There are two link parts for every scene. The first is a record in the Links Table of the controller. That record basically tells the controller (in your case the 2477D dimmer switch) to send out a scene message whenever it is physically turned ON or OFF. The second is a record in the Links Tables off all the responders. That records tells each responder how to react (ON level and Ramp rate) whenever they see the scene message from the controller. When you restored each of the responders, you removed the record in their Links Tables that told them to respond to the scene message from the controller. The controller would still send out the scene message since you didn't restore it as well, but the responders would no longer react to the message. Since all of the responders are now again reacting to the the message from the controller, something has recreated the record in their Links Table for that scene. If it is indeed a phantom record in the Links Tables of the responders that is causing this behavior, a factory reset and restore will have the same result - temporarily breaking the link between the controller and the responders until whatever is recreating the link does its thing again. Since we can reasonably rule out you manually adding the responders to a scene using the Admin Console as the cause for the recreated links ?, is there any chance that you once used an "Adjust Scene" command in a program and later deleted the scene but forgot to update the program? If it were me, I'd try factory resetting the controller and all responders, followed by a restore of each from the ISY. Then I would open the Event Viewer, set it to level 3, and allow it to run for 24-48 hours. If during that time the link between the controller and responders comes back then you should be able to see communication in the Event Viewer that corresponds to the recreation of the links which should help narrow down what it happening.

The top external photo (Photo 1) shows an Insteon ID. It's directly below the QR code on the black portion of the switch to the right of the photo.

Your program currently turns the scene on at sunset and turns it off at sunrise the next day. That's not what you want to do. You want to change how the responder reacts at sunset and the reset how it acts at sunrise the next day. So you need to use the Adjust Scene command. Replace "Set 'motion test' On" with "In 'XXXX' Set 'YYYY' To On, Z retries" where XXXX is the controller and YYYY is responder and Z represents the number of retries - to do this you must choose "Insteon" Replace "Set 'motion test' Off" with "In 'XXXX' Set 'YYYY' To ignore" where XXXX is the controller and YYYY is responder Since you're using a mixed Zwave / Insteon scene, replacing your scene with the program that @oberkc provided should work just as well as modifying how your scene reacts based on time. The reason is that for mixed protocol scenes, the ISY has to act as a middleman anyway, so you shouldn't lose any reaction speed by using a program instead.

Click the right pointing triangle that I've circled in red:

@larryllix's warning should be taken seriously, but I don't think it should keep anyone for using a condition to disable a folder. Consider that any and every program can be stopped in an unknown state due to a power failure. So you really should have some way to gracefully recover whether you're using folder conditions to control program execution, or not. In my case, for long running programs in folders that are controlled by a condition, I use variables to know whether the program has completed. If the program hasn't completed, then I either do not allow the folder control condition (a variable) to be changed, or I allow it to be changed, but then execute cleanup programs based on the values of the variables that are used to monitor the program execution. Having said all that, the only things I'm controlling are lights, and pond pumps. So if I've screwed up and haven't correctly accounted for all cleanup conditions, the worst that happens is a light (or completely submerged pond pump) remains ON or OFF when I would rather it be in the opposite state.

To put a finer point on @larryllix's points, here are a couple things you should know: Only one instance of a particular program will ever run. So if something causes a program to restart, the old instance just ceases to exist at whatever execution point it was at when the new instance starts "Wait" statements allow a program's IF to be reevaluated. This means that if at any point during the wait, a trigger in the program's IF goes off then the current instance of the program ceases, and the IF is reevaluated and either the THEN or ELSE section will begin executing as the new instance of the program. In your program, the humidity reading is the trigger for the IF. So when it changes, the IF will be evaluated. So in your case, let's say the humidity was 70 and the THEN started to execute. It turns the light on and then enters a 10 second WAIT. If at any point during those 10 seconds the humidity changes from 70 to something else (could be 70.1 or 69.9 or anything else), then the current instance of the program will cease to exist, and a new instance will begin by evaluating the IF. Depending on the the result of evaluating the IF, either the THEN or the ELSE will begin to execute.

Here is another post where the different kind of responder links are described: I haven an Insteon Only setup. There are only two times that I see a link type of "default". The first is when a controller is listed as a responder in its own table of responders. This makes sense since there is no actual link between the controller and itself. The action that the controller executes as a responder when it is physically activated is solely defined by its own hardware and not a link that the ISY can store in the device's Links Table. The other time I see a link type of "default" is when a one-way device (e.g. a motion sensor) appears as a responder in its own or another controller's responder table. By design, all scene controllers are also defined as responders in the scene. But a one-way device like a motion sensor really can't respond to other controllers. So it seems the the ISY defines its link type as "Default". What this means is that the ISY doesn't try to create an Insteon responder link in the device's Links Table and simply leaves it to the device to perform its default action. I'm not sure any of the explanations of link types has been completely accurate. For example, @Chris Jahn consistently says that default means "Takes the command the ISY receives from the controller and forwards it on to the responder device." But I don't believe this actually happens for Insteon commands. And when you think about it, it wouldn't make sense for the ISY to do that for Insteon devices since for the ISY to have seen the command the command must have appeared on the power line (or RF which eventually gets repeated on the power line) and in that case all other Insteon devices should also have seen the command. It only makes sense for the ISY to forward a command that is crossing protocols (e.g. Insteon to Zwave, or vice versa). So all of the out loud thinking above is my way of saying that for an Insteon only installation, whenever you see a link type of "Default" you can interpret it as the ISY not being involved in any way in the communication between the controller and responder. When you see "Insteon" as a link type, it means the ISY originally defined the links between the controller and responder, but after that it is not involved in the communication between the two devices (unless it is the controller).

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.