Need a Record Mismatch/Repair Automated Task

[grtaylor]

I find over time I end up with mismatched records in my devices. Not sure why, but I know the process for repairing these is a pain. I have to get all the records from the device, compare, then restore the device, then compare again... and with a lot of devices, that's a pain.

 

I'd like my ISY to do a nightly trawl of devices, perhaps during a configurable time period, with it picking up where it left off last time round, and finding and fixing records for me (and telling me when it did so), so I know the devices match what I have in ISY, and so I don't have to do this myself.

 

That would be a lovely Christmas present.

 

Thanks.

 

Greg

[SteveL]

grtaylor,

 

I think the question to ask is why you are getting record mismatches in the first place. Are you manually linking devices outside the ISY?

 

Do you have devices that regularly establish new links on their own. Are you then finding those links by checking your devices link everyday or do you find a device turning on by itself and you read the links to see what caused it? Either way I would be happy to provide you that Christmas present by helping you get to the bottom of that. I don't suspect this is happening to most users without some outside influences.

 

I can be contacted at support@universal-devices.com

[johnnyt]

Roughly twice a year I check some devices - all my KPLs plus a select few others - and usually find record mismatches that I then fix with a device restore. Quite slow with 70-80+ link KPLs. I haven't been able to figure out what causes it. It's been happening for at least a couple years.

 

I've never added/linked devices outside ISY.

 

Sent from my iPad using Tapatalk

[arw01]

Is it these ones routinely?

 

Sent from my Sony Tablet S using Tapatalk

[grtaylor]

Thanks for the replies. I do not add any devices outside of ISY, but I still end up with random record mismatches somehow. I have some older 6 and 8 button key pads with 150+ links in them, and getting a link record mismatch in one of them is a pain, as the restore of the device takes a long time, and does take a few attempts sometimes. I'm sure I have some flakiness in my network comms which is the reason some devices take a few attempts to restore, so maybe that's the reason for the bad links, I don't know. The record mismatches though are across a variety of devices, and just seem to happen all on their own.

 

Devices don't appear to show new links Steve, the link count is correct, I just do a check and find some records are shown as mismatched.

[Michel Kohanim]

Hi grtaylor,

 

Do you have any green 1011 icons next to any of your devices?

 

With kind regards,

Michel

[grtaylor]

sometimes that's possible, but it's not the only case. I see record mismatches regardless of those devices.

[LeeG]

The next time you find a mismatch without the 1011 Icons post the Show Device Links Table with Compare results showing mismatch(s).  

[bdyster]

+1 to this request.  Have >100 devices and see similar issues with periodically getting records mismatch.   Just had a PLM die and replaced with new V2.0 and did the RestorePLM and updated ALL devices.  Decided to spot check a few devices for mismatches and found that probably ~25% of the sampled devices had mismatches.  So I have started going through each device one by one - as grtaylor mentions, very painful with large device count and potentially large number of links per device (especially with KPL or IRR).  I have NEVER manually linked a device and have only used this specific ISY to program devices.  No devices found with record mismatch have the "1011" Icon indicating update pending.  Interestingly, so far it seems like the records mismatches are all toward END of the list of links AND not on links associated with the new PLM address.   So it appears the PLM restore to swap out new PLM worked pretty well but these bad links were created over time.  

 

How I think this is happening:  For one of my 2476S SwitchRelay, device only had a few links and it STILL took 3 tries before it restored correctly (never seen restore go so badly before).   First restore failed to fix the bad link, 2nd restore  fixed the bad link, but broke the next entry, 3rd time worked.   I never saw any errors reported during any of the restore iterations, so as far as ISY concerned, each time it seems to have thought the restore happened correctly.    Using an ISY994/IR Pro w/ v.4.2.30  that was rebooted yesterday when swapping out PLM.  

 

Actually also modify/expand this request:  When comparing a device links and finding mismatch, could that just create modify list of individual entries to update for the device rather than restoring the entire device? When finding record mismatch, would like to then have option to either manually or automatically stage the update device "1011" icon.  

 

I have found that restoring a device with LOTS of links (like a KPL) is often problematic - due to rewriting every link and more opportunities for bit errors.  I only really want to rewrite the specific mismatch.  Also, when restoring KPL I often find that it take several tries to fully restore and compare.   (sometimes get "cannot communicate with device" somewhere in the middle of operation).

 

