IrpTransmogrifier: new program/library for IRP protocols

Barf · Post by **Barf** » Fri Jan 20, 2023 10:06 am

Sean Young found a problem with IrpTransmogrifier, and, cutting a long story short (the long version can be found in the issues at github) lead to this fix. I consider this to be comparatively important, and intend to release a version 1.2.12 in a few months time.

I have also found a rare null pointer exception in Girr, so also here a new release is called for.

Barf · Post by **Barf** » Wed Mar 01, 2023 3:01 pm

Version 1.2.12 and version 2.2.12 of Girr have been released. Release notes for IrpTransmogrifier:

Code: Select all

2023-03-01: Version 1.2.12.

This version consists of a few bug fixes and clarifications of medium importance.
Thanks to Sean Young for initiating most of them.

* XML EEP (External Entities Protection) fixes. Resolves #237.
* Check/enforce max BitField length when rendering. #235.
* More checks for compatible BitSpecs. #236.
* Per default, disallow BitFields widths > 63. #234
* Minor refactoring of *BitField classes.
* Make number parsing consistent (as long). #233.
* Disallow infinite bitfields to be part of an IrStream. #229.
* Ensure that irp with * repeat must have all intro variants empty. #231.
* Remove parameter specs and extent on NEC-Shirriff. Resolves #226.
* IrSignal: Do not nuke intro- and repeat-sequences because they are identical to the repeat sequence. #222, #223, #224.
* Protocol.checkSanity(): Do not warn for empty parmeterspecs if no bits in protocol.
* Sensible implementation of Variation.numberOfBits
* Set "Samsung32" as synonym for NECx-f16.

Thanx to Sean for his bug reports.

Graham, Sean: The issues you both raised the last few days did not make it to this release, but will be addressed in the next release.

Post by **mathdon** » Tue Apr 18, 2023 8:30 am

IrpTransmogrifier v1.2.12 and Girr v2.2.12 are now incorporated into RMIR v2.15 which is currently in pre-release testing and available in the RMIR Development folder on SourceForge.

Barf · Post by **Barf** » Sun Dec 10, 2023 8:44 am

Almost a year has passed since version 1.2.12 was released, and it is getting time for a new release. There has been a few bugfixes (none of them very important for the average user) in the meantime, and I plan to release 1.2.13 before the end of the year.

So there is anything that you want to go into that release, please let me know. The snapshot pre-release is, as always, found here.

This issue will not be addressed in this release.

Post by **mathdon** » Fri Jan 05, 2024 9:27 am

Barf wrote:I plan to release 1.2.13 before the end of the year.

Is 1.2.13 imminent? If so, I will incorporate it into RMIR v3.0.12 which I expect to release shortly. BTW There is nothing that I want to go into that release, al least nothing that I remember wanting!

Edit: Silly me, there is of course what is in rmProtocols.xml, but you have probably thought of that.

Barf · Post by **Barf** » Fri Jan 05, 2024 2:19 pm

Graham, the 1.2.13 has been somewhat delayed because I also plan a new release of IrScrutinizer, and wanted to delay a short while, because possibly something comes up... Anyhow, I should be able to publish the release the next few days.

what is in rmProtocols.xml,

I plan to merge that, likely tomorrow.

Post by **mathdon** » Fri Jan 05, 2024 5:09 pm

Rob has just PM'd me that he has a new protocol that he wants added to protocols.ini. That will also require an addition to rmProtocols.xml. I hope to deal with this tomorrow, so I think it would be best if you hold off on the merge till I have done that.

Post by **mathdon** » Sat Jan 06, 2024 10:13 am

I am stuck. The only explanation I can think of for the behaviour I am getting is that it comes from an error in IrpTransmogrifier 1.2.12. I have created the following entry for protocols.ini:

