LeeG

It could if they were generating noise but the power cycle would be expected to fix it. Could do a factory reset followed by a Restore Device to restore the link database. I have this issue on several devices but it is related to the fact that I have an inventory of very old I1 Insteon devices which do not repeat Extended messages. Started with Insteon almost from day 1. The devices have been very reliable from those days so there has been no need to replace them. Only now when I want to add new devices which use Extended commands for many things I have comm problems because the majority of my devices are so old they know nothing about Extended commands and do not repeat them. The old devices do not block Extended commands but the lack of each device being an active repeater of Extended commands makes a big difference in Extended message reliability. The only way I know to be sure whether a device or Insteon network issue is to power the device from the PLM plug point to eliminate the network as a factor.

Any time. Hold on to your socks, the fun is just beginning. The UDI Wiki has some really good information in general. The various Program statements are covered pretty well if you want some functional information.

Just the opposite. If Control statements react to commands coming from the device. If Control 'switch' is switched Off is looking for an Off command flowing from the device which occurs when the OFF button is pressed. If Status 'switch' is Off is looking at the Current State (Status) information the ISY maintains for each node.

Sure. If Control 'switch' is switched Off And Status 'switch' is Off Then do something

The SwitchLinc is not responding to Extended commands which are used to set the Ramp Rate. Note in the trace that all the messages start with 02 62 which are outbound to the device. There are no 02 5x messages which are inbound from the device. The ISY tries three times to send the Extended message, fails to get a response each time, thus the comm error. The lack of response to Extended messages can be the device itself and it can be a problem with the Insteon Mesh network. Suggest putting the SwitchLinc on an Appliance cord (plug on one end, bare wires on the other) , plug the Appliance cord into the PLM plug point and see if the Ramp Rate can be changed. If not it is a SwitchLinc issue. If Extended commands work that way the issue is the Insteon network.

Statements such as Stop program 'Use Hot Tub - Off' stop the Program but do not change the True/False state of the Program. True/False state is based on whether the last If evaluation was True or False (which clause was run), not whether it is running or not. After stopping the Program run the Else clause to change state to False.

Save the event trace file. It will be a .txt file. I use WordPad to view .txt files. Select all the lines and Copy, then paste into forum post.

If referring to the Membership list for each node it shows what Scenes the node is assigned to and how it was assigned (Controller or Responder). This reflects what was done using the ISY. Set button links would not appear here.

A Motion based event is simple as when the Motion is sensed an action is taken. From the initial post it sounds like you want to do something when the Motion On has not been sensed for some period of time. That is not a motion based event.

In general the state/status of something has to change for it to trigger a Program. The evaluation of the IF statement, whether True or False determines which clause, Then or Else, actually runs. A static condition does not trigger a Program. A change of a variable value will trigger a Program only when using a State Variable. A change in value of an Integer variable does not trigger a Program. That is the functional difference between a State and Integer variable.

I don't know if any have been encrypted. There are several types of multi function multi button controllers the I/O Linc Relay cannot be connected to using the pair of wires between the opener and the controller. Conventional simple single button openers short the pair of wires together. This action kills the power running to multi function controllers and generally does not result in door movement. A few cases using less than .5 second Relay On time have worked but the LCD display loses the clock. A solution has been to connect the I/O Linc Relay internally where the simple Open/Close button attaches to the PCB. Another solution has been to use a simple RF remote and make the I/O Link Relay connection to the RF remote PCB where the Open/Close button attaches to the RF remote PCB. My Wayne-Dalton Controllers are all RF only which makes connection internally to the controller PCB mandatory. This has worked well for several years. The Smarthome forum has several topics that discuss how to connect the I/O Linc Relay to a PCB at the open/close button connections. Again, I don’t remember discussions about encrypted controllers but connecting the I/O Linc Relay to the open/close button connections would seem to bypass any encryption concerns.

