|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Fri Jan 20, 2023 11:06 am Post subject: |
|
|
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. |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Wed Mar 01, 2023 4:01 pm Post subject: |
|
|
Version 1.2.12 and version 2.2.12 of Girr have been released. Release notes for IrpTransmogrifier:
Code: |
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. |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4524 Location: Cambridge, UK |
Posted: Tue Apr 18, 2023 9:30 am Post subject: |
|
|
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. _________________ Graham |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Sun Dec 10, 2023 9:44 am Post subject: |
|
|
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. |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4524 Location: Cambridge, UK |
Posted: Fri Jan 05, 2024 10:27 am Post subject: |
|
|
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. _________________ Graham |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Fri Jan 05, 2024 3:19 pm Post subject: |
|
|
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.
Quote: | what is in rmProtocols.xml, |
I plan to merge that, likely tomorrow. |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4524 Location: Cambridge, UK |
Posted: Fri Jan 05, 2024 6:09 pm Post subject: |
|
|
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. _________________ Graham |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4524 Location: Cambridge, UK |
Posted: Sat Jan 06, 2024 11:13 am Post subject: |
|
|
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:
<!--Raw signal requested but could not be generated: IrSequence has odd length = 73.-->
<!--Pronto Hex requested but could not be generated: IrSequence has odd length = 73.-->
I do not know what is going on. _________________ Graham |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Sat Jan 06, 2024 12:46 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4524 Location: Cambridge, UK |
Posted: Sat Jan 06, 2024 1:03 pm Post subject: |
|
|
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. _________________ Graham |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Sat Jan 06, 2024 1:11 pm Post subject: |
|
|
It still ends the into- and the repeat sequence with 9074u (flash). You probably should have
something like
Code: | {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] |
|
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4524 Location: Cambridge, UK |
Posted: Sat Jan 06, 2024 1:26 pm Post subject: |
|
|
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. _________________ Graham |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4524 Location: Cambridge, UK |
Posted: Sat Jan 06, 2024 1:41 pm Post subject: |
|
|
Yes, your suggested correction works. Thank you. _________________ Graham |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4524 Location: Cambridge, UK |
Posted: Sat Jan 06, 2024 2:09 pm Post subject: |
|
|
The protocols.ini and rmProtocols.xml that include the Amazon Fan protocol are now in the SVN. _________________ Graham |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Sun Jan 07, 2024 7:03 am Post subject: |
|
|
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...). |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|