(This is on ISY 4.2.8 & 4.2.10)

 

I had a PLM failure last week, which resulted in me spending many hours yesterday trying to make sure all link databases were correct following the installlation of its replacement.

 

When scanning the device link databases for my devices and then comparing them against the ISY's table, I had several which reported mismatch results similar to the attached screenshot. Namely that the final record in the ISY was all zeros and the final record in the device had a first byte of zero, then other non-zero values. ISY Compare states that this is a "mismatch", but shouldn't it be "mismatch/ignore"? Because according to my reading of the Insteon specs, a zero in the first byte indicates the record is not in use and it's also a high-water marker.  Ie this condition is OK.

 

Note that when I tried to clear these "mismatches", I did a device restore, but this did not change that final record; ie it was not set to all zeros as in the ISY links table. The only way I could get the devices to match was to reset the device back to factory, then restore it from ISY - something that is time consuming and would be difficult for some of my more inaccessible devices. So I'm hoping that my reading of the specs is correct and I can just ignore the ISY's "mismatch" assesment for these records

 

- Andrew

Andrew-

 

So sorry to hear of your PLM failure but alas, they seem to fail way too often.  There is a thread here on how to repair your failed PLM power supply for under $20.  If your handy with a soldering iron, it's well worth the effort for a spare PLM.

 

As for the record mismatch, I believe that you are 100% correct in your assessment of the situation and I agree that the ISY should ignore the data following the 00 in the final device link table record.

 

-Xathros

Edited September 15, 201411 yr by Xathros

Hell Andrew/Xathros,

 

Although that might be the case, but a high watermark is a record with all zeros.

 

With kind regards,

Michel

Xanthros: Thanks for the suggestion. I've found the post you're talking about, so I'll take a look at repairing my PLM

 

Michel: My point is, shouldn't ISY really report "Mismatch / Ignore", if that final record is marked as not in use? The fact it's just marked as "mismatch" could lead people to perform unnecessary (and lengthy) recovery procedures.

 

Thanks

 

- Andrew

Xanthros: Thanks for the suggestion. I've found the post you're talking about, so I'll take a look at repairing my PLM

 

Michel: My point is, shouldn't ISY really report "Mismatch / Ignore", if that final record is marked as not in use? The fact it's just marked as "mismatch" could lead people to perform unnecessary (and lengthy) recovery procedures.

 

Thanks

 

- Andrew

 

1+

 

I have to agree displaying information no matter how accurate without context will only lead to confusion, lower customer satisfaction, and higher support calls / tickets.

 

A pop up message or some kind of contextual help message to indicate these types of mismatches can be safely ignored as they are not (in the big picture) a mismatch.

 

Information needs to be relayed to the masses so even the lay person can understand and comprehend what they are looking at. It should not require anyone to come on to the forums to find out this is something that can be safely ignored.

Hi Andrew,

 

From ISY perspective, high watermark is a record with all zeros. As you can see, ISY has all 0s and the device does not. This means that the last restore was not successful. Why would we not flag this as a mismatch when the record should be all zeros and we do know that the last restore was not successful?

 

With kind regards,

Michel

Hi Michel,

 

It is a mismatch, but the other indicators indicate the record is not in use, therefore the mismatch can be ignored. ISY Compare already uses the "Mismatch / Ignore" label for link records in other situations, why wouldn't it here?

 

Or are you suggesting the mismatch should not be ignored?

Hi andrewm,

 

I must stand corrected. LeeG just let me know that my understanding was incorrect. Already fixed.

 

Hi LeeG,

 

I am not sure what we would have done without you. THANK YOU.

 

With kind regards,

Michel