For my computer lightshows, I have previously implemented a dominant colour finding algorithm from a paper, looks like this;
This paper used LAB colour space since was better for human colour perception or whatever. For emissive light sources, L*u*v* colour space is supposed to be better, so I’m thinking to implement it like that instead of LCH.
Any strong opinions on this? Would you guys need this to be configurable? Now is the time. 
DMXking recommended sACN thinking we’d need to use Priority due to having 2 controllers (UB5 and your add-on) which could conflict and cause problems.
The UB5 is for local control.
Have you seen this situation? Do you have an eta on sACN 2-way?
I will be ordering the DMXking device today, so should have it next week to test out with your add-on
thx for the help!
Your UB5 is unable to control more than 4 light zones. Besides this, it will repeat itself over the entire universe. This means that if you put your lights and this controller on the same universe, your 1st and 5th light will be the sane, your 2nd and 6th, etc…
The only way you can have control over more than 4 light zones locally (without HA’s involvement), is with multiple UB5’s on separate universes (option A).
Alternatively, if local control isn’t mandatory, option B lets you read your UB5, and enables you to do whatever you want with this data, such as turning on specific light zones. Option B holds that your DMX Input and DMX Output are on separate universes (because of this repeating problem).
The sACN priority system is for merging signals on the same universe. With option B (=non-local control), this isn’t necessary since you need to be on separate universes anyway. With option A (=with 4 UB5’s), this does matter.
I don’t have an ETA on sACN 2-way, but sACN with priority will probably be done somewhere this year. At least this way, you should be able to override the data that your UB5 is spewing out (but don’t yet get the state inside HA).
I spoke to the owner of DMXking, he says we just control sACN Priority on the DMXking device input port, like in the screenshot. He said sACN always has a priority built into the protocol, the only issue would be if you hardcoded it in the add-on.
sACNview…
I do like Option B if I understand it… Are you saying your add-on reads DMXking device to “grab” the UB5 output going into ‘Universe 1’ and converts that into commands for ‘Universe 2’?
Yes, that looks right!
Hi,
im trying to get the Beta Work because of the openfixture Library.
But i have ( i thiunk so ) some great understanding Problems with the new Integration.
In the old Config File i set up my DIN Ethergate Lioke this:
light:
- platform: artnet_led
host: 192.168.0.25
max_fps: 40
refresh_every: 0.1
node_type: artnet-direct
universes:
1:
send_partial_universe: true
output_correction: quadratic
devices:
- channel: 1
type: rgbw
name: Lanz Rechts
transition: 0
- channel: 5
type: rgbw
name: Lanz Links
transition: 0
- channel: 10
type: rgbw
name: Par Links
transition: 0
- channel: 14
type: dimmer
name: Par Links Dimmer
- channel: 15
type: dimmer
name: Par Links Strobe
- channel: 24
type: rgb
name: Par Rechts
transition: 0
and much more Fixtures without Problems.
My new Config is now like this an no matter what i try i get errors so that the integration is not starting at all …
Here is the new one.
dmx:
fixtures:
folder: fixtures
artnet:
max_fps: 43
refresh_every: 1.2
rate_limit: 0.5
universes:
- 0/0/1:
devices:
- Lanz 1:
start_address: 1
fixture: RGBW
mode: 4ch
entity_id_prefix: dmx
- Lanz 2:
start_address: 5
fixture: RGBW
mode: 4ch
entity_id_prefix: dmx
- Moving Head:
start_address: 50
fixture: Mini LED Spot 25W
mode: 10ch
entity_id_prefix: dmx
compatibility:
send_partial_universe: False
manual_nodes:
- { host: 192.168.0.237, port: 6454 }
- { host: 192.168.0.10 }
logger:
logs:
custom_components.dmx: debug
Hello again,
was all Night fighting with this Integration … But now it Works !
Sometimes it seems a bit laggy to me. Or in other Words the “old” Integration seems much more quicker!
But Anyway i think this is a large Step in the Right Direction with the openfixture Library implemented.
Maybe one of the Dev´s could take a small look in my Configuration, for me its like i loose the Connection to my DIN Ethergate. Sometimes when i switch random the Connection is back , sometimes i have to restart the Ethergate.
Many Thanks for this very nice integration !
dmx:
fixtures:
folder: fixtures
artnet:
max_fps: 43
refresh_every: 0.5
rate_limit: 0.5
universes:
- 0/0/1:
devices:
- Lanz 1:
start_address: 1
fixture: RGBW
- 0/0/1:
devices:
- Lanz 2:
start_address: 5
fixture: RGBW
- 0/0/1:
devices:
- Eurolite PARtySpot:
start_address: 10
fixture: EurolitePARtySpot
- 0/0/1:
devices:
- Par Strahler:
start_address: 23
fixture: DRGB
mode: 8bit
- 0/0/1:
devices:
- Q-Spot 1:
start_address: 27
fixture: Q-Spot 40 RGBW
mode: 9ch
- 0/0/1:
devices:
- Q-Spot 2:
start_address: 36
fixture: Q-Spot 40 RGBW
mode: 9ch
- 0/0/1:
devices:
- Moving Head:
start_address: 50
fixture: Mini LED Spot 25W
mode: 10ch
- 0/0/1:
devices:
- RGBWAUV:
start_address: 70
fixture: RGBWAUV
mode: 8bit
- 0/0/1:
devices:
- Nebel:
start_address: 256
fixture: DeskCh
mode: 8bit
compatibility:
send_partial_universe: true
manual_nodes:
- { host: 192.168.0.25, port: 6454 }
thank you, I ordered the DMXking today!
Happy to hear it works! If the documentation was unclear, I am happy to add your suggestions
I’m using a DIN Ethergate 2 port and don’t see these performance/connection issues. Only issue I have with it is when it turns on through PoE, and my router isn’t online yet, it fails to get an IP address and doesn’t recover. After a restart when the router is online, it’s all good though.
You can put your devices that share a universe on the same level, like so;
dmx:
fixtures:
folder: fixtures
artnet:
max_fps: 43
refresh_every: 0.5
rate_limit: 0.5
universes:
- 0/0/1:
devices:
- Lanz 1:
start_address: 1
fixture: RGBW
- Lanz 2:
start_address: 5
fixture: RGBW
- Eurolite PARtySpot:
start_address: 10
fixture: EurolitePARtySpot
- Par Strahler:
start_address: 23
fixture: DRGB
mode: 8bit
- Q-Spot 1:
start_address: 27
fixture: Q-Spot 40 RGBW
mode: 9ch
- Q-Spot 2:
start_address: 36
fixture: Q-Spot 40 RGBW
mode: 9ch
- Moving Head:
start_address: 50
fixture: Mini LED Spot 25W
mode: 10ch
- RGBWAUV:
start_address: 70
fixture: RGBWAUV
mode: 8bit
- Nebel:
start_address: 256
fixture: DeskCh
mode: 8bit
compatibility:
send_partial_universe: true
manual_nodes:
- { host: 192.168.0.25, port: 6454 }
Hello Breina, thank you very much for your suggestion about the same universe. I’m really bad at YAML, so thanks again for saving me a lot of lines of text. 
Maybe things will get better with the YAML you wrote.
With your “old” integration, the connection worked like clockwork. My Ethergate is always on and runs on a fixed IP address, so I’ve never encountered the problems you described.
Thanks again for putting so much heart and soul into this, and the documentation wasn’t that unclear either. I’m just a little confused sometimes when it comes to indenting and formatting YAML. And maybe it will help you if there’s something to debug. I often had to restart Home Assistant three or four times before the devices were actually integrated. But I also have to admit that my home automation system is completely full of junk, which may also be a negative factor.
Thanks again!
Oh, and if you’re interested in what I’ve been up to with the old integration, here’s what I’ve been up to with the old integration: https://www.youtube.com/watch?v=hWWPeAvWiU8 The entire event space is “only” equipped with DMX and WS2815 LEDs running on WLED. I need to make a few more videos with the whole sound-to-light setup running. It turned out really well considering there’s no lighting console or additional computer besides the HomeAssistant one!
Regards.
Jean-Paul
That looks good! As for your curve options question, B makes sense.
Lite profile wise (min, max, maybe eventually color calibration or whatever), I’m thinking, templates. As in, a universe may have multiples of a given bulb or fixture to which a bunch of such configs would apply. But I’m also thinking, that’s something that down the line ought to transition to the HA core, as other, non-DMX lights in HA could definitely also use the same feature set.
It looks like the source code zip for the Beta-2 release artifacts on Github is pre-refactor. It still has the old artnet_led manifest and the wrong directory structure. I checked further and it looks like the wrong branch is being tagged.
