JP1 Remotes

Posted: **Tue Oct 04, 2011 10:35 pm**

Hi barf,
I guess I was way too terse. I like the IrpMaster program, and as I said, I use it. Also, I think there are some real possiblities to make use of the parser in additional applications. Furthermore, I agree that some extensions to the existing IRP specification would be useful, and I suppose the least controversial of these would be permitting multi-letter mixed-case variable names.

I was instead responding to why I included IRP files for the protocols recently added to DecodeIR. Put simply it's because MakeHex and the accomanying GUI is much easier to use, IMO, than IrpMaster in a command line version. The primary users of MakeHex, and potential users of IrpMaster hang out at RemoteCentral. I can't in good faith implicitly recommend that they switch to a CLI-based solution which has "complicated command lines". And I'm certainly not going to suggest that they load cygwin! (FWIW, I'm used to DOS/OS2/Windows CLIs, and cygwin--which I have, and am obliged to use for MinGW-- is not "much better" for me. I'm accustomed to something else.)

Regarding my "bold statement", it isn't bold at all. I'm not sure what "hierarchical repetitions" are, but perhaps this refers to the Variations described in Section 12 of the IRP spec. I've tried to make new additions to DecodeIR.html be in correct and complete IRP form, and I attempted to use IrpMaster as a check for a legal expression. Consider Zaptor, as described in DecodeIR.html 2.43:

Code: Select all

{36k,330,msb}<-1,1|1,-1>[T=0] [T=0] [T=1] (8,-6,2,D:8,T:1,S:7,F:8,E:4,C:4,-74m)+ {C = (D:4+D:4:4+S:4+S:3:4+8*T+F:4+F:4:4+E)&15}

So far as I know, the use of Variations is the only way to correctly describe Zaptor. For consistency, I want to use the same Variation form to describe the closely related Amino protocol:

Code: Select all

{56.0k,268,msb}<-1,1|1,-1>[T=1] [T=0] (7,-6,3,D:4,1:1,T:1,1:2,0:8,F:8,15:4,C:4,-79m)+ {C =(D:4+4*T+9+F:4+F:4:4+15)&15}

IrpMaster doesn't accept these forms. I don't consider this to be a bug at all; rather it is a missing feature.

Part of the issue here is that IRP is a notation for describing abstract IR protocols. Pronto Hex is a method of writing a particular IR signal. It is quite possible to use Pronto Hex to describe a signal that Zaptor boxes will recognize and respond to. But Pronto Hex doesn't have the capability of describing a Zaptor signal which persists for an indefinite number of repeats, so programs based on IRP notation would seem to need additional parameters to generate a usable signal. There is an additional practical issue for Pronto Hex. Many universal remotes accept Pronto, but add their own notions of how many repeats are to be sent. A fair amount of MakeHex activity centers around modifying a "correct" representation into one which will work with a particular remote model. IRP is much better suited to describing correct and general signals, than to describing a bastardized one.

Posted: **Wed Oct 05, 2011 1:39 pm**

Hi Graham,

mathdon wrote:
3FG wrote:Probably even better would be the combination of IrpMaster along with the capability to decode unknown IR signals to a legal IRP notation. That would allow users to learn a set of signals, and then translate that to a well-formed set, without requiring the aid from an IR expert. mathdon has made some progress with the latter part, but it isn't yet applicable to most signals.
My first attempt in IR.exe and IRScope to decode unknown IR signals into IRP notation met with almost total lack of interest. With one notable exception (ElizabethD) the few comments I received ranged from indifference at the upper end to hostility at the lower one. This did not encourage me to continue the development.

Hmm, I always had the impression that you were a highly celebrated member of the community, but of course it probably does not apply to all issues. The "automatic recognition" sits in ExchangeIR.dll, right? Is the 0.08 version still the current? Is there any API-documentation more than the comments in the code? I may come up with something

Thanx for GPL-ing it!!

Like Barf, I feel that IRP notation lies at the heart of JP1. It is, or should be, the glue that joins together the different aspects of protocol decoding and protocol building, yet any mention of it seems anathema.

