On May 21, 2010 22:26
Does anyone have an example of how to setup an ethernet-to-ir based device like the gc-100?
May 25, 2010
Haven't written down or tried GC yet. Did you get into issues with the regular TCP/IP configuration?
Excuse me for disturbing you, but I cannot reach a technical person for my problem.
I asked in another forum, but I have not had a reply.
Would it be possible to get information?
In fact, I am unable to connect remotely to my KNX, with the application OR KNX For Iphone !
With the TCP/IP setup, I see I can specify IP, port and a command. Im sure this gets openremote connected into the GC but then how do I pass through the IR commands for a specific device without having to create a command for each? I am probably missing something obvious.
Hi I have sucesfully tested the Global Cache unit using composer and iPhone How I set it up was under TCP/IP under the 4 headings I entered Label=Any Name IP= IP Addressof the unit Port=4998 Command=sendir,2:3,1,36000,1,1,97,30,16,15,16,15,16,31,16,31,32,15,16,15,16,15,16,15,16,15,32,31,32,15,16,15,16,31,16,15,16,15,16,15,16,15,16,15,32,15,16,31,16,15,16,720
This should output an IR signall on port 2 of GC100 unit. I captured this signall using th GC ir capture unit. They have several utilities on their web site one of which converts Pronto codes to GC format.
I hope this helps
So with this approach, I would have to capture all the IR commands for a given device and then enter those results into a TCP/IP setting in openremote one by one? That would be unfortunate if the device and its IR commands were already in openremote. Seems like this would be a good place for a plugin that would allow us to pick devices as they are already in openremote and have the plugin convert and send in the GC format on the fly. Is this possible?
Unfortunatly I am just a humble user and not a developer. This would be a good idea.
When composer is launched I believe there is a feature to save profiles as public or private if this is correct then users could share config files.
May 26, 2010
Yes this is a limitation with GlobalCache at the moment, there's no central repository of codes people have recorded and could be reused.
As Pierce mentions, we plan to have templates in the composer to be shareable between users. We will later look at if this could be used as some sort of solution for the issue you mention.
Thanks for bringing it to our attention. It is helpful feedback.
I see. So at the moment, OR assumes all IR will go through LIRC? And this is why the beehive DB is all stored in hex (I assume CCF format)?
May 27, 2010
Well, not really. We took the existing LIRC codes and put them into database because they were readily available. We don't assume IR must be LIRC, just that for other options (IP-to-IR like what GlobalCache does, or IRTrans for example) you need to record and feed the codes in yourself.
Eventually we hope to have other codes stored in central database as well so it will become easy for users to share them with each other.
We may be able to seed such databases based on what users store in their templates.
Jul 07, 2010
I'm not sure if you're still looking at this, but I was searching on gc-100, and came across this post. I am working on integrating a global cache device, and compared the gc-100 codes output to the CCF input codes when converting using global cache's conversion utility, and the codes are the same, but in a different format. They basically discard the first four groups of four bytes, convert the hex codes to decimal, and comma delimit them. I'm going to write a little java program to convert CCF to gc-100 using a file input, and here a description of how to convert the codes. So far I am only converting Samsung, so there are likely some other differences, but here's what I have observed.
The GC-100 codes always start with sendir,<mod-addr>:<conn-addr>,31,38000,<repeatcount>,1
The first four sets of four bytes of the CCF codes are ignored. Then convert the remaining hex value
to base ten, and put commas between.
0000 006D 0000 0022 00AC 00AB 0017 003E 0017 003E 0017 003E 0017 0013
then starting with 00AC (fifth set of four bytes), convert hex to decimal:
00AC -> 172
00AB -> 171
0017 -> 23
003E -> 62
0017 -> 23
003E -> 62
0017 -> 23
003E -> 62
0017 -> 23
0013 -> 19
append comma delimited to the start, to end up with:
Thanks, Paul. This is very useful. Would be interested in your conversion utility too if you plan to release it out in the open. As was said, eventually will host these codes in a central database to make the configuration easier.
Sure. Can I attach a zip file somehow? If not I can email it. It's very small – took about twenty minutes.
I would like to add my 2 (€-)cents to this.
First, the Globalcache API is not a secret, or a black art or something, but described very cleanly by its manufacturer, here. Moreover, on my homepage, here, I have a tool for converting LIRC-Codes to CCF ("Pronto")-Format. More precisely, it is a patch to Lirc enabling it to generate an XML-File as "output device". Optionally, the decodeIR-library is invoked to try to interpre the signals as one of the known IR classes. This XML file can be postprocessed to generate different formats, like Globalcache -- writing such a postprocessor in a language like Python, Java, Perl,... is essentially a matter of minutes. ("Learning" of IR-Signals is, in this context, an abomination!)
My Project contains a class for communicating with the GC, sending IR the CCF way as well as other stuff like connunicating using the RS232-Ports and accessing the relays. (It has developed a bit since the release I put on my web page.) I still would like to -- in some way or another -- contribute this as well as a bunch of other things to the project. LIRC is absolutely not the way to go. More soon (I hope, time permitting).
Nice to hear back from you.
Read that your Lirc2XML tool didn't get much attention on the LIRC mailing list but it will get a lot of attention here
I'd love to dig into it more but am a little pressed on time at the moment. But basically you've implemented the conversion tools we'd like to include in the OpenRemote project.
Please send me an email (juha at openremote.org)
Read through your page.. I'm gonna give the patch a try to see if I can get it to work on my Linux box.
Jul 08, 2010
Seems to work. At least it blurted out CCF of the LIRC apple remote that was sufficiently close to looking to similar what someone else had recorded for remotecentral.com
This is good, we can get from the LIRC database to CCF and seed it. Then there's a ton of CCF floating out there that we need to bring in, somehow (and then the cross section between LIRC and CCF that is not exactly the same pulse/waves, nature of the beast).
And by extension, we get GC as Paul demonstrated. Progress.
There was a small hickup with the patch, I got an undefined reference on is_XMP() call in LIRC type string function – had to comment it out for compile.
I'm gonna have to find time to seed Beehive, and add database schemas, and do batch processing for all the LIRC data we can pull through HTTP/REST, SQL, subversion...
Nov 04, 2010
Juha, running into this myself...
has the utility to translate been included? I would like to test the GC IP porting but this seems complicated at the moment.
Also the IP hardwired seems weird as GC emits a beacon? There is a way to harvest the IP which would seem more robust than hardcoding the IP address in every button.
Obviously this would mean a lifecycle for "plug-ins"...
Nov 05, 2010
If you want to take advantage of GC discovery, you'll need to add GC as separate protocol where fixed IP address is optional property.
and you do the look up statically? (if no lifecycle)
also writing to barry about the CCF beehive stuff and it sorts of hammers the point home for me that we should make the jump to CCF storage with LIRC and GC as an output.
Designer/beehive is where it is at.
Would just create thread to listen to the beacon and keep it in the background (in case the IP ever changes due to system issues but that is an 'advanced' use case
sure, email to me at juha @ openremote.org