Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support v2 battery status API #28

Closed
jamesremuscat opened this issue Jan 6, 2020 · 20 comments · Fixed by #44
Closed

Support v2 battery status API #28

jamesremuscat opened this issue Jan 6, 2020 · 20 comments · Fixed by #44
Assignees
Labels
enhancement New feature or request

Comments

@jamesremuscat
Copy link
Owner

New endpoint (GET): car-adapter/v2/cars/{vin}/battery-status.

Example response:

{
    "data": {
        "type": "Car",
        "id": "VF1AGVYC059430480",
        "attributes": {
            "timestamp": "2020-01-06T21:23:05+01:00",
            "batteryLevel": 43,
            "batteryAutonomy": 88,
            "batteryCapacity": 0,
            "batteryAvailableEnergy": 0,
            "plugStatus": 1,
            "chargingStatus": -1.0
        }
    }
}

Should also contain chargingInstantaneousPower and chargingRemainingTime entries when the car is charging.

A handful of fields have been renamed:

  • chargeStatus => chargingStatus (also changes from int to float fsr - it's still a Boolean AFAICT)
  • rangeHvacOff => batteryAutonomy
  • lastUpdateTime => timestamp

Presumably for some people, the new batteryCapacity and batteryAvailableEnergy will be nonzero - fairly sure that's not an accurate reflection of my car 😉 It looks like we should be prepared for any of these fields to be missing (they're all nullable).

@jamesremuscat jamesremuscat added the enhancement New feature or request label Jan 6, 2020
@Cheaternl
Copy link

Cheaternl commented Jan 10, 2020

I got this result for the Renault Zoe (2018) with ZE40 battery:

{
    "data": {
         "type": "Car",
        "id": "VF1AG000*********",
        "attributes": {
            "timestamp": "2020-01-10T18:21:47+01:00",
            "batteryLevel": 42,
            "batteryTemperature": 12,
            "batteryAutonomy": 94,
            "batteryCapacity": 0,
            "batteryAvailableEnergy": 0,
            "plugStatus": 0,
            "chargingStatus": -1.0
        }
    }
}

At that time, the car was NOT charging. Maybe the batteryCapacity and batteryAvailableEnergy are new fields for newer cars or are only non zero when the car is charging.

@boekabart
Copy link

boekabart commented Jan 11, 2020

For my ZE50, I get an HTTP 403 with

{"errors":[{"status":"403","code":"security.access","detail":"Access is denied for this resource"}]}

(the v1 call does work with the exact same headers)

@boekabart
Copy link

boekabart commented Jan 12, 2020

Update 1 day later: Apparently, it takes quite a while for all individual services to become active after first activating them in the car. This call now works, here's the snapshot while charging:

{
    "data": {
        "type": "Car",
        "id": "VF1AG0007__________",
        "attributes": {
            "timestamp": "2020-01-12T21:40:16Z",
            "batteryLevel": 60,
            "batteryTemperature": 20,
            "batteryAutonomy": 141,
            "batteryCapacity": 0,
            "batteryAvailableEnergy": 31,
            "plugStatus": 1,
            "chargingStatus": 1.0,
            "chargingRemainingTime": 145,
            "chargingInstantaneousPower": 27.0
        }
    }
}

Very curious what that the unit of chargingInstantaneousPower is... my home charger is capable of 3 x 24A, (17 kW) but usually the load balancer will report a slightly lower max amperage (which is visible on the Tesla dashboard & app), but there are no big consumers currently active, so I expect anywhere between 3x16 and 3x24 to be the current truth.

Repeating the call shows me a new timestamp and power every minute exactly, not more often. Power varies between 26.6 and 27.4 .

Even 7 minutes after the above result, with batteryLevel now at 63, remaining time is stable at 145.

It took about 8 minutes to go from 31 to 33 kWh batteryAvailableEnergy, which indicated a roughly 13-15 kW charging power. Could the number be simply 'double' the actual charging power?

A bit later:

{
    "data": {
        "type": "Car",
        "id": "VF1AG0007__________",
        "attributes": {
            "timestamp": "2020-01-12T23:19:16Z",
            "batteryLevel": 99,
            "batteryTemperature": 20,
            "batteryAutonomy": 230,
            "batteryCapacity": 0,
            "batteryAvailableEnergy": 51,
            "plugStatus": 1,
            "chargingStatus": 1.0,
            "chargingRemainingTime": 145,
            "chargingInstantaneousPower": 13.1
        }
    }
}

So the remainingTime doesn't seem very ... active ;)

@boekabart
Copy link

Next day, an hour and a half after a 25 km drive:

