OH2/ESH DMX binding

Add-ons Bindings
,
141

Sorry about not posting examples - I was at work without access, and also I tried so many variations that it actually could not be represented by one example.

Good news everyone!
It works now, and all I added was >dimtime=1000, turnonvalue=“255”, turnoffvalue=“0”<. I had the fadetime already in there. I pretty much anticipate that the turnonvalue=255 is necessary here to get it running, so the example is a bit misleading because there is one thing without “turnonvalue” configured.

Thanks @Spaceman_Spiff and @Doxer for your support! Without the working example I’d still be trying something else…

142

If that is true, there is a bug in the binding. turnonvalue should default to 255. I‘ll check that.

143

Hi Jan, thanks for the great binding. It works like a charm now.
But I have a problem with the mysql persistence. The values are logged in the database correctly. At startup they are properly restored to Basic UI and paper UI. But there is no artnet output. Is there a way to get this working?
I’m using openHAB 2.2.0 release on openhabian.
Thanks Daniel

144

Can anybody explain the expected behaviour of the chaser function to me?

I have it running once, holding its last values (despite resumeafter being set to true) - last hold time is zero.
Chaser runs once then crashes out - need to restart OH to gain control of those channels in the chaser again.

Switch item toggles to off automatically - tearing my hair out - its tripping up right at the last for me… wondering if its something ive done

145

Why do you set „hold forever“ and „resumeafter“? Either you want to hold the last step or you want to resume the previous chaser/state. Anyway, sounds like a bug that you lose control. Will have a look.

146

Probably states restored from persistence are not send to the binding. You can check that by setting org.eclipse.smarthome.binding.dmx.handler.DimmerThingHandler to TRACE and check the log while states are restored. If you don’t see messages about command processing from the thing handler, the binding is not receiving the restored values.

147

Sorry - I should clarify - I have not set to hold (the last step is as follows; 2000:128,0,128,255,0,0,128,128,0,0,255,0,0,128,128,0,0,255:0), I understand that a hold time of -1 would cause a hold, 0 would not - if my understanding is right? Was just saying that’s what I was experiencing.

I’ve set resumeafter to restore the previous states once the chaser is stopped.

Is there anything I can offer diagnostics wise to show whats happening? At the moment, chaser switched on - one run through and holds last step. Chaser automatically switches to an off state. No control from here. Switching the chaser back on just results in a load of “second suspend for xx messages”

Thank you though - excellent work!

148

Ok. I found a bug which was not covered by tests. I’ve added tests and fixed it. Please try this. It should work now.

149

Yep - the chaser is clearing down at the end now - it still doesn’t seem to repeat the steps? (or is that expected behavior?)

Resumeafter does not appear to be restoring the previous channel values after chaser stops, further whilst the channels do not lock ‘on’ they are held at zero - still needs restart to resume ops

150

If you want to repeat, you have to turn off resumeAfter, but you can‘t restore after that. If you want to restore the previous values, you would have to use additional logic in rules.

I‘m suprised the channel values are not restored, because that should be covered with my new tests. I‘ll have another look. Thanks for your quick response.

Please send the complete chaser step definition. Thank you.

151

No problem, I will test that without resumeafter - I can always re-write to a known state in rules!
Happy to - if there’s any assistance in testing or whatever I can be - happy to do so, think its great and willing to help :slight_smile: I’ve included my chaser config - chaser is mapped in items as a standard switch.

Here is a more in depth look at what I’ve found from testing;

DMX fade values reporting in the console take a very long format, not a visible problem in operational terms - eg. Dining_Floor_Lamp changed from 1.5686274509803921350936661838204599916934967041015625 to 52.5490196078431353043924900703132152557373046875

RGB dimmers recieve color values (eg Item ‘Kitchen_Leds_CabsR_Under1’ received command 240,100,100) but do not respond to this data - no further log data generated or viewable on network in sACNview. Rolling back to the bundled version of the binding restores operation, but breaks the chaser function (as previously described)

Chaser runs and stops at the end fine (but does not repeat) - cannot test resumeafter correctly as I cannot control the RGB channels (I see my possible error in understanding of the resumeafter operation!)

//Chasers
//Kitchen RGB Chase Mode
chaser kitchen_rgb_chasemode [dmxid=“68,69,70,71,72,73,74,75,76,80,81,82,83,84,85,86,87,88”, steps=“2000:255,0,0,128,128,0,0,255,0,0,128,128,0,0,255,128,0,128:0|2000:128,128,0,0,255,0,0,128,128,0,0,255,128,0,128,255,0,0:0|2000:0,255,0,0,128,128,0,0,255,128,0,128,255,0,0,128,128,0:0|2000:0,128,128,0,0,255,128,0,128,255,0,0,128,128,0,0,255,0:0|2000:0,0,255,128,0,128,255,0,0,128,128,0,0,255,0,0,128,128:0|2000:128,0,128,255,0,0,128,128,0,0,255,0,0,128,128,0,0,255:0”, resumeafter=true]

Thanks
Scott

152

Hi Jan, i solved it with a rule, that recalls the values from the database after startup.
Thanks

153

I’m using the ARTNET-Controller from Ulrich Radig.

In the past I used Homematik (CCU) with CUXD (artdmxdim command) to control the LEDs in my homecinema in the basement. To save power, I turn off the controller when the cinema is not in use, which has worked well so far.

With OpenHAB I lose the connection to the controller if I switch it off and only switch it on again if necessary. Commands from the DMX-Binding are then sent, but the controller does not react. This was no problem with the previous solution (CCU). As a workaround, I always leave the ARTNET controller on.

