kclenden

It might be helpful if you posted your programs as well. It's clear from the Event Viewer log that the ISY is not sending any Insteon commands at 1:59:00, 2:00:29 and 2:00:59. My guess is that the ISY thinks the device backlight is already set at the level your program specifies and thus does not send out an Insteon command - similar to how the ISY won't send an On command if it thinks the device is already on. So, for debugging purposes, you might try querying the devices first, and then sending the backlight command, though I don't know if the backlight level is returned as part of a query response. You could also try setting the backlight level to an unwanted level first, and then to the actual level you desire. If either of those things makes the process more reliable then it would seem likely that it is an issue of the ISY not sending out commands it deems unneeded to reduce powerline activity. UPDATE: Just did a little testing and the ISY does actually send an ON command even if it thinks a device is on. Not sure what I was thinking above... I'll blame it on Monday. Still, you might try the two suggestions above to see if they impact whether the ISY sends out the backlight commands.

What? Doesn't the preceding "c" make everything sort based on the "c", not the "Z"?

I often see this stated, but simply do not believe it. Why? Several reasons. First, not a single manufacturer has released their driving data for independent review. Second, even if the data supports this statement, the data that has been collected so far is for the easiest stages of driving - driving on limited access roadways. What happens when the most difficult stages of driving start impacting the data? Intersections. People. Animals. Bad weather. Musk says Teslas in autopilot are X% safer than human drivers and you believe him? So did you believe him when he said you'd be able to employ your Tesla as an autonomous taxi by the end of 2020? Did you believe him when he said five years ago that FSD would be available in a year? As someone with a BS in Computer Science, my view of when fully autonomous cars will be available clearly falls between the extremes already espoused on here. But beyond the technology, I haven't seen any discussion about non-technical obstacles that remain: Bugs or faults - Currently GM Bolt drivers aren't supposed to park their cars in their garage because of the risk of fire. Besides being really inconvenient, it also makes it really hard to charge their car overnight which makes it difficult to drive their car. They've been told to sit tight while GM works on a fix. What happens when a manufacturer discovers a bug or fault that impacts all of their models and millions of people are told they can't use their car for an extended period of time? Terrorism - What happens when the first terrorist hacks an autonomous system and tens, hundreds or thousands of people are injured or killed and millions of people are either no longer allowed, or simply won't use their autonomous vehicles? Jealous husband - see terrorism. While perhaps killing only a single spouse, the repercussions could be the same. Legal - Who is responsible for the actions of an autonomous vehicle? Passengers? Owner? Manufacturer? What happens when they turn on each other? What impact will the first class action law suit by owners against a manufacturer have on people's willingness to trust their autonomous vehicle? @Teken keeps bringing up trust as a key obstacle to adoption of autonomous vehicles and I couldn't agree more. Believe it or not, we're in the rosy part of the autonomous vehicle development stage. Wait until we hit some bumps and see how quickly people will turn on their driving overlords, and by doing so force government to step in.

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.

That's interesting, but ultimately just confuses me. If HomeSeer is just passing commands onto the ISY to execute, it really makes no sense that scenes controlled from HomeSeer would be more reliable than when controlled directly from the ISY. Hmmmm...

It's been years since I've used HomeSeer, and even then I didn't get into it really deeply. So a couple questions. Does your HomeSeer setup use a different PLM? If so, it could be that the HomeSeer PLM has a better electrical path to the troublesome device(s). It's also possible that the HomeSeer PLM sends out a stronger Insteon signal. Next question is whether you're using a HomeSeer group to control the devices. If so, I think there is a global "Send group cleanup messages" flag. If that is enabled then devices that don't initially execute a group command will execute when they receive a direct group cleanup message. Additionally, direct group cleanup messages can also configured to "retry" if they are not acknowledged. Because group (scene) cleanup messages can tie up the powerline for a while if there are a lot of responders in the group, they are given a lower priority than other insteon messages. What this means is that if a controller that is sending group cleanup messages detects another insteon command on the powerline, it will stop sending out group cleanup messages. So while group (scene) commands can be almost as reliable as direct commands if cleanup messages are enabled, if there is a lot of activity on the powerline then they fall back to basically being one-way communication from the controller to the responder without any retries.

