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?
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:
- 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
@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.