Agreed, but still that does not put it in the realm of "users". Like Latin is the scientific language in medicin, yet the physicians do not try to talk Latin to patients. There are, in order, Logitec users, IR/RM/RMIR-(normal) users, advanced users, and experts. The advanced users know that an IRP is a "program" to be rendered to a raw format (like Pronto) by a program, just as a MIDI files is rendered to a wave file, or a C program us compiled to an object file, but they do not understand it. The "experts" can read and write IRPs. It is a matter of identifying the target group. If we try to teach IPR to normal users, IMHO we will end up disappointed. For example, the discussion here is aimed at experts, advanced users also allowed.

This is why I did not attempt to improve the IRP representations in DecodeIR.html when I was working on DecodeIR.dll, as I felt it was simply not worth the effort it would take.

Sorry to hear that. Here is room for improvements. Frankly. I do not consider the response to my postings the last month to exactly soliciting my help...

But finally, you are one of the persons, possibly THE person, that I am most interested of getting feedback from. Did I implement everything correctly? What is your opinion on the extensions? I have a slightly different model for persistent variables. Your opinion is valuable and solicited. Improvements? Suggestions? I have not yet received any substantial feedback, yet you post in my thread your dissatisfaction with feedback on your work. No criticism intended, but it feels ... strange.

BTW, I am a happy user of your 7781-Extender since several years!

Posted: **Wed Oct 05, 2011 1:44 pm**

Hi Vicky,

While I find the IRP helpful, I still mutter every time I look at a learn in IR, because the IRP form is in the non-scrollable area and the stuff I need to see is scrolled to where I can't see it all at once

IrpMaster can generate a graphic representation of an IRP, like this. Do you see any usage of this feature?

(Actually, it is a feature of the ANTLR parser system, I just turned it on.)

Posted: **Wed Oct 05, 2011 2:25 pm**

Hi 3FG,

I'm not sure what "hierarchical repetitions" are,

hierarchical repetitions are, not surprisingly, a hierarchy of repetitions, i.e. repetitions that contain other repetitions. Like {...}(...(...)+ ...)+. This issue is discussed in the documentation; the bottom line is that there is no know use case for it, and it is questionable if it makes more sense than a grammatically correct nonsensical sentence. Variations are implemented however.

and I attempted to use IrpMaster as a check for a legal expression. Consider Zaptor, as described in DecodeIR.html 2.43:
Code: Select all
{36k,330,msb}<-1,1|1,-1>[T=0] [T=0] [T=1] (8,-6,2,D:8,T:1,S:7,F:8,E:4,C:4,-74m)+ {C = (D:4+D:4:4+S:4+S:3:4+8*T+F:4+F:4:4+E)&15}

It is true that IrpMaster rejects it, but it is because it is invalid IRP! See the specification. IrpMaster does the right thing. Now, lets fix the syntax:

Code: Select all

$ java -jar dist/IrpMaster.jar  --decodeir -p -i "{36k,330,msb}<-1,1|1,-1>([T=0] [T=0] [T=1], (8,-6,2,D:8,T:1,S:7,F:8,E:4,C:4,-74m))+ {C = (D:4+D:4:4+S:4+S:3:4+8*T+F:4+F:4:4+E)&15}"   E=12 34 56 78
libraryFolder=/home/bengt/harc/IrpMaster/Linux-amd64
Loading /home/bengt/harc/IrpMaster/Linux-amd64/libDecodeIR.so
Loaded /home/bengt/harc/IrpMaster/Linux-amd64/libDecodeIR.so
WARNING: Parameter specs are missing from protocol. Runtime errors due to unassigned variables are possile. Also silent truncation of parameters can occur. Further messages on parameters will be suppressed.
Device Code: 34.56 Function: 78, E=12
WARNING: When computing the Pronto representation, a (non-empty) ending sequence was ignored
0000 0073 0000 001A 005F 0047 0018 000C 000C 000C 0018 0018 000C 000C 000C 000C 0018 0018 000C 000C 000C 000C 0018 000C 000C 000C 000C 0018 000C 000C 000C 000C 000C 000C 0018 0018 000C 000C 0018 000C 000C 000C 000C 0018 0018 000C 000C 0018 000C 000C 0018 000C 000C 0018 0018 0A74
DecodeIR result: protocol = Zaptor-36, device = 34, subdevice = 56, obc = 78, misc = E = 12

