OH2/ESH DMX binding

Add-ons Bindings
,
21

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.

22

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,

Jan

23

Hi,

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.

24

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.

25

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,

Jan

26

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

27

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.

28

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="192.168.188.50", 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).

29

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.

Pro:

  • 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.

Cons:

  • 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,

Jan

30

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

Changes:

  • 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,

-jnk

31

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.

32

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,

-jnk

33

Hi @jan_n_klug
wow I am impressed by the fast pace of your development!
I am on christmas vacation now so I will be back testing in January. I will also try to think about the general layout. So far I really like the direction this is going!

34

I added Lib485 support, so all supported output devices from the OH1 binding should be supported. Since I donā€™t own or even know of a device that supports Lib485, please test that if you do.

Currently Iā€™m stuck at two things:

  1. I have no idea how to add custom actions and havenā€™t found another ESH binding that does. If anyone knows how to do that, please let me know.

  2. I canā€™t get the tests to run. I get an error and have no idea how to fix that:

[ERROR] Failed to execute goal org.eclipse.tycho:tycho-surefire-plugin:0.23.1:test (default-test) on project org.eclipse.smarthome.binding.dmx.test: Execution default-test of goal org.eclipse.tycho:tycho-surefire-plugin:0.23.1:test failed: Invalid extraRequirement jar:slf4j-api:0.0.0: Unknown artifact type "jar" -> [Help 1]

The tests are basically generated by the script with some additions along the lines of the Hue binding.

Best Regards,

-jnk

35

I got the tests running and found some corner cases where the code failed. This is fixed now. I have created a PR for review in ESH, please continue testing this version.

Best Regards,

-jnk

36

Hi all,

As this is my first post, I hope Iā€™m doing everything right :slight_smile:.

Jan, thank you for picking this up. I intend to use DMX some day with OpenHAB2 and although I wasnā€™t aware that the current binding ainā€™t working with OH2 this is a nice move forward!

As I want to use an Artnet interface from Enttec Iā€™m glad you implemented that too! However, I saw you donā€™t have an interface yourself. Can I help you by lending you one? Your name looks Dutch so just curious whether or not you are from the Netherlands :relaxed:.

37

Hello @J-N-K . Itā€™s working with art-net. So it was a problem on the receiving end. Somehow always 32 channels are being sent as a minimum, correct?

Also, it seems that after playing with the Things file, the Raspberry Pi needs to be rebooted for the changes to have effect. Is this behaviour intended or normal?

Also great that universe 0 is actually 0 now :slight_smile:

I think there are some errors in the documentation about the Things / Items, there is a ā€œ:mybridgeā€ missing, correct?
Also, it seems that dmx data is constantly being sent. is this correct? How would I switch it off?

I will keep on testing and report back any problems if I can find them. Cheers!

38

True. 24 is the minimum needed for correct timing on DMX512A transmitters, I increased the limit a bit. This should not hurt-

Which version do you use? I have oberserved that problem before (but restarting OH2 was enough). This did never happen when I used the PaperUI for configuration, so I guess this is not related to the DMX binding. I think with the things enclosed in {} after the bridge configuration :mybridge is not necessary. But you are right, the documentation needs an update.

[quote]
Also, it seems that dmx data is constantly being sent. is this correct? How would I switch it off?
/quote]

What do you mean by ā€œconstantlyā€? Sending about once a second (actually 800ms) is the lowest possible frequency allowed by the standards.

@Dennis1984120, @SpaceGlider has an ArtNet interface, and it seems to work. Just install the binding and see if it works for you. Oh, Iā€™m from germany, BTW.

Best Regards,

-jnk

39

Hi,

yes, restarting OH2 is needed somehow. Maybe this is new in the latest OH2, before I only changed the .things file and OH2 would read it again and create the thingsā€¦

My question should have been: Is it possible to turn OFF a bridge completely and not send anything at all? I have multiple inputs to the receiving device and donā€™t want to interfere.

40

Hi @J-N-K I saw that you have updated the Binding with applycurve!

May I suggest to put a ā€œswitchā€ channel to the bridge-things to turn output ON or OFF? I think this would be much mor straight forward than adjusting the output frequency to zero.

I still have occasional flickering (~1s of brighter leds) when the output value is in the lower range but this may be a problem at the receiving end again, I will investigate this.

When will the binding go into the OH2 addons? I think this is at a stage where a snapshot release is more than justified! I use it everyday now and within rules, plannng to add more devices and am very happy with the result. Big thanks for the nice development!