Hi, I could also help you with testing this.
I will work on this weekend and hopefully come up with a working example, will keep you updated
2 Likes
Happy to help in testing!
Would like to help testing aswell.
I would also be interested in testing Hyundai integration.
I am using Bluelinky through NodeRed (as part of Home Assistant) and have shared a manual for people wanting to get started via that route, mainly if you have not used NodeRed before. You can find it here. Message date is somewhere in Nov 2020. If you are interested it is worth reading the whole topic, because people have made suggestions that improve some of the approaches.
Willing to test an Hyundai Kona integration as well.
2 Likes
I have updated existing Kia Uvo integration with Hyundai Bluelink functionality. I am more than sure it will not work at first run, as I do not have an account to test this. Please give your feedback and create issues in github.
Repository link: GitHub - fuatakgun/kia_uvo
You can find more information in readme section.
Please help here for testing 
Hi!
I have not tested every detail, but it works well with Hyundia Ioniq 5. I can lock/unlock and except for the AC status everything I tested seems to work and the values make sense. But the AC status is also broken in Bluelink app, so that is not your fault. Very nice integration, thank you!
Cheers
JT
2 Likes
thanks for sharing, happy to hear that it is working well
Any issues with battery drain?
battery drain would happen only force update calls, normal update calls are reading data from respective servers and it is in your control to set the interval for both calls.
2 Likes
Hi, I set this up yesterday for my Ioniq 5, and it seems to be working well with two caveats:
The first I’m unsure of the reason for - for the main battery, I seem to have gotten an erroneous value which doesn’t mirror the true battery charge state. I haven’t checked whether this also applies to the app, but will keep an eye on it.
The second one is the pronounced staircase effect on the graph, which is presumably an effect of the addon updating from servers more often than it getting updated data from the car. I’ve just tried changing both settings to 20 minutes to see if this creates a more even curve, will report back on this.
I’ve added a graph with my expertly drawn graphics of the presumed true curve overlaid on the reported one.
1 Like
Presuming the higher frequency non-forced updates are to catch any updates from the car that do not originate from this plugin, I think a nice feature would be to not write updates to the HASS database if they have not changed since last update.
Are you getting unnecessary update events so optimize this? I haven’t had issues on this so far
I was thinking to avoid the staircase effect, as if you get an update a minute before a forced update, that will look like a true datapoint even though the update may be 4 hours old.
As it stands, the integration could write 10 datapoints to the DB over the course of several hours, and they would all really only be one datapoint at one time which creates a misleading graph.
Don’t worry, none of them will happen.
Force update is checking time delta between last update value (independent of source), so when you are driving your car, it will be updating itself and we are getting values from cached values and integration will wait 2 hours (configurable) to force an update.
Second is taken care by home assistant, it will not generate a record in db until value is actually updated.
Oh yeah, I see that now, it was just the presentation of graphs that made it seem like there were extra datapoints “added on”, but using a different graph addin, they do not show.
All my other graphed devices update a lot more often, so I’d never seen the grapher do that before.
Sorry for the confusion:)
1 Like
No worries, happy to see ideas for improvement
Got it up and running and so far great. A couple of things ive done so far:
- Setup a utility integration to monitor daily mileage from the odometer
- Setup a couple of helpers to store mileage since last charge, not sure how accurate it will be though but my basis is as follows:
- Store the current odometer in a helper as a base
- Created a template sensor to subtract the odometer value from the base - giving me a difference since base was saved
- Setup an automation to store the current template sensor value into another helper when the charger is unplugged thus giving me a value of mileage done between charges. The automation also updates the base odometer helper.
Will test how this works today.
Few suggestions, the default battery icon is the 12v battery rather than the EV battery.
The battery percentage icon would be nice to show like a phone battery icon at different levels so from a glance card you can see the level maybe rather than a car icon?