'Nuff said? Same stuff goes for the second example; incorrect as it stands, fixed it runs correctly.

I previously wrote

As I wrote previously, the IRP notations in DecodeIR.html are of low quality. Having them to be parseable would help to keep errors out.

You have very vividly shown how correct this is.

But I also like to raise the issue why you did not report the "bug" when you "found" it, only when I forced you to back up the statement of incomplete implementation? (Features that are claimed to be implemented, but are not, I call "bugs".)

So far as I know, the use of Variations is the only way to correctly describe Zaptor. For consistency, I want to use the same Variation form to describe the closely related

Slightly off topic, a variation can always be rewritten using considerable duplications.

Part of the issue here is that IRP is a notation for describing abstract IR protocols. Pronto Hex is a method of writing a particular IR signal. It is quite possible to use Pronto Hex to describe a signal that Zaptor boxes will recognize and respond to. But Pronto Hex doesn't have the capability of describing a Zaptor signal which persists for an indefinite number of repeats, so programs based on IRP notation would seem to need additional parameters to generate a usable signal. There is an additional practical issue for Pronto Hex. Many universal remotes accept Pronto, but add their own notions of how many repeats are to be sent. A fair amount of MakeHex activity centers around modifying a "correct" representation into one which will work with a particular remote model. IRP is much better suited to describing correct and general signals, than to describing a bastardized one.

Let me suggest that you say "parametrized protocol" instead of "abstract protocol" and "non-parametrized" or "raw" instead of "a particular" signal. Probably everyone in this forum agrees on your general message. A Pronto signal can contain an intro signal, and exactly one repetition, that the "device" decides on how many times it is sent. (The message a few lines earlier "WARNING: When computing the Pronto representation, a (non-empty) ending sequence was ignored" above means that Pronto representation cannot represent an ending signal.)

Now it is my turn to make a bold statement:

Writing a program/library like IrpMaster is a much harder task that to write a GUI for such a program. While IrpMaster consists of around 6000 line of java and it took months to write. A GUI would be, I estimate, 1000-2000 lines, most of which can be automatically generated by an IDE like Eclipse or Netbeans, and it would take days.

And, repeating myself, a GUI might show up in the future.

Posted: **Wed Oct 05, 2011 5:13 pm**

Barf wrote:Hi Graham, ... you are one of the persons, possibly THE person, that I am most interested of getting feedback from. Did I implement everything correctly? What is your opinion on the extensions? I have a slightly different model for persistent variables. Your opinion is valuable and solicited. Improvements? Suggestions? I have not yet received any substantial feedback, yet you post in my thread your dissatisfaction with feedback on your work. No criticism intended, but it feels ... strange.

BTW, I am a happy user of your 7781-Extender since several years!

Sorry, Barf, it's a question of time and priorities. At present my time is being spent on developing Protocol Builder facilities in RMIR. I find it easiest to concentrate on one thing at once, so I'm afraid I haven't looked at IrpMaster yet. Glad you like my extender.

Posted: **Wed Oct 05, 2011 9:48 pm**

Barf,
Yes, I wrote the IRP incorrectly. The reason I didn't submit a bug report is that I didn't think it was a bug. Variations are not mentioned in the documentation (not that it needs to be), and I didn't pick up your intent to implement all of IRP minus the hierarchical repetitions. The document describes hierarchical reps in the context of button down, button held, and button released, which is the situation the variations in my faulty IRP are trying to express. So I believed that hierarchical reps (which aren't mentioned in the IRP spec) referred to variations, and thus believed that variations weren't implemented.

However, my error illustrates the point I have been trying to make: the combination of writing IRP notation for input into IrpMaster is too difficult for me. I believe that it will be too difficult for many others.

