Can't get rid of "ZeroDivisionError: division by zero"

Just to say, things worked great at one point. I didn’t change anything with the automations. But, it’s been like hit or miss just making up random numbers to stop this error across a number of automations now. At this point, I’d just like to see what the logic is and if there’s a way to get some expert help out there to solve it.


Lots of Clouds: Parallel action at step 1: parallel 2: Error executing script. Error rendering template for call_service at pos 1: ZeroDivisionError: division by zero
Lots of Clouds: Error executing script. Error rendering template for parallel at pos 1: ZeroDivisionError: division by zero


- id: '331899958999003'
  alias: Lots of Clouds
  - platform: numeric_state
    entity_id: sensor.lightlevel_kitchen
    above: 0
    below: 467
      hours: 0
      minutes: 3
      seconds: 0
      milliseconds: 0
  - condition: and
    - condition: sun
      before: sunset
      before_offset: -01:15:01
    - condition: time
      after: 09:10
    - condition: state
      entity_id: light.kitchen_under_cabinet
      state: 'on'
    - condition: state
      entity_id: cover.velux_left
      state: open
    - condition: state
      entity_id: cover.velux_right_2
      state: open
  - parallel:
    - service: script.fade_light_v2
        light: light.kitchen_main_lights
        end_pct: 51
        transition: 125
    - service: script.fade_light_v2
        light: light.kitchen_under_cabinet
        end_pct: 71
        transition: 155
    - service: script.fade_light_v2
        light: light.kitchen_sink_light
        end_pct: 51
        transition: 65

I used light_fader, light_fader #2, and light_fader #3 variants to test across different versions of the script from the community. #2 was in use for about a year without issue until I did an HA upgrade which was behind a few months.

This is the script’s code:

  description: "Fades lights to a desired level over a specified transition period."
      name: Light
      description: Entity_id of light.
          domain: light
      name: End brightness Level
      description: Integer value from 0 to 100 representing the desired final brightness level.
          min: 0
          max: 100
          step: 1
          mode: slider
      default: 50
      example: "50"
      name: Transition Time
      description: Transition time for fading in seconds.
          min: 0
          max: 1800
          step: 1
          mode: slider
      default: 10
      example: "10"
  mode: parallel
    - variables:
        start_pct: "{{ ((state_attr(light, 'brightness') | int(0))/255*100) | round(0, default=0) }}"
        end_pct: "{{ end_pct | int(0) | round(0, default=0) }}"
        delay_msec: >-
          {{ ([100, (((transition / (end_pct - start_pct)) | abs) | round(3, default=0) * 1000) | int(0)]|sort)[1] }}
        sign: "{{ 1 if start_pct < end_pct else -1 }}"
        n: "{{ 1000 * transition / delay_msec | int(0) }}"
    - repeat:
          - condition: template
            value_template: >-
              {% set b = state_attr(light, 'brightness') %}
              {% set b = (b/255*100)|round(0, default=0) if b != none else b %}
              {{  repeat.index <= n and
              ( (sign ==  1 and (b == none or b < end_pct)) or 
              (sign == -1 and (b != none or b|int(0) > end_pct)) ) and 
              (b | round(0, default=0) - (start_pct + ((repeat.index - 1) * sign))) | abs < 3 }}
          - delay:
              milliseconds: "{{ delay_msec }}"
          - service: light.turn_on
              entity_id: "{{ light }}"
              brightness_pct: "{{ ([0, (start_pct + (repeat.index * sign)), 100]|sort)[1] }}"    

I am HAPPY to send a couple beers via Paypal or something as compensation. Been drinking a few myself off and on this weekend toying with this to the consternation of my wife.

Thanks for thinking about it.

Here’s one potential source of the error:

What would happen if the light’s current “start” brightness is the same as the desired “end” brightness?

The template subtracts the two values and the result is 0 which it uses to divide into the transition value and the result is a divide-by-zero error

transition / (end_pct - start_pct)

You should enhance the template to guard against this situation. Basically, if the two values are identical then the script has nothing to do other than exit.


BTW, I suggest you examine the script’s trace to see the details of the script’s execution.

Oh my God you are brilliant. It’s probably the whole dang problem with these floods of errors. Sensor probably falls out of bounds for a couple of seconds and returns. Ugggggggggh lol. Few other anomalies but quashing this may well lead me to s dumb error to fix the others.

I haven’t done much with the idea of if then else outside of bash scripts. Any suggestions on where to learn this?

Owe you a beer. Lemme know how to send.

I suggest looking at the examples in the documentation section dedicated to Templating.

Easiest way would be to buy me a coffee.

Caffeine sent. Will look at this templating thing and probably be annoying you for more input tomorrow or so.

FWIW, there are other solutions available for fading a light (namely a light that doesn’t support the transition option). Search the forum for “light fader”. For example, here are two:

Perhaps they already mitigate the aforementioned problem (and maybe other situations as well).

1 Like

Hi, @derekcentrico!

I’m the author of the second fading script that @123 linked to, and if you were to give that a try and if you might have any questions about getting it up and running or the like, feel free to @-me—I’ll be more than happy to chime in!

Wow yours looks a lot more versatile. I’ll play with it tomorrow during my work breaks! I have about 80 automations to convert if it works but may make more sense to something more capable than poorly hacking up an old script… although I’ll probably try to hack it up as well to learn.

1 Like

Right on, @derekcentrico—you got this!

Please consider marking my post above with the Solution tag. It will automatically place a check-mark next to the topic’s title which signals to other users that this topic has been resolved. This helps users find answers to similar questions.

For more information about the Solution tag, refer to guideline 21 in the FAQ.

Copy, marked as solution.

Upon my first coffee hydration, I figured out from reading about the scripting language used that this may be the solution to the old script:

          {% if end_pct != start_pct %}
            {{ ([100, (((transition / (end_pct - start_pct)) | abs) | round(3, default=0) * 1000) | int(0)]|sort)[1] }}
          {% else %}
          {% endif %}

I made the edit just to see if it works or not. No errors saving the scripts.yml so I guess that’s a decent sign.

Saved @handcoding script as well to have it loaded to start a slow migration today.

1 Like

Well that sucks. My thought about fixing the fader v2 script using the above if else didn’t work. The script “runs” but no actions occur so damn…

@handcoding I converted all of my fader v2 automations to your script. Used the defaults for most of it save for interval and end percent. Looking forward to seeing the results.

1 Like

That’s fantastic to hear, @derekcentrico!

You may wish to consider posting your results in handcoding’s topic, where users who are interested in light fader techniques are more likely to see it (as opposed to this topic which is labeled as being about a divide-by-zero error).

1 Like

@123 For sure. Done on this thread. Previous post was to confirm to anyone who came across it that my attempted IF/THEN/ELSE didn’t actually work. Definitely worth moving to @handcoding script. Worked just fine this morning on the first automation to be triggered.


1 Like