After fair amount of frustration while trying out various APIs, I’ve implemented bare-bone simple LIFX local API that supports the latest 2.0 firmware. It’s written in python and you can either use simple command line interface or to run bundled webservice that also supports ACK.
Only colour_change is supported but that’s the only thing I am using anyway.
Petr, I am fitting my house with the new LIFX 1000 bulbs (both BR30 and A19). I look forward to integrating with openhab when I get openhab running, as well as doing some custom development outside of OH. I hope to collaborate with you and will keep you posted–thanks for getting the ball rolling!
Good luck! Let me know how the software works for you. By the way - I’ve discussed with Lifx devs on/off function VS setting the colour to zero brightness and both options are equivalent when it comes to power consumption, therefore my implementation is not missing anything you may need for production! I have been using mine for a few months now and working perfectly. As a side note, I am running the LIFX webservice I’ve written on the same device as OpenHAB as it’s really light-weight.
Petr, I tried it for the first time last night, and it worked beautifully. I only tested it with one bulb, but I have over 20 and plan to add more. I want to personally thank you so much for doing this–the code is clean and it works like it should. I haven’t tried the webservice yet and have not tried to hook this into openhab, but I plan to do this soon. Are you hooking your webservice into openhab, or is it running totally separately?
I had used LIFX’s forum posts about controlling lights from bash and had successfully controlled them using the command line, but your tool provides so much more flexibility. Also kudos to LIFX for providing such a straightforward protocol for interaction with the bulbs. I was going to write what you wrote in C and may still do so as an exercise and to see if there is a speed difference, and if I do so, will certainly share it like you have.
The only hurdle in my implementation is the need to have static IP addresses for the bulbs but in any more thought-through setup (which I imagine OH users have), this is actually an advantage as it removes any discovery and network broadcasts.
Yes, I use the webservice (run it on the same box as OH) as it provides the ACK functionality and retries if needed. Then in OH, I’ve got triggers set up for colour items and time-based items as well just in case you power-cycle the bulb etc.
I do not think you will get much benefit when writing it in C, it’s really very simple and once it gets compiled and loaded into memory I do not think you will be able to measure any differences… but surely will be a nice exercise!
Not only is it light weight, but it has been stable! I am using two LIFX bulbs on my desk at very low light (8%) to show me the current battery level and power draw of my house. So far everything has been very stable.
Any idea how to use the Colorpicker item as Amy asked?
I managed to implement a rule in openhab to control the LIFX bulbs with your python code and the colorpicker. The rule I used is below. I am very new to coding so it took a lot of trial and error to get it to work. But it works well, and the colors are fairly accurate to the colorpicker. I just hardcoded the kelvin to 3000. I haven’t figured out how to handle that coming from RGB.
var String command2
rule "RGBLight2"
when
Item RGBLight2 changed
then
hsbValue = RGBLight2.state as HSBType
hue = hsbValue.hue.intValue.toString
sat = hsbValue.saturation.intValue.toString
bri = hsbValue.brightness.intValue.toString
command2 = "/home/pi/Python/lifx-simple-master/set_colour.py (YOUR LIFX IP HERE) " + hue +" " + sat + " "+ bri +" 3000"
executeCommandLine(command2)
end
My item, and sitemap entries are below for completeness.
Item:
Color RGBLight2 "RGB Light2" <slider>
Sitemap:
Colorpicker item=RGBLight2 icon="slider"
The only thing I have noticed is that code will not turn on the lights if they have been powered off from the LIFX app / API. I am working on a code to send a PUT through the LIFX HTTP API to turn them on, unfortunately there will be a significant delay doing it this way though.
You nailed it Tarren! The only difference in my implementation is that I use GET request to the webservice provided to take care of lost packets etc. (and I also have the rule on timer to update the colour on period basis as well).
One further tweak I am using is to have abstraction over the Color items - I use multiple color items and then assign them to bulbs via strings (for example, bulb1 can have choices Col1, Col2, Col3). This allows me to change multiple bulb colours at the same time etc. Nothing specific to the binding, just something I’ve done in OH.
@terranjp I keep getting the error “2016-02-09 23:15:34.699 [ERROR] [.script.engine.ScriptExecutionThread] - Error during the execution of rule ‘RGBLight2’: Couldn’t invoke ‘assignValueTo’ for feature JvmVoid: (eProxyURI: lifx.rules#xtextLink_::0.2.0.2.0.0::0::/1)” with your rule.
Nice script, and technically it should work - but unfortunately I can’t get any of these to - it casts them to void for some reason.
On the other hand, I do have a solution for your turning on/off the bulb itself and it basically uses the Local Network packets (which doesn’t send an ACK back so it’s not foolproof, but it hasn’t skipped a beat since I’ve tried it)
First, the rule
var String cmd
rule "onOffLIFX"
when
Item M_Lamp changed
then
if(M_Lamp.state == ON){
cmd = "<LOCATION>/switchLIFX.sh ON"
} else if (M_Lamp.state == OFF){
cmd = "<LOCATION>/switchLIFX.sh OFF"
}
executeCommandLine(cmd)
end
Then the Shell script itself (this was just simple for me to create as a shell - use whatever suits you).
#!/bin/bash
INP1=$1
if [ $INP1 = "ON" ]
then
/bin/echo -e "\x2a\x00\x00\x34\xb4\x3c\xf0\x84\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x0d\x00\x00\x00\x00\x00\x00\x00\x00\x75\x00\x00\x00\xff\xff\xe8\x03\x00\x00" > /dev/udp/IPADDRESS/56700
echo "ON"
elif [ $INP1 = "OFF" ]
then
/bin/echo -e "\x2a\x00\x00\x34\xb4\x3c\xf0\x84\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x0b\x00\x00\x00\x00\x00\x00\x00\x00\x75\x00\x00\x00\x00\x00\xe8\x03\x00\x00" > /dev/udp/IPADDRESS/56700
echo "OFF"
fi
hmm. I never ran across this error. As far as I know the rule is still functioning on my openhab setup. Unfortunately, I am out of the country but I will test when I get back.
Not sure why they are casting them to void. I am currently out of the country but I will see if the rule is still functioning on my setup when I return.
Thanks for the on/off script. I look forward to implementing that when I get back. I will probably code it in python as I have been in the process learning python and programming in general.
thanks. Let me know if you’re getting the below. I haven’t had much time to investigate it that much (spent about 30 minutes on it and couldn’t figure out why through my random browsing)
[ERROR] [o.o.c.s.ScriptExecutionThread ] - Error during the execution of rule ‘RGBchange’: Cannot cast org.openhab.core.library.types.HSBType to void
I would like to add my comment the scripts above - I am using very similar script to what is mentioned in the thread, however, I do use the webservice instead of the command line script. I find it runs faster, as well as providing the needed ACK functionality if packets get lost (they are UDP).
I ran the webservice on the same device as the OH (raspberry pi v2) and have it setup that it starts automatically after reboot in a screen session. I then use script OH to run a script that sends GET request to it but you can do the same in OH itself, I just had a working solution with scripting and found it easier to quickly adapt the script to send GET request rather than using the OH’s get request functionality.
