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.
Not sure what to tell ya, if I change dimmer to color in dmx.things the things don’t show up. As far as version, I don’t see version output in the DEBUG logs, but its the one that came with 2.2 stable.
As far as the channels, yes, its the hardware, I get the same messed up behavior if I use 30 channels (3*10) with openhab or with windows DMX program. So I just added a dummy device at 255 and things work fine.
Upgraded today to latest 2.3 and with it came a new dmx binding. Using a dmx.things with dimmer no longer worked, I had to change it to color like in the docs!
Hello,
With the new version of binding-dmx - 2.3.0 i have a different result than 2.2.0 with the same configuration.
In 2.3.0 I have to add brightness control on my channel, and just the brightness control can on / off, not my old switch on off.
In 2.2.0 i dont have to add brightness control, i just do switch on off to light on light off.
Have you an idea ?
Where can I download 2.2.0 ?
Regards
Yann
OK i just have had an idea, i have put the same switch item on brightness and channel.
So when I put the switch to ON, brightness goes full and channel goes on. It’s work like this. I don’t know if it’s the good process.
I’m await your advice.
Regards
Yann