But still the question, is there a solution with OpenHAB-DMX-binding?

154

After some time I am trying DMX with openhab again. Aaand I have questions…
Running a fresh openhab 2.2 ATM.
For color only RGB is supported so for an RGBW-fixture I need to make 2 items, right?
Are there plans for making RGBW as a single item availible?
E.g. for the bathroom I like to switch the light on with a rule so at night it fades slower and to other values. Is it right that I have to create two items with different settings or are they any options to pass values and fadetimes to a fixture by a special command in a rule? If not the fadetime but brightness and/or color could be possible I think but maybe a little example or hint could help?
Thanks in advance
Nico

155

So have edited things according to this post and now it works.
Very nice! So question remains about passing options, rgb-values I should find out soon (have to get in the openhab-context again) but I think fade- and dimtime are not possible to pass from a rule-command?
And if RGBW will is planned to built in?

Ok, let’s forget about the rules and passing options to the fixture/item for now - but…
I am not quite shure if I am configuring it right.
Createt an artnetbridge with two things

Bridge dmx:artnet-bridge:bb6ogartnet1 [ address="10.134.4.71", universe=0 ] {
 dimmer rgb    [ dmxid="5/3", fade=8000 ]
 dimmer single [ dmxid="8", fade=16000 ]
}

and also a thing through paper UI which uses this bridge.
Then I created items, at first the dimmer “rgb” and “single” doesn’t seem to work therefore I changed the channel as I found it in this thread. The second dimmer through paperUI is added to the things with the VSCode-extension:

Color MyColorItem "My Color Item" { channel="dmx:dimmer:bb6ogartnet1:rgb:color" }
Dimmer MyDimmerItem "My Dimmer Item" { channel="dmx:dimmer:bb6ogartnet1:single:brightness" }
Dimmer   DMXDimmerZwo_Brightness   "Brightness"   {channel="dmx:dimmer:8db2f44c:brightness"}
Switch   DMXDimmerZwo_Switch       "Switch"       {channel="dmx:dimmer:8db2f44c:switch"}
Color    DMXDimmerZwo_Color        "Color"        {channel="dmx:dimmer:8db2f44c:color"}

the log says:

[WARN ] [nding.dmx.handler.DimmerThingHandler] - channel color not supported in thing dmx:dimmer:bb6ogartnet1:rgb
[WARN ] [nding.dmx.handler.DimmerThingHandler] - channel color not supported in thing dmx:dimmer:8db2f44c

the “rgb” seems to work, the DMXDimmerZwo has weird behaviour when trying to control it (on/off yes, trying to set a color turns the fixture off.

my test-sitemap:

sitemap testing label="Sitemap testing" {
    Frame label="First frame" icon="icon" {
        Text item=Item
        Default item=MyColorItem label="My Color Item"
        Switch item=MyColorItem
        Default item=MyDimmerItem label="My Dimmer Item"
        // Color
        Colorpicker item=MyColorItem
        // Dimmer
        Switch item=MyDimmerItem
        Slider item=MyDimmerItem
    }
    Frame label="Second frame" {
        Text item=Item
        Default item=DMXDimmerZwo_Brightness label="Brightness"
        Default item=DMXDimmerZwo_Color label="Color"
        Default item=DMXDimmerZwo_Switch label="Switch"
            }
}

I tried with OH 2.2 and the latest 2.3 Snapshot.
In PaperUI is dimtime and fadetime, in the documentation I only saw “fade”. Where can I lookup which values are availible for the .things-file?

156

Hi. Glad you got it running. I don’t use the textual configuration, so I can’t help you there. I’m not sure which version of the binding you are using. The dimmer has been restructered in the last version, there are now three things for that: the dimmer thing, the color thing and the tunable white things. The color channel is only available for the color thing. Since you get this error, you probably have the latest version.

The latest documentation can be found here, the parameters are names dimtime and fadetime.

Best Regards,

Jan

157

I’m not sure I get your point. So you say that if you turn off the Artnet-Bridge, you have to restart OpenHAB because the connection is not restored after you turn it back on? This should not happen. The binding has no knowledge if the packets send are ever received, Artnet is UDP only without feedback.

I recently bought one of these devices myself, but I can’t promise when I find time to check that out.

Best Regards,

Jan

158

Thanks, that documentationlink makes thing much more clear for writing the files!
I just had the color-error once more but after changing one dimmer from N/3 to N,N,N it is gone.
I am on the Version included in the snapshot of OH2.3 from yesterday so I will watch if this happens when I am back on a stable version as it seems to work when the error appears in the log and also when not.
Now I am trying out the grouping-possibilities of openhab with the Color and Dimmer-items so I can plan how to extend and control my fixtures in the near future. Thanks again!

159

Yes, indeed, I have to restart openHAB.

Regards
Michael

160

So far it’s going well with the binding and I just discovered how convenient the turnonvalue is.
But I have two things: first the applycurve, does it only take the format 1,2,3,4 or also 1/4 or even sth. like 1/3,6/4,…?
And the second: it’s not totally clear to me how fadetime and dimtime work. “if incremental dimmming is used” - when it is the case I use incremental dimming?
And fadetime: is the time always relative to the dimming range, e.g. I have fadetime=4000 when I go from 0 to 25 % it’s 1000, from 0 to 50 % and 25 to 75 % it’s 2000, 0 to 75 % or 25 to 100 % is 3000?
And when I input h,s,b values and change all three values how is fadetime then used?