I'll continute to use IrpMaster, because it has real value for me.

Posted: **Thu Oct 06, 2011 9:50 am**

Barf wrote:Hi Vicky,
IrpMaster can generate a graphic representation of an IRP, like this. Do you see any usage of this feature?

(Actually, it is a feature of the ANTLR parser system, I just turned it on.)

I find the diagram to actually be more difficult to understand than plain IRP, but then perhaps I don't have the correct background to analyze and understand it. Just because I don't see how this would help users understand signals doesn't mean anything. This whole IRP thing never came naturally to me. I was always in awe when newbies used to talk IRP with John Fine and yet I had been reading the forum for years trying to make sense of the timing numbers and IRP and was still clueless. When I had my epiphany, and could finally understand what Rob and John were talking about, I wrote a document to help others gain a basic understanding. My document is more of an IRP for dummies, for people like me who are struggling with the whole infrared subject. Being able to read IRP is a huge help in understanding what signals look like, but I still can't write IRP, even after years of struggle. My document is not as technical as Graham's guide to IRP. I read Graham's technical spec often, but I'm still struggling with comprehension.

Posted: **Thu Oct 06, 2011 12:44 pm**

mathdon wrote: Sorry, Barf, it's a question of time and priorities. At present my time is being spent on developing Protocol Builder facilities in RMIR. I find it easiest to concentrate on one thing at once, so I'm afraid I haven't looked at IrpMaster yet. Glad you like my extender.

Ok, there is of course no way not to respect your priorities, but possibly appealing to a sense of interest in an issues you more-or-less stated one and a half year ago. Without your specification, IrpMaster almost surely would not exist. Don't worry about debugging or bug reports, just reading the documentation and writing down what comes on your mind would be of great value.

vicky2003 wrote:I find the diagram to actually be more difficult to understand than plain IRP, but then perhaps I don't have the correct background to analyze and understand it.

Ok, so lets not pursue that path any further. The diagram is a parse diagram, that computer scientist like. It is just a waste product of the parser anyhow.

vicky2003 wrote:This whole IRP thing never came naturally to me. I was always in awe when newbies used to talk IRP with John Fine and yet I had been reading the forum for years trying to make sense of the timing numbers and IRP and was still clueless. When I had my epiphany, and could finally understand what Rob and John were talking about, I wrote a document to help others gain a basic understanding. My document is more of an IRP for dummies, for people like me who are struggling with the whole infrared subject. Being able to read IRP is a huge help in understanding what signals look like, but I still can't write IRP, even after years of struggle.

As I wrote previously, IRP is hard, and it is because it covers a difficult subject, and solves a difficult problem. You should never expect a difficult problem to have a simple solution. "Teaching IRP to the masses" is neither necessary nor desirable, and will only lead to disappointment. IMHO, there is not much more need for "IRP for dummies" than for "Functional analysis for dummies". (I sincerely apologize and regret if you find this discouraging, Vicky.)

3FG wrote:Variations are not mentioned in the documentation (not that it needs to be), and I didn't pick up your intent to implement all of IRP minus the hierarchical repetitions. The document describes hierarchical reps in the context of button down, button held, and button released, which is the situation the variations in my faulty IRP are trying to express. So I believed that hierarchical reps (which aren't mentioned in the IRP spec) referred to variations, and thus believed that variations weren't implemented.

Ok, My problem is that I have a scientific consciousness, if something is not complete, I will not call it complete either, even if the missing piece has no practical importance whatsoever, as in this case. Instead it leads to misunderstandings,

If you have constructive suggestion on improving the documentation, I would be grateful.

3FG wrote:However, my error illustrates the point I have been trying to make: the combination of writing IRP notation for input into IrpMaster is too difficult for me. I believe that it will be too difficult for many others.

IRP is hard. How can anything dealing with "curses" like

Code: Select all

{36k,330,msb}<-1,1|1,-1>([T=0] [T=0] [T=1], (8,-6,2,D:8,T:1,S:7,F:8,E:4,C:4,-74m))+ {C = (D:4+D:4:4+S:4+S:3:4+8*T+F:4+F:4:4+E)&15}

