implement ulux binding

[openhab-bot]

From leuth...@gmail.com on October 19, 2013 03:17:47

1. Feature Description the perfect intelligent wall switch with lcd and many sensors as from http://www.u-lux.com . there is documentation about the API and should be easy to do (at least some basic functions such as switching). 2. Example Use Case open up a whole new world of home automation by support this intelligent switch.

Original issue: http://code.google.com/p/openhab/issues/detail?id=493

[openhab-bot]

From teichsta on November 05, 2013 14:53:56

Labels: To-Github

[abrenk]

Any progress on this?

[bitforker]

Also interested! Anyone working on this? Having one switch at home; can contribute by testing or programming (if time allows)...

[abrenk]

I've started to implement a binding and will push it to my fork soon.

[bitforker]

Great! Let us know as soon as we can be of help.

[leutholl]

Wow! That's awesome! I'm here to help too. Just tell me what to focus on. I do have the switch. I also know somebody who router a binding of the custom home automation system - he might be willing to share the code so I could provide it as kind of a template. But this will be in .NET - however porting to JAVA won't be that difficult.

[leutholl]

abrenk how far are you on the flux binding? I would dedicate some time to test it and order some more u::lux switches...

What's better: keep the ulux stateless and keep the logic (incl. menu-tree) in openhab or use the u::lux configuration utility to design the menu and actorID, download it to the switch and just response to commands sent by the ulux switch?

[ottonet]

@leutholl The best way to integrate u::Lux is definitely to keep u::Lux stateless and all the logic in OpenHAB. See this video to get a feel of what's possible if you integrate u::Lux this (the right) way.

I would really enjoy to see a bit of :heart: for u::Lux within openHAB and have asked the manufacturer to offer some :heart: to openHAB as well. I think great things are possible once u::Lux & openHAB are (fully) integrated.

I met @teichsta at ISE in Amsterdam just a few days ago. He borrowed one of our evaluation kits and I hope he finds some spare time to play with it and/or even have some integration with openHAB.

I'll be at the meetup in Düsseldorf as well (6th of March 2015) where I will do a short presentation on u::Lux and bring a few evaluation kits.

Stateless Integration & how to get started: Integrating u::Lux is quite easy once you know how to get started. The u::Lux config software can be overwhelming at first and if you integrate stateless, is not necessary at all - except for assigning the IP address.

It's possible to assign the IP address without u::Lux config, however the instructions and code on how to do this are currently only available under an NDA.

Once you have assigned an IP address using u::Lux config (sorry, windows only, but works great in any VM) you can start sending commands and images to the u::Lux switch using the u::Lux Message Protocol.

The u::Lux Message Protocol is a Binary UDP protocol. Why binary? Because u::Lux was built to be as fast as possible on "limited" hardware (all the intelligence is in the display part) and decoding a text-based (or human-readable) protocol just takes up extra CPU-cycles.

What we see is that u::Lux config is currently often used to design prototypes of future functionality. As you are free to use your own graphics and select your own action depending on what button you press, it's a great tool for prototyping. Just very overwhelming at first glance ;)

u::Lux config also comes with a built in "wireshark-like" decoder tool. Once you have activated this mode you can code and decode u::Lux Message Protocol Messages between your switch and your PC. It's a great help to see what's going on and how to encode the binary UDP commands.

How to see u::Lux from a programmers standpoint Once you "see" u::Lux as just a "dumb" switch with 4 hardware buttons, 4 RGB LEDs, a color display, a microphone, a loudspeaker and a proximity sensor, it all starts to make sense. u::Lux is meant to be used as part of a server and/or gateway solution that dynamically updates the display and reacts on information received from the switch like what button (or what buttons) where pressed, did someone activate the proximity sensor etc. etc.

Questions If there are any questions feel free to contact me. Either I can answer myself or have the correct person from u::Lux GmbH answer you.

Jean-Paul.

Disclaimer: I don't work for u::Lux GmbH but happen to be their Distributor for the Benelux Countries and I just happen to :heart: open source as well ;)

[abrenk]

Hey Jean-Paul,

thanks for your detailed comment. I've finally pushed my existing (work-in-progress!) implementation to a repo. See https://github.com/abrenk/openhab-ulux-binding. A lot of the UMP is implemented but needs to be put together into a proper binding. Especially the configuration part is missing.

But a former version of the code is running in my installation with one u::lux switch, two lights to turn on/off and a window to open/close without any problems for months. Reaction time is instant!

I'll come to the meetup in Düsseldorf so we can discuss how to go from here.

Andreas

[leutholl]

wow that’s awesome. my evaluation ulux is sitting around here, having no home. I would like to buy another 2-3 to integrate it into my openhab universe. Too bad the swiss frame dimensions for wall mount switches (Feller edizio due) doesn’t match any of the German or Austrians programs. I guess I have to cut my own frame to physically make it flush mount with my wall.

I could live with a offline configurator to draw the menu tree and icons etc… and „compiling“ it somehow using openhab’s constant/items and then download it to the switch. Or, more nicely, a sitemap sub-structure which gets transformed to the u:lux capabilites.

Also interesting would be to us the further I/O capabilities of the u:lux being: I2C (incl. the sensors), IrDA, Proximity, Speaker/Mic, Light and Movement.

I can’t wait to see the development of the u:lux being driven among us, openhab’lings. It’s like breathing life to a dead body which once had a bright future, needless to say the u:lux is a fantastic product with a very powerful feature set.

