EDIT: The most recent test version of this binding can be found here, the documentation is here.
Hi,
at the moment neither OH1 nor OH2/ESH support E1.31 (DMX over Ethernet) directly. Maybe it can be done using OLA, but IMHO a direct integration would be better.
I’m thinking of developing a new binding that supports E.31 directly from OpenHAB. Since there is no OH2 DMX binding (and I couldn’t find out in the various topics whether it is actively developed or not), my question is:
Is there an active development to integrate the OH1 DMX binding into OH2/ESH?
If so, what is the current state and is E1.31 already considered?
If not, do you think there should be a generalized OH2/ESH DMX binding which supports all types of interfaces or should there be seperate bindings for Artnet, E1.31, … ?
Regarding Thing/Channel: There are several possibilities:
a Thing is a single fixture, DMX universe and channels are configured there, a channel of that thing could be the color, the brightness, … . This is probably the most difficult version as it involves deep knowledge of the fixture itself
a Thing is a DMX device (e.g. a dimmer could have several channels), there is no need to know what the function of each channel represents, however this gets complicated if moving head fixtures are involved, as they represent a DMX device of unknown channel structure.
a Thing is a DMX universe, the channels equal the DMX channels. This is the most general approach and probably easiest to implement.
to my great surprise I saw your pull request and am really happy that somebody continued the development.
I once started a multi universe ArtNet implementation (because of the unbelievable cheap gateways) but did not manage to get over an alpha state. Maybe we should consolidate our ideas? Please feel free to PM me.
Since there is no Jython Port to OH2, I did not pursue the migration yet.
My recommendation is to cut ties with the OH1 Binding and start fresh with a combined ArtNet/E1.31 Binding.
I did really like the “ON” - configuration syntax in the beginning, but this caused lots of frustration afterwards since I did have to create an item for every fade I wanted to show. Things got out of hand when I wanted to overlay two fades so I had to write my own fade scheduler (you can dig it up in the jsr223 vs RuleEngine Performance Thread).
My approach to solve this was to implement an action where you pass the item (which contains only the dmx address information + universe), the desired target value, the time for the fade and an optional priority.
What is your idea on this?
Best Regards
PS: Please write DMX/ArtNet in the title, because lots of people (me included) do not know what E1.31 is.
first of all: E1.31 is not ArtNet. It is another protocol to transport DMX data over ethernet. Both use UDP but the packet format is different as well as the address space and some other things (e.g. ArtNet uses broadcast for large numbers if receivers, sACN/E1.31 uses multicast). They serve the same purpose but are not compatible.
Judging from the code you send by private mail you started a complete rewrite of the DMX support of OH1 which is only using ArtNet. Let me make some comments on that:
From a user perspective it would be much easier to have one DMX binding which works the same no matter what “backend” is used. I would very much prefer to stay there, because it allows to change the DMX interface without changing anything in the item configuration.
From my experience especially getting the fading right is very difficult. As this works well (at least in my experience), it might be easier to extend the current DMX binding to support more than one universe.
Your design with the channel naming (“universe:channel/count” breaks currrent implementation where the colon is used to define a maximum refresh rate. I would go for “1|5/3:1000” which means universe 1, 3 channels tarting with channel 5, with a maximum status update of 1000ms. The universe defaults to 1, so “5/3:1000” would be the same, this ensures backward compatibilty. For sACN/E1.31 this is enough configuration at all, because the universe is already encoded in the packet and the multicast address is calculated from the universe number. For unicast in this implementation all receivers receive all universes, but they’ll just throw those away that they do not need.
after a quick search I realized what E1.31 is, I suggested to rename the thread because DMX (over Ethernet) appeals to more users.
I agree with you, that the user should not be concerned about which protocol is used.
At the time I was not aware of E1.31 so my idea would be now to implement an DMX over Ethernet Binding.
Breaking the current configuration was intentionally because the (maximum )refreshrate per channel makes no sense at all. When transmitting over Ethernet the whole universe is refreshed at once. Also calculation of the next fade depends on the fade-duration so this has no effect, too.
What do you mean with “getting the fading right”? Imho the tricky part is to only refresh after all new values have been created. Otherwise there is a chance of flickering.
Therefore my idea was to do fades through a custom action and prohibit fade configuration in the configuration at all. Also defining an item for every fade prevents reusable code.
After reading more about OH2 I would suggest something like the following:
There is a generalized DMX binding that is used independently of output devices.
Output devices are created as bridges, mandatory parameters are type (lib485, ArtNet, sACN, probably more) and universe they are used for, optional parameters are ip-addresses, port, mode (like unicast/multicast), depending on the type.
Things are created for single fixtures (like dimmers, color items) or scenes or fades (e.g. with switches). Migration from OH1 is very simple with that. Parameters are DMX-channelid (format stays, so multi-channel fixtures are still possible), refresh time and action (like FADE, SFADE)
My question: Is it mandatory to bind things to bridges? If you have lots of DMX channels, it could be that you want to set scenes that include channels from different universes, in case of a single universe output you would have to bind one thing to several bridges, which doesn’t make lots of sense.
I think I might not fully understand what you try to describe, but it seems you run into some of the same problems as me with the descriptive fade syntax.
By defining fades as items/things there are some flaws by design:
Changing one fade causes all openhab items to update to Undefined. This results in strange rule behaviour and errors since some values get only refreshed maybe once a day.
No support for openhab colour type. This makes it impossible to use the colour picker for a new target color. Also new target colours can not be persisted with the persistence service.
Fades can only run in one universe
I think a generalized DMX binding is quite a good idea, but for the specified reasons I see the fade definition in the automation rules with a custom action (e.g. DmxFade( ItemName, TargetColor, FadeDuration)) rather than the item definition.
If wanted the ON-Fade can than be redone with a one liner so there is no additional work.
It is pre-alpha stage. A sACN/E1.31 output bridge with multi-universe support as well as a simple dimmer is implemented. It can be build but never ran up to now.
I am also very interested in this. I am currently working on setting up OH2 for my new home and would like to have LED pixel strips with an E1.31 controller.
I just pushed the initial commit of my version of a DMX binding for ESH to my repository. This includes only one connector (sACN/E1.31) and one thing (a simple dimmer). Currently there are no fades or something like that, but multi-universe support.
@andrewnabors: What do you need to control the pixel-strips? And how do you plan to control them? Recalling predefined “scenes” or sending arbitrary data?
I recently added fading for dimmer things, so this is at least usable. I can provide a .jar if you are interested.
@Kai, I need some help regarding the licensing. Some portions of the code (e.g. this are identical to OH1 DMX binding, what is the right way to put it in the headers? It was licensed under EPL before, so I assume there is no “real” problem.
Second: After installation the binding shows up in Paper UI, but no Things are shown as suported things. Because of that only manual configuration via .things files is possible. I can’t figure out what I’m missing there. Any hint?
Yes, as this was contributed as EPL as well, there is no problem of re-using code from OH1.
What you have to make sure is to add other authors (here @davy) through an “Also-By: …” line in your commit message. As you seem to plan to contribute it directly to ESH, the Eclipse IP team will check that all authors have a valid CLA at Eclipse (which is imho the case for Davy).
After installation the binding shows up in Paper UI, but no Things are shown as suported things.
Should work in general. Cannot see anything obvious. Best check for differences of your binding to other bindings to find the issue.
I was really hoping to get some feedback about my thoughts and ideas I was expressing before the thread went in a different direction. It would be really nice to get a discussion going again.
Maybe you can share your thoughts?
A custom action is not implemented at the moment but should be easy to add. I’m also thinking about adding chaser things that can be reconfigured at runtime from rules. I’m not sure but I think that things defined from the Paper UI will only update this thing on configuration change and not all things.
The next steps on my todo list is implementation of Color values for dimmers. Not sure if that works out with the way the dimmer is implemented now but I’m quite confident that this will be finished soon. After this is done I’ll switch from the OH1 DMX binding to the new ESH binding for my house to test reliability. I hope get there before 2017.
After that, I’ll implement a ArtNet bridge (should be easy because it is similar to the sACN/E1.31 bridge except the packet format). I’m not so sure about the OLA bridge, I did never check how you can communicate with OLA directly, for sure it is possible to use OLA as a bridge from sACN or ArtNet to whatever else you connect to it.
There are some more things to be done for the dimmer thing (turn-on/turn-off values, step-dimming). When this is all finished I’ll do some documentation and create a PR. Besides that it is ready when it is ready, my plan is end of Q1/2017.
I think the custom action will really improve usability. If you take a quick peek at this thread you can quickly figure out the struggle and these are not even half of the items of my sleeping room. This is why i wrote a fade scheduler (here on the very bottom) so I can apply a generic fade on a channel.
This is why my idea was to get rid of the fade configuration in the items-file all together and put them in the rules-file so other people do not have to go through the same struggle.
What do you mean with Color value for dimmers and Dimmer-Thing?
Another thing I observed was that fades the colour of the fades does not really run synchronously.
When I turn my RGB Strip on with ON[FADE|1000:255,255,200:-1] and then off with ON[FADE|1000:0,0,0:-1] I get a blue afterglow (should even be worse with longer fade times). I figured this is because of the rounding error in fade calculation. My advise would to switch to float for fade calculation and then round to int before sending.
Have you observed similar behaviour?
In the binding you have to define the acceptable item type for a given channel within a thing. This is e.g. “Dimmer” for the “brightness” channel or “Switch” for the “switch” channel. PaperUI uses this to allow only item/channel-links that are valid. Therefor for linking a “Color” item to the channel of a thing you need a channel that has set the item-type to “Color”.
The Dimmer thing is a thing that can contain an arbitrary number of DMX channels, controllable via the “brightness”, “switch” or “color” channel. This color channel was not implemented, but it is now.
Didn’t see that. How many DMX channels do you use in total? And what hardware do you run OH on? This is most likely because of a timing issue. It could happen because all channels are checked sequentially for changes. However, it should not, because the time used for the value calculation is set before each channel calculation is called (at least in the new binding, not sure about the OH1-version). My OH2 instance runs on an APU2, so there is quite a lot of processor power, compared e.g. to a RPi.
@All: If you want to test, the latest&greatest alpha is always available here.
I just reproduced it on my normal computer (Intel I7, 16BG Ram, SSD, etc) with ON[FADE|15000:255,255,200:1000|5000:0,0,0:-1].
There is definitely a short blue afterglow that shouldn’t be there.
I am convinced that this is due to how the fades are calculated (rounding error).
My idea would be to initialize a float(ing point) universe at the start of the fade and then use the more exact values and cast them back to the uint universe.
I am still running OH1 because of the missing JSR223 support of OH2 since I have written almost all my rules in jyton (better performance + easier to write). But I think I’ll play around with it a little bit between the holidays.
