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.
Finally had some time to look into it again, and I found a solution, maybe interesting for anyone else that tries to implement random dmx stuff (like to roto head mentioned above)
I checked the vlaues with lightjams and discovered that my assumption was correct. Even if I used light.toggle, it messed up after some times because sometimes it didnt send new values if the different lights where on or off (if a value is 0 it shows the light as off). I didnt find the pattern but found an easy fix.
First I set only one channel to rgbww and was able to controll all my 5 channels needed with one action.
The fix to the weird behaviour was to add a “light.turn.on” without any data at the end of every automation, this all the lights are always set to on.
Everything works flawless now
So I guess it is decided then, that the branch @Breina started will be the official DMX integration. I’ll move to that integration this weekend and probably archive my own branch to make things a little less confusing. Thanks @Breina for doing a great job on this!
Thanks for the work on this @Breina! I just migrated over, and everything is working great! Glad to see the DMX integration getting some renewed attention.
Made the switch today and everything is running fine. The only “issue” I had, was that a new dimmer light that gets turned on, gets a brightness of 0 so nothing happened. Had to set a brightness for every channel I have.
Is that recurring or a one time thing?
It was a one time thing. I rebooted several times without issues. Now, I installed 2022.9.1 and all entities got disabled. I see this in the logs:
Logger: homeassistant.config
Source: custom_components/artnet_led/light.py:7
Integration: artnet_led (documentation)
First occurred: 11:50:25 (1 occurrences)
Last logged: 11:50:25
Platform error: light
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config.py", line 878, in async_process_component_config
platform = p_integration.get_platform(domain)
File "/usr/src/homeassistant/homeassistant/loader.py", line 681, in get_platform
cache[full_name] = self._import_platform(platform_name)
File "/usr/src/homeassistant/homeassistant/loader.py", line 698, in _import_platform
return importlib.import_module(f"{self.pkg_path}.{platform_name}")
File "/usr/local/lib/python3.10/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
File "<frozen importlib._bootstrap>", line 1006, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 688, in _load_unlocked
File "<frozen importlib._bootstrap_external>", line 883, in exec_module
File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
File "/config/custom_components/artnet_led/light.py", line 7, in <module>
from homeassistant.components.light import (
ImportError: cannot import name 'ATTR_WHITE_VALUE' from 'homeassistant.components.light' (/usr/src/homeassistant/homeassistant/components/light/__init__.py)
https://developers.home-assistant.io/blog/2022/08/18/light_white_value_removed/
EDIT: I see it’s fixed on github. I installed using HACS. Maybe it’s not picking up the new version?
EDIT: HACS is messing up I think:
This shows the correct repository is added.
In the custom_components folder however, I get this:
This is not the manifest that is on github.
EDIT: removed it and re-added. I think somehow there was an issue because both integrations have domain name artnet_led. Problem solved!
I’m hoping to use this to enable me to trigger a smoke machine by using an ESPHome PIR motion sensor. This thread and the ha-artnet-led project seem to primarily talk about LED control, but I gotta imagine it would be possible to just trigger a smoke machine as well. Am I correct? If so, how?
Yep, willing to implement this for you. Someone else is using this for his ceiling fan as well. Please create an Issue for this on my repo: Issues · Breina/ha-artnet-led · GitHub
Thank you! I went ahead and submitted an issue.