No SoC send from NIO API

[lubbyhst]

Hi @nicolasvangeluwe ,
I also experience the 0.0% battery soc bug. So you are not alone.
I will support you to solve this issue. So I can provide you with more data. If you tell me, to what support channel I need to send my results I will send this to NIO. Incl. VIN etc.
And maybe you can send me the ticket number of your issue at NIO. So I can reference that ticket.

And thx for your work. Now we can finally get the data into HA for free. That's so n1 :)

[nicolasvangeluwe]

Thanks a lot—both for confirming that I’m not the only one getting the mysterious 0.0%, and for offering to help. I’d gladly take you up on that 🙂

Unfortunately, I don’t have a ticket number to give you. I forwarded the complete case to the Belgian importer but received no reaction. I also sent it to api@nio.io, which is the only API-specific address I could find on NIO’s official Vehicle API page. After five business days I still haven’t received an acknowledgement, ticket number or reply.

If you know—or can find—another route into NIO, please try it. NIO Germany officially lists contact.de@nio.io. That is a general contact address rather than dedicated API support, but perhaps they can route the case internally or put us in touch with the right team.

The useful summary for NIO is:

• OAuth authorization and token refresh work.
• vehicle_status/latest returns a current timestamp and correct odometer, proving that the VIN and vehicle connection are valid.
• The same response returns SoC as 0 instead of the real value.
• soc_status/changes returns resource_not_found, including directly after driving and an observed 2% battery discharge.
• Several other documented endpoints return permission_denied.
• Your ET7 now independently shows the same incorrect SoC result.

Please feel free to link them to this discussion and the repository. If they need your VIN or other account details, send those directly to NIO rather than posting them publicly here.

And thanks for the nice words. Getting the data directly into Home Assistant for free—without depending on another third party—is exactly why I started this slightly overambitious experiment in the first place 😄

[lubbyhst]

Hi,
in the next days I will write a summary of my tests and findings and will document them here.
Also I will send the results to api@nio.io. Maybe we get more attention if more people will test this. So I will also try to provide a simple script that tries to read the api and show all relevant informations. Just simply for testing.
Due too the lack of time. This can take a few days XD

[nicolasvangeluwe]

To keep results from different EU vehicles and countries easy to compare, I’ve opened a dedicated structured reporting thread: EU NIO telemetry test reports — model and country compatibility.

Please use the template there for vehicle test results and update the same reply when anything changes. We’ll keep this discussion for the broader SoC investigation and NIO support follow-up.

[lubbyhst]

I finally found a few minutes to write the summary and a test script for the API team. I send this to api@nio.com. Idk if this is the correct official address. But I hope it is :)

[nicolasvangeluwe]

Thank you so much. The address I found was api@nio.io.

I'm trying to find traction with other drivers, but so far no luck. Any suggestions? I don't have social to spread the word.

[Laddvin]

Hi, I’ve tried to vibecode my own integration primarily as an Android app and have come up with pretty much the same results as you.

What’s the latest on your end? Heard anything back from NIO? I will try to use the contact channels I have to bring us forward but would love to hear your latest status first.

Please do reach out to me if you hear or discover anything new at all. I have the same username in the NIO app as well.

[nicolasvangeluwe]

Hi, Laddvin,

Great that you are onboard. I still haven't heard anything back from Nio. I have a friend working at the Belgian imported who forward the request directly to a Nio engineer. We are hoping the engineer can either help us or point us to the right contact.

I'm happy you found your way to this discussion, but I feel we need a lot more traction. I'm not on social and I don't have enough karma to post in the Nio reddit. I don't know if you do or have other channels you can think of, but we need more noise.

I will keep updating this discussion. So far, no real progress.

Enjoy your day.

[Laddvin]

Thank you!

To be honest I'm surprised there haven't been more noise about this already, the API is completely useless in its current shape.

I have a few contacts in high places but I cannot guarantee that they will take us seriously. They have a very strict budget. But this is very important in my opinion.

My stance is that if they don't develop functions like the car's trip meter, then we have to do it ourselves. And right now we can't because the API is trash.

This should be a priority for them to fix. I will push them and keep pushing, but I do expect it to take a while to get a response. I'll keep you updated from my end as well.

[Laddvin]

I made a whole deviations report that I am sending to NIO
NIO-API-deviations-v1.4.pdf

[nicolasvangeluwe]

Great work. This matches everything I encountered as well. At least we're not seeing ghosts. :-p

