Sanitising IR codes (for new plugin for KIRA)

[jinxdone]

This Keene IR over IP module seems like a very interesting piece of kit, I'll definately consider it when I do the next round of changes in my htpc setup.

Immediately I was thinking about a configuration with the EG in the middle of multiple of these devices sending and receiving IR signals like you guys mentioned a couple of posts ago. It would be great for the more complex setups.

[krambriw]

I have ordered a pair two days ago....they are on the way...I'm waiting

I'm going to use it to "sniff the air" together with a power mid receiver pyramid for rf-commands from all my remote controls used to control lights etc

This will be fun!

Best regards, Walter

[ldobson]

Right, 1.0.3 now in SVN (and updated in the URL I gave earlier). It is now possible to use it as a repeater - I've added a generic "ReceivedIR" event and am saving the incoming IR into "eg.ReceivedIR" to that it can be used in the TransmitIR action (and indeed, anything else that wishes to read/modify it along the way). There's a bit more documentation in there as well.

On that "eg.ReceivedIR" thing, are there any conventions I should be following here or is what I've picked OK?

[Bitmonster]

On that "eg.ReceivedIR" thing, are there any conventions I should be following here or is what I've picked OK?

It is no good idea to create new attributes in the eg. instance. Create the attribute in your plugin instance instead. Users can then access it on reaction of an event as "eg.event.source.ReceivedIR". But this is also not foolproof. For example some new data might arrive before the user has evaluated the last ReceivedIR event. And it might flood the EG log with a lot of noise if you get ReceivedIR events every time.

So I would suggest to supply a callback hook for scripting:

Code: Select all

class KIRA(eg.PluginClass):
    ...
    def RegisterIrReceiveCallback(self, callback):
        self.callback = callback
    ...

and the user can hook some code with it that is called on every IR reception like:

Code: Select all

def MyCallback(irData):
    print irData

eg.plugins.KIRA.RegisterIrReceiveCallback(MyCallback)

[ldobson]

Good stuff, thanks for that - although I'm wary of going this far as then it becomes an issue for a non-coder to be able to use it. I'll probably go with moving it into the plugin, and then maybe make it a configuration option as to whether you want those events or not.

[Bitmonster]

Well, I actually see no use of the raw IR data, except for routing it to another KIRA device. So maybe the best option would be to simply create an action like "route this reception to KIRA device X for transmission", that a user can assign to the decoded IR event (as the decoded IR is the only reliable event, that will differentiate between different buttons) but will actually route the raw IR data directly to the other device.

[ldobson]

I'm currently using it to repeat codes back to the same KIRA in order to get around the fact that it can't route IR from its sensor directly to its blaster (I want to do this so I can hide all my equipment in a cabinet). In order to do this for the buttons for 4 remote controls I'm using the generic ReceivedIR event rather than create events for each button. As you can imagine, I'd be there all day!

I can see why a ReceivedIR event happening each and every time would be overkill for most people though, hence I'll be making it configurable.

[Bitmonster]

I fear that we misunderstand each other.

When you receive some IR code, the plugin will generate a decoded IR event anyhow but stores the raw IR data in some buffer. As soon as the first stream is decoded and identified as a valid button press an event will happen, that easily can be assigned to a macro with a wildcard event match for example. But the "route IR" action will grab the temporarily stored raw data from the plugin and send it to another or same KIRA as long as the event that started it, is active (eg.event.isEnded).

This way the user has the option to only route discrete buttons, a group of buttons or all buttons for retransmission. And he can even build a "route everything that is not otherwise handled" setup, by using a wildcard event at the bottom of the tree and filtering out explicit codes with the "Stop processing" action. And the log will not be flooded, as such macros will only execute once for every button press and not hundred times for a single button.

Filtering buttons by the raw data is nearly impossible as it will not stay constant even for the same button. So a generic ReceivedIR event will only be useful for a "all or nothing" setup. And even this can easily be archived with a single "KIRA.*" event match for the decoded events.

