LIRC Client

[hesl]

I think it's ok now.

With "list remotes" disabled:

Code: Select all

LIRC Client: Received an malformed response from the LIRC-server

With "list remotes" enabled:

Code: Select all

LIRC Client: Received an malformed response from the LIRC-server
LIRC Client: Received an erroneous response from the LIRC-server
Message data: ['bad send packet']
LIRC Client: Received an malformed response from the LIRC-server
LIRC Client: No remotes found!
LIRC Client: You can disable sending LIST on connect if it does not work on your setup

In both cases I get keystrokes from the Lirc server.
Thanks for your swift updates!

-Hein

[jinxdone]

Looks like there is still something wrong with it.. I think I will have to install a *nix lirc at some point and see for myself what is causing those malformed response warnings. Probably it's got something to do with different newline characters being expected.

But in the meantime it should receive the events just fine. I'll post a note about the next version after I'm done with it.

Thanks for your help and a bit of your time hesl!

-jinxdone

[MCP99999]

Hi,

i have IRTrans installed and Eventghost 0.3.7.r1030 (on it Lircclient 0.7.1)....runs great.

Now i would like to update to the newest svn but if i load the lircclient-plugin this message comes:

LIRC Client: Received an erroneous response from the LIRC-server
Message data: ['Unknown LIRC Command received: VERSION']

[jinxdone]

Hi,

You can ignore that message. It's basically telling you that your lirc-server(irtrans) does not support the version command sent by the lirc client. It should work just fine regardless.

You'll get rid of the message when I rewrite the plugin using some other network socket handler, but havn't had time or inspiration to do that yet.

-jinxdone

[MCP99999]

@jinxdone thx a lot for your reply

[Cjcr]

Hello everyone,
I need information about the command "LIST" and "VERSION". How it works and it for serves?
I would like to implement in an server software (LIRC).

Thanks.

ps: sorry for me bad english.

[jinxdone]

Hello everyone,
I need information about the command "LIST" and "VERSION". How it works and it for serves?
I would like to implement in an server software (LIRC).

Thanks.

ps: sorry for me bad english.

The protocol is very simple, you can find info about the commands at the lirc docs. http://www.lirc.org/html/technical.html#applications

-jinxdone

[Cjcr]

Explain me this (please):

Code: Select all

BEGIN
  <command>
  [SUCCESS|ERROR]
  [DATA
  n
  n lines of data]
  END

[jinxdone]

Sure. When you explain a command syntax the standard way of marking up things is:

<> = mandatory argument
[] = optional argument
<one|two|three> = mandatory argument, must be either "one", "two" or "three".
[one|two|three] = optional argument, could be either "one", "two", "three" or none of them.

Let's take some examples. Command from client and a typical server response.

Code: Select all

Client sends command:
VERSION

A successful response from the server should return the version of the lirc server:
BEGIN
VERSION
SUCCESS
DATA
1
Cjkr's Lirc server v1.0
END

Code: Select all

Client sends command:
LIST

A successful response from the server should give a list of all the configured remotes:
BEGIN
LIST
SUCCESS
DATA
2
MyRemote
Another_Remote
END

Code: Select all

Client sends command:
LIST Another_Remote

A successful response from the server should return a list of all the commands(usually buttons of remote) for a remote named "Another_Remote":
BEGIN
LIST Another_Remote
SUCCESS
DATA
3
BUTTON_1
PLAY
PAUSE
END

In case the client sends a bad command or some error occurs etc. you should respond like:

Code: Select all

Client sends command:
BADCMD

Server response:
BEGIN
BADCMD
ERROR
DATA
1
Unknown command "BADCMD".
END

Code: Select all

Also a valid respose to the earlier could be (because you can omit the entire DATA lines, they are optional):
BEGIN
BADCMD
ERROR
END

And according to the docs, this would also be valid:
BEGIN
BADCMD
ERROR
DATA
0
END

Obviously you should always return a line of data telling what the error was, but just to clarify things the two latter ones are technically good responses.

I hope this helped.

-jinxdone

[Cjcr]

First, thanks for reply and explain me.

this:

Code: Select all

BEGIN
VERSION
SUCCESS
DATA
1
Cjkr's Lirc server v1.0
END

Send all in one packet?

See this:

Your Lirc Client send me:

VERSION

And then respond:

BEGIN
VERSION
SUCCESS
DATA
1
Cjkr's Lirc server v1.0
END

All in the same packet?

[jinxdone]

Yes, exactly. The client will then read your response line-by-line and parse it.

-jinxdone

[Cjcr]

Thanks

I'll try tomorrow ...

BRs,
cjcr.

[cstrutton]

I am not sure if this thread is dead but I have been experimenting with EventGhost and Lirc. I believe the bad list response is due to the response from Lirc being split amongst more than one packet. Your code seems to expect everything in one read. I have written a Lirc module and a plugin that correctly handles the data from lirc. It is rough around the edges but hopefully someone with more python experience can help clean it up (ie error checking etc.)

[jinxdone]

No, the thread is very much alive still.

In practice it's not a big problem that it expects to receive a command as one read, but you're right, it is a shortcoming. Actually it wouldn't be that hard to fix it to wait for more data to arrieve incase of tcp/ip fragmentation during listing. I'm pretty sure the reason why there's problems with the LIST command is that some hardware vendors havn't bothered to implement the command, for me it's working just fine. Anyway, since the lirc plugin mostly works just fine improving it hasn't been that high on my to-do list.

Originally I just wanted it to receive the normal lirc commands, which are pretty short one-liners, and it just evolved from there. If I would write the Lirc plugin today I would take a different approach to it.

I have been meaning to rewrite the plugin using some other network library entirely. All I can say about asyncore (and asynchat) is to advise to stay away from it if at all possible. It has some issues that I ran into while working with the Lirc plugin. For example it does not update the connected state until some data is sent or received over the tcp/ip connection. The problems I ran into were in the asyncore itself, so not something I would attempt fixing.

Generally speaking people are holding twisted in high regard around the net so that's what I've been meaning to look into..

I'm convinced though that the next step is to redo it entirely with something better than asyncore/asynchat, so this is something I wish and recommend you to look into as well. If you want to continue development of the plugin feel free to improve upon it. If not then I will probably redo it myself sooner or later.

PS. I couldn't get your plugin to connect.. it dumps my eg log full of "Waiting for Chat.Connected" and then some exception.

-jinxdone

[dukey]

Hi,
I fixed a load of bugs in the WinLIRC server. Crash vulnerabilities caused by malformed information sent to the server. There were also some show stopper bugs with regards to sending. You needed to set the password SEND_ONCE in the registry for it to work previously, but even this didn't work properly because the transmit string wasn't NULL terminated, so it was pure luck whether it worked. WinLIRC should support most of the LIRC protocol reliably now.

I tried getting sending to work with the MCE plugin included with eventghost, but it resulted in a cataclysm and crashed eventghost. You might have more luck with my own MCE plugin.

Enjoy