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, 4, 5, 6, 7, 8, 9  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: 1196

PostPosted: Tue May 19, 2020 9:09 am    Post subject: Reply with quote

Release candidate for 1.2.6 avalable. This contains, among other changes, protocol updates suggested by Graham.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Barf
Expert


Joined: 24 Oct 2008
Posts: 1196

PostPosted: Mon May 25, 2020 2:15 am    Post subject: Reply with quote

New release 1.2.6!

This release contans a few bug fixes and minor improvements.


Release notes:
Code:

* Checksums (signed in released versions) now reside in files checksums.*. #169.
* Improvements in the main documentation.
* Changes to the Dyson protocol(s), as proposed by Graham Dixon.
* Rename JVC_alt -> JVC_squashed.
* Merged in new documentation for NEC*-f16 protocols from RemoteMaster v2.10 build 8.
* Rename protocol Dysan -> Dyson.
* Fixed inconsequent working of --radix. #167.
* Fix bug in analyze --invert. #163.
* New option --validate in analyze. #166.
* Make the radix prefixes in IrCoreUtils configurable in API. #165.
* Validate --radix command line option. #164.
* Refactor commands. Resolves #162.
* Fix bug in Biphase decoding. #161.
* Improved analyzer command line output for named parameters.


Available here.

Keep transmogrifying!
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


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

PostPosted: Mon Jun 08, 2020 12:24 pm    Post subject: Reply with quote

I am testing a new facility in RMIR to export device upgrades as Girr files, which for example can be imported into IrScrutinizer. I have come across a possible issue with the X10.n protocol. The description for the X10 protocol says of the X10.n protocol that the parameter N is incremented on successive keypresses, running from 0 to 15 (or some lower value). The X10.n IRP specifies its range as N=0..15. As it is not a parameter of the executor, instead being an unusual toggle, should this range be N@=0..15 like other toggles?

This may seem very nit-picking, but it causes my export algorithm to throw an error that N is undetermined. The @ causes the algorithm to know that it is OK for it to be undetermined and so will prevent the error.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


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

PostPosted: Mon Jun 08, 2020 12:47 pm    Post subject: Reply with quote

Further to the above, trying to test my fix by including
Code:
    <irp:protocol name="X10.n">
        <irp:irp><![CDATA[{40.8k,565}<2,-12|7,-7>(F:5,N:-4,21,-7,(7,-7,F:5,~F:5,21,-7)+)[F:0..31,N@:0..15]]]></irp:irp>
    </irp:protocol>

in my rmProtocols.xml patch file causes RMIR to fail to open, with the error
Code:
org.antlr.v4.runtime.misc.ParseCancellationException
   at org.antlr.v4.runtime.BailErrorStrategy.recoverInline(BailErrorStrategy.java:66)
   at org.antlr.v4.runtime.Parser.match(Parser.java:206)
   at org.harctoolbox.irp.IrpParser.parameter_spec(IrpParser.java:2760)
. . .

Have I got invalid syntax in this?
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1196

PostPosted: Mon Jun 08, 2020 1:10 pm    Post subject: Reply with quote

You are right, there is a contradiction between the IRP and the verbal description. The verbal description would translate to

Code:

{40.8k,565}<2,-12|7,-7>(F:5,N:-4,21,-7,(7,-7,F:5,~F:5,21,-7)+,N=(N+1)%16)[F:0..31,N@:0..15=0]


Any of the protocol expert want to chime in on this?

mathdon wrote:

Have I got invalid syntax in this?

Yessir. A persistent variable ("with @") must have a default, otherwise the parser barfs. As you have seen...
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Barf
Expert


Joined: 24 Oct 2008
Posts: 1196

PostPosted: Wed Jun 10, 2020 7:35 am    Post subject: Reply with quote

Just checked in a new versions, that has some minor changes in the API.

* Some classes has been moved from org.harctoolbox.ircore to org.harctoolbox.xml. For example, it is now org.harctoolbox.xml.XmlUtils, previously org.harctoolbox.ircore.XmlUtils.
* A few functions now throws SAXException (= broken XML), that previously did not.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Barf
Expert


