New bindings

Add-ons Bindings
1

Hi! Me and a friend have developed some bindings to make some of our devices work with openHAB 2 (and we find OpenHAB really useful). Some of the bindings could be useful for others, so I thought the time is overdue for offering to share them. The code quality is a bit variable. Some bindings were ported from an earlier project of ours and used jSSC instead of NRSerialPort. This could probably be changed if there is interest in the binding.

List of bindings: ( see https://github.com/famake3/openhab2-addons )

artnet

Basic implementation of the Art-Net protocol, commonly used for stage lighting (real time effects). At the point we made it, we weren’t able to use the existing openHAB 1 binding (dmx – don’t think there was a stable 1.x binding interface then). This binding only supports sending a single RGB value to each IP address, repeating it for one or more pixels. Manual thing entry only.

benqprojector

Support for BenQ projector via serial port (tested on W5000), on/off only. Does polling with a configurable polling interval. Manual thing configuration.

folding

Folding@home control: run/stop/finish and status monitoring via local socket protocol, with polling to refresh the status.

lgtvserial

LG TV serial binding with write (set) only, no possibility for querying. Can set on/off, backlight brightness, color temperature, volume, source. Manual thing configuration.

lifx

I had a lot of trouble with the Eclipse SmartHome LIFX binding. This is an alternative LIFX binding designed to be less “chatty” on the network and have additional channels for scripting, primarily “transition time”". I had much better results with this, but it coincided with a firmware update of the light bulbs, so the imrpoved stability could be unrelated to the binding.

ninjablocks

Support for Ninja Blocks (https://ninjablocks.com/). The Ninja Block can be used to interface with RF 433 MHz devices (among other things). This binding has limited support for the original Ninja Block, not the Ninja Sphere. The callback function only works if the server can receive HTTP requests from the internet (on the OpenHAB web port).

receivernadt748

RS232 control of the NAD T748 receiver. Volume control, input selection, etc. Has limited support for reading the state, but doesn’t do polling, so it’s write-only in practice.

rotelra1x

RS232 control of the Rotel RA11 and RA12 integrated stereo amplifier and DAC units. Supports power, volume control, input selection, and some other functions. The serial protocol is quite nice, so this binding updates the values in openHAB in real time when changed by other means (remote control or on device itself).

serialmultifunction

custom serial protocol used with Arduino, probably not of general interest.

I hope someone can have a look if it’s interesting. I am willing to keep maintaining the binding, but don’t have a huge amount of time for adapting it or maintenance, so it may be a bit slow. We’d probably start with one of them and see how it goes, and then I’d recommend the rotelra1x binding.

2 Likes
2

That sounds interesting indeed. If you think the “rotelra1x” is at a state where others can also benefit from it, we should try to include it. @Kai does probably have an opinion and some remarks on that.

What you will definitely have to do is add a README.md.
You will also need to put each addon you would like to merge in its own branch, so a Pull Request can be opened and discussed.

A question regarding the lifx binding. I think it would be worthwhile to discuss (a) the reasons why you decided to build your own and (b) how both bindings could possibly be combined. Do you have any opinion on that?

3

Hi Marius,

Sounds as if you and your friend were really eager, nice :slight_smile:

I would suggest that you create separate PRs for all the bindings where you think that they might be interesting to others - at least as they are not completely custom (as the arduino one) and fit into the architecture (using gnu.io instead of jSSC). Having a PR will give them some visibility and as long as nobody shows much interest (by commenting on the PR), we could treat it with low prio wrt reviewing and merging them). It would be good if they would be conform to the Coding Guidelines, e.g. have a README.md as @ThomDietrich already mentioned.

Regarding the LIFX binding, I would have the same question as @ThomDietrich: If you are also using the local LIFX protocol for communication, I would much prefer if you could discuss your improvements with @kgoderis and help making the existing binding better: I am personally actually quite happy with it and I guess the network traffic could be reduced through configuration options.

Regards,
Kai

4

Intersting. After the initial release of the LIFX 2.0 binding we fixed some bugs, so, it depends a bit when you had a go with it. Also, we might want to revisit the LIFX protocol spec to verify whether new features have been added, and that are of our interest.

Indeed, the LIFX binding is a bit chatty, but there is a simple reason for that: to degree that it is possible, I considered the bulb to be the sole element in the ecosystem that holds the truth, so, no states or alike are cached in the binding, and when a parameter of the bulb is set through a command we do not assume that the command was executed correctly, and therefore read-out the changed parameter after the command. Obviously this generates more traffic, but will avoid any transition or side effects and so forth. As far as I experienced, this extra traffic, certainly on the LAN, with “normal” control of the bulb does not result in congestion on the LAN and neither the bulb.

5

Thanks a lot for the replies! We will go through the bindings and create pull requests when they look fine.

As for LIFX, I will try the official binding again. Could be that it works just as well. I like the idea of treating the bulb as the only source of truth, Especially when it comes to INCREASE/DECREASE and brightness only commands. This wouldn’t be completely natural to implement in our design. Also, our LIFX binding is a bit incomplete, doesn’t support white lights. However, I think that receiving an ACK from the bulb should be sufficient to see that a command was executed (and retry if no ACK was received). It’s also possible to request a more complete state, res_required field, but I’m not at home and can’t check what it does.

6

If nothing else, if the two LIFX bindings could have the same channels that would be amazing. I really miss the ability to transition time a turn off even via a smooth fade that the native app and web API support. I find myself using Openhab for almost everything else except this when I head off to bed at night.

7

Note that you can already set the “fadetime” parameter for every bulb separately (default is 300ms). This is “global” for the bulb, so you cannot have different fade times defined for different items that are linked to the same bulb.
Note that it is planned to also support configurations on links on day; once this is in place, the LIFX binding could be enhanced to use different fade times for different links, which would be nice. It does not make sense to have a second LIFX binding though, we should all just work on making the one we have perfect :slight_smile:

8

My use case is I want a 2 minute fade that is activated with a “bed time” switch, however I wouldnt want a 2 minute transition from one color to another for general scenes.

9

That’s what I thought. Such use cases are the idea of configurable links.

10

Hi,

I’m new to OpenHAB and to LIFX lights and home automation in general. In my use case I’d like the ability to set brightness and/or temperature of a light without turning it on.

For example, in the evening set the lights by the stairs to 20% without turning them on so that even if someone uses the wall switch and cuts the power and restarts them (standard switches) they will boot back up at their last brightness setting.

Can these binding achieve that?

Thanks in advance. Regards,
Michal

11

Apologies for the heavily edited post below.

@Michal, EDIT: contrary to what I wrote first (edited now), I don’t think it would work! I thought the wall switch was some kind of “smart” switch but if it cuts the power to the LIFX bulb, there’s nothing to be done.

It would be possible to set the colour and then send the power on command. But the bulb has to have power to do that.

12

@fa2k If you find the current LIFX binding still unstable (perhaps due to packet loss), you might give the version from PR #2366 a try. It also uses ACKs and resends packets in case they get lost. I’ve also created a JAR which you can use for testing. This version is now rock solid for me with dozens of bulbs.

13

Great! Downloaded, will try it.

14

Hi,

Apologies for posting to a dormant topic, but I wanted to mention that I’ve extended @fa2k 's receivernadt748 binding to work with more of the NAD T receivers.

Specifically, I’ve added:

  • Ability to communicate over TCP or serial
  • Some devices send different combinations of line endings

I think these changes are backward compatible with the existing code, though I ended up reorganizing it a bit (and giving it a more generic name). One thing I’d like to change but don’t have a good solution for more easily configured input names. They’re currently embedded in the binding configuration xml, and I’m not sure there’s a straightforward way to supply values for them in the Thing configuration so that they can be used to map input numbers to names in the various UI components.

Feel free to have a look… as always, comments and suggestions are welcome!

Bill

1 Like