I would like discuss a feature request with you:
I use the light transition for all my lights. In general this works very well and as expected. Especially for soft start and soft stop everything is fine.
But I have a “problem” with the behaviour of long transition times.
The issue is that the state of the HA entity does not represent the real state of the device.
Compare it to a roller shutter: The (estimated) state of the roller shutter gets updated periodically in Home Assistant so that you can see where the roller shutter is at a given time. Additionally you can even see if it is moving.
In my oppinion it should be similar when using light transition. Right now the state of the entity does not report the true state of the device and I think this is just wrong. It does not have to be updated every millisecond but once every second (as long as it has changed) or so would be nice.
I can construct a scenario where this would be an issue: Let’s say you turn on a light with a transition of 10 minutes for whatever reason. Additionally you have an automation that does the following: Lower the brightness of the light by 20%.
Now after 5 minutes your light is dimmed to 50% (but HA says it is 100%). You trigger the automation because you want to lower the brightness by 20% (to effectively 30%) but HA raises it to (100-20 = ) 80% because it does not know the real state.
Don’t get me wrong here: I don’t have that automation. This is just a theoretical construct to emphasize the problem. I still think that the behaviour of the light entity with transition is not correct.
What do you think? Is this something that should be changed in this integration?
How do I map the Home Assistant devices so I can control them via ArtNet?
I have some light.ikea_of_sweden_tradfri_bulb_e27_cws_opal_600lm_light and other Zigbee bulbs that I’d like to expose over some lighting protocol so my lightshow can control the house, switch some smart sockets and turn the lights off (or have them available in the light show).
I’ve installed the addon and added the example config with an node_type: artnet-controller and now I can define devices to send out ArtNet packets to. But how do I do the other way round? Receive incoming input and have it control my non-ArtNet smart bulbs?
There are node red DMX or artnet addon modules you could tinker with to interface and synchronise between home assistant entities and artnet. May even be possible to achieve this within home assistant alone but I don’t know how.
I’ve read though a lot of this thread, and it’s clear that DMX control is working well for people.
But the configurations never seem to set the DMX Address of the lighting fixture. Obviously I’m missing something. But in other DMX software I"ve used, it goes [Universe] → [Device Address] → [/n/ channels]
I have two lighting fixtures, one on address 0002, another on 0005. The first has 11 control Channels, the second only two.
All example configurations just seem to jump straight from Universe to Channels. I’m confused. How do I configure channel 1 on device 0002 and channel 1 on device 0005 ?
If device 0002 and 0005 are on separate artnet nodes (thus IP addresses), you are forced to use node type artnet-direct. This is because the artnet-controller implementation follows the spec and will only allow a single value per controller/channel combination.
More people are waiting on this one, and it has been in the works for a while. Since this is a major overhaul, I don’t want to change the existing code too much, to avoid conflicts.
@Breina - thanks for the feedback, and understand your position. Good luck 1st with the major overhaul !
@turboPasqual - FYI: I applied your suggested code change in light.py but that did not result in the desired behavior … dimming was still linear however output correction quadratic defined for both universe and channels …
Did you change both occurences of “output_correction” to “set_output_correction”?
Additionally I think you need to restart home assistant after changing the code.
For me that had worked very well. Unfortunately this was not good enough for me. My DMX controllers already offer a “logarithmic” dimming curve which works better for me than the available dimming curves in this integration. Quadratic is still too steep and cubic/quadruple won’t switch on the light at all until I dim to a certain level (I think it was around 10%).
Maybe there will be an option in the future to implement individual dimming curves other than those that python already has.
By crawling the internet and finding 2 home assistant scripts I was able to gather a few dimming functions. Maybe those are of any help in the future.
Hi, everyone:
I’d like to chime in that just about all LED’d have a very non-linear response at the low end of the brightness and some also at the high end of brightness, that can’t fit into any one clean formula (unless it’s absurdly complex). Dimmers may have an impact as well, in that certain bulbs with certain dimmers may buzz, hiss, or flicker at the low end (or sometimes with lower-end hardware also near a 50% point).
I propose the following scheme of mapping the user’s intent (% illumination demand level) to the fixture’s performance, where P is the raw / native / uncorrected dimmer output in % and L is the actual light output in %. This is a finite list of 5 or 6 points that would profile a given type LED in a given type fixture:
P0: Highest P where L is still 0
P0.4: P where L is 0.4%; this would be the lowest flicker-free output from a fixture. 0.4% and not 0.5% as 0.004 is roughly 1/255
P1: P where L is 1%;
P10: P where L is 10%;
P40: P where L is 40%;
P90: P where L is 90% (optional);
The method of interpolation between these points is as you see fit. Because the light profile points are exact, whatever’s computationally simplest that’s one notch better than linear interpolation, I think can be good enough.
It’d be also perfectly fine to denominate these in units from 0 to 255 vs 0 to 100%, at equivalent brightness points. Either way, the thrust of my message in a nutshell is that:
The main objective is for the fixture to produce light in the 1-100% user input brightness range (or 1-255), i.e. map away the region where he fixture doesn’t light up.
The secondary objective is to “tame” to the extent possible the low end of the curve (that is highly peculiar to each LED model) such that useful low brightness levels can be selected - vs going from 1% to 2% input making LED jump straight to 20% of its light output.
The final objective is to facilitate brightness curve matching across different lights.
I’m quite convinced that NO choice of “pure” math functions where 0 maps to 0, can do it adequately. However profiling the light output starting point, a few low values biased towards the very start of light output, and one middle and one high value, can profile different lights to a point where pretty consistent output across them can be achieved with 5 or 6 data points.
There can be a global “brightness curve” setting on top of these already calibrated profiles. It should be a single number, akin to “gamma” in displays or photo editing, to be able to globally adjust the “middle bulge” of the brightness scale. The further from 1.0, the more distinct input brightness % levels would be assigned to the lower end of the scale of their light control sliders. (Although I feel this global curve ultimately ought to be more of a HA global light preference and HA already offers an entity mapping integration that can do one-value mapping.)
@turboPasqual I’m the author of Ashley’s Light Fader (which you had also linked to), and if it might be helpful to anyone here, the formulas for the curves that I’m using are all freely available at easings.net:
In each of the formulas below, x represents the current linear percentage of the fade that has been completed, as a value from 0.0 to 1.0. And then what’s returned is a number—also from 0.0 to 1.0—that represents the current percentage after that particular curve has been applied.
Hi, just to be lazy I wondered if you might share how you’re setting up and programming your moving head lights? I have to unexpectedly integrate some next week and hoping I can cut out the experiment-and-swear middle ground if possible!!
I am trying to get DMX lighting installed and configured in HA. I have the configuration.yaml setup and compiled with no startup errors I just don’t know where to put the rest of the files for DMX Artnet . My apologies for the noob questions Just need pointed in the right direction and I can’t find anything remotely close on the web, and the README instructions only talk about the configuration.yaml would someone mind showing me what needs to be configured, besides the configuration.yaml
I set up a parcan at channel 1, which works, and I’m now trying to set up a moving head light that I’ve set to be channel 6. It’s got 12 channels doing various things - is the below a sensible way of addressing these?
EDIT: this just worked, no universes…
using pknight artnet dmx adapter and a beamz cobra 100h for anyone trying the same…
Also, does anyone have any scene examples for light controls using this?
Do you happen to have any working NodeRed modules? I’ve tried the sACN ones and the Artnet one. But they’re either 5 or 8 years old and abandoned and I can’t get them to work any more. Or the ArtNet module (which is newer) just crashes the whole Node-Red.
I had hoped I can use this project, since it claims input support in some release note. And it’s not a 1 GB RAM Java beast that I have to run in addition to all the other addons on my Home Assistant…
Hi @turboPasqual, sorry for the late response, I have been out a while due to circumstances …
I still have to come back to my previous feedback: your proposed code change was working. In a 2nd observation I did monitor the actual DMX buffer on my Enttec DIN Ethergate, instead of the DMX value of the standard light entity in HA, and here the values were matching a quadratic or cubic behavior (and differing from the DMX value visible in HA, for some reason the correct value is not displayed here, still matching linear behavior).
However, as you also stated in later posts, I noticed during testing that these curves are not the way to go At that time I also remembered playing around a couple of years ago with different curves (parabolic, exponent and logarithmic) in combination with limiting the “working area”, as also proposed by @Chef-de-IT. This ended up with exponent curves giving very good results. To my opinion preventing a part of the working area by defining a Min and Max DMX value in between which the 0-100% dimming should take place, is at least even important as the curve defining relation between input % and output %
** copy from Siemens TIA Portal SCL code → driving Beckhoff KL2751 dimming module **
** exponent curve → I believe n=2 gave the best results, but might vary between bulbs and dimmer? **
@Breina when you work on the curve part I highly suggest:
Add also the possibility to define DMX Min and Max values as proposed
Forget about cubic and quadruple curve, but give the option to use exponent with “n” to chose. @all I know you have been proposing other curves but maybe we are making things too complex resulting @Breina doesnt’t know how to move forward and getting demotivated … I propose to take it step by step, so let’s start with this one which is quite straight forward and take it from there
@robinbervoets Robin, having thought about your response some more, and others, and based on my hospitality experience, I’ve this to say: broadly, we’ve 3 “stages” of light calibration. In priority order as I see it:
Profiling a bare fixture’s valid dimmer input and light output levels i.e. just defining the ranges where useful & safe light output is produced at all. In practical terms (most inclusive scenario I can think of - which I have seen in the field):
.
1.1 A dimmer or fixture may hiss or buzz badly in say the 0-5% dim level (electrical input). A fixture doesn’t light up at all in the 0-3% dim level. It lights up at say 3.1% dim level (lighting up at 7% of its max lumen output level) but besides hissing is also flickering. The flickering goes away at 6% dim (electric input) level, at which point the bulb is producing 11% of its max lumen output level.
.
1.1.1 In HA, I believe the proper representation would be, 0% on HA slider is 0 dim level (duh) and 0 lumen output level. Not sure if HA supports “disallowed” ranges on a slider, but if so, the next selectable % brightness level on the HA slider should be, in this fixture’s case, 11%. With the integration knowing that for this fixture, that 11% output maps to 6% electric input, so when user picks 11% the fixture gets that 6% dimmer input.
.
1.1.2 If no “disallowed” ranges are supported currently, then the integration should “split the bad range down the middle”: in this case for 0-5% user or scene/script brightness demand, it should just use 0 dim input level for the given fixture, and for 6-11% brightness demand, it should just use 6% dim input level that produces that lowest buzz/hiss/flicker free lowest available output from the dimmer+bare bulb/fixture. I feel, this “starting brightness point” handling is the most important in profiling a given fixture. If we just go linear or exponential per Robin, from there to 100% and do nothing else, we’ll already have solved like 70% of the problem with that singe calibration point.
.
1.2 Some lights can have an intermediate brightness flicker zone say 48-52% dimmer input, which may also be sensible to be able to exclude. But this is lower priority vs point 1.3 - and getting lower all the time as LED driver quality and sophistication improves.
.
1.3 De-rating per-light or light type where needed. Some fixtures or dimmers can be heat or wattage or bulb life (27ft ceiling, $400 labor to swap bulb) or otherwise constrained, where say above 82% dimmer input, things start melting or smelling or the curtain touching the fixture begins to smoke or the dimmer paddle looks like something out of a Dali painting. I’ve seen and smelled it all. In this example’s case it’d be great to make “real” 82% input the “de-facto” 100% for this given fixture or fixture type, i.e. max allowed dimmer input level (say corresponding to 92% lumen output level) so when the user or scene or script pick 100% for this light, 82% input is sent instead by this integration to the respective dimmer hardware, telling the user “this is the 100% you got, bud”. I’m sure on some other planet this is resolved between a conscientious manufacturer, a conscientious electrician, and a fully informed client with budget to buy good stuff and hire smart folks. Our planet, however, has unanimously been called “Dirt” for a reason.
.
The peculiarity in this case is, unlike the starting point 1.1.1 where the starting range of 1-11% is genuinely blocked off or split, I think in the case of the max point 1.3 (for particular lights/dimmers that need this de-rating) we ideally want to re-scale the range so the 100% from HA’s perspective is in fact 82% input internally in the integration.
.
Profiling curve. Our eye perceives brightness logarithmically - even more so than sound. For something to seem 10x brighter vs an already fairly bright object, it needs to “really” be like 400 times as bright in linear terms. So @robinbervoets very validly picked the exponential function to “moderate” / linearize the logarithmic human perception range. This is where a coefficient can be picked per fixture, helping to match different fixtures among each other. It’s absolutely vital that this curve is passing through the “actual initial good brightness point” as defined in 1.1.1 and ends in “de-facto 100%” point 1.3. I.e. the point defined in 1.1.1 should NOT be just slung over to become “the new (0,0)” as far as this curve is concerned - or else the entire early half of the curve is going to be way off. The point defined in 1.3, however, should be slung over to become “the new (100%,100%)”.
.
Optional. And should probably be an HA-wide feature - not this one integration’s. A user (as is often the case in hospitality) may want a larger chunk of the 0-100% brightness scale be allocated to picking among the multiple dim values more precisely. So this ought to be an HA-global property.
.
Separately, certain lights’ placement or treatment (like lamp shade) may also affect their “perceived” curve “as installed” as opposed to “bare”. Like an up-shining awning light in my experience. This can also be dependent on an ambient natural light level or “competing lights” level. This is admittedly pretty advanced and I’m not aware of any light control system that accounts for this. It’s somewhat synonymous to “volume-dependent equalization” in high end speaker management systems. Just brain-dumping it here for completeness.