Are your KPLs still getting out of sync? Don't worry about the questions. Smarthome just loves to change things with the magnetic switch in the I/O Linc Garage Kit being one of them. A reed switch is the part of the magnetic switch that has the wires attached. There are two pieces of metal inside a small glass tube that look like reeds which are affected by whether the magnet is next to or away from the reed part of the switch. Some reed switches are closed when the magnet is near, others are open when the magnet is near, and others have both type reeds built into the switch so either can be selected (when the kit came with a magnetic switch with three wires). The I/O Linc is one of the most complex Insteon devices you will encounter. Lots of device options and features. Each one individually is not too difficult to understand. It’s when they all come together, interacting with each other that things seem more complex than they actually are. Also do not attribute feelings to how information is phrased. I personally don't spend time dressing up a post with pleasant sounding phrases. Just a waste of time.

Okay thanks. That verified Standard length messages which are used for On/Off device control. With Hops Left=1 consistently there should be no comm message failures displayed. The setting of the Ramp Rate (Applied Locally) is likely done with Extended commands which present an additional set of challenges. Run the same Tools | Diagnostics | Event Viewer with LEVEL 3 selected. Move the Ramp Rate (Applied Locally) slider to some new position. A few Insteon messages should be traced. Move the slider to 0.1 seconds and a few more Insteon commands should be traced. Post the event trace. There will only be a few commands in the trace.

Run Tools | Diagnostics | Event Viewer at LEVEL 3. Using the Admin Console turn the SwitchLinc On and Off a few times and look at the Hops Left=x counts. A Hops Left=2 is as good as comm gets. A Hops Left=1 is okay if it is consistent. Hops Left=0 is as bad as it gets and still work. Also if Hops Left=x count is changing in value from On/Off request to On/Off request that is an indication of comm problems with the SwitchLinc location.

Did the light turn On when the Program was Disabled and Saved?

Sounds like the Motion Sensor is linked to the Insteon LED Light, with the Motion Sensor as Controller and LED Light at Responder. Mark the Program Disabled and see if the LED bulb turns On with motion.

The device types have to be the same (dimmer for dimmer, relay for relay) to use Replace xxxxx With .... function. Move the device to be Deleted outside of Folders, then right click node and select Delete.

I think the problem will be developing the characteristics of the 'ideal' solution. Some want the KPL buttons On when doors are open. Some want the KPL buttons On when the doors are closed. Some want to combine door movement and door status into a single KPL button. Some want to have door status and door movement on separate buttons. Then what hardware is being used. Is the magnetic switch NO, NC or both. Smarthome changed the type of magnetic switch shipped with the garage kit. Is a single door position being monitored or are both fully open and full closed being monitored. EDIT: another factor to consider. A Program may not be required at all. A few Scenes may be all that is necessary to get the desired KPL display and door control.

There is no DC side on my AC fans. They have different windings that control starting rotation. Same with the motors on my boat lifts. No DC component. Once 'nudged' in the desired rotation direction the running winding keeps them going.

"How can one KPL be out of sync but the other on be in sync?" 1 Communications problem 2 Link record problem either in the I/O Linc or the KeypadLinc 3 Trigger Reverse option being used which can create problems under ISY

Insteon has some automatic retry built into the protocol for some communication. However, the ISY does not automatically retry Program issued commands. Is the Program turning a Scene On/Off or a specific device On/Off?

Does not matter. Run If is the same as Run Then in this case.

If the only thing in the If section is one specific time the Waits will not be interrupted. If there are checks for temperature along with a specific time the Program will trigger each time the temp changes. The If would be False at that point and drive the Else clause. The Waits in the Then would not complete nor the statements after the Wait. Best to post the Program so the actual If can be seen.

I guess the Keypadlinc link database could be empty. Try a right click, Restore Device. I am concerned the AV like Kaspersky or Avast may be blocking the push of data from the ISY to the Admin Console so that there are actually records there but the data cannot be displayed. I think there are too many questions that are developing, I think it would be better for you to open a ticket with UDI tech support. They can remote in and resolve things better than having to iterate so many possibilities.

kaphely A UPS and other electronics should be on a FilterLinc. They are common sources of interference with Insteon signals.