I came up with this from the above slope.
{{ (-0.41 * states('sensor.kitchen_sensor_illuminance_lux')|int) +255 | round }}
Not sure if the math was right though.
But on the graph you posted above it should be
{{ (-0.57 * states('sensor.kitchen_sensor_illuminance_lux')|int) +283 | round }}
17/30 = .56666666 round to .57
850/3 = 283.3333 round to 283
hmm so how would I stop it going over 255 for the brightness. Because it’s trying to set 261 as the brightness right now when the lumens are at 39.
You only defined the problem for lumens between 50 and 500. If you want to allow for other use cases then yes, you’ll need to do something like:
if lumens < 50 brightness = 255
else (your formula above)
ah of course.
Perfect!
Thank you very much for helping me get to this.
It’s quite fun to see my light dynamically adjust though out the day. it seems my lumens sensor checks in every minute or less so it’s near real time!
for completeness,
Here is the final automation for anyone else looking at this.
- id: dynamically_adjust_kitchen_lights
alias: dynamically adjust kitchen lights
trigger:
platform: state
entity_id: sensor.kitchen_sensor_illuminance_lux
condition:
condition: time
after: "06:00:00"
before: "18:30:00"
action:
- service: light.turn_on
data_template:
entity_id: light.kitchen_pendant_lights
brightness: >-
{%- set kitchenbrightness = (-0.57 * states('sensor.kitchen_sensor_illuminance_lux') | float) + 283 %}
{% if states('sensor.kitchen_sensor_illuminance_lux') < '50' %}
255
{% else %}
{{ kitchenbrightness | round }}
{% endif %}
1 Like
Not sure if you aware but perception of brightness is logarithmic not linear, therefore, linear translation of the brightness measured by sensor to brightness of a lamp might not give desired result.
Indeed, do you have a better solution?
The solution should be to map brightness meassured by the sensor in logarithmic scale, e.g.: 500 lx and more: 0% lamp brightness; 375: 1.6% brightness; 255: 6.25% brightness; 155: 25% brightness; 0 lx: 100% brightness. It is easier btw to use brightness_pct. The numbers given are some approximations.
I was trying to get away from having to create “steps” of brightness and have it seem more fluid.
I was also using brightness over brightness_pct as brightness_pct is being deprecated.
If I can see an example of how to do this logarithmic rather than the way I have it now that’d be great.
But similarly perception of brightness (of the light) is not linear either so you probably have 2 log scales.
C++ has functions for log/ln so doable. Beyond my coding ability. The other option is a lookup table, but again not in my skillset.
Log/ln will require processing power, lookup table will take memory. Its a tradeoff.
I don’t see anywhere in docs that brightness_pct is deprecated Light
The code is rather simple, might provide it later. Alternatively, you might be interested in this Circadian lights. It would not use your brightness sensor but is much healthier model.
You don’t need two logarithmic scales, it is only one due to physiology how human eye perceive brightness.
Processing power is neglectable in this case.
The fact that we do not perceive light linearly plays in to both the lumen reading and the brightness setting.
The eye will not perceive the difference between 100 lumens and 200 lumens as the same as between 400 lumens and 500 lumens. It is not linear.
The eye will not perceive the difference between a light brightness of 50 to 100 as the same as between 150 and 200 - it is not a linear scale.
There are two non - linerarities to take into account.
I did see somewhere a reference to brightness_pct being deprecated - but it might be my poor memory. However one is just a scale from 0-255 the other is exactly the same range but goes from 0-100. There is no real advantage in using one over another, although 0-255 has greater granularity - but in terms of perception, it probably doesn’t matter!
I saw the brightness_pct depreciation message in my logs recently.
The main reason I wanted to achieve this was because on cloudy days, when the kitchen is darker, I’d like the lights to be brighter.
That’s why I was basing this off a lux sensor so when lux was low, the lights would be brighter.
Sorry, you’re wrong.
Wouldn’t be the first time!
@nickrout
I’m trying a variation on this, but want the lights to vary differently.
- 300 lux: light.turn_on at 70% (brightness 191)
- 50 lux: light.turn_on at 40% (brightness 107)
- over 300 lux: light.turn_off (brightness 0)
I’m getting an error though: Message malformed: template value should be a string for dictionary value @ data[‘action’][0][‘data’]
here is the code:
trigger:
- platform: state
entity_id: sensor.lichtsterkte_fietsenberging
action:
- service: light.turn_on
data:
entity_id: light.licht_bureau_1
brightness: >-
{%- set kitchenbrightness = (-0.356 * states('sensor.lichtsterkte_fietsenberging')|float) + 107 %}
{% if states('sensor.lichtsterkte_fietsenberging')|float > '300' %}
0
{% else %}
{{ kitchenbrightness | round }
{% endif %}
I got it resolved. Seems to be working correctly now.
trigger:
- platform: state
entity_id: sensor.lichtsterkte_fietsenberging
condition:
- condition: time
after: 07:30:00
before: "22:30:00"
weekday:
- mon
- tue
- wed
- thu
- fri
action:
- service: light.turn_on
data:
brightness: >
{% if states("sensor.lichtsterkte_fietsenberging")|int >= 300 %}
0
{% else %}
{{ (0.356 * states("sensor.lichtsterkte_fietsenberging")|int) + 107 }}
{% endif %}
entity_id: light.licht_bureau_1