Outdoor illuminance template sensor

There is a math translation error. The results are incorrect currently. I realized this morning that I could probably use @craigb’s pyscript component to evaluate the original code and this has been incredibly helpful!

I was able to set both my template script and the pyscript code to the same time of day to compare their sun factor values. With both set 1 second before the sunrise_end time (7:16:02 am) the Python code output 0.9997222222222222 while my template produced 0.16665227643869543.


now = datetime.datetime(2020, 9, 23, 7, 16, 2)

Home Assistant Template
A note on hour=(7 +7): to make it easier for my brain I included the timezone offset to set the UTC time to match my local, California time.

{%- set test_time = states.sensor.time.last_updated.replace(hour=(7 +7),minute=16,second=2) %}
{%- set right_now = test_time.timestamp() %}

My brain is overheated. I’m going to park it for a while. But now that I know where the problem is, I should be able to figure it out.

1 Like


Code updated (see first post)
This is exactly what I needed. The calculations now match the custom_component. The math was messed up, but I couldn’t see how until I could see the results of the python math.
Screenshot 2020-09-23 114608

Honestly I credit explaining the problems on this thread to helping me resolve this! I hope you don’t mind. :blush:


What kind of dark clouds from hell appeared in your neighborhood to cause illuminance to drop from 10000 to 1000?

1 Like

Haha! OpenWeatherMap reported “Fog”. I think getting a weather source you trust is the trickiest thing with this whole system. But, that is why I wanted to create a template version. This way ANYBODY can modify the list of condition_factors to match their weather condition provider. Although, I tried very hard to make mine fairly universal through data normalization.

1 Like

Update: Sept 24, 2020

Grab a copy of the template code from the original post and start using it! The intent of this code is to give all of you (that aren’t comfortable with Python) the ability to customize the condition factors and even the sun factor in any way that works best for you.

The template code is performing very well! I started this as a personal challenge just to see if I could do it, and I did. I don’t plan on updating the code much in the future. Consider this your starting point!

Here is a screenshot how the template performed in the evening and this morning as compared to nkm8’s fork of ha-illuminance. The reason for the slight difference in timing is ha-illuminance estimates dawn and dusk, while I am getting, what I assume is a more accurate time from @pnbruckner’s sun2 component. Due to this comparison I modified the template code to keep the lowest lx value at 10 instead of 0.
Screenshot 2020-09-24 074700


Optional: Multiple Weather Condition Sensors
If your primary weather source goes “unavailable” sometimes, you can modify a few lines of code to add one or more backup sensors.

current_condition: original lines

{%- set factors = namespace(condition='',sun='') %}