be considered easy? With or without GUI. But what I do not buy is that cutting-n-pasting a "curse" like the above into a GUI like in a screenshot in a previous posing of mine is easy, while cutting-n-pasting it to a command line interpreter is hard. It can also be pointed out that giving the IRP on the command line (the -i option) is not the normal case; the normal case being using a configuration file and calling the protocol by its name. Still, can be done! And it can be published in web forums like this, without resorting to those pesky screen shots.

3FG wrote:I'll continute to use IrpMaster, because it has real value for me.

Great. I look forward to your constructive suggestions, criticism, and (yes!) bug reports.

Posted: **Thu Oct 06, 2011 2:47 pm**

Barf wrote:
vicky2003 wrote:This whole IRP thing never came naturally to me. I was always in awe when newbies used to talk IRP with John Fine and yet I had been reading the forum for years trying to make sense of the timing numbers and IRP and was still clueless. When I had my epiphany, and could finally understand what Rob and John were talking about, I wrote a document to help others gain a basic understanding. My document is more of an IRP for dummies, for people like me who are struggling with the whole infrared subject. Being able to read IRP is a huge help in understanding what signals look like, but I still can't write IRP, even after years of struggle.
As I wrote previously, IRP is hard, and it is because it covers a difficult subject, and solves a difficult problem. You should never expect a difficult problem to have a simple solution. "Teaching IRP to the masses" is neither necessary nor desirable, and will only lead to disappointment. IMHO, there is not much more need for "IRP for dummies" than for "Functional analysis for dummies". (I sincerely apologize and regret if you find this discouraging, Vicky.)

Interesting. When I was trying to get Graham to move the RAW Irp form to another portion of the screen in IR, my argument was much the same. I thought that seeing the IRP on the learn screen made the screen less than friendly for the newbie and should have been an "advanced Menu" item, the way the raw timings are. However I do think having IRP knowledge is something that should be available to anyone here who wants to know.

I sure am glad that Rob and John didn't feel that educating the "masses" in IRP to be unnecessary and disappointing. They may have felt it was hopeless at times,

but they didn't give up on me and I appreciate the effort.

Posted: **Tue Oct 25, 2011 1:00 pm**

I just uploaded a new version. Only user visible feature is that Graham Dixon's automatic protocol analyzer, originally a part of his ExchangeIR library, (see this) and included in the latest versions of IrScope, is supported through use of the --analyze flag, just as the --decodeir flag. There are some more API-functions that I needed myself, in particular for IrMaster (Yes, the name of that program differs from the present one by only one letter!

)

I have changed the location of the sources, from tools/programs to misc/Program sources since I suspect that is Rob's intention. Souce download.

Keep IrpMaster-ing and IRP mastering!

Posted: **Wed Feb 15, 2012 12:46 pm**

I am very interested in this tool.

In the simplest form, I would like the ability to have a simple html file running on a "personal web server" computer close enough to the media equipment so that when a link in the html file was clicked, that link would call something such as your tool to issue a specific command from the computer's ir dongle.

On the server, the link should be able to call the api along with an argument to generate a specific ir command.

With this capability any device with a simple web browser connected to the personal server would be able to issue ir commands needing no local software to do so.

fwiw, I have thirty years experience with FoxPro and it would be (relatively) simple for me to write a windows application that would generate html files containing small screen layouts with command links drawing from IR commands stored in local files. It would also be possible to allow the users to choose their specific devices and generate html pages tailored for their devices.

More importantly, once the templates are generated, anyone with basic html editing capabilities could further customize the html pages to meet their own needs.

Please contact me if this approach is at all interesting to you.

Beverly Howard
Bev@BevHoward.com

Posted: **Wed Feb 15, 2012 3:12 pm**

Hi Bev,