The Nokia Smart Lighting Bridge list price is $39.99. That's half the price of the PLM or Insteon Hub Central Controller. What could they have stripped out of it to make it so inexpensive (relatively)?

There's a significant communication difference between ISY DIRECT vs SCENE commands. With DIRECT commands, the ISY uses "retries" while with SCENE commands it does not. A little bit about communication. Insteon uses "hops" so that devices can pass along commands. So if "max hops" is set to 3, devices can repeat the command up to three times. This tends to amplify the command which makes it more likely the appropriate devices will receive the command. After three repeats, however, the command is no longer repeated and if the device has not received it, the command is just lost. This is where "retries" comes in. With "retries" if there is no response to a command from a device, the controller sends the command again. As with the original attempt to send the command, it will be repeated by other devices up to "max hops" number of times. What this means is that ISY DIRECT commands have, in theory at least, a better chance at being received than SCENE commands. To make SCENE commands more reliable, there is a GROUP Cleanup message that can be sent from the controller to each responder in the scene. This would result in an ACK or NAK from each responder so that the controller knows whether to resend the original command. The ISY does not use cleanup messages when it sends SCENE commands, but I think that non-ISY scenes do.

This implies that in general, the communication channel between the ISY and the device is pretty reliable. As mentioned in a previous reply, when a SCENE ON/OFF command is sent, no status replies come back from the controlled devices. The ISY just assumes the devices executed the command. This contrasts to when a DIRECT ON/OFF command is sent from the ISY to a specific device in which case the device does respond with a status update and the ISY only updates the device status after it has received the reply from the device.

Set 'Backdoor / Backdoor KP-E Outside' On sends out a SCENE ON command. The ISY sends out a single command and all responders in that scene see the command and turn ON to the level that was previously defined. Which means the "E" button is coming on because it is a responder in the scene. When the ISY sends out a SCENE ON command, the responders do not reply with a status update. This is by design so that the powerline is not flooded with responses by what could be a very large number of devices. Since there are no replies from the responders in the scene, the ISY just assumes they all turned on and thus changes their status accordingly.

You can use the Admin Console to help troubleshoot. In the AC choose TOOLS->DIAGNOSTICS->EVENT VIEWER. In the Event Viewer change the LEVEL to "3. Device communications events". With the Event Viewer open, try switching ON and OFF the troublesome devices. After each command, look in the Event Viewer for "Std-Direct Ack]" On those lines you'll see "Max Hops=" and "Hops Left=". When a command is sent via Insteon it is allowed to be repeated a certain number of times. That is defined by "Max Hops". You can tell how many times the command was repeated before the device received it by looking at "Hops Left". If "Max Hops" and "Hops Left" are the same, it means the device heard the command the first time. If you subtract "Hops Left" from "Max Hops", that tells you how many times the command had to be repeated before the device heard the command. With this information, you can try turning other devices ON/OFF (or plugging/unplugging) and then commanding the troublesome devices to see if the average "Hops Left" changes.

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.

When devices are grouped in a scene, the ISY doesn't actually monitor them to see if they react to a scene ON or OFF command. Instead, when the ISY sees a scene command, it assumes that all devices in the scene have reacted appropriately. Since the ISY shows the button G status as ON, it means that the ISY knows that button G on that keypad is in the scene that has been command ON, and so it updates the button G status accordingly. For that reason, at some point the ISY should have created a link in that particular keypad's Links Table that corresponds to button G being a responder for that scene. Before trying @lilyoyo1's suggestions above, you might try performing a RESTORE on the subject keypad (i.e. right-click on the device and choose "Restore Device"). The ISY will rewrite the Links Table in the device which should restore any missing links that might be keeping button G from responding to certain scene commands.

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.