I/O Link Device Missing Record on Compare of PLM and Device

[Dean]

I've just replaced my PLM and finally everything showed up without having unwritten updates, etc. However, I've noticed that my garage doors behave strangely.

When I click the button to close Garage Door 1, the door closes, but immediately after it stops, Garage Door 2 opens. I have the standard garage door setup described in the forum with the two scenes that drive the opening and closing of the doors. In looking through the forum, I saw the suggestion to compare the links in the PLM to those in the device. The screens are identical (attached image), but there are several "missing records". I am unclear what this means or how to correct. The records missing are all devices mentioned within the scenes.

A couple of other peculiar issues are that Garage Door 1 button is lit when closed, just the opposite of what it was before I replaced the PLM. I do not have the wires switched, so the button is normally on when open and off when closed. On a side note, I have a set of buttons in the Master Bedroom primarily for visual confirmation that the garage door is closed at night. The garage door 1 button seems to have always been backward, meaning on when closed and off when open.

Any help is appreciated. 

Dean

[larryllix]

Right click on the device in the admin console device tree and select "Restore".

When done try it again.

[larryllix]

@Dean If the above doesn't work try deleting the device. Factory reset the device (all devices should be factory reset when new before linking to ISY) and then link it again.

Once the links are proper, reassociate your programs with the device by selecting  the lines in the program and updating them. Click Save when done.

[Dean]

 I did think about factory reset. Then, doing a restore. What do you think about that? Or, should I just delete and start from scratch? 

[paulbates]

Just doing the restore alone will most likely address it as @larryllix suggested.

If not, then factory reset and then restore. 

Either of these won't take long to prove / disprove his suggestions

Paul

[Dean]

Thanks! Restore fixed the problem on the garage door opening when another closed. After the restore, the link tables on the i/o link matched perfectly and the switches properly controlled the garage doors.

That being said, I performed a similar process on the pesky 8 button switch in my Master Bedroom to see if that would fix the problem with the control switches showing the open/close of the garage doors. Light on when open, and off when closed. This switch has been notorious for always show garage door 1 backward (lights on when closed, off when open).

I performed a factory reset, then restored the switch. Although, I received a "cannot communicate" message during the process, it showed everything restored without any green arrows beside the switch. However, when I tried to do the Device Links Table comparison, I received the communication message shown in the first attached picture. I tried again and the process finished but showed only 3 links. Then, when I clicked compare, there were many missing links, per the second attached image. Also, why is it showing so many links for this device? I have also attached an image, showing the membership listing for the switch. 

This room has 8 or 10 kpl's, so why am I getting so many communication problems with this switch only? Should I possibly move this switch to another location in the room? Would that help?

 

 

[larryllix]

12 hours ago, Dean said:

Thanks! Restore fixed the problem on the garage door opening when another closed. After the restore, the link tables on the i/o link matched perfectly and the switches properly controlled the garage doors.

That being said, I performed a similar process on the pesky 8 button switch in my Master Bedroom to see if that would fix the problem with the control switches showing the open/close of the garage doors. Light on when open, and off when closed. This switch has been notorious for always show garage door 1 backward (lights on when closed, off when open).

I performed a factory reset, then restored the switch. Although, I received a "cannot communicate" message during the process, it showed everything restored without any green arrows beside the switch. However, when I tried to do the Device Links Table comparison, I received the communication message shown in the first attached picture. I tried again and the process finished but showed only 3 links. Then, when I clicked compare, there were many missing links, per the second attached image. Also, why is it showing so many links for this device? I have also attached an image, showing the membership listing for the switch. 

This room has 8 or 10 kpl's, so why am I getting so many communication problems with this switch only? Should I possibly move this switch to another location in the room? Would that help?

<photos snipped>

If you look at the links in the list, you see the middle three bytes with the dots between them. These are links to other Insteon devices, including your PLM.
Now, if you refer to the device summary tab in the admin console (you can sort them by clicking the chart column title) , or each individual device's page you will see the Insteon address for each device and some will  match the links displayed in the lists.
A little research using this comparison should expose why so many links are present and enable you to "prove" why they exist.