there are some approaches to controlling IR-equipment through a web browser already: There is Openremote which contains a web-services based server (tomcat e.g.) which can send IR commands using e.g. GlobalCache (although the configuration is awkward). The user sends commands either through a web interface or a ipad/ipod/android/you-name-it-interface. Then there is Eventghost, a general purpose home/windows-automation tool, being able to send IR commands through e.g. GlobalCache or USB-UIRT, and containing a web-server for accepting user commands. Girder is essentially a commercial counterpart to Eventghost. And then there is or course LIRC. In the first three cases, the programs, or their configurations, contains the rendered IR signals, most often in Pronto format. Most things you suggested should be possible to do with one of these tools. It is is or course not as elegant as being able to render them just-in-time from e.g. a protocol-name/devicenumber/commandnumber-description. The commands are entered either pre-rendered from some source, or, anacronistically, recorded ("learned") from existing remotes. From a practical point of view, this "beaty spot" should probably not be exaggerated, at least not as long as the signals are "clean". (LIRC has its own format, often considered to be unusable, see this however.)

I intend to integrate IrpMaster into OpenRemote as soon as I get some free time. Also the next version of IrpMaster/IrMaster will support LIRC directly; both sending commands to a (patched) LIRC server (on the TCP port) and generating configuration files for LIRC from an interval of command numbers. (It is in principle finished, I have just not had the time to release it yet.)

BTW, you may like to check out my other IR-related open.source project, Harctoolbox.

Posted: **Wed Feb 15, 2012 3:24 pm**

Thanks for all of the links and information... a bit overwhelming since the last few times I made similar requests, I found little to nothing.

I will look at all of these and expect I will be back for more info and discussions.

Thanks again... and, please stay tuned.

Beverly Howard

Posted: **Fri Feb 17, 2012 9:42 pm**

While I have not waded through all of the links you gave me, I have read enough to learn a lot.

All of the options, except Barf's, have their own baggage load and design approaches that add complexity that I think can be avoided.

In looking at your app, I wondered if you knew about
http://www.byremote.com.au/HIP/Default.htm

I have tinkered with this software a few years back, but, my primary concern with it was that there was no way (at least apparent to me) to import and easily handle a number of remotes and all of their commands.

This software does allow capturing, viewing, saving and rebroadcasting ir commands but I never got to drilling down enough to find out how to implement it's commands from another program.

I have to also admit I am intimidated by JAR files... I tried, unsuccessfully, to learn Java a little over a decade and have had mixed success with the JAR utility available here.

At the moment, my main goal is to try and learn how to issue command lines to your software from a local IIS (formally personal web server) page. If I am not too dumb and too old to do that, I think 90% of the quest will have been met.

Thanks again. Any tips (not already in this thread) on a dummy downloading your JAR files and executing them? Looks like I have Java 6 update 7 on the XPPro machine I will be experimenting on.

Thanks in advance,
Beverly

Posted: **Sat Feb 18, 2012 2:20 pm**

I have not looked into the HIP-Tool; however I read the web page. I get the impression that Eventghost can do everything that tool can do, and more. Most importantly, Eventghost is -- as opposed to the HIP -- free software (with source code), technically GPL.

All of the options, except Barf's, have their own baggage load and design approaches that add complexity that I think can be avoided.

I am a bit puzzled by that statement.

I have to also admit I am intimidated by JAR files... I tried, unsuccessfully, to learn Java a little over a decade and have had mixed success with the JAR utility available here.

jar-files are, as the name suggests (Java ARchive), nothing but a sort of archives, similar to zip-files. There is nothing intimidating about that. Anything in the instructions that was unclear or could be improved?

At the moment, my main goal is to try and learn how to issue command lines to your software from a local IIS (formally personal web server) page.

If I strip out tool names from your request, it seems (on the basis of your previous posts) that you want a web server that sends commands to an IR dongle (MCE?) causing it to send IR signals to your equipment. Eventghost should be suitable for this; it has a www-server and should support the dongle. You can use Ir(p)master offline to generate your configuration files. Eventghost also has its own active community and forum.

Any tips (not already in this thread) on a dummy downloading your JAR files and executing them?

You might like to use IprMaster in the form of IrMaster, you may find it to be easier.

JP1 Remotes

IrpMaster, program/library for IRP rendering, released