{
    "data": {
        "type": "Car",
        "id": "VF1AG0007__________",
        "attributes": {
            "timestamp": "2020-01-13T08:11:09Z",
            "batteryLevel": 91,
            "batteryTemperature": 20,
            "batteryAutonomy": 216,
            "batteryCapacity": 0,
            "batteryAvailableEnergy": 46,
            "plugStatus": 0,
            "chargingStatus": 0.0,
            "chargingRemainingTime": 15,
            "chargingInstantaneousPower": 1.1
        }
    }
}

Note that the timestamp is about 1 hour old, so I suppose the car doesn't communicate constantly with the 'service', and we just get the old data instead.

I kind of doubt that the batteryTemperature is accurate, as the car's been driven only for about 25 minutes, and sitting for 15 minutes after that as per the time of the data, and it's too much exactly as it was last night during charging.

After starting the HVAC from the app, I finally got a battery status update that's fresh:

{
    "data": {
        "type": "Car",
        "id": "VF1AG0007__________",
        "attributes": {
            "timestamp": "2020-01-13T09:09:28Z",
            "batteryLevel": 91,
            "batteryTemperature": 20,
            "batteryAutonomy": 215,
            "batteryCapacity": 0,
            "batteryAvailableEnergy": 46,
            "plugStatus": 0,
            "chargingStatus": 0.0,
            "chargingRemainingTime": 15,
            "chargingInstantaneousPower": 1.1
        }
    }
}

Battery still 20 degrees, with an outside temperature of about 7, that sounds unlikely.

@ArnoutVos
Copy link
Contributor

Bart, batteryTemperature look strange but after charging it usually stays at rather high values. Renault is keeping the battery as warm as possible during winter. This is my temp the last 7 days:

afbeelding

@jamesremuscat
Copy link
Owner Author

@Cheaternl Interesting that you get a reported batteryTemperature and I don't. Is yours a Q90 (like mine) or an R90?

@boekabart

Very curious what that the unit of chargingInstantaneousPower is

For me this has always returned a plausible value in kilowatts - my 7kW home charge point usually ramps up to about ~6.6kW via the API, with rapid chargers showing values in the 20-30kW range.

Repeating the call shows me a new timestamp and power every minute exactly

Honestly, I'm astounded that it's that frequent! Safe to assume the rest of the data, including chargingRemainingTime, only updates every 10 minutes - for ZE40 and earlier, that's as frequently as the car sends the data to the server.

There are two parameters that control how often the car will send a battery status update:

  • Change of x% battery state
  • y minutes elapsed since last state update

but a state update will only be sent if the car is "awake" - e.g. for about ten minutes after you leave it, or if you wake it via the API such as when you issued your HVAC request. (Values for x and y are configurable via the car's CANbus via DDT4all.)

It looks like the charging power might use a different mechanism if it's truly updating outside of this cycle. It's unhelpful that it overwrites the battery data timestamp!

@boekabart
Copy link

Parked my car at the airport (charger) this morning, and ever since the battery went full, this status hasn't changed at all in the last 8 hours:

{
    "data": {
        "type": "Car",
        "id": "VF1AG0007__________",
        "attributes": {
            "timestamp": "2020-01-15T11:48:40Z",
            "batteryLevel": 100,
            "batteryTemperature": 20,
            "batteryAutonomy": 252,
            "batteryCapacity": 0,
            "batteryAvailableEnergy": 53,
            "plugStatus": 1,
            "chargingStatus": 0.2,
            "chargingRemainingTime": 20,
            "chargingInstantaneousPower": 1.1
        }
    }
}

Notes:

chargingStatus really is a float... it's 0.2 now !?

I think we've now seen -1.0, 0.0, 0.2 and 1.0. On my ZE50, only the latter 3, for (assuming based on limited sample size) unplugged, plugged_but_full, charging, respectively.

Currently, calling the ac endpoints (start, stop) no longer get me an updated v2 battery_status like it did before... maybe simply because the values don't change, and then it won't even tell you this is still the status!? What I mean is, I have no way to tell apart 'no data incoming' vs 'still the same data incoming' if that's true. Or maybe the car is just sound asleep.

@Cheaternl
Copy link

I have a R110

@ArnoutVos
Copy link
Contributor

Currently, calling the ac endpoints (start, stop) no longer get me an updated v2 battery_status like it did before... maybe simply because the values don't change, and then it won't even tell you this is still the status!? What I mean is, I have no way to tell apart 'no data incoming' vs 'still the same data incoming' if that's true. Or maybe the car is just sound asleep.

My experience is that one out of 10 times the car is not connected to the Renault API infra. You can't get updates and AC control doesn't work. It happens on places where it worked before so it's not a GSM coverage thing.

Some additional info: https://canze.fisch.lu/when-does-zoe-phone-home/

@jamesremuscat
Copy link
Owner Author

Please can we not turn this issue into a generic "my car isn't talking to the server" discussion? It is to cover implementing support for the v2 battery status API into pyze, not to act as a triage for Renault Connected Services support.

On chargingStatus, the app has these meanings:

    NOT_IN_CHARGE(Utils.FLOAT_EPSILON),
    WAITING_FOR_A_PLANNED_CHARGE(0.1f),
    CHARGE_ENDED(0.2f),
    WAITING_FOR_CURRENT_CHARGE(0.3f),
    ENERGY_FLAP_OPENED(0.4f),
    CHARGE_IN_PROGRESS(1.0f),
    CHARGE_ERROR(-1.0f),
    UNAVAILABLE(-1.1f);

where Utils.FLOAT_EPSILON is 1.4e-45. (Seriously, Renault? Using a float for an enum?)

I've seen -1.0 when not plugged in so let's assume that "charge error" includes "missing copper between car and charger"...

@boekabart
Copy link

I see 0.0 when the only connection between the world's network of chargers and the car, is wireless... Maybe a difference between generations of cars?

@MattCheetham
Copy link

Interesting. I'm seeing -1.0 where my car is plugged in waiting for a scheduled charge. I really hope this doesnt behave differently between the different cars (I'm Z.E. 40 Q90)