Joined: 24 Oct 2008
Posts: 1196

PostPosted: Sun Jul 05, 2020 4:49 am    Post subject: Reply with quote

IrpTransmogrifier 1.2.7 has been released, and is available on GitHub.

Release notes:
Code:

* Add Motorola as alt_name for Blaupunkt, #187. Remove Blaupunkt_relaxed.
* Merged rmProtocols.xml from RemoteMaster commit r1712 as well as r1714.
* Reformatted IrpProtocols.xml using list --dump.
* Now allows attribute xml:space in <irp:documentation>.
* Better check for circular prefer-overs, option --prefer-overs. Resolves #170.
* Recognize NULL as argument to --out.  Resolves #186.
* Improvements in list --dump. #184, #183.
* Remove -v as command line option.
* New option --xslt by decode and analyze. #182.
* API: Fix usage of UnsupportedEncodingException. #181
* Replace option --encoding by separate options for input and output. #180.
* Protocols: Kaseikyo family protocols now "prefer-over"-ed Kaseikyo. #177
* analyze with --tsv: layout fixes.
* New main-class XmlTransmogrifier: allows command line validation, reformatting, transformations.
* Implemented local XML Entity resolver (for accessing common Schemas locally, not over tne net).
* API: new package org.harctoolbox.xml. Some classes relocated to this.
* New option --validate. #173.
* Fixes to the schema irp-protocols.xsd. #174, #172.
* API: New function Protocol.fillInDefaults(Map<String,Long>)
* New option --fatgirr.
* Bugfixes and improvements in analyze --girr.


Also the Girr library has a new release, Version 2.2.7.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


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

PostPosted: Sat Jul 11, 2020 12:30 pm    Post subject: Reply with quote

The RMIR version now in the SVN includes changes that enable the export of a device upgrade as a Girr file to represent correctly the toggle behaviour of the exported device upgrade, in particular for executors that support both toggle and non-toggle behaviour of what is otherwise the same protocol. The rmProtocols.xml file has the changes required to uei-executor entries. Some of these may look strange, such as an additional parameters section
Code:
{X=-1,Y=-1,TS=T,T=X-2*Y}

which looks as if it gives T=1. It does on import when processed from left to right, but on export it is processed from right to left. Such entries are carefully constructed to give different behaviour on import and on export. I have also added an RC6-M-24 protocol.

The other change is that I have used the recursive ability of IrpTransmogrifier Decoder to handle Ict imports that are not broken by notes into separate signals. Thank you for drawing my attention to this feature, which I had not previously noticed. I will post a compiled version of this development build so Rob can see if it meets his need.
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1196

PostPosted: Wed Jul 15, 2020 1:59 pm    Post subject: Reply with quote

I have merged all the changes from Graham's rmProtocols.xml, mentioned in another thread.

Available at GitHub in today's snapshot. (However, for technical reasons not yet available in today's snapshot of IrScrutinizer: you have to select it as Options -> IRP protocol data base -> select. )
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


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

PostPosted: Tue Aug 11, 2020 11:27 am    Post subject: Reply with quote

I have posted build 11 of RMIR v2.11 in the usual folder and also uploaded it to the SVN. To handle the TCL A/C protocol, see this post, I have needed to expand the syntax of the rm:translator element in IrpProtocols.xml. The rmProtocols.xml in build 11 includes replacement paragraphs of documentation describing this. I have tried to describe the edits needed in a form that I hope is clear, but I will merge it into IrpProtocols.xml if you like. Just let me know.
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1196

PostPosted: Sun Aug 23, 2020 6:06 am    Post subject: Reply with quote

I have merged the fixes to the TCL_AC protocol, as well as the comment updates. (Graham, can you verify that I got the latter right?).

However, I did not "take" the executor mapping for NEC-Shirriff-32, since it is not directly usable anyhow.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


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

PostPosted: Sun Aug 23, 2020 7:39 am    Post subject: Reply with quote

