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.
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.
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!
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?
Works great. But would also be nice if it would support my RGBW Brumberg VITALED spots.
I’m now using them as 4 separate channels. A dimmer converts the 0->100 value to:
white = value
blue = 0
red = value * ,9
green = value * ,83
But it’s somewhat complex to make color cycling rules, make them user friendly in site maps, dashboards, etc…
So would be great if the Color data type could be converted to RGBW directly (4 DMX channels).
I have found some code here and here.
I didn’t tested the first one yet. But white = min(R,G,B) isn’t optimal because that would make white running white at 0. I want white at 100% always unless dimming or real scene coloring. Also the code in that thread makes white very minimal.
So channel/width is not working for you? that is really strange, since all my channel configurations are that way and they all work, Do you configure via PaperUI or .things-file?
Regarding applycurve: It should work with any valid configuration, so even 1/4,8,9,15/10 should work. If not, please tell me. it’s a bug then.
dimtime: Incremental dimming is used if you send IncreaseDecreaseType values to the BRIGHTNESS channel, e.g. if you use a KNX wall switch with dimming capability.
fadetime: All other cases when values change. It’s always the time for the change, so 0->100% or 10->15% always take fadetime ms.
It might be posssible to add an option for RGBW to the RGB thing handler. However, it should be an universal formula that fits at least most use cases. And it has to work in both directions, as the color status is constructed from the indiviual channel values. I’ll have a look.
BTW: I don’t see why white=min(r,g,b) would run white at 0% for white light? for white r,g,b are all 100%, so white would be 100%, too.
My mistake, I was thinking from my RGBW values being 90, 83, 0, 100%. Then you should have 0 because blue is 0. For my vitaLED’s everything on maximum is far from white. It’s more blue. I think having a generic formulae will be difficult: you can have one, two, three white LEDs, warm or cold Led’s, etc… Maybe something with some sort of correction factor for each channel? In my case for the vitaLED’s I see it like this: RGB white is disastrous: it’s strange and you have coloured shades. That’s because the LEDs have a large distance between each other and there is no diffusion cell on it. So for normal usage I use while as normal (so 100%) and I just add some red and green to make it warmer. Even a little blue makes it cold. The reduction factor could bring blue down and white up. So blue only gets to 100% when select something really blue in the wheel?
channel/width wasn’t working all the time, but I have completely rebuild my setup and I am now on the latest OH stable and used the 0.100-jar from this thread. It hasn’t occured since then.
Thanks, dimtime is now clear to me!
so you say if fadetime is e.g. 2000 ms 0 to 100 % takes 2000 ms and 10 to 20 % also takes 2000 ms?
Isn’t that contrarious to the documentation that says
The fadetime option allows a smooth fading from the current to the new value. The time unit is ms and the interval is for a fade from 0-100%. If the current value is 25% and the new value is 75% the time needed for this change is half of fadetime.
?
I’ll try some valuecombinations for the applycurve as soon as I get more fixtures installed!
My fault. You are right. I did look up the code and the documentation is correct. The reason for two different values is:
You might want a smooth transition from lets say ON to OFF. The time used for this is fadetime. So if you set it to 1000, it’ll take 1s for the light to turn off (or on). This is always used if absolute values (ON, OFF or a value) are send to the things BRIGHTNESS channel. The actual time for the transition is calculated from the current value and the target value, fadetime is the maximum for 0-100%.
If you send INCREASE (or DECREASE), you would have to be very quick to set a value of 20%. In fact, it might be impossible to do so, the stop command has to arrive 200ms after the original command. Obviously this is not very convenient. So you can set dimtime to something like 5000, which means “if I send an incremental command, slowly fade up (or down) in 5s from 0-100%”, so you can easily send stop after 1s, which is much easier.
Since in most cases you would not want your light to take 5s to switch from OFF to ON (e.g. if you trigger the ON command with a otion detector), we need two different values.
In ChaserThings the fadetime is absolute and the time this steps takes to fade from the current to the target value, no matter how big that step is.
Now when I saved my .things file I get this in the log:
2018-04-11 20:23:53.752 [hingStatusInfoChangedEvent] - ‘dmx:sacn-bridge:mybridge’ changed from ONLINE to UNKNOWN
2018-04-11 20:23:53.764 [me.event.ThingUpdatedEvent] - Thing ‘dmx:sacn-bridge:mybridge’ has been updated.
2018-04-11 20:23:53.767 [hingStatusInfoChangedEvent] - ‘dmx:sacn-bridge:mybridge’ changed from UNKNOWN to ONLINE
2018-04-11 20:23:53.769 [me.event.ThingUpdatedEvent] - Thing ‘dmx:dimmer:mybridge:single’ has been updated.
2018-04-11 20:23:53.772 [me.event.ThingUpdatedEvent] - Thing ‘dmx:chaser:mybridge:ampel’ has been updated.
Here you can see that the bridge, the single and ampel things gets an update and there is nothing to see about the color rgb thing???
Thanks man, it works now!
Why are the bindings not updating themselfs automaticly? is there a way to do that?
Or do we have to wait for the next version of openhab?
I had DMX working long ago on 1.7 and now I want to set it up again in 2.2. Is it just more or does the dmx binding not output ANY logs even in trace mode?
[root@lisa openhab2]# more /etc/openhab2/things/dmx.things
Bridge dmx:artnet-bridge:edmx1 [ address="10.88.64.102" ] {
color Pool_Light_A [dmxid="1/3", fadetime=1000, dimtime=10000 ]
color Pool_Light_B [dmxid="4/3", fadetime=1000, dimtime=10000 ]
color Pool_Light_C [dmxid="7/3", fadetime=1000, dimtime=10000 ]
color Pool_Light_D [dmxid="10/3", fadetime=1000, dimtime=10000 ]
color Pool_Light_E [dmxid="14/3", fadetime=1000, dimtime=10000 ]
color Pool_Light_F [dmxid="17/3", fadetime=1000, dimtime=10000 ]
}
[root@lisa openhab2]# more /etc/openhab2/items/dmx.items
Color Pool_Light "Pool Lights" <pool> (Pool)
Color Pool_Light_A "Pool Lights Segment A" <pool> (Pool_Lightstrip) {channel="dmx:color:edmx1:Pool_Light_A:color"}
Color Pool_Light_B "Pool Lights Segment A" <pool> (Pool_Lightstrip) {channel="dmx:color:edmx1:Pool_Light_B:color"}
Color Pool_Light_C "Pool Lights Segment A" <pool> (Pool_Lightstrip) {channel="dmx:color:edmx1:Pool_Light_C:color"}
Color Pool_Light_D "Pool Lights Segment A" <pool> (Pool_Lightstrip) {channel="dmx:color:edmx1:Pool_Light_D:color"}
Color Pool_Light_E "Pool Lights Segment A" <pool> (Pool_Lightstrip) {channel="dmx:color:edmx1:Pool_Light_E:color"}
Color Pool_Light_F "Pool Lights Segment A" <pool> (Pool_Lightstrip) {channel="dmx:color:edmx1:Pool_Light_F:color"}
I thought I was doing good because I noticed that the bride was ONLINE, but then I disconnected the ethernet and still got ONLINE…
events.log:2018-05-09 18:43:47.354 [.ItemChannelLinkAddedEvent] - Link 'Pool_Light_B-dmx:color:edmx1:Pool_Light_B:color' has been added.
events.log:2018-05-09 18:43:47.356 [.ItemChannelLinkAddedEvent] - Link 'Pool_Light_C-dmx:color:edmx1:Pool_Light_C:color' has been added.
events.log:2018-05-09 18:43:47.357 [.ItemChannelLinkAddedEvent] - Link 'Pool_Light_A-dmx:color:edmx1:Pool_Light_A:color' has been added.
events.log:2018-05-09 18:43:47.361 [.ItemChannelLinkAddedEvent] - Link 'Pool_Light_F-dmx:color:edmx1:Pool_Light_F:color' has been added.
events.log:2018-05-09 18:43:47.361 [.ItemChannelLinkAddedEvent] - Link 'Pool_Light_D-dmx:color:edmx1:Pool_Light_D:color' has been added.
events.log:2018-05-09 18:43:47.362 [.ItemChannelLinkAddedEvent] - Link 'Pool_Light_E-dmx:color:edmx1:Pool_Light_E:color' has been added.
events.log:2018-05-09 18:43:52.649 [hingStatusInfoChangedEvent] - 'dmx:artnet-bridge:edmx1' changed from UNINITIALIZED to INITIALIZING
events.log:2018-05-09 18:43:52.669 [hingStatusInfoChangedEvent] - 'dmx:artnet-bridge:edmx1' changed from INITIALIZING to OFFLINE
events.log:2018-05-09 18:43:52.670 [hingStatusInfoChangedEvent] - 'dmx:artnet-bridge:edmx1' changed from OFFLINE to ONLINE
I love wireshark, turns out it can read artnet. I compared what I was seeing from openhab 2 dmx binding from a windows program that works with my dmxking module.
If I look at the ArtDMX packet, they both have Universe: 0 but the OpenHab shows ARTDMX packet Physical: 0 where working windows program shows Physical: 1. Not sure if that matters, can’t find much information on what that part of the packet does. The other thing that is odd is that my DMX channels from OpenHab show 0% for all channels even if I adjust the sliders.
Ok, got everything working, I had to change the .things from color as showed in the docs to dimmer to get them to show up. The other odd thing was that even tho my board is a 30 channel board, it would not sync up unless I sent more than 30 channels of DMX in the packet. Hope this helps someone else, drove me crazy for a day.
It‘s a little bit strange that you can use the color channel on a dimmer thing. Are you sure you are using the latest version?
Regarding the channels: that is most probably a problem of your dimmer. Which DMX channels do you use? Maybe the your bridge is repeating the values too fast if you use too less channels.