Usually each major function in a device requires a link for it to communicate with another Insteon device. Don't forget both directions for commands and statuses.

[Dean]

larryllix, thank for the advice. I do see where these addresses are linked, etc. It's an 8 button control, so a button can control a scene that another button also controls, therefore, the link. Also, there is one address in the links table that does not exist any longer in my system, but only one address. The others are related.

What is the best way to fix this switch to reconnect, since the PLM also shows these as missing? Should I remove it from the various scenes, factory reset and then add it back to the various scenes?

[larryllix]

53 minutes ago, Dean said:

larryllix, thank for the advice. I do see where these addresses are linked, etc. It's an 8 button control, so a button can control a scene that another button also controls, therefore, the link. Also, there is one address in the links table that does not exist any longer in my system, but only one address. The others are related.

What is the best way to fix this switch to reconnect, since the PLM also shows these as missing? Should I remove it from the various scenes, factory reset and then add it back to the various scenes?

Sorry. I really don't know enough about links to advise you further on that one.   I was never that familiar with the codes displayed in the events.

I try to avoid Insteon scenes as much as possible. I only use them where necessary for speed or significant reduction of program size (all on/off) where resultant success is not paramount. In addition I only have one KPL and I find them a disaster for clarity of operation.

Anybody else jump in here?

[Dean]

52 minutes ago, larryllix said:

Sorry. I really don't know enough about links to advise you further on that one.   I was never that familiar with the codes displayed in the events.

I try to avoid Insteon scenes as much as possible. I only use them where necessary for speed or significant reduction of program size (all on/off) where resultant success is not paramount. In addition I only have one KPL and I find them a disaster for clarity of operation.

Anybody else jump in here?

Not to go off topic, but which is faster and/or most efficient, a scene or a program?

[larryllix]

47 minutes ago, Dean said:

Not to go off topic, but which is faster and/or most efficient, a scene or a program?

I use a Insteon scenes for MS to single lights, where On response speed is important for the human. Off timing is done with ISY programs and conditional control. Where a human operation is required  (SwitchLinc)  the ISY program / comm time delay is inconsequential.

I use scenes for whole house operations, like security flashing every light in the house. It reduces the Insteon comm traffic to every device involved,  where the flash would end up being too slow with so many ACKs and hops of the Insteon signals. If a few devices did not respond it would be inconsequential to the application.

The control, visibility, extra security of signal, and maintainability of ISY programs offered by ISY programs, is preferred for everything IMHO. I find Insteon Scenes very obscure and harder to troubleshoot when you do have problems. 

Remember....ISY programs are not slow. Insteon signal protocols are the bottleneck. 
An initiator sends out a signal (battery devices usually  send 3-4 repeat signals). Then every device simultaneously repeats these signals  three Hops to extend range. Then the PLM will acknowledge ACK or NAK, three hops will ensue again, while every device waits. This can be repeated if a NAK or nothing is reported. Now ISY processes and the same thing happens in reverse operating the device from ISY. Insteon is a very polite protocol and devices wait for everybody else to be done. The time adds up.

