Jump to content

Access Hyundai BlueLink data via WebAPI


Recommended Posts

Description:  In a closed facebook group, a user mentioned, that Hyundai's BlueLink can be accessed via a WebAPI. Integrating this, all (in US, from 2019/2020 models  in the EU) Hyundai and KIA (I guess) vehicles' data can be accessed via that API

Use Case: Car data acces Tesla style without needing to use ODBII and/or helper apps

That facebook post was about this app (free and paif for version available), which uses that API.
https://play.google.com/store/apps/details?id=com.gotnoname.bluelinkify.free
Developer's fb page:
https://www.facebook.com/stianandre.thoresen

A user in that discussion thread mentioned, that it accesses a WebAPI, I've asked him for info/link about it.

Link to post
Share on other sites

That'd be great! We actually have a system set up to poll APIs, as you mentioned for the Tesla logins.  It was designed to be easily expandable once we gain enough knowledge about another API.  The main things we'd need from the API to make it useful to you (in order of importance):

  1. SoC
  2. Speed
  3. Lat/Lon
  4. Power
  5. Any other data about the car's status (health, temperature, voltage, current, etc)

If we can get those things relatively frequently, we can make a really good tool!  Of course, once we find enough about the API to start building, we'd need someone with an actual Hyundai to help us out so we can test the telemetry calls out.

  • Like 1
Link to post
Share on other sites

That'd be great, and even greater if such access would be available for VW

I've received an answer, not from the developer, but from that guy in the thread. The project is inofficial, it's an API wrapper. I've yet neither found if the API is officially open, nor if it covers Kia aswell. And as I have a pre facelift Ioniq, that is not bluelink enabled in EU, I'm not able to help unfortunately, but I'll post quests for help in the Ioniq, Kona and e-Niro groups I'm in if you decide to start implementing 🙂

https://github.com/Hacksore/bluelinky

Link to post
Share on other sites
On 5/24/2020 at 1:46 PM, Hacksore said:

So seems like a lot of those things are possible to get from the bluelink endpoints. I think making something that can work is possible so I'm down to help with whatever is needed.

Sounds great! I think the first order of business is for us to expand our poller so we can easily incorporate additional manufacturer methods like BlueLinky.  As far as parameters which can be retrieved - if we have SoC only that's workable.  It'll take a long time to calibrate correctly though.  Calibration is much faster if we can get Power data from the battery pack (input/output) and much more accurate we've found.

Of course, if it's not possible, that's a limitation we'll have to deal with.

Edited by Jason (ABRP)
Added details on desired parameters
Link to post
Share on other sites
  • 6 months later...

I am using BlueLinky alot with my homegrown NodeRed project. Hyundai has a rate limit of IMHO 200 calls/day. After that all requests are blocked until midnight. This might be too less for a good ABRP integration.

Currently i am querying the API

  1. every 15 min normaly
  2. every 5 min when "ignition = true"
  3. every 2 min when "charging = true"

Just to give an idea.

The API has also very limited infomation, i.e. the battery temparature is missing.

Link to post
Share on other sites
  • 1 month later...
  • 2 weeks later...
On 1/24/2021 at 9:31 AM, Marc816 said:

I am also interested in a link via Bluelink API for my Hyundai Kona EV. 

Any plans in this direction yet?

You can do this via Tronity. But I’m not sure yet how useful it is or how well it works with ABRP until I test it. It maybe doesn’t update frequently enough to be useful.

Link to post
Share on other sites
  • 2 months later...

Pretty please -  add this for premium users.

I do not like the idea of tronity storing my movements and everything. Furthermore I do not like the idea to have a second subscription just to feed my soc into abrp.

Just be kind to the bluelink/uvo2 api as it does not like to be asked more than 200 times a day. So probably just when planing a navigation ans then like all 10 minutes while driving 😉

Other sources to see how it could be done are openWB and EVCC which are open source and offer SOC modules to integrate this kind of „soc polling from car companies servers“.

Probably you could start a colaboration  with openWB or evcc by using the same modules - that could be a win(you) win(them) win(us)...

Edited by BigKid
Link to post
Share on other sites

So, we've looked at this, and it's just not that useful.  Updated SoC is nice, but it's very slow, and that's about the extent of the EV-specific data.  You won't get a good calibration of your car model through most manufacturer APIs.  They don't put anything aside from the SoC on there typically.  To be useful for driving we really need insight into the power draw for the car, and this is almost never provided.

