JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

IrpTransmogrifier: new program/library for IRP protocols
Goto page Previous  1, 2, 3 ... , 12, 13, 14  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Fri Jan 20, 2023 11:06 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Wed Mar 01, 2023 4:01 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Tue Apr 18, 2023 9:30 am    Post subject: Reply with quote

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
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Sun Dec 10, 2023 9:44 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Fri Jan 05, 2024 10:27 am    Post subject: Reply with quote

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
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Fri Jan 05, 2024 3:19 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Fri Jan 05, 2024 6:09 pm    Post subject: Reply with quote

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
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Sat Jan 06, 2024 11:13 am    Post subject: Reply with quote

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
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Sat Jan 06, 2024 12:46 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Sat Jan 06, 2024 1:03 pm    Post subject: Reply with quote

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
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Sat Jan 06, 2024 1:11 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Sat Jan 06, 2024 1:26 pm    Post subject: Reply with quote

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
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Sat Jan 06, 2024 1:41 pm    Post subject: Reply with quote

Yes, your suggested correction works. Thank you.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Sat Jan 06, 2024 2:09 pm    Post subject: Reply with quote

The protocols.ini and rmProtocols.xml that include the Amazon Fan protocol are now in the SVN.
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Sun Jan 07, 2024 7:03 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Software All times are GMT - 5 Hours
Goto page Previous  1, 2, 3 ... , 12, 13, 14  Next
Page 13 of 14

 
Jump to:  
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
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control