Thanks for doing the merge. The comments are merged correctly, however the TCL_AC entry is out of date. You appear to have used revision 1734. Since then it has been updated twice, first to 1736 and then yesterday to 1738, Revision 1738 is final, as it corresponds to Rob's final executor for this protocol rather than my various versions of it, but I have not yet posted a binary that includes this.

I would like to check your revised merge, when you have included that from 1738, as it uses a notation not used elsewhere in IrpProtocols.xml, as far as I can tell. This is the need to use numeric forms for <, > and & in the executor string within an rm:deployment element. I tried CDATA but it is not valid in that context. So it has & #60; for < and so on for other special characters (the space after # is to stop it being converted to < here also Rolling Eyes ). I know you now use an automated merge process that can do such things as change CDATA special characters back to their html forms, so for peace of mind I would like to make sure that it leaves & #60; and similar unchanged.

Quote:
I did not "take" the executor mapping for NEC-Shirriff-32, since it is not directly usable anyhow.

I'm not sure what you mean by this. Is it because it sets executor to an empty string? This is valid syntax and means that the executor wrapper is used in formatting the output for the learned signal parameters when imported into RMIR as learned signals when there is no executor that is valid for the protocol. In the case of NEC-Shirriff-32 there are no executors so this entry always applies and all data values are displayed as hex. So I hope you will include it.
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1196

PostPosted: Sun Aug 23, 2020 9:14 am    Post subject: Reply with quote

Silly me for not checking if there was a later version. Embarassed

Quote:
This is the need to use numeric forms for <, > and & in the executor string within an rm:deployment element. I tried CDATA but it is not valid

XML does not allow an attribute to contain a CDATA section. A rule of thumb for XML design says that only if something is "simple", you should put it in an attribute, otherwise an element. Is the "problem" important enough to warrant this re-design?

Any reason you do not use &lt; &gt; &amp; instead of the numeric entities?

NEC-Shirriff-32: This protocol is there only to communicate with the IRremote community. It is for those who "believe" that "the NEC protocol" is parametrized by one 32-bit parameter, msb first. Would it not be a better idea to put <irp:parameter name="prefer-over">NEC-Shirriff-32</irp:parameter> within NEC-f16, i.e. to suppress the NEC-Shirriff-32 decodes in favor of NEC-f16? They decode the same set of signals, and we have an executor for the latter.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


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

PostPosted: Sun Aug 23, 2020 11:24 am    Post subject: Reply with quote

Barf wrote:
A rule of thumb for XML design says that only if something is "simple", you should put it in an attribute, otherwise an element. Is the "problem" important enough to warrant this re-design?

No, this is the first time the issue has arisen and I cannot foresee any others, outside of further air-conditioning protocols Rolling Eyes , so not worth the effort to change. BTW the design, of including the executor string as an attribute, was yours Wink . I knew, and pretty well still know, very little about XML and just went along with code you provided for me.

Quote:
Any reason you do not use &lt; &gt; &amp; instead of the numeric entities?

I could have sworn I tried that and it didn't work, so I did a web search and found this link that said it was necessary to use the numeric form. But I have tried the mnemonic form again now and it works, so I have posted yet another version of rmProtocols.xml to the SVN that uses the mnemonic form. Thanks for pointing this out. I must have made a silly typo the first time.

Quote:
Would it not be a better idea to put <irp:parameter name="prefer-over">NEC-Shirriff-32</irp:parameter> within NEC-f16, i.e. to suppress the NEC-Shirriff-32 decodes in favor of NEC-f16? They decode the same set of signals, and we have an executor for the latter.

Fine, go ahead and do that. I had no idea why the Shirriff protocols were there and just came across some learns that decoded as them. If it will never show up in a decode then I am happy not to include my update for it. The facility to set the radix with this format of rm:translator will remain in RMIR but, at present at least, will not be used.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


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

PostPosted: Tue Sep 08, 2020 1:12 pm    Post subject: Reply with quote

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 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.

Edit: I forgot to say the most important thing, which is that 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.
_________________
Graham
Back to top
View user's profile Send private message
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, 4, 5, 6, 7, 8, 9  Next
Page 8 of 9

 
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
Get Smart! the band's official homepage Rockabilly Central