Home Assistant 2023.6.0
Supervisor 2023.06.1
Operating System 10.2
Frontend 20230607.0 - latest
I apparently copied from Supervisor. let me delete and recreate.
apparently I just needed to remove it and put it back… works now.
I am having the same issue after updating to 2023.6.1, I opened up an issue on the repo: "RuntimeError: Cannot modify ReadOnlyDict" after upgrade to 2023.6.1 · Issue #34 · Breina/ha-artnet-led · GitHub
Home Assistant 2023.6.1
Supervisor 2023.06.1
Operating System 10.2
Frontend 20230608.0 - latest
I’ll give that a try too.
Quick update, removing and readding the integration also fixed it for me!
Okay thanks for the reports guys! I will investigate what might cause this.
1 Like
What is the best way to create a new fixture “type?” (other than the currently implemented ‘fixed’ ‘binary’ ‘dimmer’ ‘rgb’ ‘rgbw’ 'rgbww or ‘color_temp’). Would that require homeassistant core changes, or can I bolt-on new light type definition only within artnet_led code?
What I want:
- I want to control – as if it’s ONE color_temp fixture – some custom-built LED fixtures that internally are built from 4 different color WHITE LED arrays. Essentially, they are WWWW lights
- Each of the 4 WHITE LED arrays within a fixture are different calibrated, fixed color temps, as example 6500K, 5200K, 3000K, 1800K respectively.
- To change the fixture’s color_temp, or to emulate warm-dimming of the fixture, I’d do some custom math equations in Python to set the independent brightness of the different WHITE arrays within the fixture. I’m hoping to implement that ideally within modified artnet_led code, or else I have to use separate module in appdaemon (but that makes it more difficult to use the 16-bit fading with pyartnet and the direct port addresses of the dmx channels for each array).
What I have now:
- I’ve got the 4 white arrays working individually in artnet_led as separate lights. I added code to initialize each WHITE light to a color temp. Since each array is controlled separately, I have 4 controls, so this doesn’t meet my needs for having just ONE control for the entire fixture.
- I can do simple mixing between 2 arrays if I group them as a color_temp light, but this doesn’t fade with my math, nor does it allow me to fade between 4 different color temps.
- I tried to use platform: group as a hack, but the scripting is way too complicated to iterate through and do math for each group member of the group.
Question is whether the “light” definitions can be extended for a custom fixture? Maybe to add something like COLOR_MODE_FIXTURE_COLOR_TEMP (a made-up name) to the light definitions. This would operate in the User Interface just like a COLOR_TEMP light would, but in the code it actually adjusts 4 different lights. Implementation code could be similar to RGBW, but the mixing logic between channels would use different math.
from homeassistant.components.light import (
ATTR_BRIGHTNESS,
ATTR_COLOR_TEMP,
ATTR_RGB_COLOR,
ATTR_RGBW_COLOR,
ATTR_RGBWW_COLOR,
ATTR_TRANSITION,
COLOR_MODE_BRIGHTNESS,
COLOR_MODE_COLOR_TEMP,
COLOR_MODE_RGB,
COLOR_MODE_RGBW,
COLOR_MODE_RGBWW,
SUPPORT_TRANSITION,
PLATFORM_SCHEMA,
LightEntity, COLOR_MODE_ONOFF, COLOR_MODE_WHITE,
)
Thoughts?
Sorry to make multiple posts.
In the “Compatibility” table on breina github site, should “custom_white” text be changed to “color_temp”?
Happy to hear you’re looking to contribute! I’ve ran into this before, and it would require some core changes to have it within 1 light.
The gist of it is that HA expects people to use the device registry to group different LEDs together. Currently ha_artnet_led doesn’t have that implemented, but it’s on the back of my mind when doing my next refactor.
A really beautiful solution isn’t there right now I’m afraid.
Fixed the custom_white in the README, thanks for noticing! 
Should be fixed now in v0.1.9.
1 Like
Hello, I have simple led strips, one color.
Connected to a DMX controller, I’ve been running them for many months with this simple setup:
- channel: 46
name: led_m_1
type: dimmer
- channel: 47
name: led_m_2
type: dimmer
- channel: 48
name: led_m_3
type: dimmer
Since the last update I can no longer turn them on/off.
has something changed ?
What is the right configuration to use?
Thank you
Regarding support for custom arrays of 4 WHITE LEDs: ONE OPTION that I like but can’t seem to finalize is to use a “phantom” (virtual) color_temp light as a master control in an unused dmx channel (channel 11, in the simple example below). Whenever the “phantom” light is changed by HA or GUI, the code for color_temp should actually update the physical channels (channels 3, 5, 7, 9) of the 4 LED entities. The main problem I have is: how one entity (“phantom” on channel 11) can reliably find and index into the physical channel numbers of the physical LED entities (and also use the output_correction and interpolation values already implemented for channels 3,5,7,9?) See config below for example (I added code to handle “fixed_color_temp” mireds parameter in config):
ANOTHER OPTION, I am thinking of a different work-around solution – How about if I implement a custom ColorMode.XY light type? Currently, it appears that ColorMode.XY type is not yet implemented in artnet_led.
In the code for ColorMode.XY, I can then define my own custom array of 4 LEDs, do custom CCT equations and brightness in that module. Although the code implementation would be custom for my own 4-LED fixture setup, maybe it can be further generalized with a switch?
For instance, can the light be defined with “wwww” channel setup flags, to indicate the light is built of 4 white channels, each one is different CCT? Not sure, but I think the util/channel_switch function might be extended to allow for that, and to generalize: other types of custom .XY implementations (maybe extending to UV LEDs for instance)?
node_type: artnet-direct # Which protocol to use
universes: # Support for multiple universes
1: # Nr of Universe (see configuration of your Art-Net Node)
output_correction: cubic
channel_size: 16bit
transition: 2
devices:
- channel: 3 # first physical used channel of dmx controller
name: my_dmx_1800K_strip # 1800K dynamic warm-dim LED strip varies 1800K-3000K
type: dimmer
- channel: 5
name: my_dmx_3200K_strip # 3200K LED strip
type: dimmer
fixed_color_temp: 313
- channel: 7
name: my_dmx_5600K_strip # 5600K LED strip
type: dimmer
fixed_color_temp: 179
- channel: 9
name: my_dmx_6500K_strip # 6500K LED strip
type: dimmer
fixed_color_temp: 153
- channel: 11 # "PHANTOM" control, unused dummy location on dmx, use as the color_temp and brightness master control of the entire fixture
name: my_dmx_phantom_dimmer # A master warm-dimmer. To implement seamless warm-dim of ALL lights combined with custom math
type: color_temp
min_temp: 1800K
max_temp: 6500K
That’s odd, can you check if you see anything in the logs? The configuration is ok by the looks of it.
Yeah I see we’re running into hard limitations on how the integration is configured. I think it should be revised anyway, as there’s other open Issues that run into this same problem. Further customization just isn’t really possible; any solution for you is going to necessarily be a hack in its current form.
I’ve since discovered Open Fixture Library, and their fixture format. The main idea here is to decouple channels from fixture capabilities, and then couple HA Entities onto those capabilities. So instead of configuring a channel and defining what that is, you would define your color_temp entity to a fixture’s capabilities, which will then map onto channels.
I’m a bit stuck in the research phase on this though; if people are going to have to change their config, I want to do it only once. Meaning we have to look forward into how RDM and E1.31 sACN integrates in the future.
1 Like
Thanks for the reply
- channel: 42
name: led_p_1
type: dimmer
transition: 1
- channel: 43
name: led_p_2
type: dimmer
transition: 1
- channel: 44
name: led_p_3
type: dimmer
transition: 1
- channel: 45
name: led_p_4
type: dimmer
transition: 1
- channel: 46
name: led_m_1
type: dimmer
transition: 1
- channel: 47
name: led_m_2
type: dimmer
transition: 1
- channel: 48
name: led_m_3
type: dimmer
transition: 1
So, I did all the possible variations. Here are the results:
- By setting everything as “binary” all channels work
- By adding the “Transition 1” line, only channels 43 and 45 work
I am going crazy…
I’ve turned on debug logging, but I can’t figure out where to go to look at them
Settings > System > Logs
Search for artnet_led and click open any errors you see.
Questo errore ha avuto origine da un'integrazione personalizzata.
Logger: custom_components.artnet_led.client.artnet_server
Source: custom_components/artnet_led/client/artnet_server.py:247
Integration: artnet_led (documentation, issues)
First occurred: 12:03:11 (1 occurrences)
Last logged: 12:03:11
Haven't seen node 192.168.20.69#0 for 5 seconds; removing it.
Logger: homeassistant.core
Source: core.py:361
First occurred: 11:59:13 (1 occurrences)
Last logged: 11:59:13
Something is blocking Home Assistant from wrapping up the start up phase. We're going to continue anyway. Please report the following info at https://github.com/home-assistant/core/issues: sonoff, sensor.mqtt, usb, sensor.broadlink, binary_sensor.shelly, hardware, default_config, update.mqtt, cast, light.artnet_led, sensor.esphome, sensor.hassio, frontend, energy, sensor.fully_kiosk, image_upload, fan.sonoff, device_tracker.mobile_app, stt, application_credentials, config, media_player, webhook, lock, network, bluetooth, api, hassio, button.mqtt, cover.mqtt, auth, select.mqtt, button.sonoff, switch_as_x, tapo, fully_kiosk, switch.esphome, switch.shelly, ssdp, hacs, device_tracker, camera.mqtt, light.mqtt, update, input_number, system_log, scene, sensor.shelly, tts.google_translate, conversation, button.shelly, binary_sensor.sonoff, number.sonoff, humidifier, fan, input_button, device_tracker.mqtt, logger, shelly, vacuum.mqtt, sensor.sun, system_health, analytics, device_automation, update.hassio, fan.mqtt, timer, cloud, sensor.mobile_app, notify, notify.group, button, vacuum, binary_sensor.esphome, update.shelly, weather.met, search, homeassistant, sensor.time_date, broadlink, input_select, switch.mqtt, binary_sensor.hassio, met, sensor.tapo, humidifier.mqtt, light.tapo, file_upload, alarm_control_panel, onboarding, binary_sensor.fully_kiosk, lock.mqtt, input_text, text.mqtt, zeroconf, light, group, notify.mobile_app, switch.fully_kiosk, input_boolean, sensor.energy, repairs, websocket_api, text, mobile_app, automation, binary_sensor.mobile_app, sensor.template, tts, script, recorder, media_player.fully_kiosk, number, remote, persistent_notification, sensor.sonoff, switch.sonoff, stream, number.mqtt, logbook, climate.sonoff, telegram_bot, binary_sensor, person, diagnostics, generic, weather, counter, template, http, media_player.cast, light.switch_as_x, button.fully_kiosk, mqtt, camera.generic, dhcp, siren, light.shelly, light.sonoff, cover.shelly, sensor.hacs, blueprint, trace, map, switch.broadlink, media_source, input_datetime, binary_sensor.group, scene.mqtt, select, radio_browser, scene.homeassistant, light.group, cover, notify.telegram, my, assist_pipeline, binary_sensor.mqtt, binary_sensor.tapo, siren.mqtt, remote.sonoff, number.fully_kiosk, sensor, camera, button.esphome, zone, sun, remote.broadlink, alarm_control_panel.manual, history, homeassistant_alerts, climate.mqtt, cover.sonoff, climate, tag, schedule, lovelace, alarm_control_panel.mqtt, switch, esphome, switch.tapo, light.esphome
Hmm nothing abnormal… I don’t see anything going wrong directly.
A surefire way to fix it is to re-install;
- First remove the integration
- Comment or remove the YAML config
- Restart
- Delete the light entities
- Install this integration and re-introduce the config
- Restart
Thank you!
I followed the procedure and now everything works!!!
Hello, first let me say that this is an awesome integration! Absolutely something that I need. However, I am having a bit of an issue getting this to work with multiple universes. I’ve got both input and output working just fine with Universe 0 but when I try to setup a simple config like this:
light:
- platform: artnet_led
host: 10.0.1.98 # IP of Art-Net Node
max_fps: 25 # Max 40 per second
refresh_every: 0 # Resend values if no fades are running every x seconds, 0 disables automatic refresh
node_type: artnet-controller # Which protocol to use
universes: # Support for multiple universes
0: # Nr of Universe (see configuration of your Art-Net Node)
devices:
# Dimmer
- channel: 1 # first channel of dmx dimmer
name: my_dimmer # name
type: dimmer # type
channel_size: 8bit # width of the channel sent to DMX device, default "8bit", "16bit", "24bit" and "32bit" available.
1: # Nr of Universe (see configuration of your Art-Net Node)
devices:
# Dimmer
- channel: 1 # first channel of dmx dimmer
name: my_dimmer_1 # name
type: dimmer # type
channel_size: 8bit # width of the channel sent to DMX device, default "8bit", "16bit", "24bit" and "32bit" available.
I get nothing on Art-Net universe 1. I’ve tried it without the universe zero as well and still the same thing. Perhaps I’m misunderstanding how the multiple universe setup is supposed to work. If so I would greatly appreciate some help!
This is an amazing integration and may be able to solve my problems, but I can’t get it working. Am I able to use this to talk to my CueServer Mini by entering its IP and selecting sacn as the node type?
light:
- platform: artnet_led
host: 10.0.1.202. #my local CueServer Mini IP
max_fps: 25
refresh_every: 0
node_type: sacn #I have tried each type
universes:
0:
send_partial_universe: True
output_correction: quadratic
devices:
- channel: 20 #3 Channel RGB that I am able to control using either LumenID and CueServer Studio
name: my_dmx_light_test
type: rgb
transition: 1
output_correction: quadratic
channel_size: 8bit
This is how I am trying to test it and nothing shows up in HA.
This is what I am using to control these lights right now, I would love to have them set up as RGB dimmers in HA.
1 Like