Link records in hex on screen vs. XML in output file?

[ELA]

I have been trying to review some link records both on the ISY screen and then later in a saved file.

I understand the command on screen but find the xml format that is a saved file representation of that information frustrating to view and with my limited knowledge somewhat useless.

 

Why does the ISY show it on screen as hex characters and then save it as XML?

Is there an easy method to convert the XML output back to hex?

I have heard the term REST command used a few times ?

 

Is REST helpful for converting back and if so how. I read the wiki but it appeared to be for other things?

I am interested in converting the output file back to hex ( off-line when I do not have the the ISY running in front of me).

Or if there is another method to output the link record file while in front of the ISY direct to hex characters?

[LeeG]

This subject has been discussed before. UDI position is the XML file is not intended for human use. The decimal values can be converted to hex if you have a calculator that handles hex. I have done it a few times, concluding it was not a useful analytical/debug tool because of the time/effort it takes to do the manual conversion.

 

REST is not helpful as none of the commands return the data in the format of the Show screen display.

[Michel Kohanim]

Thanks LeeG, you're 100 correct. The decision was made to reduce the file size.

 

If you are comfortable with Java, I can send you the file that converts it.

 

With kind regards,

Michel

[ELA]

Thanks LeeG,

I did do a search before I posted but missed that discussion, sorry for being redundant.

 

The answer is unfortunate, if not intended for human use then the save option must be only for ISY programmers??

 

While I do know how to convert decimal to hex it would be way to laborious for the 50+ link records I viewed on screen and would now like to parse further off-line.

 

I was reading my IRlinc link-records in an attempt to help further understand another posters issues with the IRlink and to learn more myself. I will have to do it next time I am in front of the ISY, or use the ELAM since I have just completed adding that ability to it.

 

Thanks Michel,

I unfortunately I am not a java guy.

[LeeG]

"the save option must be only for ISY programmers??"

 

The Save/Load buttons work with the XMLfiles.

[ELA]

Michel,

I do not want to belabor this too far but one more question please.

 

I understand if UDI preferred to output the file in XML for your purposes, however I did not understand the comment that the XML output was to reduce file size?

 

Last night I saved a file that contained 51 link records. That XML file is 6.5K in size.

On the surface that seems like room for 127 bytes per link. If there are 8 (hex) bytes per link record that leaves about 15 characters to define each byte in a record?

 

Couldn't a straight hex output (as ascii) be that size or smaller?

 

This is of course not important at all, just makes me curious.

[Michel Kohanim]

Hi ELA,

 

I didn't say we used XML to reduce size. I said we used integer representation (4 bytes) to reduce size and furthermore have a unified representation across ISY/Admin Console. This way, it's up to the UI to format it however it chooses to do so.

 

With kind regards,

Michel

[ELA]

I had implemented reading the PLM's link records, over the power line, in my tester (ELAM) and all appeared to be working well (reading using the 0x2F) command.

The ELAM reported 261 records. I then ran the get PLM links on the ISY for a confirmation that my code was working correctly. The ISY reported 327 records!

 

I had the communications viewer open and could see a lot of records containing addresses that did not exist in my system!

 

When I ran the same test in the ISY a second time it reported 261 records.

 

I found this really strange since I would expect more likelihood of message corruptions when retrieving over the power line vs. the ISY reading the PLM's links directly over the serial cable using the 0x69, 0x6A commands.

 

I will try more tests to see if this happens again when I can. Any explanations available, happen to anyone else? I am running ISY 3.2.4 I think.

[Brian H]

Any messages on the power lines {probably RF also if it is a Dual band PLM} during the PLM link database counting through the Administrative Console will give you a messed up count.

[LeeG]

ELA

 

The Show PLM Links Table is susceptible to Insteon traffic reaching the PLM adversely affecting the count. The internal NEXT pointer in the PLM used to sequentially read the link records is altered by Insteon traffic reaching the PLM that requires the PLM to search its link database. Causes link records to be skipped (low count) or the same records to be read multiple times (high count). It is necessary to run Show PLM Links Table multiple times with Count to verify a specific count can be reproduced which is usually accurate.

 

