Can you please the update jar-File 
It still seems to be the old one
thx
It should be the new file. The difference is very small. Did you compare the checksums?
Hi, sry for the delay. 
It should be the new file. The difference is very small. Did you compare the checksums?
I thought because there was no version change.
I put this into a console and can see updates on the current things and channels
log trail org.eclipse.smarthome.binding.dmx.handler.DimmerThingHandler
But there a still Errors within the openhab.log like:
But the Way. The Swich Channel isntâ working correctly. May this will help.
When I change to âONâ there is no Update to the dimmerchannel.
greetings
Hi @derandi
your items should be âdmx:mybridge:dimmer:rgb:colorâ etc. then your errors should go away.
@J-N-K
I concur with @derandi on the Switch issue, I have the same behaviour which is a bit unexpected.
Also, I was trying to make a chaser for a âturn lamp onâ animation and an additional âturn lamp offâ in the same chaser so that when I switch the chaser off the lights go off with an animation.
I tried to use the âresumeafterâ but it seems not to work for me. Could you post an example? Or do I need two chasers and connect them to another item through a rule? I guess it would be a neat feature to have to only use one chaser for the whole thing.
Also I totally do not understand how to use the âresumafterâ.
chaser onoff [ dmxid="1/3", steps="500:35,0,0:10|500:255,35,0:10|500:255,255,35:10|100:255,255,255:-1|100:255,255,35:10|500:255,35,0:10|500:35,0,0:10|500:0,0,0:10", resumeafter=true]
Best regards
Regarding the switch-issue: this should be fixed now. There was a small mistake with the parameter order if the turnon- and turnoff-values were not explicitely specified. The JAR has been updated.
resumeafter should restore the previous state when the chaser ends. If it does not, there is a bug. For what you try to do indeed two chasers are needed at the moment, because the chaser always starts with ON and stops with OFF (and restores whatever state the lights had before, including other chasers). The intended use-case is e.g. an optical door-bell where the light is flickering 10s or so and the previous light state is restored afterwards.
Best Regards,
Jan
Regarding the switch-issue: this should be fixed now. There was a small mistake with the parameter order if the turnon- and turnoff-values were not explicitely specified. The JAR has been updated.
Thank you it goes better than before. But a small bug still exists.
https://dl.dropboxusercontent.com/u/60972473/dimmer_switch.gif
How to use the âChange Fade Configurationâ ? Changes have no effect.
https://dl.dropboxusercontent.com/u/60972473/chaser_fade.gif
greetings
your items should be âdmx:mybridge:dimmer:rgb:colorâ etc. then your errors should go away.
Everything is set using PaperUI. The error messages come from items / things which no longer exist.
Regarding the update: This is a known issue. I already asked about that (somewhere, I canât remember exactly where). I have no idea what is missing to get that working. A OnOffType and a PercentType status update is send to each linked item, but switches linked to dimmer items seem to ignore that. If you know of any binding where this works, please let me know and Iâll have a closer look.
Regarding the change configuration: you need to send a string containing a full configuration. I donât think this can be used without rules. The format is the same as used in the chase defintion, so fadeTime:value(s):holdTime, ....
Regarding the items: do you have some simple steps to reproduce that?
I fixed a small bug with the status updates. Please try if that fixes the switch problem.
@J-N-K are you planning to put the binding on the IoT marketplace? Would be great to make it more accessible to users!
I have one more suggestion:
When I use a chaser to change some channels which are also in the thing/bridge as single channel, these channels are also automatically update. However, when I group a few channels in a dimmer (e.g.â1/3â) and the chaser changes all of the values to the same value, this âgroup dimmerâ still remains at â0â. It would be nice that if the values for the âgroup dimmerâ are all the same, that this dimmer also updates to the value! I hope i described this well
Done. However, it is waiting for approval from a moderator.
Regards,
-jnk
Iâm not sure if I understand you right. The first part obviously works as designed.
So you define a dimmer with e.g. 7/3, it uses channels 7,8,9. If you define another dimmer with 8/3, it uses channels 8,9,10.
The value of the first channel of each dimmer is used for the status report, so changing dimmer 1 to e.g. 125 will update channels 7-9 to 125 and report back 125. dimmer will also report 125, because the first channel (which is 8) is used for the status and that is updated to 125 by dimmer 1. If you the set dimmer 2 to 200, channels 8-10 will change to 200 and dimmer 2 will report a value of 200. Dimmer 1 will not change its status, because channel 7 is still at 125. The same goes for chasers. If that works different, then itâs a bug.
There is no easy solutions to that problem, because channel-assignments are not exclusive and there is no guarantee that the all channels have the same value all the time, but only one value can be reported.
Regards,
-jnk
In that case, there seems to be a bug.
Bridge dmx:artnet-bridge:kitchen [address="xxx.fritz.box", universe=0, applycurve="1/3"] {
dimmer lamp1 [ dmxid="1", fadetime=3000, turnonvalue="230" ]
dimmer lamp2 [ dmxid="2", fadetime=3000, turnonvalue="230" ]
dimmer lamp3 [ dmxid="3", fadetime=3000, turnonvalue="230" ]
dimmer ww1 [ dmxid="4", fadetime=3000, turnonvalue="230" ]
dimmer ww2 [ dmxid="5", fadetime=3000, turnonvalue="230" ]
dimmer all [ dmxid="1/3", fadetime=3000]
chaser on [ dmxid="1/3", steps="500:100,0,0:10|500:255,100,0:10|500:255,255,100:10|100:255,255,255:-1"]
chaser off [ dmxid="1/3", steps="100:255,255,100:10|500:255,100,0:10|500:100,0,0:10|500:0,0,0:-1"]
}
If I switch âchaser onâ to ON, dimmer lamp1, lamp2 and lamp3 all go to 100, but dimmer âallâ stays at â0â.
Also, I am observing some strange behaviour of the âturnonvalueâ / âturnoffvalueâ function.I am not sure how to describe it, but it seems that the channel definition is being ignored?
With this, channels 1-3 dim up to 100, but 4 also goes to 100?.
Bridge dmx:artnet-bridge:lamp [address="ESP-xxx.fritz.box", universe=0, applycurve="1/4"] {
dimmer rgb [ dmxid="1/3", fadetime=3000, turnonvalue="100", turnoffvalue="0" ]
dimmer single [ dmxid="4", fadetime=3000, turnonvalue="255", turnoffvalue="0" ]
chaser ampel [ dmxid="1/3", steps="100:255,0,0:1000|100:255,255,0:500|100:0,0,255:1000|100:0,255,0:500"]
}
When I try the following, nothing goes on at all:
dimmer rgb [ dmxid="1/3", fadetime=3000, turnonvalue="0", turnoffvalue="0" ]
dimmer single [ dmxid="4", fadetime=3000, turnonvalue="255", turnoffvalue="0" ]
I think I understand the pattern now: The turnonvalue mapped to channel â1â is applied to all channels. It would be nice if this could be specified for each channel!
Great that we will find it on IoT Marketplace soon!
Cheers
Thatâs strange. Works perfectly for me. You can already define turnon/turnoff values for different channels. Just use the same notation as for chasers:
turnonvalue="100,100,200"
should use turn-on-value of 100 for channel 1 and 2 and 200 for channel 3. I confirmed that works with the latest build. There seems to be a bug with delegating events to wrong handlers in OH2, I canât properly reproduce it. Iâm quite sure that this has nothing to do with the DMX binding as this sometimes still happens after a restart. How do you link the things to items?
Regards,
-jnk
I have played around a little using the latest version (from today?).
The âswitchâ now controls the corresponding channels, however the slider of that channel is not updated.
things:
Bridge dmx:artnet-bridge:tubelamp [address="192.168.188.22", universe=0, applycurve="1/4"] {
dimmer tubeRGB [ dmxid="1/3", fadetime=3000, turnonvalue="127", turnoffvalue="0" ]
dimmer tubeWW [ dmxid="4", fadetime=3000, turnonvalue="127", turnoffvalue="0" ]
chaser tubeAmpel[ dmxid="1/3", steps="100:255,0,0:1000|100:255,255,0:500|100:0,0,255:1000|100:0,255,0:500"]
}
items:
Switch TubeLampMute "TubeLamp Mute" {channel="dmx:artnet-bridge:tubelamp:mute"}
Color TubeLampColor "TubeLamp Color" {channel="dmx:dimmer:tubelamp:tubeRGB:color"}
Dimmer TubeLampDimmer "TubeLamp Dimmer "{channel="dmx:dimmer:tubelamp:tubeWW:brightness"}
Switch TubeLampSwitch "TubeLamp Switch" {channel="dmx:dimmer:tubelamp:tubeWW:switch"}
Switch TubeLampChaser "TubeLamp Chaser" {channel="dmx:chaser:tubelamp:tubeAmpel:switch"}
when I remove the tubelamp: in the items definition, the sliders actually do work with the switch, however, I do not get an artnet output and an error in the log: âitem not linked to a channelââŠ
the item description is copy-pasted from the paperUI, just to be sure it is correct:
I noticed another error: when there is a minus (-) in the adress/hostname, there is another error.
This should be fixed now. Iâll have a look into the other thing as soon as I find time. Thanks for your testing
What exactly is not working? I copied your configuration and tried to switch the TubeLampSwitch via PaperUI. This turns the light on to 0x2f (which is correct). You are correct that this value is not updated in the slider in the PaperUI. However, after a refresh of the PaperUI page the slider correctly shows 49%. I think this might be related to the PaperUI, not the DMX binding.
In my own configuration I use the iOS app, this is immediately updating the silder if I turn on the switch.
Best Regards,
-jnk
You are right. It works now! I really wonder why this has never worked before? I guess I have forgotten another reboot.
There is one more thing I did not mention: I do have multiple bridges with different names. Each of these contained things with the same name before - now each thing or channel has a unique name. This may have been the source of the weird behaviour I experienced?
As a general observation, this binding (or openHAB?, but contrary to other bindings) seems to have some issues with initalization. I am setting up everything with text-file editor, but whenever I change the a thing/bridge It seems that at least one reboot is necessary to come into effect. Just changing a thing (without changing the name) seems to work better.
Cheers from a happy user
David
Iâll probably withdraw the binding from ESH. Since some bindings get reviewed and merged within less than a month while this one awaiting review for half a year, I assume that this contribution is not considered of much value.
Regards,
Jan