Template sensor not updating as intended

Configuration
1

Hoping for some help getting a template sensor to update when it should.

I have a simple template sensor to return the min and max values of a couple of other entities, as attributes:-

- sensor:
  - unique_id: sensor.ipad_white_battery_info
    name: iPad White battery info
    icon: mdi:battery-alert
    variables:
      HAPP: "{{ states('sensor.ipad_air_white_battery_level') | int }}"
      ICLOUD: "{{ states('sensor.ipad_white_battery') | int }}"
    state: "{{ states('sensor.ipad_air_white_battery_state') }}"
    attributes:
      lo: "{{ min(HAPP,ICLOUD) }}"
      hi: "{{ max(HAPP,ICLOUD) }}"
      unit_of_measurement: "%"

The above is from an included templates: file. The templates are correct, work in the Template tester and when 'Template entities' are reloaded, the above sensor returns the correct values in the attributes. My problem is that they never update, even when the entity states on which they're based have changed - until I reload the 'Template entities'.

My understanding is that changes in those states should trigger an update to the sensor, but that appears to not be the case.

Thinking that to trigger an update, the sensor's 'state' value needs to change, I added the values of the other entities' states into this sensors 'state':-

- sensor:
  - unique_id: sensor.ipad_white_battery_info
    name: iPad White battery info
    icon: mdi:battery-alert
    variables:
      HAPP: "{{ states('sensor.ipad_air_white_battery_level') | int }}"
      ICLOUD: "{{ states('sensor.ipad_white_battery') | int }}"
      MINIMUM: "{{ min(HAPP,ICLOUD) }}"
      MAXIMUM: "{{ max(HAPP,ICLOUD) }}"
    state: "{{ MINIMUM|string+'<'+states('sensor.ipad_air_white_battery_state')+'<'+MAXIMUM|string }}"
    attributes:
      lo: "{{ MINIMUM }}"
      hi: "{{ MAXIMUM }}"
      unit_of_measurement: "%"

That will work I thought as my sensor's 'state' is now dependent on the values of those other entities 'states' and so should update when they change.

But the sensor still doesn't update when those other entities' states change.

I must be misunderstanding something here. If the state value changes for any other entity that is used in this sensor's 'state' template, should this sensor not update?

2

as far as I know variables in a template sensor are only rendered at template load, but not on every state change of the entities used in it. So they are rather static.
If you use a trigger based template sensor, they are loaded every time the sensor is triggerd, so something like this should work:

- triggers:
  - trigger: state
    entity_id:
    - sensor.ipad_air_white_battery_level
    - sensor.ipad_white_battery
    - states('sensor.ipad_air_white_battery_state
  sensor:
  - unique_id: sensor.ipad_white_battery_info
    name: iPad White battery info
    icon: mdi:battery-alert
    variables:
      HAPP: "{{ states('sensor.ipad_air_white_battery_level') | int }}"
      ICLOUD: "{{ states('sensor.ipad_white_battery') | int }}"
    state: "{{ states('sensor.ipad_air_white_battery_state') }}"
    attributes:
      lo: "{{ min(HAPP,ICLOUD) }}"
      hi: "{{ max(HAPP,ICLOUD) }}"
      unit_of_measurement: "%"

or you just don't use variables, and use the entity states directly

- sensor:
  - unique_id: sensor.ipad_white_battery_info
    name: iPad White battery info
    icon: mdi:battery-alert
    state: "{{ states('sensor.ipad_air_white_battery_state') }}"
    attributes:
      lo: "{{ min( states('sensor.ipad_air_white_battery_level') | int, states('sensor.ipad_white_battery') | int) }}"
      hi: "{{ max( states('sensor.ipad_air_white_battery_level') | int, states('sensor.ipad_white_battery') | int) }}"
      unit_of_measurement: "%"
3

For future reference, variables in a Template Sensor is evaluated on (re)loading only. If you want variables to be evaluated at other times, you must use a Trigger-based Template Sensor.

From the documentation:

variables map (Optional)

Key-value pairs of variable definitions which can be referenced and used in the templates below (for trigger-based entities only). Mostly used by blueprints. With State-based template entities, variables are only resolved when the configuration is loaded or reloaded. Trigger based template entities resolve variables between triggers and actions.

4

Ah, that would be it.

Thanks.

5

By the way, I assume you want unit_of_measurement under sensor, not attributes, and refering to the state meansurement.

6

I don't think so. The 'state' is a string and needs no unit specified, but the attributes I'm setting are numbers. I added the 'unit_of_measurement' more as an explanation, but in some instances I see it added to the 'state' string, so looks like it means more than just a text attribute.

It's not too important, but ideally I'd like the unit (%) added to the attribute numbers when displayed, but not to the actual 'state'.

A bigger problem is that I now realise the above is not sufficient for my requirements. The idea was to have 2 different sources of battery level to be sure charging was switched on when at least one of them dipped below a minimum level. Just using the companion app's sensor is unreliable as first of all the app is very bad at actually updating its sensors, but also, when it crashes (yes, when) the battery level is never updated, the charger is never turned on and the iPad simply drains the battery.

Using the iCloud Integration gives me another battery level that works even when the app has crashed, but it updates rather too infrequently to catch one of the iPads whose battery is problematic and can suddenly drop at a fast rate and run out before a sensor has a chance to report it to HA so the automation can turn on the charger.

I ifigured triggering the automation from the lower of the 2 values would be sufficient, but I now realise that if e.g. the HA app has crashed and the battery level is stuck, it can still lead to incorrect control of the charger.

So I'm now trying to set it up looking at the most recently updated battery level value.

That has lead to another question, but I'll ask that in another topic.

7

I wondered if that was the case. Wanted to make sure since the key name matched the key that typically goes under the sensor config.

You have a smart switch on the iPad charger? Is that to save energy? I leave mine plugged in all the time. I just never bothered to see how much energy it used when the phone was full charged.

I have two iPhones (14pro and 15pro) and the 14 seems to report good battery level and the other not. The 15 also doesn't report the activity very well, but haven't spent time looking at it.

8

No not to save energy but to save the battery.

I have had several iPhones running as displays of some sort and constantly plugged in to a charger. The batteries suffer from that and don't last long before they become a 'spicy pillow' and I got fed up with changing them. I want a display with no battery basically and although there have been attempts to run Apple mobile devices without a battery, it's messy and I didn't like the end result with extra wires dangling etc.

I've replaced the iPhones with Sonoff NSPanel Pro 120s that have no battery so no problems there, but they have their own issues. Such is life. :roll_eyes:

Controlling the charge seemed an obvious solution, but as usual, harder than I first thought. However, I've started so I'll finish. :grinning_face: