Add area_calculated_light based on areas luminance sensor and area_min_lux configuration parameter

[andyinno]

If a light sensor is present in the room, it makes sense to use the combined value of the illumination sensor in order to disable automatic lights.

My previous setup was:

• during night turn on all light at it's max brightness
• measure illumination level
• add in the automation, if the illumination level is greather than the maximum with the lights on, then don't turn on the lights.

What do you think?

[issue-label-bot[bot]]

Issue-Label Bot is automatically applying the label feature-request to this issue, with a confidence of 0.83. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[sti0]

You could achieve this by using a template binary-sensor which handels the illuminance level. In that way you could handle multiple scenarios like only turn on if illuminance level is under 30 lx, presence of people (e.g. no need to turn lights on by cats if nobody is at home)....

e.g.

binary_sensor:
  area_kuche_active:
        friendly_name: Area aktiviert
        value_template: >-
          {{ not ( is_state("input_boolean.area_kuche_auto_light","off") or
                   is_state("binary_sensor.people_home","off") or 
                  (is_state("binary_sensor.people_home","on") and 
                   ( states('sensor.ms_kuche_illuminance_lux')|int <  30)))  }}

simple use this as the disable_entity (in that case with disable_state: "off")

[jseidl]

As @sti0 said, that's exactly the intended use of disable_entity using template sensors over lux values.
This feature isn't baked in to give more flexibility on what you want to use as a disable reference.

[andyinno]

@sti0 I know that I can achive it, thank you in any case for providing the code.

@jseidl,Please let me rephrase,
I know that it is possible to use a template for disabling automatic lights.
from your blog post, you wanted to have all the things that you like in a single place. Therefore you added the possibility to join multiple sensors, and create area illuminance, area motion, area .... All this handled automatically.

Why am I now forced to create n binary sensors, one for each area, when it could be possible to have a single parameter in the configuration file?
I would love to have the addon integrated with the integration menu in the future. Without having to add anything to the configuration.yaml. Having the binary_sensor template directly handled by the addon would be a plus.
Could you please re-evaluate your decision?
thank you in advance

[jseidl]

For the integration menu, there's an issue tracking this feature #16 .

I try to keep versatility in focus so I don't want to tie the disable_entity to anything as of right now. One possibility would be to add an area_min_lux and then create an area_XYZ_light but that would conflict with the aggregation sensors.

I believe this could be implemented more in the lieu of "Auto create area_XYZ_calculated_light" then add this light sensor to the area_XYZ_light and then you'd need to manually specify binary_sensor.area_XYZ_light in the disable_entity.

[jseidl]

Good news! #350

Coming up on next release

[jseidl]

This is implemented in release 4.0.0 which is out!