I THINK......I read somewhere that there was a way of extracting the various macros etc as .xml code from a RU990 series remote......would appreciate any tips for doing sov

An xcf-file is nothing but a zip file, that contains an XML-file named ConfigEdit.xml, as well as a number of bitmaps in png format. You can, possibly after renaming open an xcf file with "any" achiever program, Winzip or 7zip, or ... then you can extract ConfigEdit, which contains all data, in a fairly easy to decode way. IrScrutinizer's xcf importer does exactly this.

OK, got the xml fie - thank you
how on earth do I tie that up with the macros and commands

Well, you are unlikely go get a documentation from Philips, so you basically have to "reverse engineer", which basically amount to guessing. I did this in the xcf importer in IrScrutinizer, and it was not terribly hard, and it worked! Much easier than the silly indentation based files called .yaml, that I am currently swearing at (Homeassistant!)

If you want to look at the IrScrutinizer code, it is here. It imports the commands of a given xcf file, while respecting the partitioning in devices and pages.

I tried using the importer with a PEP2 PCF on Scrutinizer 2.1.0 and had no luck.

Is there a minimum version where this is known to work?

I also just downloaded 2.4.1 and same issue. How is it that you are supposed to import an XCF file?

I'd be willing to share a PEP2 file that I'm trying to use here.

When I try dropping a PEP2 file into the import tab (After reading help), I get parse exception on line -1 - No Modules Present.

I do know that the scripts in my current config file, may have some CDATA wrappers present. Not sure if that would cause issues.

My current XCF is also over 10MB in size.

The java on my system is 32 bit v1.8.0_162-b12 (Hotspot Build 25.162-b12 mixed mode, sharing)

Let me know if you'd like to troubleshoot.

Edited to change PCF to XCF

Hi Lyndel, nice to hear from you!

PCF is not supported, since it uses an encrypted form of the Pronto Hex codes. (Opening in PEP and exporting in another format might decrypt it though...)

For the XCF: while my work is based on reverse engineering, it is quite possible that either there are different versions of the XML format, or that I have missed something. I will be happy to have a look at any XDF file that is not accepted. Please send/upload it, for example with personal PM. (Actually, ConfigEdit.xml will be sufficient if size is a problem.)

I said PCF but I meant XCF. Sorry. ;-)

Dropped you an RC Mail note with more details as to where and what I sent. Let me know if you did not receive it.

I got it. Turns out that the file has Version 6 (attribute Version on the root element of ConfigFile.xml), which is presently not supported. I opened an issue here. Will be fixed shortly.

Should be fixed in the snapshot build. Please try it and report the outcome. Is it complete? Can you find anything that should be different? Or can you suggest any other improvements?

Turn out that I added the possibility to open ConfigEdit.xml files directly, not just xcf files.

B,

I can confirm that snapshot release is good for PEP2 files. I sent you a PEP1 file to consider as well.

Also, a while back, I sent you some info on simplifying the format for the apple IR codes.

Seems they have a 5 bit device and an 11 bit subdevice that is ALWAYS consistent.

[Link: en.m.wikipedia.org]

Not sure if this would help things for you as you always need a PairID, Device, and Function or you could hard-code a Subdevice value and use the SubDevice input as the value for 8 bit PairID. That would simplify as users wont have to add PairID=254 for example when generating codes.

Not sure if having a hard-wired value for Subdevice would make detection of the codeset easier as well.

If you are interested in a further discussion, hit me up on email.

Lyndel

It loads, actually. Problem is that there are about 50 signals, all having the informative name "learned"!! Presently, only one signal with a certain name can be contained, so there shows up only one signal.

Anyhow, it may be desirable to handle the case of non-unique names in a more graceful way. I have checked in a new version (snapshot with the same URL as before) that will rename in order to keep all signals. Also, it handles "Pages" by mapping them to CommandSets (version 4 only). Please try it.

I suggest you open a new thread on this topic.

Here or in your issue tracker?

I can confirm that the new version works only if you drag the XCF file onto Scrutinizer Import tree list. If you click the "..." button to import a file, nothing appears to be processed.

The "..." brings up a file selector, which fills in the "File/URL" text field. (Alternatively, you can fill it in by typing and/or pasting). To actually load, you press "Load File/URL". See [Link: harctoolbox.org] . This is the way it works since the program was designed. I believe this behavior is consistent with most GUI standards.