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:
- Turn on channel, set it to some value
- 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 - - 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?
Regards
-jnk
1 Like
@J-N-K:
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.
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.
Some questions about the DMX binding.
I use it with RGBW LED strips.
- When I set a color using the colorwheel and then send a “OFF” command the LED strip goes off. when I then send a “ON” command, the LED strip goes back on but not in the same color is was. The v1 DMX binding always came back to the last light status when sending a “ON” command.
- When using the colorwheel on a 4 channel thing (RGBW LED strip) the 4th channel does not work? In the android app you can dim the LEDs but you can’t control the white channel with the second slider.
Regarding the first point: see OH2/ESH DMX binding and dynamicturnonvalue should be your friend.
Regarding the second point: there is no transformation between hsb and rgbw that returns the same values if the inverse direction is requested. That makes it impossible to keep rgbw and openhab‘s color picker (hsb) in sync.
thank you for your anwer but the links are not working anymore. Is it possible to upload the jar file again?
dynamicturnonvalue what do this? (I don’t know it)
The link is no longer available because the feature is already available in latest master builds.
The lasted master builds are the snapshots?
Why isn’t it possible to update the bindings in your running openhab system? (like apps on your smartphone)
The last days I tested the “dynamicturnonvalue” function together with the last snapshot binding.
I have the following problem:
Sometimes the values (RGB) are changed to 0 (or almost 0).
I think that when I turn OFF a RGB LED strip that sometimes the “dynamicturnonvalue” function used values of the RGB LED strip when it is almost OFF.
I use this options on my thing: [dmxid="1/3", fadetime=1000, dimtime=5000, dynamicturnonvalue=true]
could it be that the “dynamicturnonvalue” function cannot work together or clash with the fadetime or dimetime delays?
Maybe. I don‘t use it. I can imagine that dimtime could be a problem.