The PLM does not compress the link database as records are deleted and added. It would be common to have Insteon addresses which are no longer in the system. A Restore Modem (PLM) will effectively compress the PLM link database as the database is reset and only active records written back.

[ELA]

Thanks for the information LeeG and Brian H.

 

I realized that traffic might upset this process, even though it was via the serial cable and not over the power line. For that reason I thought I was avoiding purposely creating any traffic but perhaps "stuff happened" without me knowing it.

 

Interesting information LeeG about link data base compression. This is a very new PLM that I ran a restore on when I installed it about 2 months ago. The strange addresses I saw were never in my system. Maybe I forgot to run a factory reset before the install? Or does that not clear memory either?

[LeeG]

I would have expected a Restore Modem (PLM) to have cleared any old information. Are the link records with the non-existing addresses active (E2 or A2).

[ELA]

HI LeeG,

I had to run some more testing to provide the info you requested. I ran several tries in a row that produced the same result 261 result while the house was empty and I could control the activity. I then purposely turned on lights during the PLM reads and got several "short stops" with less than 200 links.

 

I finally caused one with 355 links and the same address I noted last night - that is not in my system.

They were both A2 and E2 to the same address. A few were identical duplicates such as

"E2 00 1B B0 FE 01 19 40"

 

Based on your reply I am not worried and understand the errant reads can happen. I just wanted to provide you with this feedback since you asked.

[LeeG]

For whatever it is worth the 01 19 40 is for a SwitchLinc Dimmer with firmware v.40.

[Xathros]

To follow up on the subject of this thread, I dumped my links using the save option, converted the xml file to a dbf using the "Advanced XML converter". Opened the resulting file in Excel and used =DEC2HEX(H2,6) to convert the decimal back to hex then to dotted hex using =CONCATENATE(MID(J2,1,2),".",MID(J2,3,2),".",MID(J2,5,2))

NOTE: DEC2HEX is part of the Analysis Toolkit Add-In available from Tools/AddIns on the Excel menu.

 

It took about 3 minutes to make a readable file that looks like:

 

 

-or-

 

A cheap way out: Open event viewer at level 3, then Show PLM links table, then save the event log as text file. Sort out the extra records and your done. Output looks like:

Wed 05/16/2012 16:29:55 : [LNK-DATA    ] 02 57 E2 00 12 12 D4 02 0D 38 
Wed 05/16/2012 16:29:55 : [LNK-DATA    ] 02 57 A2 01 12 12 D4 02 0D 38 
Wed 05/16/2012 16:29:55 : [LNK-DATA    ] 02 57 E2 00 12 12 1F 02 0D 38 
Wed 05/16/2012 16:29:55 : [LNK-DATA    ] 02 57 A2 01 12 12 1F 02 0D 38 
Wed 05/16/2012 16:29:56 : [LNK-DATA    ] 02 57 E2 00 12 11 B1 02 0D 38 
Wed 05/16/2012 16:29:56 : [LNK-DATA    ] 02 57 E2 00 12 13 BC 02 0D 38 
Wed 05/16/2012 16:29:57 : [LNK-DATA    ] 02 57 A2 01 12 11 B1 02 0D 38 
Wed 05/16/2012 16:29:57 : [LNK-DATA    ] 02 57 A2 01 12 13 BC 02 0D 38 
Wed 05/16/2012 16:29:58 : [LNK-DATA    ] 02 57 E2 00 13 29 F9 02 14 38 
Wed 05/16/2012 16:29:58 : [LNK-DATA    ] 02 57 A2 01 13 29 F9 02 14 38 
Wed 05/16/2012 16:29:59 : [LNK-DATA    ] 02 57 E2 10 12 11 B1 02 0D 38 

 

I hope you find this useful.

 

-Xathros