[Laddvin]

I got a response from NIO. I don't know exactly what it means in practice, but I guess well have to keep our eyes out for changes in the documentation and changes in our application's behaviors. And I'm well aware that the timeline is very vague:

Hi Edvin, I have shared your feedback and insights internally. Based on the current issue list, quite a number of these issues can be resolved from our product side, especially many of those related to technical documentation. However, in terms of timing or versions we can't make any promises. Hope this helps a bit.

I also found out that the email address api@nio.io has been inactive. I am awaiting confirmation about when it's live.

[Laddvin]

I'm afraid there was a misunderstanding... When they said they'll "fix" the email adress they meant remove it from the website, not start to monitor it... 💩 I'm sorry guys. But I will keep fighting for a API fix, which is the important part.

[Laddvin]

Guys, the API seems to be updated and works way better now!! I will take the coming days to evaluate what works and what don't. But overall great news!!

[nicolasvangeluwe]

@Laddvin, I also noticed a change on my side. Since 8 October, my ET5 Touring has started returning remaining range through the official API. It isn’t in every response, which may be normal for a changes endpoint. NIO’s SoC still says 0%, so it’s not fixed—but it’s finally something useful. 😄

This appears to be the default, linear remaining range shown in the NIO app, rather than a range adjusted for recent driving. I changed the HA integration to keep the last real reading until a new one arrives, including after a restart.

In my own HA—not in the public HACS integration—I use that range to construct a charge percentage: range in km ÷ 557 × 100, rounded and limited to 0–100%. For my car, 500 km gives 90%, 561 km gives 100%, and 213 km gave 38%, matching the app at the time. I don’t yet know how battery degradation might affect that relationship, so it may need recalibrating later. I’ll also add a freshness check before using it for charging automations.

@lubbyhst, if range has started appearing for your ET7 too, a calibration based on your own car might work for you as well.

[nicolasvangeluwe]

Also, the grant issue has been fixed in my integration and HA asks to reauth when needed. I'm thinking about an app as well, but for now I'm using full HA. I'll post some screen shots soon. It's coming nicely together.

[Laddvin]

@nicolasvangeluwe
Yeah, the linear range you talk about is WLTP for sure, so very useless. But at least it's a real value!

Move away from using the feed "vehicle_status_latest" if you do, and capture the changes in the feed "soc_status" instead, it works for me. You just have to read the latest 10 minutes repeatedly, and every time a value changes, like the soc, the feed will deliver it to you. If it's not changed, you don't need an updated value anyway.

I just updated the app to remove latest as an input completely, until it's fixed.

See my screenshots below from my app logging. I will reset the logging to zero tomorrow, since real data stated showing up yesterday. This version has been running for up to a week already.

[nicolasvangeluwe]

As promised, some screenshots of the Car dashboard I’ve been building in Home Assistant. It grew a fourth tab while I was at it. 😄

• At a glance: remaining charge, range, odometer, charging power, connection status and a charging forecast.
• Laden: recent charging sessions, energy, costs, reimbursement and solar share, with full history and charging controls.
• Ritten: recorded trips with distance, average consumption and battery used. There are actual trips in there now!
• Verbruik: consumption over different periods, distance and energy used, plus charging costs. Stationary loss is kept separate from driving consumption.
• Stilstand: estimated battery loss while parked, with individual intervals and a monthly total. It shows what changed, not a guessed cause.

This is running in my own HA; the dashboard isn’t in a public HACS release yet. I’m exploring whether it could become an optional part of the integration, with EVCC connection options and car settings such as model, colour and image.

The remaining complication is SoC. NIO’s official value still isn’t usable for me, so the charge percentage shown here is calculated from remaining range using my car’s calibration. I’m considering whether to make that an optional per-car setting or wait for NIO’s official fix before offering the dashboard more widely. No promises yet.

[nicolasvangeluwe]

I wouldn’t call the WLTP range useless 😄 Its linearity is exactly what makes it useful for me: I can turn the remaining range into a charge percentage calibrated to my car. It’s matching what the NIO app shows, while the official API SoC still reads 0% on my side. I’m looking into your soc_status suggestion and the PR now—thanks for pointing me in that direction.

[nicolasvangeluwe]

I'm still only seeing my odometer and no SoC. Did your values just start appearing or did you do something? It might have been fixed on VIN or country level?

@lubbyhst Did anything change on your end?

[Laddvin]