{#- Retrieve the current condition and normalize the value #}
{%- set current_condition = states("weather.accuweather") %}
{%- set current_condition = current_condition|lower|replace("partly cloudy w/ ","")|replace("mostly cloudy w/ ","")|replace("freezing","")|replace("and","")|replace(" ", "")|replace("-", " ")|replace("_", " ")|replace("(","")|replace(")","") %}

current_condition: new lines (with 2 backup condition sensors)

{%- set factors = namespace(condition='',sun='',current_condition='') %}

{#- Retrieve the current condition and normalize the value #}
{%- set weather_sensors = [
] %}
{%- for sensor in weather_sensors if states(sensor) not in ["unknown","unavailable"] and factors.current_condition == "" %}
  {%- set factors.current_condition = states(sensor) %}
{%- endfor %}
{%- set current_condition = factors.current_condition|lower|replace("partly cloudy w/ ","")|replace("mostly cloudy w/ ","")|replace("freezing","")|replace("and","")|replace(" ", "")|replace("-", " ")|replace("_", " ")|replace("(","")|replace(")","") %}

A small change to the line that does normalizes the current_conditions variable (with lots of replace() filters. The |replace(" ", "") needs to be moved so it is the last replace on that line. I ran into a situation this morning where the condition was “mostly cloudy”, instead of “mostlycloudy” like I expected.

I believe that this line of code is incorrect, if I comment it out the template runs, but otherwise it always returns a value of 10. I believe the issue is after the assignment you cannot reference factors.current_condition as that does not exist. It just needs to be current_condition = current_condition…
So the corrected line is:

{%- set current_condition = current_condition|lower|replace("partly cloudy w/ ","")|replace("mostly cloudy w/ ","")|replace("freezing","")|replace("and","")|replace("-", " ")|replace("_", " ")|replace("(","")|replace(")","")|replace(" ", "") %}


1 Like

Oops! I just realized what the problem was. Here is the correct line of code:

{%- set current_condition = current_condition|lower|replace("partly cloudy w/ ","")|replace("mostly cloudy w/ ","")|replace("freezing","")|replace("and","")|replace("-", " ")|replace("_", " ")|replace("(","")|replace(")","")|replace(" ", "") %}

I mistakenly left a code fragment which was intended for the Optional: Multiple Weather Condition Sensors. Sorry about that. (factors.current_condition should have just been current_condition.)

{%- set current_condition = factors.current_condition|lower|replace("partly cloudy w/ ","")|replace("mostly cloudy w/ ","")|replace("freezing","")|replace("and","")|replace("-", " ")|replace("_", " ")|replace("(","")|replace(")","")|replace(" ", "") %}

Yep, HA has been, and continues to be, a moving target. FYI, just released updates to my custom integration to deal with changes through 0.117. I don’t use it anymore myself (since I got a light sensor a while ago) so can’t be sure it’s 100% right, but it does appear to work again (and at least doesn’t crash anymore.) Having said that seems like you’ve gone beyond what I did anyway.


For some reason my HA didn’t like that so I used:

          {#- Compute Sun Factor #}
          {%- set right_now = now() | as_timestamp %}


1 Like

Also @BrianHanifin you seem to have updated to:

{%- elif right_now <= sunrise_end %}
  {%- set factors.sun = ((right_now - sunrise_begin) / (60*60*60)) * 10 %}
{%- else %}
  {%- set factors.sun = ((sunset_end - right_now) / (60*60*60)) * 10 %}
{%- endif %}

But the original post doesn’t reflect that. Can you confirm the code in Post 1 is actually correct?
It shows /(6060) not (6060*60))*10
Also I have to use now() as the other function doesn’t work and gives log errors

I had problems with

{%- set right_now = states.sensor.time.last_updated.timestamp() %}

at first too, because I apparently did not have a time sensor in my config yet. I updated to include the following in sensors.yaml, which fixed the problem for me. (@BrianHanifin, maybe update the OP to reflect this dependency)

- platform: time_date
    - 'time'

Is there a reason to not use now()?

I don’t believe there is.

It’s odd because the original code did use (now) but for some unexplained reason he switched it.

That was a mistake which I made early in development. I didn’t fully understand the math then, but I have been updating the code in the first post with any changes as I go. For example I just switched to now() | as_timestamp() per your suggestion.

1 Like

At the bottom of this post is a link to a snapshot of my personal variation on this sensor. To make it easier for me to troubleshoot the code I have broke the 3 pieces of data out into attributes of the sensor. I am including this for the benefit of advanced users.

You can see the 3 attributes in the below screenshot.

My preferred weather source becomes unavailable after I hit their limit for the day. So the current_condition attribute automatically fails over the the next weather provider in the list of weather_sensors. This is more complexity than most people will need, so use this as a reference and replace that code to your current weather condition from a single sensor.

1 Like

This is great work guys. I am going to use it to turn on some lights gradually from a darker area of the house first then the other areas slightly later. I was using Dawn and Dusk plus offsets, then a sunlight percentage calculation which didn’t quite hit the mark. Going to monitor the values to see what triggers to use.
Thanks again a keep up the good work.
P.S. I used the example from BrianHanifin’s post #43 and it seems to be working.


I have just started to try and get useful information out of this script (which works great BTW)

Here is my automation:

  - id: '1505977024304'
    alias: Turn Lounge Light On Elevation < 25° & after 4PM
    - platform: state
      from: 'on'
      entity_id: 'binary_sensor.sun_above_25'
      to: 'off'
    - platform: time
      at: '16:00:00'
    - condition: and
      - condition: time
        after: '16:00:00'
      - condition: and
        - condition: or
          - "{{ (states('sensor.illuminance') | float < 7500 ) and (states('sensor.estimated_illuminance') | float < 10000) }}"
          - condition: state
            entity_id: 'binary_sensor.sun_above_25'
            state: 'off'
    - condition: state
      entity_id: 'input_boolean.homeandawayauto'
      state: 'on'
    - service: script.turn_on
        entity_id: script.loungenormal

So I want the lights in the lounge room to go on if the sun is below 25° and after 4PM. So I am using Phil Bruckners sun2 binary sensor that switches off at 25°

In Summer though, I don’t want it to switch on unless it’s low light outside. So I use this script to provide sensor.illuminance with a local weather provider in Australia (BOM) and I also use Phil Bruckners illuminance with met.no but I set a different illuminance for both . With the local one < 7500 and the met.no one <10000
(I also have a global overide input_boolean for when we are not home)
Initial testing seems to give the desired result…

1 Like