GEO Location data is truncated Hyundai USA #196
Comments
|
Are you able to confirm the Kia app works correctly? |
|
yeah here is a screen shot (Hyundai app): |
|
Is the above from the logs or home assistant data? I don't see us doing anything to the location so not sure why this would occur unless they aren't giving us the right amount of accuracy. |
|
The above data is from the logs (after I turned on debug level logging). For what it's worth, I used to use Bluelinky with Node Red, and that did have the correct precision in the data. |
|
Here is the full message from the log: |
|
I am primarily a java coder so take this with a grain of salt, but it looks like |
|
get_location was used in the canada API because the data wasn't included in the first API call. It appears as though Hyundai USA includes atleast some data in the initial call. I think you are correct in that we need to call a second API to get the more accurate data. Today we don't have a developer actively working on Hyundai USA API, I cover canada and other regions where I can. Feel free to drop a PR if you are inclined. I can also give it the first go around if you would rather not, I would need a hand testing though. |
cdnninja
changed the title
|
I could take it up, but I don't know how to setup the testing environment. Can you point me to how to do that? |
|
I am terrible and just edit my production HA code, restarting HA all the time. I have it so I can browse my HA via SMB and edit via my editor of choice. @fuatakgun recommended I setup a dev environment and had thoughts on a way that works well. |
|
i have setup vs code following home assistant developer guidelines which us independent than my production environment. Restarting it is very fast, please let me know if you can do it or i can code blindly and ask you to test @rappazzo |
|
Once I have the VSCode dev container up, I need to install HACS to it? Then, how do I point it to my copy of this repo? (I am happy to discuss on discord/etc rather than hijack the github issue if there is such a place too). |
|
https://github.com/fuatakgun/kia_uvo/compare/master...rappazzo:hyundai-usa-location?expand=1 |
|
I can see your pull request and it is a good starting point and I see that it requires PIN based call, which consumes daily API call limit of the user. I am not sure if we should place this call part of
@cdnninja , I remember you had some issues with limits, what do you think? |
|
What I did in CA was calling get location in get_status but only when odometer changed. It also passes the pauth to reuse it i believe. A little hacky if you look at it but works. |
|
did you call |
|
I can confirm I am also having the same Hyundai USA location truncation issue. |
|
I didn't add any triggers as of yet. When I had the node red bluelinky setup, I also needed to make a separate call to get the odometer reading, so @cdnninja's solution may not work for Hyundai USA. I don't see the odometer among the entity listing for this integration either, so that would be consistent. That node red setup was on a 1 hour cadence, making 3 calls - status, location, and odometer. As far as the daily API limit, I don't think that I ever reached it. Would it make sense to put these on a separate schedule? Is that an option? |
|
what about last_updated in get_vehicle response? if data is updated on cloud response, we can trigger a PIN based call to fetch location. |
|
Judging by the logs, this may work. Over the last day or so in my log with DEBUG level set, it doesn't update too often. One thing that I am a little unclear on. This code seems to want to format the date: But the log looks like that isn't working:
Or is this log from before the alteration? (I've updated my fork -- see the link above for changes) |
|
Logs are coming from line 148 so before the datetime change. The home assistant data entity is after the changes occur. I think your updated fork above still needs data mapping to get the value returned to Home assistant? As to odometer that is another bug that is open that needs to be fixed. In Hyundai USA it is in a separate call, it is the only region like this. |
|
I've updated my branch to be based on your odometer patch branch (with my fix). I (mostly) copied the "if odometer changed" code from Kia CA for the updates. Once the odometer code is merged, I will test this on my HA instance, and submit a pull request. |
…nect#196) The location information provided in the cached vehicle status does not include decimal precision. In order to fix this, implement the get_location method in the api for Hyundai USA. Considering that there is a daily API limit, poll the get_location method based on how fresh the data in the get_status response is.
|
Good FYI on rates: https://github.com/Hacksore/bluelinky/wiki/API-Rate-Limits Once this is working we can see if you hit the limit and how the integration handles it. I find I don't using this logic, but we don't drive often. In theory location is only hit if you moved between scans. A full day of driving may max out location calls. |
|
In the logs there are a lot more requests than I would have expected. I lot of different threads(?) doing the same request in clusters. (11:41 (2x), 12:11 (5x), 12:41 (5x), 13:11 (5x), 13:41 (5x), 14:11 (5x)). Is it over subscribed? Should we try to detect a recent request + successful response? Along those same lines, I have seen instances where some of the data returned is bad (my EV battery in the response was 0). Then in a subsequent request it seems to self correct (you can actually see an example of this in my post above with the battery graph - a quick down spike). My concern here is that if we do try to limit the number of requests, how can we assure that the response data is of quality? |
|
Well that is odd -is this debug logging or did you just truncate it? Typically it is configured to pull in the minutes not the seconds. |
|
I trimmed the log down to only those calls and removed the response details. It is from the DEBUG level logging. I can post the whole thing if you think that would help, but I would have to edit out the PII |
|
Is this with my PR integrated and was this happening before changes were made? Almost looks like an infinite loop of some form. |
|
This is running the HyundaiBlueLinkAPUSA.py from your branch. Revision 5619c71. I wouldn't say that it is an infinite loop. Just a loop of 5 iterations. Notice that each of the thread names is different |
|
Fair - It almost seems something else is missing from the logs or it is a different view. Typically other methods that call get vehicle response also have other log entries. |
|
I totally trimmed it down. I'll post more details in a minute, but it looks like most of those calls is preceeded by |
|
Here is the full log (with all of the responses removed): kia_uvo.log |
…nect#196) The location information provided in the cached vehicle status does not include decimal precision. In order to fix this, implement the get_location method in the api for Hyundai USA. Considering that there is a daily API limit, poll the get_location method based on how fresh the data in the get_status response is.
|
I think some of this is caused by having to call the vehicle command for both login and updating car status. Looks like the API also logs out so every time a scan occurs it has to login again. |
…nect#196) The location information provided in the cached vehicle status does not include decimal precision. In order to fix this, implement the get_location method in the api for Hyundai USA. Considering that there is a daily API limit, poll the get_location method based on whether or not the odometer changed.
…nect#196) The location information provided in the cached vehicle status does not include decimal precision. In order to fix this, implement the get_location method in the api for Hyundai USA. Considering that there is a daily API limit, poll the get_location method based on whether or not the odometer changed. It will also keep track of the last time that the location was retrieved form the server, and only fetch a new location if the last update was more than an hour ago.
|
So, I have been running my |
…nect#196) The location information provided in the cached vehicle status does not include decimal precision. In order to fix this, implement the get_location method in the api for Hyundai USA. Considering that there is a daily API limit, poll the get_location method based on whether or not the odometer changed. It will also keep track of the last time that the location was retrieved form the server, and only fetch a new location if the last update was more than an hour ago.
|
I am looking into overfetching of the location data, and it seems like HA is either keeping multiple instances of the Hyundai/Kia component, or it is discarding and then recreating new instances (ie, instances are being garbage collected). My evidence of this is that that I see in multiple log entries that it doesn't have the previous vehicle state, nor does it have a copy of the stored timestamp of my last location update. The odometer and timestamp checks do work in short term cases, but I think we would be better served if we could actually read the entity value history from HA....do you know how to do that? (edit) |
…nect#196) The location information provided in the cached vehicle status does not include decimal precision. In order to fix this, implement the get_location method in the api for Hyundai USA. Considering that there is a daily API limit, poll the get_location method based on whether or not the odometer changed. It will also keep track of the last time that the location was retrieved form the server, and only fetch a new location if the last update was more than an hour ago.
…nect#196) The location information provided in the cached vehicle status does not include decimal precision. In order to fix this, implement the get_location method in the api for Hyundai USA. Considering that there is a daily API limit, poll the get_location method based on whether or not the odometer changed. It will also keep track of the last time that the location was retrieved form the server, and only fetch a new location if the last update was more than an hour ago.
…nect#196) The location information provided in the cached vehicle status does not include decimal precision. In order to fix this, implement the get_location method in the api for Hyundai USA. Considering that there is a daily API limit, poll the get_location method based on whether or not the odometer changed. It will also keep track of the last time that the location was retrieved form the server, and only fetch a new location if the last update was more than an hour ago.
…nect#196) The location information provided in the cached vehicle status does not include decimal precision. In order to fix this, implement the get_location method in the api for Hyundai USA. Considering that there is a daily API limit, poll the get_location method based on whether or not the odometer changed. It will also keep track of the last time that the location was retrieved form the server, and only fetch a new location if the last update was more than an hour ago.
…nect#196) The location information provided in the cached vehicle status does not include decimal precision. In order to fix this, implement the get_location method in the api for Hyundai USA. Considering that there is a daily API limit, poll the get_location method based on whether or not the odometer changed. It will also keep track of the last time that the location was retrieved form the server, and only fetch a new location if the last update was more than an hour ago.
|
OK, so the pull request is submitted for this, but there are still duplicate calls going on from (I presume) different threads. Followed shortly by Would it make sense to use the double check idiom to execute the get_location code? Something like this: I would do this in a separate issue later. |
|
If we have thread issues I am thinking it may be a bigger issue but this part gets over my head. I will watch my logs to see if I see any similar trends. lets open a new issue for it. We good to close this one? |
|
Yeah. Good idea. Let's close this one and start a new one on the thread problem.
…On Dec 10, 2021, 9:27 PM -0500, cdnninja ***@***.***>, wrote:
If we have thread issues I am thinking it may be a bigger issue but this part gets over my head. I will watch my logs to see if I see any similar trends. lets open a new issue for it. We good to close this one?
—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android.
|
Please check Services, Known Bug / Issues and Troubleshooting over here first: https://github.com/fuatakgun/kia_uvo/blob/master/README.md
Region and Brand of car
USA - Hyundai 2020 Ioniq EV
Describe the bug
The Location info in the logs seems to have lost its decimal precision
Here is my car's current location (in the Atlantic Ocean!):
It looks like this is just truncated (not rounded), as my actual latitude is closer to 41
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The lat and lon values need a few more decimal places for more accuracy
Screenshots
("mep" is my phone's location)
The text was updated successfully, but these errors were encountered: