Wrong brightness from time in template if statement

Configuration
21

Ok let’s do that. I don’t know how to setup the sensor though.

Apparently not:

sensor:
  - platform: template
    sensors:
      brightness_test:
        friendly_name: Brightness test
        icon_template: mdi:ceiling-light
        value_template:
          {% if now().hour < 6 %}
          {{ 6 }}
          {% elif now().hour < 9 %}
          {{ (((now().hour*60 + now().minute) * (46/45)) - 360 ) | round(0) }}
          {% elif now().hour < 22 %}
          {{ 192 }}
          {% else %}
          {{ (((now().hour*60 + now().minute) * -(184/119)) + 2233.0084 ) | round(0) }}
          {% endif %}
22

Yeah, that’s what it should look like. Don’t add an entity_id, just update it from the service with the automation.

23

Ah yes I forgot the symbols. value_template: >- works.

And added to the automation:

  action:
  - service: homeassistant.update_entity
    data:
      entity_id: sensor.brightness_test

Ah and for the notification:

  action:
  - delay:
      seconds: 3
  - service: notify.ios_phone
    data:
      message: "Hallway lamp b<9 and sensor.brightness_test value is {{ states('sensor.brightness_test') }}"

Thought to delay it a bit to make sure the sensor is updated.

24

@petro
Just had a hit on brightness 8 but not sure if the new sensor value did get updated. It said 192 and “xx minutes ago”. Could be its initial value too.

I manually set it too 200 and then it said “x seconds ago.”

I guess if it hits 192 and it is 192 already then the timestamp doesn’t update?

25

well, if the update is not working you can always add the entity sun.sun. it will update the sensor every minute. I believe last changed (what is on the UI) only will tell you when things changed.

26

Yes, so it worked before. Meaning that from one sample of hitting 8 we have:
Sensor: 192
Light: 8

27

I’d look towards your light disconnecting from HA then. I mean, it’s possible that HA is screwing up. This would be something in the component for your light only, and even then I find that hard to believe. But, it’s still possible. What light component are you using?

28

This is a Philips Hue color bulb. It never was shown as unavailable in HA or Hue application.
Initial pairing was done via the (auto) discovery. Later I removed discovery and manually pointed the Hue component to the ip.

29

Using new formulas since yesterday (will be released in a how to guide soon).

Just got a brightness of ‘2,’ while it should have been ‘121’ (as said by the test sensor).
Meanwhile, while the formulas are changed to be even more dynamic, with current settings ‘2’ is not even a possible outcome of the formula…

My feeling is still that HA trips over the template somehow.

30

I really think you are looking at this wrong. Other people would be having this issue. I have 40 or so template sensors, not one of them screws up. In my experience, any intermittent issues always leads to hardware or communication issues. Having your template sensor side by side your automation confirms that. Hell, you can even look at your template sensor history, see if that trips up. The template logic all gets executed through the same code. So if your automation template truly was screwing up 0.1% of the time, you’d see the same screw ups 0.1% of the time in all other templates. The only difference here is your hardware, or the component setting the lights on your hardware. The template is not the problem.

EDIT: Try this if you really can’t get past this template thing. Remove the template and set the lights to 121 at all hours of the day. I’ll put money on it that it will screw up still without the template.

31

Okay sounds true.

Trying a fixed ‘192’ now.

  - service: light.turn_on
    data_template:
      entity_id: light.hallway
      color_temp: 250
      brightness: 192

After that going to use the formulas on another light (same platform).

32

You’ll have to rule out resume state on your switch as well. My lights when turn on is sent will resume to the last state. That could also be a possibility. But again. You are the only guy in all of home assistant with this happening and lights are apart of pretty much every ones configuration.

33

Yes when turning on the light it will restore state if not provided new data. But, the last state should not even be 8 or lower after having been turned on during the day (thus >8, <192) already.

34

The error rate seemed to have dropped a bit after having put in | ints for all the brightness outcomes, which are a bit more now after the formula got extended greatly.

From more extended debug messages I also found out that likely the low brightness is set after the light is already on for ‘some time,’ e.g. 20 seconds, or 30 seconds, etc.

Moved to another hardware platform hosting HA today, so we will see if that has influence, I don’t expect so.

Maybe it is the bulb then.

35

When I was referring to hardware, i should have clarified. I was always referring to the bulb, not the system. These IOT devices are hit and miss and none of them behave the same way. Computer hardware is pretty rock solid.

36

Yeah I always understood you meant the bulb itself. And so far as this has developed that indeed seems to be the case, also as a similar script on a (different) bulb has no problems.

1 Like
37

I really like the brightness flow of your automation. I’d really like to test/implement it also in my config :slight_smile: .
Just a quick question, because I can’t reproduce your formula… Is it possible to get the same formula, but lowering the light already at 20:00 to 23:00?

38

Hi,

Yes. In fact, I have upgraded the setup so that the values are now variables that are set via Lovelace input sliders. This means you can set the low and high brightness, the times when to start fading in and finish fading in (aka reach high brightness), the times when to start fading out and finish fading out (aka reaching low brightness).

I will post it in a new topic and link from here. I hope tomorrow.

39

That is great! Really looking forward to that!

40