leutholl

Am 16.02.2015 um 22:29 schrieb Andreas Brenk notifications@github.com:

Hey Jean-Paul,

thanks for your detailed comment. I've finally pushed my existing (work-in-progress!) implementation to a repo. See https://github.com/abrenk/openhab-ulux-binding https://github.com/abrenk/openhab-ulux-binding. A lot of the UMP is implemented but needs to be put together into a proper binding. Especially the configuration part is missing.

But a former version of the code is running in my installation with one u::lux switch, two lights to turn on/off and a window to open/close without any problems for months. Reaction time is instant!

I'll come to the meetup in Düsseldorf so we can discuss how to go from here.

Andreas

— Reply to this email directly or view it on GitHub https://github.com/openhab/openhab/issues/493#issuecomment-74575220.

[ottonet]

@abrenk Can't thank you enough for pushing your u::Lux binding to github! I took a quick look at it, it seems you already figured out quite a lot! And I'm sure it'l help @teichsta to get started with his evaluation kit, and others as well.

And great that you're coming to the meetup. We'll discuss further there. I bring my eval-kit with me, would we be able to actually do a small demo of the integration with openHAB?

@leutholl I don't know the details, but for single-frame Feller edizio should be OK. I know there are already some solutions in place for double frames, and more is being worked on. The demo video from my first post in this thread is from a swiss company, so you can be assured, you're not the only one that needs this ;)

Most of the sensor information is already available in the UMP protocol, as well as controlling audio and volume. Even starting an audiostream is part of the protocol and as such available for integration in openHAB.

[abrenk]

I've had some time after the meetup in the hotel and later in the train and finished making the binding a lot more configurable. It should now be usable outside my own network configuration.

A build of the current version can be downloaded from my Dropbox: https://dl.dropboxusercontent.com/u/18314075/org.openhab.binding.ulux-20150307.jar

I'll try to keep the README in the repository updated with all the information needed to get the binding working. To please watch the the repository at https://github.com/abrenk/openhab-ulux-binding to get notified of any changes as I won't be commenting here for every update.

@leutholl @ottonet Would be great if you could give the binding a try and report back if you get it working.

@teichsta I know that you have a lot of pending pull request to review, but if you've got some time it would be great if you could review the binding already before my pull request.

[teichsta]

@abrenk didn't manage yet … since deadline for 1.7 is on Sunday 19th, please be so kind and create a PR soon. We'll hopefully manage to review all open PR's until the end of April. Best, Thomas E.-E.

[Averelll]

Hi all,

New to OpenHAB, and got myself a u::lux evaluation kit as well, it looks great. Trying to make the existing binding work, but no success. Might there be a compiled version for 1.7 available? and a simple instruction as well? :)

Thanks, Averell

[abrenk]

A build of the binding is available at https://dl.dropboxusercontent.com/u/18314075/org.openhab.binding.ulux-20150514.jar.

Can you be a little more specific what the current documentation at https://github.com/abrenk/openhab-ulux-binding is missing?

[teichsta]

@abrenk how is the binding evolving? Are you going to provide it as PR? Best, Thomas E.-E.

[Averelll]

@abrenk, a big part is understanding how it all works together. I will give you an example. In the example u=lux project, there is a dimmer, for this light actor 1 is defined. So looking at your example, I would say I can capture the key clicks for up and down using Switch Ulux_Key_1 "Key 1" { ulux="{switchId=1, actorId=1, type='KEY', additionalConfiguration='1'}" } I understand the actor, but the additionalConfiguration is a mystery to me. As is the behaviour of what I see. When I do a protocol test, I can see the EditValue being changed, and sent across as part of the message. But in openHAB, I can only get an "OFF" event when the value is set to 0, any push on the key to increase the value doesn't lead to any event. It would make more sense to me if this would actually look like Number Ulux_value_1 "light" { ulux="{switchId=1, actorId=1, type='XXX', additionalConfiguration='1'}" }, where every push up and down actually changes the value, because I'm interested in the value, right? Maybe I'm thinking wrong, and actually you just see the u=lux switch as 4 individual switches, you handle all events, and tell the switch to display exactly what it needs to show from within (rules in?) OpenHAB, but I'd then like to understand how the project inside u=lux looks like. Like I said, I can't really get my head around how I need to set it up. I would love to see more info on what exactly the is concept. Also the poximity sensor seems to be polling every few seconds or so, and not work as an event trigger. Edit I fixed the proximity behaviour by setting the proximitysensor bit in the flowcontrol. Did the same for showing the page. Would be great if we can set these bits via the binding as well. Looks not that difficult to do, the format is quite straightforward, might start playing with it if I ever get the compile and build stuff worked out.

Averell

[ottonet]

Just a quick update about u::Lux and improvements in their software.

At the u::Lux Partner day last week in Salzburg they released a new software version with an (IMHO) very important new feature in the area of integration:

The possibility to create direct TCP or UDP network requests to the IP port of your own choosing, in either binary, Plain text or HTTP Get/Post/Head/Put format.

This means that as of now one can use u::Lux to integrate with all kinds of IoT (HTTP/TCP/UDP) API's, including standard OpenHAB API's.

Currently the only limitation is that it's a "write only" function. You can use variables and values internal to u::Lux to set a value or text in the API, but you won't be able to read or evaluate values from the API.

Still a great way to quickly and easily configure a u::Lux switch and have it control OpenHAB, Sonos, Philips Hue etc. etc.