[ldobson]

Aha! I was unaware of wildcard event matching. Or I was previously aware and had forgotten. Either way I now agree that there's no need for a generic event (although it only fires once per button press, not hundreds of times).

[ldobson]

1.0.5 now in SVN. Realised I should be using payload in order to solve the issue of subsequent events overwriting the raw data string. To do this I'm using:

self.handler.irDecoder.Decode(data, len(data))
self.handler.irDecoder.event.payload = rawCode

Is there a problem doing this? i.e. having the payload initially created as the default None and then assigning to it once the call to Decode has completed. If this creates a race condition then I guess a possible solution would be to have the payload as an optional parameter in the Decode function.

[krambriw]

Dear Idobson,

The plugin works very nice with the modules and I have some suggestions, inputs

One great usage is to send IR codes over the LAN. However, if you have pronto codes you have to convert them first. Instead of learning, you can use the java app for this provided by Keene download

I think you should actually look how the plugin for the USB-UIRT is made. Here you have settings for repeat count, wait etc

My experience is that repeat is necessary when sending IR...and should be introduced in the action "Transmit IR"

I have made a hard coded "modification" for my internal use and it works now much more reliable when I send my IR commands

Kind regards, Walter

[Melloware]

I think you should actually look how the plugin for the USB-UIRT is made. Here you have settings for repeat count, wait etc

Walter,

How did you accomplish this? Withe USB-UIRT the API has params for RepeatCount and InactivityWait time etc but for the KIRA it is just a UDP Packet send to the KIRA. There is no API.

So do you mean you added your own repeat count where you blast the same UDP packet X times in a row? I am confused, hopefully you can clear up what you mean.

[krambriw]

Dear Melloware,

Yes, I send the same stuff several times from the plugin with a short delay in between. This improved the reliabilty for controlling some of my devices (basically rf devices)

My "normal" config looks like this

PC-WinXP-EG -> USB-UIRT -> IR -> IR/RF Powermid Pyramid -> RF Devices power switches

What I try now

PC-WinXP-EG -> LAN -> KeeneIR standalone -> IR -> IR/RF Powermid Pyramid -> RF Devices power switches

Best regards, Walter

[ldobson]

Interesting stuff - of course I can look at this and beef it up, do you fancy mailing me your modified version so I can have a look at it? It would be useful if the Transmit IR action could take Pronto codes as well as native, if anyone can point me in the direction of some docs on the subject I can hopefully make that happen as well.

[krambriw]

Oh, my modification was just a quick/dirty/hard coded to see if I could make an improvement in controlling my stuff. I just modified part of your code as seen below. A nice implementation would of course allow that you can change settings for this (nbr of repeats and delay in between) in the action dialogue.

Regarding the other subject you are pointing at, I fully agree , it would be perfect if the plugin could support pronto directly. For this we need the algo that is used by Keene. I think we could ask Mark Fibiger at Keene directly if he could provide it for the EG project. I have spoken with him already a couple of times and he has been very helpful with other issues. One thing to think about is why it doesn't support pronto itself already. I guess it has to do with limited resources on board (memory etc), otherwise a little checkbox in the "options" would be perfect

Best regards, Walter

Edit: I forgot, you need also to add import of "time"

Code: Select all

import time

Code: Select all

    def __call__(self, mesg):
        for i in range(9):
            if i == 8:
                print "M: ", mesg
            time.sleep(0.1)

            mesg = eg.ParseString(mesg)
            codes = mesg.split()
      
            try:
                info = codes.pop(0)
                frequency = int(info[:2], 16)
                numpairs = int(info[2:], 16)
                data = [int(i, 16) for i in codes]
                if (
                    len(codes) == (numpairs * 2)
                    and
                    codes[len(codes) - 1] == '2000'
                ):
                    self.plugin.Send('K ' + mesg)
                else:
                    raise self.Exception()
            except:
                raise self.Exception('IR code does not conform to protocol')