@lubbyhst It's not that I don't want to help you - I'd love to, but I've spent soo much time on the app that I don't just want to give it away fully or partially without thinking it trough. I used a lot of AI since I'm not a coder myself, so there are some security aspects as well in making sure I don't accidentally give away personal information or keys.

I would consider releasing the app publicly for the community eventually, but my api "license" doesn't allow for distribution either.

With that said, I'll be with you for support, just ask and I'll provide you with whatever info you need!

The authentication token needs to be refreshed against NIO's server every once in a while. My server does this automatically, but I don't know how often on the top of my head.

And I agree, the API is still not perfect, but with the data I get today, most of my app functions actually work!

I need more time to evaluate, summarize and then submit a new case to NIO with the remaining issues. Let's move forward in a structured manner now and not rush it.

[lubbyhst]

@Laddvin

that is ok. I'm fine with that. I just would compare your api impl. against the integration impl.
Now I will check the actual integration api impl. against the actual spec.

And yes. The invalid grant issue is related to the token refresh. Actually I did not know if this already works well in the integration. But this will be fixed soon I think.
Now as I see that you get correct data, I think the integration can be fixed too :)

[Laddvin]

@lubbyhst I understand. I'm pretty sure my server code is thousands of lines long by now due to all the functions in my app, and I'm out of tokens on Claude Code for the moment, but if there are any specific questions you have regarding the API implementation or anything else, just ask and I'll try to give you an as clear answer as possible! And good luck!! It's way more fun to develop something that you know can actually work, right!?

[lubbyhst]

the magic happend :D

[Laddvin]

@lubbyhst

Ooh look at that!
Nice job man! Happy for you 😁🥳

What did you change? 😉

[lubbyhst]

And here the PR:
PR

@Laddvin
It was exactly what you've mentioned.
"Move away from using the feed "vehicle_status_latest" if you do, and capture the changes in the feed "soc_status" instead, it works for me. You just have to read the latest 10 minutes repeatedly, and every time a value changes, like the soc, the feed will deliver it to you. If it's not changed, you don't need an updated value anyway."

That fixed the issue. I also let codex do some refactoring magic so some loc moved into own files in the PR. But maybe this can work.
I hope somebody is testing it and give feedback.

[nicolasvangeluwe]

Good news: the latest HACS release (v0.1.1-dev.14) is out, and the integration now uses the soc_status change-feed approach @Laddvin pointed us to. My ET5 Touring is receiving real, changing native SoC and remaining range in Home Assistant. The range-derived percentage can finally retire from my dashboard. 😄

A big thank-you to @Laddvin for spotting the first real data and finding the working method, and to @lubbyhst for testing and early improvements. If you have another EU NIO, please give the integration a try and add a quick model/country/working-readings report in the test thread. That comparison would really help.

[nicolasvangeluwe]

A small NIO support update: NIO Netherlands has now replied to the report I sent earlier. They say they forwarded the findings to their technical teams and that their IT Cloud Team is working on known API-related issues. They couldn't give a timeline, and I still don't have a case number. But I'm happy we finally got an acknowledgement and know the report reached the right people. 🙂

Since that report, we've also seen a real improvement: since 8 October my ET5 Touring has been receiving native SoC and remaining range via the soc_status/changes feed. The integration now uses that feed, so I no longer need my range-calculated SoC. As @Laddvin found, vehicle_status/latest wasn't the useful source for this. I can't say whether NIO changed the backend, our use of the right feed made the difference, or both.

This doesn't mean every car/account is sorted: other owners are still reporting energy-telemetry access problems. I'll reply to NIO with the new findings and ask about those remaining differences. @Laddvin, this seems broadly consistent with what you heard from your contact—known issues, but no promised date.

[Laddvin]

@nicolasvangeluwe Great news indeed.
I got a reply yesterday as well, indicating that they are aware of the fluctuating availability of data. My interpretation of their reply is that they submitted a first fix last week and that "soon" the reliability will increase. I think we should give them some time to figure out their backend while we collect data on our end. That way we can keep track of what works and what doesn't over the coming weeks and submit feedback.

One thing I really don't like at the moment is that the car is reporting zeroes on many fields when it is at sleep, instead of a distinct "no data". This makes my average temperature calculation include a lot of zeroes, just as a simple example. The car also jumps to 0 SoC sometimes, which makes my app think it was a battery swap when the SoC jumps back up, which it wasn't. I think all fields must include a distinct "no data" for the data to be reliable.