-
Notifications
You must be signed in to change notification settings - Fork 30
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
Comments
I got this result for the Renault Zoe (2018) with ZE40 battery:
At that time, the car was NOT charging. Maybe the |
For my ZE50, I get an HTTP 403 with
(the v1 call does work with the exact same headers) |
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 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 ;) |
Next day, an hour and a half after a 25 km drive:
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. |
@Cheaternl Interesting that you get a reported
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.
Honestly, I'm astounded that it's that frequent! Safe to assume the rest of the data, including There are two parameters that control how often the car will send a battery status 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! |
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 I think we've now seen 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. |
I have a R110 |
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/ |
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
where I've seen |
I see |
Interesting. I'm seeing |
Also sad to report that it seems like the Z.E.40 still reports charge speed in Wh instead of kWh.
|
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... |
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. |
Yes the battery temperature is valid at least for ZOE Ph1 cars. It is the mean battery temperature from LBC on can bus. |
@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? |
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... |
Ah ok found again :) Enum for battery-status charge state.
https://github.com/hacf-fr/renault-api/blob/main/src/renault_api/kamereon/enums.py |
New endpoint (GET):
car-adapter/v2/cars/{vin}/battery-status
.Example response:
Should also contain
chargingInstantaneousPower
andchargingRemainingTime
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
andbatteryAvailableEnergy
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).The text was updated successfully, but these errors were encountered: