IrpTransmogrifier: new program/library for IRP protocols

Barf · Post by **Barf** » Wed Sep 09, 2020 3:33 am

mathdon wrote:I have left in my addition to NEC-Shirriff-32 as this ICT file still decodes as NEC-Shirriff-32 despite NEC-f16 including prefer-over NEC-Shirriff-32. To see this, open RMIR, select Advanced > Import Ict as Learned and load this file. The data values will display as hex because of the entry in rmProtocols.xml, which makes a lot more sense than decimal for a 32-bit value. I am happy for this not to be included in IrpProtocols.xml if you can ensure that nothing will ever decode as NEC-Shirriff, but that is not yet the case.

The reason why (some of) these signals decode as NEC-Shirriff-32 is since that protocol has just a very short leadout required (1*564 micros) (as opposed to NEC*-f16). Your signals have a (first) payload of 35 bits, so they (partially) decode if the 33rd bit is a 1. I have changed the leadout of these protocols to be the same as other NEC*-signals, ^108m. So now the signal do not decode, neither as Shirriff nor NEC*-f16. (The background is that Shirriff's software, IRremote, just as well as Lirc and Linux, does not really consider lead-outs.)

The changes are in Github. Let me also point out that there is a function IrpDatabase.remove(List<String> protocolNames) which can remove unwanted protocols from the data base.

I will address the other issues later.

Post by **mathdon** » Wed Sep 09, 2020 3:55 am

OK. I can't see why you object to including my addition to the NEC-Shirriff-32 protocol, but it seems to be a matter of principle to you so I won't push it. I do not want to remove any protocols in RMIR, including this one, so IrpDatabase.remove is not relevant to me.

Barf · Post by **Barf** » Wed Sep 09, 2020 6:42 am

mathdon wrote:I... I have also updated the included IrpTransmogrifier to the latest snapshot. It was a 1.2.8-SNAPSHOT already but is now the latest one. I do not know how to mark them with the revision number, as I was doing with Ant.

I just checked in a fix, making the commit hash available in the public Java variable org.harctoolbox.irp.Version.commitId. Interactively, it is printed by the command "version". Using the irptransmogrifier.sh script, this can be called also from a RM fat jar.

Having said that; the only really clean way is to use only official versions, i.e. from the Maven central repository. Using snapshots is always, well, informal. As I said in a PM, when submitting to the central repository, it may take some time (1-2 days) for it to show up.

But I am also happy to tag releases in any way you request: Just PM/mail me something like "Please tag IrpTransmogrifier release e749c66ae514bfbea3e2b6617016275ee61f7317 as RemoteMastern12.34.build56".

Post by **mathdon** » Wed Sep 09, 2020 7:47 am

Thanks. I really want to use only official versions, but I also want the first release of RMIR from a maven build to use the latest version. That is why I asked if you had an idea when the 1.2.8/2.2.8 versions will be finalized. I think you said somewhere that you would change IrScrutinizer away from RxTx in August so I am hoping your next batch of releases is not far off.

I am planning that the first RMIR from a maven build will be labelled 2.12.0, which in the present form would be v2.12 build 0 (though previously I have numbered builds from 1, not 0). I think you will approve of this change to the standard maven form of numbering.

Barf · Post by **Barf** » Thu Sep 10, 2020 2:24 am

mathdon wrote:In my latest updates of RMIR to the SVN, I have updated protocols.ini with the additions that Rob has requested and made a corresponding update to rmProtocols.xml. This updates the Anthem protocol to align with Rob's changes in protocols.ini. I do not propose to make additions to rmProtocols.xml for either the Keeprite A/C protocol or his new NEC1-f16 2Fixed protocol, so as far as I am concerned, rmProtocols.xml is now up-to-date.

I have merged rmProtocols.xml into IrpProtocols.xml. I also made a (dummy, improvements are welcome) keeprite protocol. Rob's NEC1-f16 2Fixed is not a protocol, it is an executor, so there is nothing to add.

Thanks. I really want to use only official versions, but I also want the first release of RMIR from a maven build to use the latest version. That is why I asked if you had an idea when the 1.2.8/2.2.8 versions will be finalized.

Consider the just published snapshot as 1.2.8 release candidate. I will publish it as 1.2.8 RSN. If any changes are requested, let me know.

I think you said somewhere that you would change IrScrutinizer away from RxTx in August so I am hoping your next batch of releases is not far off.

This is, at least in principle, independent. Work proceeds, although not as fast as I would like...

I am planning that the first RMIR from a maven build will be labelled 2.12.0, which in the present form would be v2.12 build 0 (though previously I have numbered builds from 1, not 0). I think you will approve of this change to the standard maven form of numbering.

I am delighted to hear that.

Semantic versioning is a pseudo-standard in the Open-source community.

Post by **mathdon** » Sat Sep 12, 2020 6:29 am

As you have added Keeprite to IrpProtocols.xml and at Rob's request I have added it to protocols.ini, I will create a uei-executor entry for it. Please wait for it, I have other things in the queue first but will do it soon. I know NEC1-f16 2Fixed is an executor, not a protocol, so there is nothing for you to add but I could add it as a uei-executor entry to one or more protocols. However, I think there are quite enough NEC executors already so I don't intend to do that.

As the release of 1.2.8 is not imminent, I think I will issue an RMIR release numbered 2.11 build 14 with the zip package manually renamed to match the present format. To the user it should then appear indistinguishable from the Ant builds. This will in fact be a good test of whether there is anything missing in the Maven builds that needs to be fixed. I would like RMIR 2.12.0 to include official releases of Git and IrpTransmogrifier and also be the first to be released under license, though depending on how things progress, I may have to change my mind on that.

When you have time, do please give me your suggestions for how to package the files that are presently in the setup and textfiles folders.

Barf · Post by **Barf** » Sun Sep 13, 2020 4:40 am

As soon as I get the promised fixes to IrpProtocols.xml I will release IrpTransmogrifier 1.2.8. So in that sense, it is imminent. (Note that it can take two days to show up at Maven Central.)

I would recommend to release a version ASAP (build15?), to let the users test if if can install and if it runs, or if something is missing.

please give me your suggestions for how to package the files that are presently in the setup and textfiles folders.

Just did in the other thread.

Post by **mathdon** » Sun Sep 13, 2020 8:46 am

Many thanks. It can be build 14, as although I have been using that number throughout this reconfiguration, it has never been posted in the RMIR Development folder. However, you and I will have one or more versions labelled build 14 so to remove all doubt, I will call it build 15.

In case I use snapshot versions of IrpTransmogrifier in future, I have incorporated your commitId into RMIR. The 7-character commit id, as appears in Git, for both Girr and IrpTransmogrifier will be included in <properties> in the pom. My one unit test will check the value for IrpTransmogrifier against the start of Version.commitId just as it tests the RMIR version in the pom against that hard coded into RemoteMaster.jar. There won't be a similar check for Girr as I don't think the commit id can be read from its files. If IrpTransmogrifier is a snapshot then the commit id will also appear in Help > About, but not if it is a release version.

I have incorporated your pom additions concerning running in place, together with some other files needed to make all the RMIR, RM and RMPB facilities fully operational. I will also incorporate your suggestions on packaging, but have not yet done so.

Barf · Post by **Barf** » Sun Sep 13, 2020 11:03 am

Nice.

mathdon wrote:There won't be a similar check for Girr as I don't think the commit id can be read from its files.

It can now.

Since several minutes...

Barf · Post by **Barf** » Thu Sep 17, 2020 6:02 am

New release 1.2.8!

This release contans a few bug fixes, new protocols and protocol fixes, and some minor improvements.

Release notes:

Code: Select all

* Support commitId in Version. Given out from "version" command.
* Set a sensible lead-out on protocols NEC-Shirriff and NEC-Shirriff-32.
* Bugfix for comments within irp:protocol/irp:parameter[@type='xml"]. #191.
* irp-protocols.xsd: Allow xml:space in <irp:documentation>. #188.
* New option decode --girr.
* New protocols TCL_AC, keeprite.
* Error message improvements.
* analyze --bit-usage now computes lengths of constant/varying segments.
* Fix problem with analyze/--parametertable. #190.
* IrpDatenbase: Recycle get-ted Protocols. #189.
* IrpProtocols.xml: NECx2: put reject-repeatless=true
* Merge rmProtocols from remotemaster, several times.

Download.

It has also been deployed to Maven central, but it may take a few days for it to show up.

Also Girr-2.2.8 has been released and deployed to Maven Central.

Barf · Post by **Barf** » Sun Sep 20, 2020 5:04 am

I consider the just published version 1.2.8 as quite stable. Future changes are expected not to change the working of the program, nor the API, in an incompatible manner.

However, I do not consider IrpTransmogrifier finished or frozed. The planned extensions mostly deal with improving the bulk analyze capacities, issues.

So I hope that RMIR can use only released versions. Should the need arise to use an unreleased snapshot version, this works as in the past.

There are two issues regarding decoding but they are not really critical, and would require quite substantial changes that may have unwanted side effects.

Post by **mathdon** » Sun Sep 20, 2020 5:18 am

Barf wrote:So I hope that RMIR can use only released versions.

I very much hope this myself. In fact, at present I cannot foresee any further development of RMIR other than bugfixes or additions to protocols.ini and rmProtocols.xml unless UEI comes up with something new, none of which would require changing IrpTransmogrifier from 1.2.8. If there are additions to rmProtocols.xml that you then incorporate into IrpTransmogrifier, even that does not require a change from 1.2.8 as for RMIR purposes the additions can simply remain in rmProtocols.xml.

Barf · Post by **Barf** » Sun Dec 13, 2020 10:53 am

Project status

This project was started some five and a half years ago. (Actually, I have been working on a predecessor project, IrpMaster, which "donated" some ideas and code, so in a sense the project is older than that.)

Now, I think that the goals I had then have been reached. In this sense, the project can be considered as mature and "finished", although not frozen.

Of course, bug reports, -fixes, new protocols, etc, are welcome as always. My plan is to collect minor improvements, bug fixes, and additional protocols, and likely to publish a new version once or twice every year.

Open issues:

* There is a "quirk" in the loose-mode decoding, #168, when the repeat is reduced too much. I do not consider it too sinister; loose mode is by nature somewhat heuristic anyhow.
* Parameters are implemented using Java's long data type, which essentially gives 63 useful bits. Work has started on allowing unlimited length parameters using Java's bigInteger, #38. Although I am convinced of the feasibility, it is unlikely that I will ever complete this task.
* There are a number of suggestions for improving the bulk analyzer. Although these suggestions are sensible, it is unlikely I will implement these; the main reason being that bulk analysis of IR signals is presently not exactly a hot topic.

There are two projects that directly extend the present one:

* IrpTransmogrifier-GUI is an unfinished GUI for the (bulk) decoding and analyze features.
* IrProtocolCodeGeneration. The present project contains support for IR protocol code generation using XSLT and StringTemplate. The target specific code in XLST and StringTemplate has been relocated to this project. The GitHub project contains a number of issues for interesting target languages.

Barf · Post by **Barf** » Sun Apr 11, 2021 7:34 am

I plan to release version 1.2.10 in June or so. (The version number "1.2.9" was botched... so there will not be a version with that number.) This will just be collecting a number of tweaks and fixes, in particular to IrpProtocols.xml. The then-current rmProtocols.xml of RMIR will be merged into IrpProtocols.xml (likely).

There will also be a corresponding release of Girr.

Post by **mathdon** » Mon Apr 26, 2021 12:22 pm

I have posted v2.12.17 of RMIR on the SVN, though have not issued it yet as a development version in case there are further changes needed. It includes an rmProtocols.xml with my proposals for the X10 protocols. The rather strange looking definitions sections in the executor entries correspond to the new X10Translator that I have added to RMIR to unscramble the rather odd ordering of hex values that X10 uses. I would welcome any comments.