[Amazon Fan]
PID=01 FF
VariantName=JP1Amazon
DevParms=Device=2
DeviceTranslator=Translator(comp,0)
CmdParms=OBC
CmdTranslator=Translator(comp,0)
DefaultCmd=00
CmdIndex=0
FixedData=FD
Code.S3C80=44 89 11 8B 18 85 44 08 08 01 04 02 EC 01 04 04 FA 02 EC 08 CA 08 B6 63 9C 11 94 04 CE F6 01 46 C6 1C 18 6A F6 01 49 C6 28 80 45 2C 06 C6 C0 22 1C F6 01 5B E6 0D 02 8D 01 49

and this for rmProtocols.xml:

<irp:protocol name="Amazon Fan">
<irp:irp>
<![CDATA[{38.5k,520,msb}<1,-3|1,-5>(9,-9,D:8,F:8,1:1,9,-9,D:8,F:8,1,-13.7m,9074u,(-5,1,-52m,9074u)*)[D:0..255,F:0..255]]]>
</irp:irp>
<irp:parameter name="uei-executor">01FF:JP1Amazon[D;F]</irp:parameter>
</irp:protocol>

I have updated Rob's .rmdu file to use this protocol rather than the Manual Protocol he has used, and have loaded this into my RCRP05B. It creates signals that match the IRP in rmProtocols.ini. The learns in the .rmir file posted by 120240VAC60HZ are identified as Amazon Fan with correct values. "Convert to Device Upgrade" converts them successfully (this of course uses IrpTransmogrifier). If I try to export the device upgrade as a .girr file, either from the .rmdu file or from the converted learns, I get a message that they have all been exported successfully. BUT if I open the .girr file in a text editor, the commands all say:




I do not know what is going on.

Barf · Post by **Barf** » Sat Jan 06, 2024 11:46 am

mathdon wrote: {38.5k,520,msb}<1,-3|1,-5>(9,-9,D:8,F:8,1:1,9,-9,D:8,F:8,1,-13.7m,9074u,(-5,1,-52m,9074u)*)[D:0..255,F:0..255]

Your intro (and repeat) ends with flash ("9074u"). So that IRP would generate sequences with an odd number of durations.

I have merged rmProtocols.xml version 2023-06-03 and uploaded it.

Post by **mathdon** » Sat Jan 06, 2024 12:03 pm

Sorry, the IRP should be:

<![CDATA[{38.5k,520,msb}<1,-3|1,-5>(9,-9,D:8,F:8,0:1,9,-9,D:8,F:8,1,-13.7m,9074u,(-5,1,-52m,9074u)*)[D:0..255,F:0..255]]]>

That is what I tested with. I tried both 0:1 and 1:1 and somehow posted the wrong one for you.

Barf · Post by **Barf** » Sat Jan 06, 2024 12:11 pm

It still ends the into- and the repeat sequence with 9074u (flash). You probably should have
something like

Code: Select all

{38.5k,520,msb}<1,-3|1,-5>(9,-9,D:8,F:8,0:1,9,-9,D:8,F:8,1,-13.7m,(9074u,-5,1,-52m)*)[D:0..255,F:0..255]

Post by **mathdon** » Sat Jan 06, 2024 12:26 pm

I hadn't spotted your message about the 9074u when I posted mine about the 0:1, sorry. I based my IRP on this from you:

Barf wrote:So, possibly one of the executer wizards can write an executor for the protocol {38.5k,520,msb}<1,-3|1,-5>(9,-9,A:17,9,-9,B:16,1,-13.764000000000001m,9074u,(-5,1,-52m,9074u)*)?

I will now try to fix it.

Post by **mathdon** » Sat Jan 06, 2024 12:41 pm

Yes, your suggested correction works. Thank you.

Post by **mathdon** » Sat Jan 06, 2024 1:09 pm

The protocols.ini and rmProtocols.xml that include the Amazon Fan protocol are now in the SVN.

Barf · Post by **Barf** » Sun Jan 07, 2024 6:03 am

Great! Would it be ok to use "Amazon_Fan" (with underscore instead of the space) instead of "Amazon Fan"? We can handle protocol names with a space in them, and in fact we have several already. However, names with spaces in them always tend to create problems down the line, scripts that does not quote the arguments for example (yes this is strictly speaking sloppy programming and wrong...).