Has anyone looked at adding LIFX support into Hyperion?
LIFX support
- PaulWebster
- Erledigt
-
-
The protocol looks well documented so it doesn’t look too difficult.
-
I see that a while ago someone made a Kodi add-on for it.
https://forum.kodi.tv/showthread.php?tid=289230 -
What are your coding skills like ?
I don’t have a bulb or the time to do it myself, but happy to provide pointers to what’s needed
-
It is a long long time since I wrote anything substantial that required compiling but I'll take a look at how Philips Hue is done and see if I can do something similar with the LIFX LAN protocol
-
It’s like riding a bike isn’t it ?
Do it for Hyperion.ng - classic Hyperion is not the future.
Led drivers are here:
https://github.com/hyperion-pr…e/master/libsrc/leddeviceRecent pull request that highlights all the files that need editing:
https://github.com/hyperion-project/hyperion.ng/pull/487 -
What are your coding skills like ?
I don’t have a bulb or the time to do it myself, but happy to provide pointers to what’s needed
Hi penfold tacking advantage of your comment, what language i need to know to programming hyperionng -
C/C++ with some QT
-
C/C++ with some QT
How would one go about coding something like this?
I'm very entry level - I've written automation scripts/desktop macros/setup daily tasks on my Pi's etc.
I can understand basic Python. So I'm very honest about where I am.
However, I do have a desire to learn and this sounds like a good project to get started. I want to learn and I'd also like to use this thing and allow other people to.
Where would I get started pulling together the above linked info into something usable?
-
-
That's the cloud API. LIFX has a much faster UDP based LAN API, which is the route to pursue. There's a very nice python library already, but I've yet to find a decent C++ implementation, and don't have any experience working with the language. -
Hey,
Are there any updates ? Is lifx now supported?
-
Good morning,
I'm a new happy owner of two "lifx z" led strips & extension and would be really interested in getting this up and running.
I've made a fork and started playing around with the code.....
https://github.com/daouid/hyperion.ng
but I have not coded for 15 years and would definitely need some help to move forward.
Anybody willing to give me a hand and allow me to pick their brain?Some resources I tried to get knowhow from:
Manufacturer's documentation:
https://lan.developer.lifx.com/docs/workflow-diagramsPython library implementation:
https://github.com/sweettuse/lifxlan3
https://delfick.github.io/photons-core/index.htmlKodi addon with lifx support
https://github.com/pdf/kodi-callback-daemonlooking at this pull: https://github.com/hyperion-project/hyperion/pull/777/files
I'm under the impression I need to create two files in /leddevice/dev_net (as Lifx is controlled via network)
LedDeviceLifx.h
LedDeviceLifx.cppNot sure where to go from there.
this is probably a lead:
https://lan.developer.lifx.com/docs/header-description
https://delfick.github.io/photons-core/packets.html
building al lifx packet:
https://community.lifx.com/t/building-a-lifx-packet/59and this as well:
[MEDIA=gist]smarthall/875301eb5a6b35378aec[/MEDIA]and these other implementations
https://github.com/kalimaul/lifx-api
https://github.com/iotivity/io…/lifx_plugin/lifx_objects
https://github.com/DeanMakovsky/clifx/blob/master/lifx.cppalso found a wireshark lua script for debugging:
https://github.com/mab5vot9us9a/WiresharkLIFXDissector -
Progressing slowly, any help would be appreciated.
Here is where I'm at now:Have a working dev environment comprised of:
* xbian latest to pi 4
* made sure to be able to compile and run vanilla fork of latest hyperion.ng - all seem to work fine
* tested output daemon - all good
* using atmoorb as a base, started working lifx device.
* simple clone with rename works, got proper entry into web interface page as well (net device)still very far from anything. Ultimate goal would be to have ability to make use of multi-segment led strips (Lifx Z).
https://github.com/daouid/hyperion.ng
I've joined hyperion's discord, even if I appear offline/hidden ping me if you have some time.
-
We have a discord? didnt know till yet
-
We have a discord? didnt know till yet
Not sure how official it is, but this is the one I joined:
https://hyperion-project.org/t…rion-discord-server.3138/ -
@Daouid Hi, great to see you joining in getting more devices up to speed with hyperion.
" have not coded for 15 years and would definitely need some help to move forward."
Coding is like riding a bicycle, so do not worry about that.
Let me give you some pointers, food for thought (as I started similar lately with a Nanoleaf device).As you are developing for a network device, there is no need to do the coding or testing on a raspberry pi (unless you prefer).
I am for example running an ubuntu 19.10 in a virtual machine to leverage the horse power of the underlying PC.
As development environment, I am using QtCreator which nicely fits with the QT framework hyperion is using. I know others using MSVC.
You can either run hyperion from QtCreator or compile via commandline (./bin/create_all_releases.sh).
I normally go for commandline, but for debugging use QtCreator.
In addition, I am using SmartGit to work with GitHub....I had a quick lock at the LIFX LAN-API.
a) Given that the protocol is UDP based, you may want to check inheriting your class from ProviderUDP (similar to LedDeviceUdpArtNet).
Then you do not need to cover the socket handling stuff, yourself.b) Detecting devices requires a UDP broadcast. I do not got from teh documentation quickly, if they mean ssdp discovery or pure broadcast.
Nevertheless, it may be worth you have a look at SSDPDiscover.cpp. It is an updated version in my repository (with PR outstanding).
It allows to do ssdp broadcasts flexible to different ports. If not ssdp, the code may provide some guidance how to deal with UDP responses (see discoverServices).To see, if LIFX respond to ssdp calls, you may want to check what is out there:
CodeSSDP_PORT=56700; SSDPDiscover discover; discover.setPort(SSDP_PORT); QMap<QString, SSDPService> services = discover.getServices();
c) After you got the general "writes" running, I would suggest that you also override the switch-on and switch-off functions.
Historically many devices write a continuous stream of Black to "simulate" the off state.
This is of course a bad idea for network devices. As Lifx has an api function to turn on or off, I suggest you make use of it here.
You may have a look at the Yeelight or Nanoleaf device for reference.d) I am currently adding support for Yeelights. They are not UDP, but TCP.
Nevertheless, the commits in my repository may provide you an idea what files require changing.
If not clear what is relevant, just ping me.https://github.com/Lord-Grey/hyperion.ng/commits/Yeelight
Hoping that I provided you additional input for a good start...
In case of further questions, do not hesitate coming back to me.
Enjoy coding (again).
-
@Lord-Grey Hey, many many thanks for your constructive reply and precious help.
Installing QtCreator now, will see if I go the virtualmachine way or not,
for now I'll stick to winscp and compilation on overclock pi 4 .
For sure SmartGit looks useful as wella) thank you, I'll look into that.
b) I've checked and can confirm that lifx does not work with SSDP
https://community.lifx.com/t/l…-on-m-search-query/3869/2CodeThe protocol documentation includes a section on workflows including how to do discovery. Essentially it works like this: Send a Device::GetService packet to the broadcast address (255.255.255.255) on port 56700 Each bulb will respond with a list of service they support as a Device::StateService message. The only service currently documented is UDP which has its type field set to 1. When your application receives one of these messages it should store the sender address and the service port internally. This will constitute the list of LIFX devices that you have found. source: https://community.lifx.com/t/discovering-lifx-bulbs/265 && The basic premise is you create a UDP socket and then throw bytes at it. It’s recommended you only broadcast the GetService to 255.255.255.255 and use the StateService replies to know what devices are on your network. /// Then you “unicast” bytes to specific devices, which is the same as a broadcast, but instead of sending to 255.255.255.255 you send to the specific IP of the device you want to talk to. https://community.lifx.com/t/how-to-send-a-packet-to-a-lifx-bulb-using-the-lifx-lan-protocol/6502
c) I hope I get this far not too long from now
d) will look into this as well
I've found today this git today
https://github.com/riplatt/LIFX-Touch-SwitchI believe it should also help.
-
b) ok. Seems no ssdp, but you might still have a look at the file I linked. It will give you a quick start on sending the broadcast and handle the responses. You „only“ have to cater for the payload.
On separate note, I am currently planning addIng a general discover method to the LedDevice. So this one could be a good case to fill it with life :).„I've found today this git today“
That looks promising. You get lots of definitions and the endianess for free...
For the socket and other stuff, please stay with the Qt-framework.
-
"On separate note, I am currently planning addIng a general discover method to the LedDevice. So this one could be a good case to fill it with life :)."
==> please consider it and count on me for testing :pI know the payload is going to be so painful:
- its a raw form of UDP packets I believe
- lifx uses HSBK for color encoding
- and to really make more than a single color change you need to work with "multizone" https://lan.developer.lifx.com/docs/multizone-messages
I'll try making use of the Qt framework, but I lack so much knowledge of C++ that I wont probably wont go very far unless someone can do the actual coding. I cannot even properly load the project in Qt. As of right now, I seem only good at researching/documentation and testing.
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!