I’ve been trying to find a viable solution for this for a while - seems like I just can’t
Maybe somebody here has a great idea?
Setup:
I have an Amazon Fire Tablet that is in a stand most of the day, getting charged wirelessly.
When I have dinner on the patio, I take it with me to display a media card showing me which song Spotify is currently playing.
When I’m finished with dinner, I put the tablet back into the stand.
The tablet’s HA App changes the charger_type sensor to ‘wireless’; which is the trigger in an automation that sets up my TV Den for watching TV (with lights, etc.).
Complication:
When the tablet is in the charger and fully charged, every so often the charger_type also changes from ‘wireless’ to ‘none’ back to ‘wireless’ - it’s only on ‘none’ for a few seconds, so I avoid the automation being triggered by using this template condition:
Enhancement - That’s what I can’t figure out:
In order to reduce the battery strain, I have set up a smart plug, which I want to turn off the charging wall wart when the tablet is charged at 80% and back on at 50%.
This will also change the charger_type from ‘none’ to ‘wireless’, but in this case the condition above will be fulfilled because it will take more than 15s to charge the battery from 50% to 80%.
What would a condition have to look like, that
considers the combination of turning on the plug and then the change of the charger_type to ‘wireless’ within less than 15s as FAIL
and
still caters for the ‘Complication’ above?
This is the automation I’m currently using:
alias: DRDash Wireless Charging Triggers Dinner2TV
description: ""
triggers:
- trigger: state
entity_id:
- sensor.drdashboard_charger_type
to: wireless
conditions:
- condition: template
value_template: >-
{% set previous = trigger.from_state.last_changed | as_datetime | as_local %}
{{ now() - previous > timedelta(seconds=15) }}
- condition: time
after: "19:45:00"
actions:
- data:
message: TTS
data:
tts_text: The Dining Room Dashboard is now back in the charging cradle
media_stream: alarm_stream
priority: high
action: notify.mobile_app_drdashboard
- action: script.dinner2tv
metadata: {}
data: {}
mode: single
Hey @NathanCu and @Sir_Goodenough - thanks, I just tried that.
Looks like I can’t have to, not_to, and not_from in the same trigger.
Trying with
triggers:
- trigger: state
entity_id:
- sensor.drdashboard_charger_type
to:
- wireless
not_from:
- unavailable
- unknown
not_to:
- unavailable
- unknown
results in
And taking the to: out triggers in every case, i.e. removing the tablet from the stand, putting it back into the stand, turning the smart plug on, turning the smart plug off all result in the action being carried out.
Either way, I think the main issue is that in both cases (placing the tablet into the dock and turning the smart plug back on) the state changes from ‘none’ to ‘wireless’ (which are both valid states according to the Developer Tools - States screen).
I think the additional condition required would have to do with the state of the smart plug changing from ‘off’ to ‘on’ just a few seconds before the charger_type changes from ‘none’ to ‘wireless’.
But I can’t use a .from_state.last_changed in a condition for the smart plug device (entity_id switch.mplug) because it’s not the trigger.
Only thing I came up with so far is to create a (timestamp?) helper that records, if the smart plug was turned on in the last 15s before the charger_type changes to ‘wireless’ and use it as an additional condition.
Once you constrain the to states, there is no need to include the not_to. You’re telling it to trigger on changes to wireless, period. So it’s superfluous to say, don’t trigger on changes to other states.
that’s for a condition check of the other entity after the trigger. It doesn’t have to be IN the trigger. Trigger fires - Script then goes -ok how’s that other thing doing if this, then… go…
I guess I don’t have enough information from your post about what you’re trying to do. I didn’t fully understand your objectives from initial post, so I didn’t comment on it; I just jumped in to point out why you got the error you reported.
Ok, understood.
How do I formulate the other condition based on the recent state change of the switch.mplug entity?
Can I do it without a helper entity?
I can’t speak for NathanCu, but in view of all the thread here, I can’t tell what the specific issue is. Could you possibly walk us through what you’re tried and how it’s failing? I’m stuck on your “enhancement” bit.
But also, I think maybe a specific example of something that happened and how your existing attempts didn’t handle what you want, would help. In terms of entity IDs and states.
The current condition detects that the charger_type has been none for more than 15s and allows the actions to be carried out
Scenario B:
The tablet is in the dock
Due to whatever reason the charger_type changes from wireless to none back to wireless
The trigger goes off
The current condition detects that the charger_type has been none for less than 15s and prevents the actions from being carried out
Scenario C - Enhancement (keep charge between 50% and 80%):
The tablet is in the dock
The charge goes below 50%
The smart plug turns on the wall wart to charge the tablet.
The charger_type changes from none to wireless
I need a condition to prevent the actions from being carried out.
The current condition would pass because the charger_type was none for more than 15s before it turned to wireless
Okay, I understand better now. This is a hard scenario. You can’t just trigger on charger_type since you have an independent automation that turns off the power to the charger.
One way to solve this is to keep track of whether your smart plug is what caused the charger_type to change.
The smart plug turn off will happen first. So, you need a condition to test whether the smart plug is on or off. I don’t see it in the previous posts, and maybe I just missed it: what’s the entity ID of your smart plug?
So, I’m probably stuck with something like this after all.
Was hoping for somebody having an approach that allowed me to check for the (recent) status change of the switch entity even though it’s not a trigger.
Not comprehending why you can’t share the entity ID of the smart plug.
If it’s not a smart plug that’s in Home Assistant–you’re looking at a much harder project. Might not be impossible, but you need to share the information if you expect people here to help.
I’ll probably have to go for a helper that turns ‘On’ when the mplug switches on and turns ‘Off’ 10s later.
Then I can ensure with an additional condition in my original code, that the helper is actually set to ‘Off’ when it is triggered and only then execute the actions.
Scenario A:
Scenario C - Enhancement (keep charge between 50% and 80%):