@MattCheetham
Copy link

Also sad to report that it seems like the Z.E.40 still reports charge speed in Wh instead of kWh.

{
    "data": {
        "type": "Car",
        "id": "VF1AG______",
        "attributes": {
            "timestamp": "2020-01-20T17:46:13+01:00",
            "batteryLevel": 97,
            "batteryTemperature": 4,
            "batteryAutonomy": 203,
            "batteryCapacity": 0,
            "batteryAvailableEnergy": 0,
            "plugStatus": 1,
            "chargingStatus": 1.0,
            "chargingRemainingTime": 90,
            "chargingInstantaneousPower": 4200.0
        }
    }
}

@boekabart
Copy link

Report on tens of samples over the last 2 weeks: 100% of the time, our ZE50 reports a battery temp of 20. It's 0 degrees outside and the car has been 'wireless' plenty of time, so an actual temp of 20 degrees is ... impossible? I suppose this API is not consistent between car models...

@ArnoutVos
Copy link
Contributor

I've added the battery temperature because it gives (at my car at least) interesting and reasonable values.... but it is possible it doesn't work that good for al cars and/or models.

@jamesremuscat jamesremuscat self-assigned this Jan 22, 2020
jamesremuscat added a commit that referenced this issue Jan 23, 2020
@MattCheetham
Copy link

I've added the battery temperature because it gives (at my car at least) interesting and reasonable values.... but it is possible it doesn't work that good for al cars and/or models.

Can confirm that I've been using the battery temperature in my own app for several months now and it does go up significantly when charging and comes down when left to stand (Q90). So it works well for me at least.

@premultiply
Copy link

Yes the battery temperature is valid at least for ZOE Ph1 cars. It is the mean battery temperature from LBC on can bus.
Works very well on my ZOE R90.

@myhrmans
Copy link

It took about 8 minutes to go from 31 to 33 kWh batteryAvailableEnergy, which indicated a roughly 13-15 kW charging power. Could the number be simply 'double' the actual charging power?

@boekabart yes. I see the same issue of a double result returned when charging at public charging stations that can output a maximum of 11kW but I see result in range of 20kW.. Anyone found the issue behind this?

@jumpjack
Copy link

Which are the possible values for chargingStatus ? I read 0.2, 0.4 and other valuese for my Captur plugin; I had found somewhere on github a source code listing all values but I cannot find it anymore...

@jumpjack
Copy link

Ah ok found again :)

Enum for battery-status charge state.

NOT_IN_CHARGE = 0.0
WAITING_FOR_A_PLANNED_CHARGE = 0.1
CHARGE_ENDED = 0.2
WAITING_FOR_CURRENT_CHARGE = 0.3
ENERGY_FLAP_OPENED = 0.4
CHARGE_IN_PROGRESS = 1.0
# This next is more accurately "not charging" (<= ZE40) or "error" (ZE50).
CHARGE_ERROR = -1.0
UNAVAILABLE = -1.1



"""Enum for battery-status plug state."""

UNPLUGGED = 0
PLUGGED = 1
PLUG_ERROR = -1
PLUG_UNKNOWN = -2147483648

https://github.com/hacf-fr/renault-api/blob/main/src/renault_api/kamereon/enums.py

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants