OH2/ESH DMX binding

Yes, as this was contributed as EPL as well, there is no problem of re-using code from OH1.
What you have to make sure is to add other authors (here @davy) through an “Also-By: …” line in your commit message. As you seem to plan to contribute it directly to ESH, the Eclipse IP team will check that all authors have a valid CLA at Eclipse (which is imho the case for Davy).

After installation the binding shows up in Paper UI, but no Things are shown as suported things.

Should work in general. Cannot see anything obvious. Best check for differences of your binding to other bindings to find the issue.

Thanks. I can do that for further commits, do I need to change that for past commits, too? If so, any idea how to do this?

This worked after upgrading to latest build and deleting mapdb. So maybe corrupted database.

Best Regards,


No, just squash in the end and have a single commit with the correct footer.

Hi jnk,

I was really hoping to get some feedback about my thoughts and ideas I was expressing before the thread went in a different direction. It would be really nice to get a discussion going again.
Maybe you can share your thoughts?

A custom action is not implemented at the moment but should be easy to add. I’m also thinking about adding chaser things that can be reconfigured at runtime from rules. I’m not sure but I think that things defined from the Paper UI will only update this thing on configuration change and not all things.

The next steps on my todo list is implementation of Color values for dimmers. Not sure if that works out with the way the dimmer is implemented now but I’m quite confident that this will be finished soon. After this is done I’ll switch from the OH1 DMX binding to the new ESH binding for my house to test reliability. I hope get there before 2017.

After that, I’ll implement a ArtNet bridge (should be easy because it is similar to the sACN/E1.31 bridge except the packet format). I’m not so sure about the OLA bridge, I did never check how you can communicate with OLA directly, for sure it is possible to use OLA as a bridge from sACN or ArtNet to whatever else you connect to it.

There are some more things to be done for the dimmer thing (turn-on/turn-off values, step-dimming). When this is all finished I’ll do some documentation and create a PR. Besides that it is ready when it is ready, my plan is end of Q1/2017.

Best Regards,


Hi jnk,

I think the custom action will really improve usability. If you take a quick peek at this thread you can quickly figure out the struggle and these are not even half of the items of my sleeping room. This is why i wrote a fade scheduler (here on the very bottom) so I can apply a generic fade on a channel.
This is why my idea was to get rid of the fade configuration in the items-file all together and put them in the rules-file so other people do not have to go through the same struggle.

What do you mean with Color value for dimmers and Dimmer-Thing?

Another thing I observed was that fades the colour of the fades does not really run synchronously.
When I turn my RGB Strip on with ON[FADE|1000:255,255,200:-1] and then off with ON[FADE|1000:0,0,0:-1] I get a blue afterglow (should even be worse with longer fade times). I figured this is because of the rounding error in fade calculation. My advise would to switch to float for fade calculation and then round to int before sending.
Have you observed similar behaviour?

In the binding you have to define the acceptable item type for a given channel within a thing. This is e.g. “Dimmer” for the “brightness” channel or “Switch” for the “switch” channel. PaperUI uses this to allow only item/channel-links that are valid. Therefor for linking a “Color” item to the channel of a thing you need a channel that has set the item-type to “Color”.

The Dimmer thing is a thing that can contain an arbitrary number of DMX channels, controllable via the “brightness”, “switch” or “color” channel. This color channel was not implemented, but it is now.

Didn’t see that. How many DMX channels do you use in total? And what hardware do you run OH on? This is most likely because of a timing issue. It could happen because all channels are checked sequentially for changes. However, it should not, because the time used for the value calculation is set before each channel calculation is called (at least in the new binding, not sure about the OH1-version). My OH2 instance runs on an APU2, so there is quite a lot of processor power, compared e.g. to a RPi.

@All: If you want to test, the latest&greatest alpha is always available here.

Best Regards



I just reproduced it on my normal computer (Intel I7, 16BG Ram, SSD, etc) with ON[FADE|15000:255,255,200:1000|5000:0,0,0:-1].
There is definitely a short blue afterglow that shouldn’t be there.
I am convinced that this is due to how the fades are calculated (rounding error).
My idea would be to initialize a float(ing point) universe at the start of the fade and then use the more exact values and cast them back to the uint universe.

I am still running OH1 because of the missing JSR223 support of OH2 since I have written almost all my rules in jyton (better performance + easier to write). But I think I’ll play around with it a little bit between the holidays.

Hello @jan_n_klug thanks for developing this binding. It is a great addition to openhab. I will try to test it today.

Do you also consider developing a OSC (open sound control) binding? A java library is available, however I have no idea how to implement a binding.

I implemented ArtNet support and status update for items, JAR is here

Since I do not own ArtNet devices, please somebody check if that is working. Wireshark at least tells me that I produce valid ArtDMX packets, not sure if something around that is missing. I’m aware of the fact that the sender should check with a ArtPOLL packet if the receiver is there, however this is not implemented at the moment and not top-priority for me.

Another thing: I did take a look at OLA. There is a library that is used for communication with OLA. It would be easy to implement an OLA bridge if this library is EPL compatible. It is licensed under Apache License, Version 2.0, if I understand 30. What licenses are acceptable for third-party code redistributed by Eclipse projects? right, there should not be a problem. Can someone confirm that (probably @kai?)

