Raspberry Pi accepting IR commands and updating my isy994i

[arw01]

SUCCESS! With a lot of help from Ben at iguanaworks.net, I know have my Raspberry pi translating a couple of Tivo remote buttons to a rest command to update the isy state variables.

 

Next few days I will flesh this out and post an article on the wiki.

 

But the basic gist is:

 

Raspberry Pi version B

 

follow instructions on iguanaworks.net site to apt-get their drivers and compile lirc

 

test out the lirc and igdaemon are working

 

run irrecord from lirc to "learn" your remote buttons

 

combine the config files

 

start up the lirc daemon

 

create a .lircrc config file for use with irexec and start it as a daemon

 

adjust your programs in the isy to respond to variable updates and if you have the networking module (which I don't yet) then I could send commands back to the Pi when I write up some sort of listener app to send IR out the iguanaworks transceiver or some other ir blaster you can talk to. e.g. a ip2ir from iTach.

 

Right now I just update a occupied variable, but plan to really flesh this out in the next few weeks after I get the network module.

 

Alan

[io_guy]

Pretty cool.

I'm in the process of doing something similar because of issues I'm having with the ISY's built in IR.

Going to be using a GC-IRE and a "GCLink" program to send variables to the ISY. IR learning will be GUI based. The nice thing about that unit is it does the full spectrum of IR frequencies, not just 38kHz.

 

On the send side, with an IP2IR you can send commands directly from the network module, no need for a middle man.

[arw01]

Pretty cool.

I'm in the process of doing something similar because of issues I'm having with the ISY's built in IR.

Going to be using a GC-IRE and a "GCLink" program to send variables to the ISY. IR learning will be GUI based. The nice thing about that unit is it does the full spectrum of IR frequencies, not just 38kHz.

 

In your case the "GCLink" will be the middle man?

 

 

 

On the send side, with an IP2IR you can send commands directly from the network module, no need for a middle man.

 

I bought one of those as well, not knowing that it could not "receive" commands out of the air. It is pretty slick to send codes from. It's a $100 investment and that pretty much covers both the Pi and the iguanaworks and the emitters and splitters. Plan to spend a little time looking for the utility that lets me send the codes out the lirc transmitter next and then figure out the rest of the middle man code.

 

Ultimately, I hope to init script all the programs so when the kids unplug the pi I don't have to log in and restart it all. That will make it more like the iTach devices where they just work.

[io_guy]

Yep, GCLink will be middle man.

The GC-IRE is an infrared receiver which processes the IR commands and sends their data as ASCII packets over RS-232.

 

GCLink will support RS-232 so it would be run on the same computer as the GC-IRE is plugged into, or as a TCP client which could run on any computer. I plan to run it this way and just connect my GC-IRE up into my multi-port serial server (and GC-Link would run on my Pi or Synology).

[arw01]

Tonight I was able to get the irsend command figured out. and just for the search engines an example of the --count=2 option is counter intuitive:

 

irsend --count=2 SEND_ONCE yamaha yamaha_volume_up

 

You still need the SEND_ONCE in there that makes no sense to me.

 

My current iTach ir cable I am using may be a bit too weak, but I have more playing to do with placement etc.

 

Next few days will be figuring out the perl programming scripts and seeing what I can wrap together.

 

Alan

[arw01]

with the help of this handy little website to convert cpan modules for perl to apt-get packages.

 

http://deb.perl.it/debian/cpan-deb/

 

I was able to install the LWP::UserAgent package and the XML::Simple package.

 

This allows the perl modules Peter wrote to talk to the ISY, list the variables, set variables etc.

 

Next step will be starting to figure some sort of subscription to the ISY, in that I can then get updates from the ISY for whatever it will send out in that manner. I assume, at the very least, you can monitor the value of variables being changed and update variables in a quick fashion.

 

It's my hope that I can get the conversation going so that when I hit a remote button and I update a variable, the isy can send me back what the irsend program on the pi is supposed to do next, etc. I suppose I could look at some sort of webserver on the pi that would execute perl modules with the various calls.

 

Anyone with some experience with this stuff care the chat and shorten a newbies learning curve?

[apostolakisl]

Next step will be starting to figure some sort of subscription to the ISY, in that I can then get updates from the ISY for whatever it will send out in that manner. I assume, at the very least, you can monitor the value of variables being changed and update variables in a quick fashion.

 

You can't do that. Only UD can do that by writing it into the firmware.

 

What you can do is write programs that use the network module to send one of the various types of IP commands (like GET,POST,etc). But they have fixed content, so you would need an individual program for each value of each variable you wanted to send.

 

The best way to do this might be to get your raspberry pi to query the ISY using the REST interface to get the values. Of course this relies on the rasberry pi knowing when it needs to ask.

 

It might be that you do some combination of the above two. ISY could send a single command to rasberry pi informing it that it needs to ask for the variable values. One big program with all the variables listed in the "if" section where they are state variables, so anytime one changes, it sends a message to rasberry pi which then queries ISY?

[Xathros]

You can't do that. Only UD can do that by writing it into the firmware.

 

Are you sure? Michel indicated that subscribing was easy and data would be pushed once subscribed. I know Mobilinc subscribes and if kept awake will show variable and device status changes as they occur. I don't see why this wouldn't work here as well. All communications would be limited to variable values and device statuses/commands but that should be enough to accomplish his goal I would think.

 

-Xathros

[apostolakisl]

Well, we'll see what Michel says. I may be wrong. Perhaps you can run something like a java console that gets updates as things change. Working with Michel and Wayne on getting the webcontrol unit linked, this was not possible, but with linux, you might have more options.

[G W]

Just call your http://your.isy.ip.address/services.wsdl subscribe

 

It's all in the documentation.

[Michel Kohanim]

Hi Guys,

 

Xathros/Gary are 100% correct. You can subscribe to ISY.

 

With kind regards,

Michel

[bsobel]

Well, we'll see what Michel says. I may be wrong. Perhaps you can run something like a java console that gets updates as things change. Working with Michel and Wayne on getting the webcontrol unit linked, this was not possible, but with linux, you might have more options.

 

You definitely misunderstood its fully supported and not a linux thing. I'm doing it with my Raspberry Pi now for my Hue integration. You can see status changes, variable changes, etc. With the 4.x alpha you can get control events as well.

[arw01]

On that very vein I was playing with the other perl_util download from the wiki entries on programming. I can get some responses, but need to figure out the encoding for user name and url to get the subscription really tied up. Not sure what i will do with it from there or what the program does, but it's a step by step process thus far.

 

Far easier to just buy the network module (waiting for a sale ;0), have my existing irrexec use wget with rest commands to update status variables and then use the network module to send the iTach command as a command down the line and the IP2IR with emitters would handle the tv, stereo and such. Could have that up probably in a hour or so.

 

BUT I am learning and hope to get even more flexibility out of the Pi and a subscription method. Thinking of a heartbeat, that way if the pi doesn't update in x number of minutes, it gets power cycled and the init scripts restart everything. I don't know how long term stable lircd, igdaemon, irexec, ir send are. Should they be cycled every night at 3:00 am etc. I haven't come across any long term issues on the boards yet.

 

Alan

[apostolakisl]

Well, we'll see what Michel says. I may be wrong. Perhaps you can run something like a java console that gets updates as things change. Working with Michel and Wayne on getting the webcontrol unit linked, this was not possible, but with linux, you might have more options.

 

You definitely misunderstood its fully supported and not a linux thing. I'm doing it with my Raspberry Pi now for my Hue integration. You can see status changes, variable changes, etc. With the 4.x alpha you can get control events as well.

 

What I meant by Linux, is that it is an OS thing. For example, the Elk can't subscribe, you must have the Elk module. Webcontrol can't enroll, and there is no module.

[arw01]

 

You definitely misunderstood its fully supported and not a linux thing. I'm doing it with my Raspberry Pi now for my Hue integration. You can see status changes, variable changes, etc. With the 4.x alpha you can get control events as well.

 

Bsobel, what are you using to talk back and forth, or just listen?

[arw01]

Glad I put some notes in this thread, forgot about irexec as a daemon and beat my head against the wall for a while.

 

I have lircd starting at boot up now, need to add another set of instructions and a delay to start the irexec daemon as well.

 

I noticed my multiple presses are getting swallowed up a bit, have to figure out if that is a delay of the rest interface itself, or if I need some tweaking to lirc for passing multiple presses along.

 

Alan

[arw01]

Having survived parties, furniture making, and such, I was able to spend a few hours this morning working on this.

 

I now have a successful hook into Jeffrey's isyutil module so I can watch far particular variable names to come across the subscription with the --monitor command line. Eventually, I will add a more sophisticated checking from a simple if to a hash of variables I want to monitor, and what action I want to occur.

 

So far I have occupancy being updated on any remote control press via irexec command running a wget to use the rest interface to set a variable. Other specific IR buttons like play three times or pause 3 times in a five second span cause the lights to come up for slowly fade out to a movie scene I have set up.

 

The plan for the monitoring of the variables is for the Pi, with the iguanaworks module to now send ir codes to turn devices on or off in particular sequences. This ultimately will give me two way communication via integer values with the ISY and the Pi.

 

Alan

[arw01]

Final success. I have now completed a testable amount of code that allows me to set the input on my ir receiver to hdmi 1 whenever the Panasonic remote is pressed.

 

I can make an arbitrary amount of commands to be executed by arbitrary variables and their specific values. Using the process::background module, I just fire off an irsend command and Jeffrey's module keeps humming along. I will strip some more of the verbosity out of his module in the coming weeks.

 

Now to start some sort of new thread on the best practice to handle all this capability and find out how you guys do it. I think I would be best served making a script that actually runs the ir commands in sequence.

 

Thank you all for your assistance.

 

Alan

[arw01]

Fixed a bug I put in from bypassing an if on a defined variable. I was not checking to see if it it was an init type event which resulted in $val->text being undefined and croaking the eventlogger each night at midnight when the calendar programs updated themselves.

 

I need to replace the custom gray keypad buttons back to white, because gray is too opaque and you cannot tell if they are on or off.

 

 

Alan

[arw01]

Just an update that this has been running several weeks and works great. As long as I remember to push the correct buttons on the remote my lights dim and go up.

 

I changed the order of a couple of the irsend scripts this morning on the pi, and I need to yet figure out when to have the isy update the movie kpl button is someone does not use it but turns on the equipment by the remote.

 

Should buy a syncrolinc next time insteon is 20% off and use that to tell if the stereo or tv are on.

 

Someday I will make the perl utility that I use from Jeffrey to self restart, but I also need to put something into the code that watches for the heartbeat and times out if it's missing and try to reconnect after a period of time.

 

Alan

[arw01]

Follow up post as I fixed my Panasonic remote not triggering via irexec updates to ISY variables.

 

Turns out i forgot to put the repeat = 3 after the button line, which caused lirc to ignore the button presses since they basically repeat 2 or 3 times before you let off the button as is normal on a ir remote control.

 

example:

 

begin
prog = irexec
remote = Panasonic
button = PAUSE
repeat = 3
config =  wget  --http-user=admin --http-password=admin http://isy.ip.add.ress/rest/vars/set/2/32/1 &
flags = quit
end

 

 

Now I can also press the panasonic remote pause 3 times and cause my lights to come up in the media room, and hitting play 3 times causes them to go down slowly. This also updates my occupied variable so as to not turn off all the lights in the basement if no motion, remote, switch activation occurs. The motion is completely unreliable though, as the motion detectors can go hours, or days even without the ISY getting notice of an event.

 

This appears to be a lot better in the last new motion sensor I bought in the spring, but they are still triggered by the pets jumping on the sofa, and therefore not an entirely reliable method of keeping the lights on.

 

My next struggle is to make sure that a reboot or power up of the pi results in all the lirc related programs starting up automatically, and then to make the modified isy perl module startup eventually without my manually doing it.

 

Alan

[opensauce]

I figured I'd put this program here since rpi and ir is my use case. I wanted a way to hit a remote button and toggle a light. This is the leanest way I could come up with. I wanted a fast response so I didn't use any perl modules.

 

#!/usr/bin/perl

my $light = 'http://admin:admin@lights/rest/nodes/%s/cmd/%s';
my $status = 'http://admin:admin@lights/rest/status/';
my $node = $ARGV[0];
my $off,$on;

$off = 'DOF';
$on = 'DON';

#Poll Status
my $lights = `curl -silent -o - '$status'`;
my %add = ();
%add = $lights =~ /node id=\"(.*?)\".*?value=\"(.*?)\"/g;

#Decide the toggle
my $mode = ($add{$node} == 0) ? $on : $off;

#Do Something
$node =~ s/\ /%20/g;
my $url = sprintf $light, $node, $mode;
exec("curl -silent -o /dev/null '$url'");

 

my .liric file looks:

 

begin
       remote = directv
       button = dash
       prog = irexec
       config = ~/lights.pl '20 32 1E 1'
end

[arw01]

Pretty slick, could you break down the program a bit, I think it takes the current status of the light from a rest command, then decides to turn it on or off based on that status?

 

I try to do the same sort of thing with just variable values and let the isy determine if the light is on or off and make the swap.

 

The perl module is "heavy" but is allowing me to have 2 way communications now via the subscription, rest and watching for variable changes. Excited for the new variable enhancements to come, perhaps I can pass text back and forth.

 

Alan

[opensauce]

Sure, no problem. I looked at the perl module but on the rpi it took too long to load, not the authors fault just the lag in the pi. So I wrote that not to use any modules.

 

Yeah, as you wrote I poll the ISY for the status of the lights and then I perform the opposite command on the light itself. Goes nice and fast:

 

$ time ~/lights.pl '20 32 1E 1'

real    0m0.362s
user    0m0.140s
sys     0m0.080s

[arw01]

Ah good, like it when I have it figured out in my head.

 

I agree the perl modules are heavy for one off communications vs just doing it straight. However, in the long term the pain to get two way communications has been worth it. Someday may figure that out deeper and clean a lot of the fluff code out of it.

 

need to go read the watchdog manual and see if I can use that to restart the perl module with the --monitor command line which is what I use from one linux machine to the other. Need to move that startup function to a boot routine or something next, but my lirc procresses did not startup properly on the last reboot of the pi. Put a delay in one of them to see if it was a race condition.