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.
well, i am willing to test as i can when its ready.
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?
Best Regards,
Jan
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?
Best Regards,
Jan
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.
Thanks. I can do that for further commits, do I need to change that for past commits, too? If so, any idea how to do this?
This worked after upgrading to latest build and deleting mapdb. So maybe corrupted database.
Best Regards,
Jan
No, just squash in the end and have a single commit with the correct footer.
Hi jnk,
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.
Best Regards,
Jan
Hi jnk,
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.
Best Regards
Jan
Hi,
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.
Hello @jan_n_klug thanks for developing this binding. It is a great addition to openhab. I will try to test it today.
Do you also consider developing a OSC (open sound control) binding? A java library is available, however I have no idea how to implement a binding.
I implemented ArtNet support and status update for items, JAR is here
Since I do not own ArtNet devices, please somebody check if that is working. Wireshark at least tells me that I produce valid ArtDMX packets, not sure if something around that is missing. I’m aware of the fact that the sender should check with a ArtPOLL packet if the receiver is there, however this is not implemented at the moment and not top-priority for me.
Another thing: I did take a look at OLA. There is a library that is used for communication with OLA. It would be easy to implement an OLA bridge if this library is EPL compatible. It is licensed under Apache License, Version 2.0, if I understand 30. What licenses are acceptable for third-party code redistributed by Eclipse projects? right, there should not be a problem. Can someone confirm that (probably @kai?)
@SpaceGlider: I did take a quick look, OSC has nothing to do with DMX?
Best Regards,
Jan
Hi,
my ArtNet devices operate on universe “0” which seems forbidden by the implementation. Could you add the possibility to use universe 0?
It would be very nice to have a small documentation on how to setup things, talk to channels through items etc. I looked through the github but I could only find hints in the code. Maybe I also overlooke something?
Yes, OSC is not directly related to DMX, but used in a similar context (lighting control, music etc). If openHAB had an additional OSC binding to talk to OSC devices or receive messages from OSC controllers, this would be a great addition.
I am keen on testing it after the holidays. Is there a small wiki page on how to do the ip-addresses/configurations? I really don’t want to use the broadcast with my artnet nodes any longer. I have one of them also running in universe 0.
ArtPOLL is definately not a priority.
I have checked the ArtNet spec and unlike the E1.31 spec for sACN, universe counting starts at 0. Since the implementation uses 1 as default universe, I have decided to reduce the universe number by 1 before sending them to ArtNet nodes, i.e. you have to use universe 1 in all configurations (like channel 1) but you’ll get universe 0 on the output. This is much like the “old” problem with stage dimmers that usually use 0 as first channel while slot 0 in the DMX protocol is the start code and channel values start with slot 1. I’ll build a new JAR this evening.
A documentation has been added. If you find something inaccurate or missing, please tell me. Sometimes it’s hard for the developer to write a good documentation.
Best Regards,
Jan
Yes, I can confirm. Including an Apache-licensed library is no problem at all!
Thanks, @kai. We’ll have OLA support as well when this is ready for merge.
@SpaceGlider, @Spaceman_Spiff: The new JAR is available at the same place as the old one.