|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Tue May 19, 2020 9:09 am Post subject: |
|
|
Release candidate for 1.2.6 avalable. This contains, among other changes, protocol updates suggested by Graham. |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Mon May 25, 2020 2:15 am Post subject: |
|
|
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 |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4530 Location: Cambridge, UK |
Posted: Mon Jun 08, 2020 12:24 pm Post subject: |
|
|
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 |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4530 Location: Cambridge, UK |
Posted: Mon Jun 08, 2020 12:47 pm Post subject: |
|
|
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 |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Mon Jun 08, 2020 1:10 pm Post subject: |
|
|
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 |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Wed Jun 10, 2020 7:35 am Post subject: |
|
|
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 |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Sun Jul 05, 2020 4:49 am Post subject: |
|
|
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 |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4530 Location: Cambridge, UK |
Posted: Sat Jul 11, 2020 12:30 pm Post subject: |
|
|
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 |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Wed Jul 15, 2020 1:59 pm Post subject: |
|
|
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 |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4530 Location: Cambridge, UK |
Posted: Tue Aug 11, 2020 11:27 am Post subject: |
|
|
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 |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Sun Aug 23, 2020 6:06 am Post subject: |
|
|
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 |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4530 Location: Cambridge, UK |
Posted: Sun Aug 23, 2020 7:39 am Post subject: |
|
|
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 ). 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 |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Sun Aug 23, 2020 9:14 am Post subject: |
|
|
Silly me for not checking if there was a later version.
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 < > & 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 |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4530 Location: Cambridge, UK |
Posted: Sun Aug 23, 2020 11:24 am Post subject: |
|
|
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 , so not worth the effort to change. BTW the design, of including the executor string as an attribute, was yours . 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 < > & 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 |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4530 Location: Cambridge, UK |
Posted: Tue Sep 08, 2020 1:12 pm Post subject: |
|
|
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 |
|
|
|
|
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
|