@SpaceGlider: I did take a quick look, OSC has nothing to do with DMX?

Best Regards,



my ArtNet devices operate on universe “0” which seems forbidden by the implementation. Could you add the possibility to use universe 0?

It would be very nice to have a small documentation on how to setup things, talk to channels through items etc. I looked through the github but I could only find hints in the code. Maybe I also overlooke something?

Yes, OSC is not directly related to DMX, but used in a similar context (lighting control, music etc). If openHAB had an additional OSC binding to talk to OSC devices or receive messages from OSC controllers, this would be a great addition.

I am keen on testing it after the holidays. Is there a small wiki page on how to do the ip-addresses/configurations? I really don’t want to use the broadcast with my artnet nodes any longer. I have one of them also running in universe 0.
ArtPOLL is definately not a priority.

I have checked the ArtNet spec and unlike the E1.31 spec for sACN, universe counting starts at 0. Since the implementation uses 1 as default universe, I have decided to reduce the universe number by 1 before sending them to ArtNet nodes, i.e. you have to use universe 1 in all configurations (like channel 1) but you’ll get universe 0 on the output. This is much like the “old” problem with stage dimmers that usually use 0 as first channel while slot 0 in the DMX protocol is the start code and channel values start with slot 1. I’ll build a new JAR this evening.

A documentation has been added. If you find something inaccurate or missing, please tell me. Sometimes it’s hard for the developer to write a good documentation.

Best Regards,


Yes, I can confirm. Including an Apache-licensed library is no problem at all!

Thanks, @kai. We’ll have OLA support as well when this is ready for merge.

@SpaceGlider, @Spaceman_Spiff: The new JAR is available at the same place as the old one.

Hi Jan,
thanks for the update! The documentation is helpful, but I am still struggling with it. I have stuck to the documentation and used the examples, but my this:

Bridge dmx:artnet-bridge:1 [ ipAddress="", universe="1"]

Does not get initialized. Also what is unclear to me is how the dimmer-things are linked to the bridge.

When I create the Bridge and the Thing through PaperUI, everything is there (initialized), but my light does not yet switch on (however, this could be an issue on the receiver end, I will investigate further).

ipAddress is wrong in the example, it is address, as stated in the bridge description above. I’m not sure if universe="1" or universe=1 is correct, I’ll check that.

At the moment things are not bound to bridges. Thje bridges are more like “output” devices. There are ups and downs to this approch.


  • A thing can contain DMX channels from different universes. Since a bridge is always for one universe, this is not possible if things are bound to bridges.
  • A universe can be send out to different devices, i.e. you can send universe via ArtNet to one node and use E1.31 multicast for the same universe without duplicating the things. You can also send e.g. the same ArtNet package to different nodes.
  • If needed, you can change the output by simply adding a new bridge for this universe and deleting the old one. No need to change anything in the things.


  • The user needs to keep track of the universes. If the thing is bound to a bridge with a fixed universe, the universe is determined by the bridge.
  • The coding is more complex and more checks are needed.
  • The configuration differs in this binding from the other ones.

Some things can be worked around. E.g. it would be quite easy to enhance the bridge configuration in a way that you can define more than one receiver node. However, the restriction is still that you can’t send the same universe to different bridges. I’m not sure if someone needs that. Since changing the bridge only requires another selection from a dropdown menu in the thing configuration and not a complete thing setup, this maybe is a minor problem.

The only thing that is not possible is cross-universe things. While this is probably not a problem for dimmers, it may be for chasers. It would be great if someone with a larger DMX setup could comment on this. Is anyone using more than one universe at the moment?

I’m open to suggestion. It’s maybe 2-3h of work to change from the way it is now to the other approach.

Best Regards,


After thinking about the general layout of ESH, I have decided to bind all things to bridges, so please update your configuration.


  • Bridges now accept multiple receiver Nodes.
  • OLA support added.
  • ArtNet and OLA universe 0 is now allowed and default. sACN default universe stays at 1.
  • Documentation has been updated.

Known Bugs:

  • After bridge update, things are not properly initialized.

The new JAR can be found here.

Next step for me is adding tests. If you find bugs, please tell me.

Best Regards,


Hi jnk,

I am still not very fond of the concept of defining fades (dynamic) in the item configuration (very static).
Would you kindly consider creating an action which allows posting fades to channels directly?
It would mean much to me since I won’t have to restart openhab everytime I want to change a fade.

I like the custom action idea. However, I have no idea how to implement that in ESH. If someone can point me in the right direction, that would be great.

You can already change the fade configuration (at least channel values and their timing) in chaser things via the control channel. Bind that to a String item and write a configuration string to that item. Your thing will get updated. It is not possible to change the DMX channel configuration at the moment. If you configure vial Paper UI, only the thing that changed it’s configuration will be updated.

Another thing where I need help: I can’t manage to update a dimmer item to the correct state. The item state changes from OFF to ON if I increase the value from 0 to a higher value, but it will not change back to OFF when the value is 0 again. Sending OnOffType.OFF doesn’t help either. Any idea?

Best Regards,