That’s true, but I think, in this case, an RJ45 connector is “abused”, maybe to save some space on the device or to be able to use existing cables. I don’t think artnet is “going in that device” but regular DMX, just not with XLR connectors.
Thanks for your fast reply, really appreciate it.
Thanks for the device you linked, I was hoping to find a bit a cheaper solution since I only need it for my 2 TL60… but I guess its either that or buying different light’s that support native smarthome connections.
The Showtec almost costs as much as 1 of those lights
Yes, agreed re: abuse of RJ-45 in the case of being a DMX input/output; however, these ‘abuses’ are everywhere.
Also note that the RJ-45 abuse is not wild-west: there is dominant/standard pin assignment (I forget the name), and as I understand it, there is no danger of electrical damage to equipment (i.e. if you get it wrong, it won’t work, but at least it won’t fry your gear).
Ironically, the use of XLR3 for DMX is NOT this case. I forget which combo causes damage, but if you plug audio equipment to DMX using XLR3, you could end up with serious hassle and a big bill…
Thanks for the help guys!
One last question beofre I order the hardware:
I read the manual and it seems like the light uses a bit a weird kind of DMX controll:
From my understanding I have to send signals over 6 channels to set different colors/FX.
My idea now was to set 4 channels all as dimmer (I dont need RGBW), and create automations for the different colors/FX I want. But this seems to be a bit overcomplicated, maybe there is an easier way to do it.
My Idea:
config:
Action:
I added the disered value in % from 255 → set brightness 66% = 168 is this assumption correct?
Sorry for the maybe stupid questions but never worked with DMX before and I want to get this right before I order Hardware just to realize that it doesnt work the way I intended
Dont be sorry for asking questions. We’ve all been there and there’s no shame in it.
If you don’t want RGBW, why not go with CCT mode then? You’d need one dimmer for brightness adjustment and one for color temperature. If you’re not planning on changing the color temperature, I’d use a channel of type ‘fixed’ for that. Those never change values, not even when you call a service in HA to turn off all lights.
If you do want RGBW, I think you better use a dimmer type for brightness and an rgbw type for the next 4 channels. You assign the first RGB channel (=n+1) to the entity and it will use the next three as well. I don’t have any RGB(W) devices myself though, so I can’t speak from experience.
I dont need RGBW because I will use the HSI for colors (less channels used then). The idea with the RGB for the last three is very good thanks, so I only need to set values in one entity instead of all of them. Thanks I lot I will report back when I got the hardware.
Hi maznaz. So sorry for the super late reply.
I had these controllers in testing mode for quite a while and only last week decided to put them to use for the whole house.
I got 16-bit resolution working and compared with the gledopto controllers I had earlier, these controllers make the lights even brighter and the control respons is really fast.
About light flickering that does still occur which is a little bit annoying but I decided to live with it for now. Im not sure if there are any settings I could adjust to have a smoother fade.
Give me a reply if you need any assist in setup.
Im having some issues with restoring brightness and color_temp with the corb3000/ha-artnet-led integrations.
Every time I restart home-assistant, all lights from artnet_led integrations return to off and to default color temp 261,5 (middle value between cold and warm light)
I tried experimenting with parameter “refresh_every:” but that didnt do anything.
I re-downloaded files for the integrations via HACS. Checked files in file editor to verify they match with the files in the github repo.
I also tested with files in mvandenabeele/ha-artnet-led integration but that just renders all entities unavailable
Home Assistant 2022.8.5
Supervisor 2022.08.3
Operating System 8.4
on a rpi 4
lights.yaml:
Light before restart:
Light after restart:
mvandenabeele/ha-artnet-led:
Hi @methosmen
I haven’t updated to 2022.8.x yet, but I remember having issues with switching between the corb3000 branch and my own because of the incompatible way we generate unique id’s for the devices. If I’m not mistaken, a second set of devices get added to the list of entities (names ending with _1). I’ll update my Home Assistant this weekend if I can find the time, and fix my branch if needed. I’ve still not decided if I would jump on the branch @Breina created, but his and my branch are compatible at the configuration level (last time I checked anyway)
Merijn
Hi @merijn
I managed to find files for latest PR for corb integration. Then all entities were recreated. Removed old entities and renamed the new ones to match and vòila. It worked - now I have restored values on restart
Thank you so much for this commit
I am back to report, some problems solved, but some new ones are now here (sight)
I got my hardware, I went for a AIR2DMX Micro WLAN DMX Interface ArtNet Node, which seems like a good deal for 70$ compared to the other nodes.
So far everything working great, node setup, very responsive, all controlls work in Q light controller plus.
Now my new problem:
I tried both integrations mentioned in this thread and had the same problems with both of them, since the light uses some weird custom channels:
I set up channel 1-5 as dimmers, hoping I can just send the values I want and preset some colors/FX that I want.
This works great on the first few tries, except every 2nd time I trigger a automation the light goes out completly until I trigger again.
Here you see the automation to turn the light red
But the weirdest thing is, after some time it stops working entirely, for example when I trigger an FX (that works) and I want to trigger a color afterwards (that worked previously) , the light just stays white. If I trigger the FX again the FX works but colors dont
I works again every time I restart HA but after some time I have this weird behavour again and cant get colors and FX to work, it almost seems like it doesnt update all the channels…
Has someone an idea how to fix that? also the turn off every 2nd time is a bit annoying.
You’re setting light.t160_n to 100 which is HSI mode. Then, the following 3 channels are out of range according to the table you posted. I don’t know if that is the source of your problems, but it won’t hurt to fix it
Also, maybe toggle isn’t the best choice as you may not know if you’re turning the channel on or off. I’d use turn_on instead.
So strange to have that brightness channel from 0 to 100 instead of the full range from 0 to 255. I don’t have a lot of experience in different DMX devices, but this one sure seems odd.
What do you mean with out of Range?
I think the Brightness 0-100 is an error in the manual, because if I test with my Q light controller 255 is max brightness and 0 is off.
I also tried the turn_on instead of toggle now, at least it doesnt turn off anymore but it doesnt change values sometimes.
I just had an idea what could cause the problem. If I look at the light in my dashboard some of them show up as turned on and some as turned off
Is it possible that that interfears with the sending of the values? for example if HA sees tl60_n+2 as on it doesnt send the new value if I trigger another “turn_on”? if so is there a way to get around this?
Maybe the integration is “to advanced” for my usecase since I only need to send the values and ignore all the light stuff… is there a simple “send XXX to channel XX” integration or script?
I think I am getting closer but can’t wrap my head around it completly yet.
If a channel is off like that, it will still have a value in the DMX data stream, but it will be 0. If you turn on a channel that is already on but with a different brightness, the new brightness will be picked up as you’d expect. From what I see in your screenshots, I don’t think you’re doing something wrong and the integration should fit your needs perfectly. n+4 is turned off because you set its value to 0. I can only assume n+5 was already set to 0 since that isn’t touched in your automation.
About the out-or-range remark: assuming all toggle actions in your example are in fact turn_on actions; you set light.tl60_n to 100. 100 falls in the range of HSI which is from 52 to 103. In HSI, tl60_n+1 should be in the range of 0 to 100, but I believe you if you say brightness goes from 0 to 255. That would make more sense anyway. Next, tl60_n+2 should be between 0 and 180 but you set it to 255. And last, tl60_n+3 should be between 0 and 100, but you give it a value of 255. Unless the whole documentation is wrong, I think you are using the wrong values for this but your experiments may prove me wrong on this.
If you want to debug the values that are sent by the integration, I can recommend “The ArtNetominator” https://www.lightjams.com/artnetominator/ Select the network adapter you want to use for this tool in the upper left corner, and change the HA configuration to that IP address. After a restart, you should see the expected values appearing in the DMX Data field
Been thinking about implementing moving head lights controlling movig head spotlight? · Issue #62 · jnimmo/hass-dmx · GitHub
There’s specific channels for panning, tilting, strobing frequency, etc… I could kind off use the effects properties of LightEntity for the strobing, but it would be vastly uncomplete.
I don’t think there’s some way to hack LightEntity into supporting more functionality like this. One way I can think of is to make these channels a separate entity each and group it into one Device. Then we would have one LightEntity to select brightness and color, and several NumberEntities for the rest. Doesn’t really feel like the best way to go about it either.
What’s do you guys think about this?
Edit: Started a HA architecture discussion on this: Extending LightEntities in a generic way · Discussion #800 · home-assistant/architecture · GitHub
Also this one, for implementing fans https://github.com/jnimmo/hass-dmx/issues/54
I can of course use the FanEntity as a separate platform, and have this integrated easily, but the trick is in the config. We want to have only one DMX Master updating the universes, so we will need to share the ArtnetDMX instance between them.
The way to do this is to move to a one common platform that controls both lights and fans. The very annoying thing here is that this will make the config move from a platform under lights, to its own platform altogether. This means it’s a breaking change for everyone using the integration.
Is it worth it? Will we be having more and more types of devices in the future? We may be able to leverage the new Repairs feature for this, still have to look into that.
Hi,
Just wanted to report a breaking feature in HA Core 2022.9.
The DMX addon will have to be modified for it to work with 2022.9.
Got this error message: “Platform error light.artnet_led - cannot import name ‘ATTR_WHITE_VALUE’ from ‘homeassistant.components.light’”
Do not update your home assistant to 2022.9 until this has been resolved!!
Happy to report that my fork runs correctly on HA 2022.9: https://github.com/Breina/ha-artnet-led
If you’re up for it, you can migrate. Your configuration is compatible if you’re coming from jnimmo’s or corb3000’s version. For reference, here’s the open issue on their end: https://github.com/jnimmo/hass-dmx/issues/68
Thanks for picking up and taking DMX forwards @Breina!
I think moving to a platform makes long term sense to be able to implement different device types etc, and probably helps pave the way for config flow support.
Thats good to know. Will definately be migrating to this fork after the weekend.