Hello everyone, I apologize for my English but I have a problem with an automation. the condition battery_charger is not seen, in practice if I remove the automation is performed, otherwise it locks them. I tried both ways and now I’m with the # otherwise it does not go …
alias: “batteria_scarica_alex on”
trigger:
platform: template
value_template: ‘{{ states.device_tracker.google_maps_code.attributes.battery_level | int < states.input_number.min_battery_alarm_phone.state | int }}’
platform: time
at: ‘22:00:00’
condition:
condition: and
conditions:
condition: state
entity_id: device_tracker.google_maps_code
state: ‘home’
When posting YAML code, please follow the instructions at the top of the page so that it is formatted correctly. Otherwise it is very difficult to read and see what might be wrong.
But I think your problem is the battery_charging attribute is a boolean, but you’re comparing it to a string. That won’t work. Just use it as is. For example:
condition: template
value_template: "{{ not state_attr('device_tracker.google_maps_code', 'battery_charging') }}"
This condition will be satisfied if battery_charging is false.
Next question is do you want this as a condition or a trigger? Right now it’s a trigger, which means the automation will run if either battery_level goes above min_battery_alarm_phone, or if battery_charging becomes true. I tend to doubt that’s what you want.
You actually don’t need to do that if the attribute is already a boolean. In fact, you’d have to be careful using is_state_attr with a “boolean” attribute, because it might actually be a real boolean, or it might be a string representation of a boolean. I.e., this will always work:
{{ state_attr(entity_id, attribute) }}
Whereas only one of the following would work, depending on whether the attribute is a real boolean or just a string representation of one (and even then you’d have to worry about letter case – e.g., is it ‘true’ or ‘True’ or ‘TRUE’ …):
Are you saying it still does not work the way you want?
If so, maybe we should take a step back so you can explain what you are ultimately trying to achieve. In general automations should not need to use a periodic time trigger. Normally you should use triggers corresponding to the events that should cause the action to run. Whenever I see an automation with a periodic trigger and a bunch of conditions that’s usually a “red flag.”
Hi,
I do not know if it works now with the latest changes, I have to rehearse.
I arrived at this configuration because of the thousand tests …
we would have to rewrite everything …