Scenes just blast out a scene code and assume everybody behaves. Then there is a follow up protocol  where each device reports status. after the desired device responses. (don't quote me).

Insteon RF signals must stay in synch with the powerline signals so it is no faster.

 

Insteon Scenes are like jumping back into the 1980s using X10 protocol IMHO.

 

So, efficiency is relative to what you want....response speed, response security, program writing, etc.. etc..

[Dean]

Just to update the status on the issues. I completely deleted the 8 button switch from both scenes. I did a factory reset, then added the switch, etc. back to the scenes. For a little while, the switch behaved normally. Then, after a few days, it has resorted back to the first garage door lights being on, when the door was closed. The other controller switch in a different location has always worked perfectly. Then, after another few days, both garage door 1 and garage door 2 showed up lights on when closed on that 8 button switch, with the other controller switch still working perfectly. 

I have only used these switches for visual, so I guess I'll just get used to them being on when the door is closed.

[larryllix]

16 minutes ago, Dean said:

Just to update the status on the issues. I completely deleted the 8 button switch from both scenes. I did a factory reset, then added the switch, etc. back to the scenes. For a little while, the switch behaved normally. Then, after a few days, it has resorted back to the first garage door lights being on, when the door was closed. The other controller switch in a different location has always worked perfectly. Then, after another few days, both garage door 1 and garage door 2 showed up lights on when closed on that 8 button switch, with the other controller switch still working perfectly. 

I have only used these switches for visual, so I guess I'll just get used to them being on when the door is closed.

Nice one!

I have one KPL led doing the same thing but it is never seen.

I also have a MiLight RGBW bulb that slowly flashes red when the garage door is open, and it works like a charm. It has saved our garage door open many times now, avoiding a friendly skunk sleeping in the next door neighbours garage, they kicked, as well as a few raccoons that are particularly hard to get out and rip your garbage up everywhere.

[mwester]

I hate that.  What's the point of an indicator that you can't really trust?  Might as well have a random number generator turn the LED on and off...

My garage door and shed door have two and three indicators, respectively.  The indicators are correct in that they light up when the door is open, and correct in that they always reflect the true status of the doors -- and it took some work to get them that way.  Here's the basics of how I tackled the problem:

First, if you bought the Not-So-Smarthome garage door kits, then keep the IOLinc but toss the switch they provided into the nearest trash can.  Buy the correct switch so that you do not have to use the oh-so-bugridden "reverse-sensor" option.  Until you do that, you'll never be able to trust the status as known to the ISY (it will change at 3:01 AM or thereabouts when the nightly ISY query runs).

Next, set up all the buttons and corresponding IOLinc for each door in the normal manner -- use scenes for this.  How to do this is documented all over the forum, and I'll not attempt to repeat those instructions here.

Now, you need to handle the exceptions -- the door may have reversed due to an obstruction, or the signal may have been missed due to noise, or whatever -- but regardless of what went wrong, the door and the button don't match each other.  This is infuriating, and the incredible perverse power of Murphy's Law dictates that you will NEVER solve this by measures such as improving the signal to the IOLinc, etc.  Something will ALWAYS happen to break it, even if it's a 1 in a million fluke, right at the most inopportune moment.  Such is the power of "Murphics" (Murphics, of course, is the science behind Murphy's Law, and once we understand this as well as we understand Physics today, well, the next big wave of technology will arrive... but I digress.)  So, to handle the exceptions, add a program.  Or two.  Basically, when the door operates, if all goes well, the buttons will correctly reflect the status.  But, when the door operates (i.e. sensor changes state) or when a button is pushed (i.e. button sends an "on" or "off" signal), I start a program.  That program waits long enough for the door to close, then it queries the sensor -- and updates the buttons to reflect the state of the sensor.  It does this again 10 seconds later, and once again 10 seconds after that.  At that point, my confidence that the buttons reflect reality is pretty high.

Finally, considering the power of Murphics, I added a z-wave tilt sensor to the main garage door.  It has its own set of programs, and serves as the backup for the IOLinc.  The result is that I'm as confident as I can be that my garage door is closed for the night when I glance at the KPL in the bedroom hallway at night.

Don't give up and accept "maybe" as a good status from your garage door sensor, it's not that hard to make sure!

[Dean]

Thanks mwester, very good explanation! I'll work on this. I did buy the Smarthome garage door kit. So, what switch do I need to buy to replace the one that came in the kit?

[larryllix]

I used the kit just the way it came and I don't have any of those problems. I wrote my own programs in ISY and don't use the ioLink status reversal flaw option.

I have never studied the supplied programs suggestion but it seems to me, somebody needs to save the masses and forum a lot of time and aggravation and delete those problematic programs.