I would think that with >100 devices on my network, most are dual-bank, pretty evenly spread across both phases of my home and every room in the home (every switch/fan/etc is insteon),  I really shouldn't be having any issues with flaky  communication issues.  I also generally do most of my ISY programming either early in morning or late at night when everyone else is in bed so there shouldn't be any spurious communication traffic from kids switching on lights (only chance I have to find time to play with my HomeAuto.).  

[johnnyt]

This is now a quarterly maintenance activity for me that usually requires a restore of at least one KPL each time. It sure would be nice if I could automate this maintenance to occur during quiet time, with some sort of notification of success or failure and perhaps the ability to retry at least once on failure. It would need to be on per device basis and limited to one device at a time. I would rotate through my devices at a rate of one per night or maybe per week.

[Teken]

This is now a quarterly maintenance activity for me that usually requires a restore of at least one KPL each time. It sure would be nice if I could automate this maintenance to occur during quiet time, with some sort of notification of success or failure and perhaps the ability to retry at least once on failure. It would need to be on per device basis and limited to one device at a time. I would rotate through my devices at a rate of one per night or maybe per week.

 

The way you describe the use case is exactly how I envision it being used in my environment. Most excellent idea and hope this makes it on the road map once 5.XX is released into the wild.

[Michel Kohanim]

Hi bdyster,

 

In PRO series you can disable auto write (button with 1011 icon) and then do each one manually.

 

Unfortunately it's not possible to just fix the mismatch.

 

With kind regards,

Michel

[bdyster]

In PRO series you can disable auto write (button with 1011 icon) and then do each one manually.

 

Unfortunately it's not possible to just fix the mismatch.

 

 

I nearly always disable auto write to each device with the PRO (same with battery devices).  Find this so useful function as when blasting MANY devices all together in one big batch, seems like have issues with loosing communication with one device somewhere along the way and things getting garbled after that point.   This feature is so great makes me glad I went with the PRO when buying - not sure I'll ever run into the link limit of a std, but this feature is worth the upsale. -> (wonder why this is not default on std ISY - oh well...)    However, this time when restoring the new PLM I didn't disable writes to all devices since I didn't want to have to manually do each device for update (>100 devices).  But now stuck going through and repairing each one individually.   Live and learn....

 

Too bad its not possible to fix just the mismatch.  Seems like on a KPL or IRR with tons of links, it would be desirable to write updates to that one address in the link table...  Oh well, guess I'm stuck restoring tons of devices.  Finding enough devices with mismatch that it is faster to just restore and check rather than check (find mismatch), restore, then final check.    

 

Actually after I commented that all of the mismatches were on devices NOT to the new PLM, it seems like the rest of the mismatches actually have been the opposite (or are extra records at the end to the new PLM).     

 

Example:  (my new PLM is 30.DE.01).   

  OfficeFanLinc (device link):  0F98 : AA 00 30.DE.01 00 1C 01    The ISY table for 0F98 link address is all 0's and an empty field.   So somehow restore PLM might have stuck in an extra link here?    

 

Another:  GuestBed KPL:  0FF0: A2 01 3.0.DE.01 FF 00 01.     The ISY table for this link address is 0FF0 : E2 01 30.DE.01 FF 00 01   (so seems to have a single-bit error between the A2 vs E2).  Haven't looked up  what the A2 01 vs E2 01 cmd difference would be but just going through and fixing rather than spending too much time on each mismatch.  (again have >100 devices have to crawl through). 

 

 

Really like the idea as stated by johnnyt for being able to have option to crawl through devices during quiet times device at a time and even at least identify/notify of mismatches.  Could then have option to either auto-repair or leave mismatch and let user determine restore timing.  

[LeeG]

A link record that starts with A2 is a Responder link. One that starts with E2 is a Controller link. Not likely a bit error but a different link.

 

Compare has some addition issues of late. SmartLabs started using 2 additional bits in the first byte for a SmartHops function on some of the newest I2CS devices.

 

xxxy yxxx

 

The 2 y bits control the initial Hops count starting point but this results in a Compare mismatch that is not really a functional mismatch.

 

Another common physical mismatch that is not functional is the end of list entry. The ISY sets the first byte to 0x00 which is all that Insteon requires. The ISY Links Table shows this as 8 00's which is rarely true for a device that has had changes to Scene definitions.

[mwester]

Thanks LeeG - that explains a lot; I've constantly been "fixing" all of my newer KPLs, wondering how these compare errors have crept in.

 

What you describe seems like something the ISY should handle, though -- not a human being.  It knows which of the devices is at what rev, and thus can easily figure out which bits "don't matter" in the comparison.  And as for the last record, it also knows that.

 

My point being that the compare function is still broken, although I feel a lot better knowing that my devices aren't!