So, with that in mind we haven't put any manufacturer API implementations close to the top of our list, we'd rather work on better app support (there's a lot to improve here), and we are actively pursuing better OBD support.  Probably the best thing to do here is EVNotify for now.

That said, if someone wants to work with us to implement an API poller, we're happy to help (and even host it on our servers / integrate it into the app), it's just not a high enough priority yet for us to spend our limited dev time on.

  • Like 1
Link to post
Share on other sites

Supporting Tronity is relatively low workload (so we could fit it in our other priorities) but adds a lot of supported cars.  Even if that support is not very complete, since it's only SoC.

  • Like 1
Link to post
Share on other sites
9 minutes ago, Jason-ABRP said:

Supporting Tronity is relatively low workload (so we could fit it in our other priorities) but adds a lot of supported cars.  Even if that support is not very complete, since it's only SoC.

Ok - understood. 

So presumably the Tesla API is way more advanced then in terms of the parameters it can feed ABRP?

So we really need more manufactures to provide more extensive APIs so that, hopefully in future, drivers of more cars can just provide ABRP directly with credentials so it can pull all the necessary data from the car itself. Fiddling around with OBD dongles is okay for a few % of drivers, but I think is never going to be something that a large proportion of people are going to bother with.

I wonder whether you guys are attempting to speak to manufactures to get across to them the value of this stuff in giving people confidence about range and helping to eliminate anxieties, and maybe to help them understand what sort of data is needed.

Although, most of them seem to be struggling at the moment to even get their own apps to work reliably, so maybe it’s a bit of a pipe dream for the foreseeable future.

 

 

 

 

Link to post
Share on other sites
21 hours ago, Jason-ABRP said:

So, we've looked at this, and it's just not that useful.  Updated SoC is nice, but it's very slow, and that's about the extent of the EV-specific data.  You won't get a good calibration of your car model through most manufacturer APIs.  They don't put anything aside from the SoC on there typically.  To be useful for driving we really need insight into the power draw for the car, and this is almost never provided.

So, with that in mind we haven't put any manufacturer API implementations close to the top of our list, we'd rather work on better app support (there's a lot to improve here), and we are actively pursuing better OBD support.  Probably the best thing to do here is EVNotify for now.

That said, if someone wants to work with us to implement an API poller, we're happy to help (and even host it on our servers / integrate it into the app), it's just not a high enough priority yet for us to spend our limited dev time on.

Oh thats too sad.

Problem with EvNotify is that all iOS Users will need to have a second cellphone just to keep evnotify and abrp running - thats because iOS will send EvNotify (or ABRP) to sleep as soon as its in the background.

So unless abrp gets obd via bt integration a lot of us will be very sad 🙂

Edited by BigKid
Link to post
Share on other sites

Yes, the Tesla API provides a lot more detail and updates very frequently.  Any time we've talked to OEMs we've mentioned that this is the ideal, but they move very slowly.

For now our ideal solution would be a standalone OBD Dongle with:

  1. Cell / WiFi connection so you can get status while away from the car (let you know when charging is done).
  2. Bluetooth connection so you don't lose data when you lose cell connection.

We've actually got a few candidate devices in mind (Freematics, EVDash/M5Stack).  If anyone's good with Arduino programming send me a message and maybe you can help us get this off the ground.

Link to post
Share on other sites

Agree, and on top of that it's not available outside of Europe at all.  You can also do 1 with an AutoPi (which is available worldwide, and I'm using one for my Bolt EV), but again it's not cheap, and it's hard to do 2 with an AutoPi (but technically possible).  The limiting factor is the AutoPi by default only allows local PID pulling via its WiFi network, which means you can't be connected easily to your car's wifi if you use wireless Android Auto / CarPlay.

 

  • Like 1
Link to post
Share on other sites
  • 1 month later...
Posted (edited)

Just to follow this up, since having had the e208 (which can update the SoC in ABRP via Tronity whilst driving), I’ve found that more than enough to be very useful, and much better than having to manually check the real SoC against ABRP’s current estimate.

So given this, and also given my belief that most people will not be bothered to go down the route of using ODB devices, I would really like to see higher priority given to enabling direct car API links into ABRP.

Continual app improvements are important and necessary, but for me the biggest improvement from using ABRP in an i3 compared to in the e208 was the ability to have the SoC in ABRP automatically updated whilst driving.

If ABRP could allow direct login with credentials for any manufacturer that supports SoC updating when driving, that would be the biggest single improvement you could make, in my opinion.

Edited by Bill N
  • Like 1
Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...