OH2/ESH DMX binding

Tags: #<Tag:0x00007fc3f76cfa58> #<Tag:0x00007fc3f76cf990>

I’m also using the DMX-Binding 0.10.0-binding from Jan/2018 and could do some tests.
But a sample.things as example would be helpful.

Here is ma current one:

Bridge dmx:artnet-bridge:mybridge [ mode="unicast", address="x.x.x.x", universe=0, applycurve="1,2,3,4,5,6", refreshrate=240] {
 dimmer KNO_LED_R		[dmxid="1", fadetime=9000, dimtime=10, turnonvalue="255", turnoffvalue="0" ]
 dimmer KNO_LED_G		[dmxid="2", fadetime=9000, dimtime=10, turnonvalue="255", turnoffvalue="0" ]
 dimmer KNO_LED_B		[dmxid="3", fadetime=9000, dimtime=10, turnonvalue="255", turnoffvalue="0" ]
 dimmer KNO_GUV_4		[dmxid="4", fadetime=3000, dimtime=10, turnonvalue="255", turnoffvalue="0" ]
 dimmer KNO_GUV_5		[dmxid="5", fadetime=3000, dimtime=10, turnonvalue="255", turnoffvalue="0"  ]
 dimmer KNO_GUV_6		[dmxid="6", fadetime=3000, dimtime=10, turnonvalue="255", turnoffvalue="0"  ]

 chaser KNO_CH4_AUS		[dmxid="4", steps="8000:0,0,0:-1"] 
 chaser KNO_CH4_AN		[dmxid="4", steps="8000:255,0,0:-1"] 


rule "Kino Taster 2: Licht Bühne an/aus"
	Item SW2_MQT_231 changed to 1
    logInfo("manuell.rules", "Bühne Licht an/aus")
    if (SW2_MQT_231.state==1 && GUV1.state==ON){ 
    if (SW2_MQT_231.state==1 && GUV1.state==OFF){ 

I have an issue with the KNO_GUV*. They turn on/off not smooth.
The chaser are not in use.

@J-N-K: Any new ideas yet?

Yes. I think we should wait for #6398. It looks like it shopuld be easy to add the needed action then.

What do you mean by „not turning on smoothly“? What happens and what is expected?

What do you mean with #6398?

PR #6398 in the ESH Github repository.

Hi Jan,
sorry, indeed it’s not described good by me.

I want to fade on my spot, but if i send the command to fade on a long time nothing happens and then it fades on very fast. The same for fade off.

Try adding the affected DMX channels to „applycurve“ in the bridge-definition. This sounds like a problem with the dim curve.

Already done, see my config some post above.

Hi @J-N-K, thank you for implementing dynamic turn-on value settings, it makes the rules much easier especially for color channels. But it seems there is a small deficiency with this feature. I think you are storing the last channel value which works fine as long as the channel is not set to OFF more than once.
Steps to reproduce:

  1. Turn on channel, set it to some value
  2. Turn off the channel
    So far so good, you can repeat steps 1 and 2 as many times as you want it works correctly but -
  3. Turn off the chanel again while it is off

The result is that the channel will not turn on with ON command until it is set to some value for brightness or color.

I think this is because when #3 occurs the previous channel value is 0 and that is recorded as previous ON value. Could you please take a look at this issue? Maybe it makes sense to store only values that are greater than zero.

There is no easy solution, for sure storing only non-null values will not work. For a color channel 120,67,0 might be perfectly valid and should be restored as that.

Also only storing data once for an OFF command (until it has been restored) might be unexpected, since there is no 1-1 relationship between DMX channels and thing channels. You can re-use DMX channels in several things (e.g. chasers and dimmers). Imagine for a single channel bound to a dimmer and a chaser thing:

DMX channel is at 95%.
Dimmer receives OFF, stores 95% and sets the channel to 0%.
Chaser is turned on and the result is 15%.
Someone comes in (not knowing what happened before) pushes a wall switch „OFF“.

What would he expect if he pushes „ON“ now? The 95% or the 15%? I would guess the 15%.


Please test this version. The documentation can be found here.. Is that what you requested?



1 Like

Thank you - that’s exactly what I wanted. Unfortunately I postponed my Openhab2 migration and am not yet sure how to integrate my DMX lighting (see my HABApp post HABApp).
Maybe I’ll find time between the holidays to setup a test instance and check you implementation but I can not promise it.

Is anyone using a wireless bridge? If so, is it diy, or commercial? I’m looking for a commercial product; as it’s being installed in a place I’d rather not access very often.

Unfortunately I‘m not aware of any such device. If you find one, I would be interested as well. If it speaks a currently unsupported protocol, I‘ll check if it is possible to include.

Well, diy, there is the http://forkineye.com/espixelstick-v2-assembly-usage-manual/

Like this:

Exactly, thank you!

Hi, should persistence/restoreOnStartup work with this binding?
I have mapdb running, but all dmx items are 0 on restart. Other items working fine. No group filters active in persistence rules.
Thanks Matt!

I don’t know. The binding itself knows nothing about items. It also doesn’t know what the actual DMX output is (since this is one-way-communication), so best guess is to set everything to 0. This is communicated via the thing’s channels to the items (if a REFRESH is requested) and also to the DMX output.

If you restore the item’s values afterwards, probably nothing happens, because I guess (without looking at the code) that this is done via postUpdate, not sendCommand. The DMX binding only reacts to commands, so it will know nothing about the item’s state change.

A workaround maybe to set the item-states from a rule via sendCommand.