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.
@PKBreck I just installed 13 D5-E, are yours still working well for you? Any tips? I have not been able to get them to be viewable in DMX-Workshop, to show as RDM devices, have you tried that?
@Breina I’m finally able to start config/test of your integration. Right now I have a single Universe with 6x D5-E controllers (all on Channel 1) doing RGBWW is the below config file good for that? Is there any way to make the DMX configs separate from HA’s configuration.yaml so we dont need to restart the entire system to add/remove a light? (I have a lot more lights to add)
Also, what do you recommend in this situation…
re above, I have 6 separate controllers / light strips. Really I want be able to control those 6 lights in 3 different groupings of Front, Rear, Sides (which is 2 Left + 2 Right ). Should I create each of the 6 lights as separate entities and use an HA Group? or create an Art-Net Light for every combo – thus the L/R sides (which is actually 4 different strips) would be a single ‘light’ (can I do this in the config yaml?)
thx!
light:
- platform: artnet_led
host: 192.168.2.73 # IP of Art-Net Node
max_fps: 40 # Max 40 per second
refresh_every: 0.1 # Resend values if no fades are running every x seconds, 0 disables automatic refresh
node_type: artnet-direct # Which protocol to use
universes: # Support for multiple universes
0: # Nr of Universe (see configuration of your Art-Net Node)
send_partial_universe: True # Only send the universe which contains data
output_correction: quadratic # optional: output correction for the whole universe, will be used as default if nothing is set for the channel
devices:
# Dimmer
- channel: 1 # first channel of dmx dimmer
name: Tray # name
type: dimmer # type
transition: 2 # default duration of fades in sec. Will be overridden by Transition sent from HA
output_correction: quadratic # optional: quadratic, cubic or quadruple. Apply different dimming curves to the output. Default is None which means linear dimming
channel_size: 16bit # width of the channel sent to DMX device, default "8bit", "16bit", "24bit" and "32bit" available.
Yep! In your configuration.yaml add this;
light: !include dmx.yaml
And then make a new file dmx.yaml that starts with - platform: artnet_led and the rest of your configuration.
I think HA groups are a cleaner solution for now. On the beta branch, you could opt to use matrixes, though I’d honestly just use HA groups as well.
Btw best practice is to start your universes from 1.
@ArcticCascade Hey man that’s awesome! Thanks for sharing; this fills me with joy! <3
thank you!
I tried creating this single DMX light, it shows in HA but it will not turn on?
- platform: artnet_led
host: 192.168.2.73 # IP of Art-Net Node
max_fps: 40 # Max 40 per second
refresh_every: 0.1 # Resend values if no fades are running every x seconds, 0 disables automatic refresh
node_type: artnet-direct # Which protocol to use
universes: # Support for multiple universes
0: # Nr of Universe (see configuration of your Art-Net Node)
send_partial_universe: True # Only send the universe which contains data
output_correction: quadratic # optional: output correction for the whole universe, will be used as default if nothing is set for the channel
devices:
# Dimmer
- channel: 1 # first channel of dmx dimmer
name: Tray # name
type: rgbww # type
transition: 2 # default duration of fades in sec. Will be overridden by Transition sent from HA
output_correction: quadratic # optional: quadratic, cubic or quadruple. Apply different dimming curves to the output. Default is None which means linear dimming
channel_size: 16bit # width of the channel sent to DMX device, default "8bit", "16bit", "24bit" and "32bit" available.
@Breina help please I’d really like to get my DMX working in HA. thank you!
Looks good to me, except refresh_every is a lot, this sends 10 times per second when nothing is happening. This option is mostly useful if you have another ArtNet controller on the network, you can leave it on 0 for simplicity.
Can you see anything in your logs?
These kinds of problems are usually network related, i.e. your HomeAssistant cannot reach 192.168.2.73 .
Try putting node_type: artnet-controller, this will auto-discover your ArtNet node. If it can’t find it there either, it’s definitely a network issue.
@Breina or anyone that can help
I need to do this, per your recommendation. Where is the info on how to do this?
Option B: put HA in between the UB5 and your lights. This would connect the UB5 to an Art-Net Node’s DMX input, the other lights to that node’s DMX output (thus at least 2 DMX ports), and HA connected to the Art-Net in/output. This way you are able to read the input from your UB5 and use it for automations, whilst still being able to control your lights through HA.
thank you!
Something I recently learned the hard way: Home Assistant’s recorder stores everything by default and something like an animated pixel strip generates a whole bunch of event data that—if unnecessarily recorded—can both degrade server performance and cause database bloat. Section added to the docs explaining how to exclude devices from recording. Short version: use wildcard-friendly entity names (e.g., “pixelstrip_1_pixel_1”) and exclude them from recording with entity globs in configuration.yaml. E.g.,
recorder:
exclude:
entity_globs:
- light.pixelstrip*
I also learned that the unwanted data doesn’t last forever and will fall off after a few weeks. Or you can try to manually delete it, but that’s a pain. It’s easier to just avoid adding it to the database in the first place.