Home Assistant Automations

[DanHi]

Nothing there. It hasn't happened again, so I'll just wait until I get below 60% and if that works, I'll be happy.

 

[DanHi]

Happened again, and I see the problem, I just don't know what's causing it. You can see below that the from state is a little less that 65%, the to state is 0. So the automation is doing what I asked, I just don't know what the to state is showing 0. For now I'm just going to add a condition that the battery remaining has to be above 0, but I'd like to know what is causing this spurious state change.

 

[borski]

Happened again, and I see the problem, I just don't know what's causing it. You can see below that the from state is a little less that 65%, the to state is 0. So the automation is doing what I asked, I just don't know what the to state is showing 0. For now I'm just going to add a condition that the battery remaining has to be above 0, but I'd like to know what is causing this spurious state change.

That is odd. The API does some weird things sometimes, like returning 65535 for the tires (or some similar MAX_INT value lol) when they really mean “unknown”

So it’s possible it dropped below 60 to “some unknown value at this time” or similar

 

[DeaneG]

That is odd. The API does some weird things sometimes, like returning 65535 for the tires (or some similar MAX_INT value lol) when they really mean “unknown”

So it’s possible it dropped below 60 to “some unknown value at this time” or similar

Seems it's like a good idea for automations to range-check returned values for sanity before acting on them!

 

[DanHi]

Well, as long as it consistently goes to 0, I can deal with it. Thanks for the work on this, it's really useful.

 

[Haj]

Someone who knows more than I may correct this, but I believe the automation triggered because remaining_battery_percent changed. Take a look at the automation's decision tree on the left to see its progress through your automation. It should have bailed out upon deciding that the new remaining_battery_percent was not below 60.

View attachment 25161

The trace is insufficient for understanding the automation. It looks like you are trying to poll SOC every minute. Not sure that makes sense. Post the yaml of the automation.

 

[DeaneG]

The trace is insufficient for understanding the automation. It looks like you are trying to poll SOC every minute. Not sure that makes sense. Post the yaml of the automation.

My automation (and the sample trace I posted of mine) is working fine - the OP's had an issue. Unfortunately for mine, given the car's scheduled charging behavior, there wasn't an easy way to avoid polling.

 

[Haj]

My automation (and the sample trace I posted of mine) is working fine - the OP's had an issue. Unfortunately for mine, given the car's scheduled charging behavior, there wasn't an easy way to avoid polling.

How do you use polling with the car?

 

[DeaneG]

How do you use polling with the car?

I charge our EVs when possible using excess solar PV power. This comes and goes with sun/clouds/oven/air conditioning etc coming on and off. So available charging power is often interrupted by dropping to zero for an hour or more. When this happens, the car goes to sleep with the charging cable plugged in, and does not wake up again. It's the exact same problem the car has with externally-scheduled charging. My automation checks periodically for this condition, and wakes the car so it can begin charging again. It only bothers Lucid's cloud when it's very likely that the car should be charging.

 

[DanHi]

I'm curious about the polling as well. Haj said it looked like I was polling, which I don't want to do. Here is my yaml:

- id: '1734025992822'
alias: Lucid Battery Low
description: Lucid battery below 60%
triggers:
- trigger: numeric_state
entity_id:
- sensor.lucid_air_remaining_battery_percent
below: 60
conditions:
condition: numeric_state
entity_id: sensor.lucid_air_remaining_battery_percent
above: 0
actions:
- action: notify.danhinsley
data:
title: Lucid Battery Low
message: Lucid battery below sixty percent
mode: single

 

[DeaneG]

I'm curious about the polling as well. Haj said it looked like I was polling, which I don't want to do. Here is my yaml:

- id: '1734025992822'
alias: Lucid Battery Low
description: Lucid battery below 60%
triggers:
- trigger: numeric_state
entity_id:
- sensor.lucid_air_remaining_battery_percent
below: 60
conditions:
condition: numeric_state
entity_id: sensor.lucid_air_remaining_battery_percent
above: 0
actions:
- action: notify.danhinsley
data:
title: Lucid Battery Low
message: Lucid battery below sixty percent
mode: single

Yours isn't polling. Haj was looking at my post and seeing that my automation was doing polling.
In general it's not a great idea to poll when you can use event-driven triggering instead. Sort of like the old GOTO statement, there's usually a better way to et the job done if you think about it.

In my case, I could not get an event trigger to work reliably, and fell back on polling. It's the only automation I have that is polling, my HA Green's CPU load is 3% maximum, and it works reliably. I'm trying to hit Lucid's and Enphase's cloud API as infrequently as possible while still maximizing my car's charging. I'll delete the automation when Lucid updates the car to be able to function with externally-scheduled charging.

 

[Haj]

I charge our EVs when possible using excess solar PV power. This comes and goes with sun/clouds/oven/air conditioning etc coming on and off. So available charging power is often interrupted by dropping to zero for an hour or more. When this happens, the car goes to sleep with the charging cable plugged in, and does not wake up again. It's the exact same problem the car has with externally-scheduled charging. My automation checks periodically for this condition, and wakes the car so it can begin charging again. It only bothers Lucid's cloud when it's very likely that the car should be charging.

View attachment 25205

Interesting. Why poll every 1 minute versus a longer period? Literally just curious.

 

[DeaneG]

Interesting. Why poll every 1 minute versus a longer period? Literally just curious.

I wanted to minimize the amount of time the Air spent asleep when it should have been charging. Before I added this automation, the car would stop charging and go to sleep several times per charging-afternoon, and I had to observe that manually and wake the car up via phone app.

I started with a five minute polling interval, but saw that my HA CPU usage was negligible. I'd had a fair amount of grief with both Enphase's and Lucid's charging software and decided WTH and switched to one minute.

 

[Haj]

Yours isn't polling. Haj was looking at my post and seeing that my automation was doing polling.
In general it's not a great idea to poll when you can use event-driven triggering instead. Sort of like the old GOTO statement, there's usually a better way to et the job done if you think about it.

In my case, I could not get an event trigger to work reliably, and fell back on polling. It's the only automation I have that is polling, my HA Green's CPU load is 3% maximum, and it works reliably. I'm trying to hit Lucid's and Enphase's cloud API as infrequently as possible while still maximizing my car's charging. I'll delete the automation when Lucid updates the car to be able to function with externally-scheduled charging.

DanHi, are you trying to run an automation off of the SOC trigger? If so, I've found that reliable execution of automations with the car requires that it be in Sleep/Charge status (if not actively driving) and then using wait logic to delay each command until the prior command results in the API reporting the desired state based on the prior command. For example, I have scripts set up that I use with Alexa to set changing level. "Alexa, charge the car to 85%" runs a script to wake the car, set the charge limit to 85%, initiate charging and set A/C to my desire temp. To ensure reliability, no step is actioned until the prior step reports the expected state. The script might take a minute to run but it is reliable.

So, I suggest that you build state checking into your automation if the SOC state action triggers but you aren't getting the reliable performance of actions from the trigger.

 

[DanHi]

After I put in the condition to not trigger on 0, it's working as expected.

 

[DanHi]

I just wanted to say a heartfelt thank you for this. The information it supplies on charging (how much time is left, amount of kWh used) is great and now something I could find anywhere else. A big thank you and Happy Holidays to all.