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.

 

[Cornell]

I've been using the automated garage door detection with ratgdo for a couple weeks now. I like the garage door to open / close when I'm a certain distance from my house. I've set the zones in HA but the garage door doesn't open/close at the same distance. Sometimes I have to wait while I'm down the street for the garage door to start closing. Is this because the update rate is only every 15 secs? Any way to get more consistency?

I also have my neighborhood gate opener programmed into the car. Is there a way for me to use HA to have the Lucid automatically open the gate as I enter the neighborhood?

I ran into the same issues. I mostly just care about not having to wait for the door to open/close. I want it to close before I'm out of sight, and open before I'm in my driveway. So, I'm trying a couple of things to alleviate it. I made 2 more zones, each with different radii. I made a "leaving home" zone with a very small radius, one that only covers my house. When the Lucid leaves this zone, it'll close the door. I then made an "entering home" zone, which is much much larger, I think around 75 meters (just large enough that it doesn't hit the next street over from me). When the Lucid enters this zone, the garage door will open. I've only tested this a couple of times, but so far, the door activates sooner on both occasions. The other thing I'm doing is I'm checking the gear position, so the door will only activate if the gear position of the Lucid is not in "Park".

If this still doesn't give me the timing I want, my next try will be to use my iOS phone's location, which I'm thinking updates more frequently. I would still use the gear position check, that way the garage door should only open/close if I'm in the car, not just walking down the street.

If anyone else has any suggestions as to better mitigate this timing issue, please let us know!

But otherwise, I'm super happy with the HA and Lucid integration. Huge thanks to the developers and everyone's comments on this thread!

 

[segbrk]

I ran into the same issues. I mostly just care about not having to wait for the door to open/close. I want it to close before I'm out of sight, and open before I'm in my driveway. So, I'm trying a couple of things to alleviate it. I made 2 more zones, each with different radii. I made a "leaving home" zone with a very small radius, one that only covers my house. When the Lucid leaves this zone, it'll close the door. I then made an "entering home" zone, which is much much larger, I think around 75 meters (just large enough that it doesn't hit the next street over from me). When the Lucid enters this zone, the garage door will open. I've only tested this a couple of times, but so far, the door activates sooner on both occasions. The other thing I'm doing is I'm checking the gear position, so the door will only activate if the gear position of the Lucid is not in "Park".

If this still doesn't give me the timing I want, my next try will be to use my iOS phone's location, which I'm thinking updates more frequently. I would still use the gear position check, that way the garage door should only open/close if I'm in the car, not just walking down the street.

If anyone else has any suggestions as to better mitigate this timing issue, please let us know!

But otherwise, I'm super happy with the HA and Lucid integration. Huge thanks to the developers and everyone's comments on this thread!

I've found overlapping zones get a little bit confusing, I'd suggest the Proximity integration: https://www.home-assistant.io/integrations/proximity/
Set that up and you'll get e.g. a "Home Lucid Air distance" sensor that tells you your car is X feet away from your home zone, then you can use a numeric less than trigger in your automations.

 

[DanHi]

I would love to do something like this. I have a refoss garage door opener that interaces with alexa. Is this something you can only do with the ratgdo?

 

[borski]

I would love to do something like this. I have a refoss garage door opener that interaces with alexa. Is this something you can only do with the ratgdo?

If it has a Home Assistant integration, you can do it. And Home Assistant has a *ton* of integrations. I’ve written 3-4 myself, heh, including the Lucid one.

A bit of googling informs me Refoss is secretly Meross under the hood, and there is an integration for Meross: https://github.com/albertogeniola/meross-homeassistant

It is installed via HACS, same as the Lucid integration.