Timestamp of "last_updated_at" sensor is wrong #931
Comments
|
I have same issue. |
|
Europe, Hyundai Kona 2020, Version of the integration 2.26.6 From my logs analysis - invalid timestamp appears when it is getting cached vehicle status. Here is a snippet of my log (not a full JSON to keep privacy)
|
|
Could this have created it? Hyundai-Kia-Connect/hyundai_kia_connect_api#592 Easier for someone in EU to figure this one out. |
|
@cdnninja thanks for the hint. I will try troubleshoot if it had any impact |
|
|
Use "Force Update" instead of just "update".
yaml for button card in dashboard (device id xxxed): show_name: true So, for me its working like a charm. |
|
Last updated is last time car provided data not last time we checked the servers. Force update prompts it to update from the car vs cached from server. Car reports data for a variety of reasons. Force update consumes car battery. |
|
As I wrote ... 😎 |
|
@steps56 You probably missed, that in the OP I wrote I have used the "force update" 😉 I am not sure what caused it as I have seen it only once since I reported the issue. Usually it's fine. So I wonder why it is not consistently wrong or consistently right 🤔 |
|
Only thing to note is incorrect time will cause the integration to incorrectly calculate force refresh interval. This will cause it to query more often and consume 12v battery. Worth keeping an eye on it. |
|
Sure, but it will also manifest by getting rate limited by Hyundai servers as the amount of force updates is limited (20 per day if I am not mistaken). |
|
if forced update fails, we fallback to cached data, right? |
If you ask me or in general: Main problem about bad connection to the car is bad mobil connection of its sim card to the internet/cloud/server... or even car sits some days unused going to deep sleep. |
|
Got it again now after calling force update: Notice the two different times. Seems like the location data is the source of trouble...again 😅 |
|
I can't see any problems at my place/car/BlueLink/HA...
May be setting time at all stuff may solve the time gap ifthere is any at somebodys setups 🤷🏼♂️ |
|
To confirm, your last updated sensor in HA reverts to the location response time stamp? Location time is placed in the location timestamp here: In turn placed into the object here: I don't believe we expose vehicle.location_last_updated_at in HA only last_updated_at. I am not clear if this is actually an issue or not? Last_updated_at sensor in HA should match the cached call data response from the server, not last time a call was placed. |
Hmm, don't understand the programming stuff... Crosstest if someone sees any problems by using the Bluelink App. |
|
@steps56 why do you post here if you don't have issues? 🧐 @cdnninja I am not sure I read the code correctly, I am just a poor SysAdmin not Coder, but you are probably right. It just caught my eye when going through the debug log. |
|
@johny-mnemonic I am a sysadmin too but primary coder of this. :) Yes two timestamps can differ. I don't see a spot where the variables get mixed up. After the above two links where the values are stored to vehicle.location_last_updated_at and vehicle.last_updated_at we display this data here: kia_uvo/custom_components/kia_uvo/sensor.py Lines 69 to 74 in cd73b74 with key being the variable off the vehicle object. You can see all spots last_update_at is touched here: Keep in mind as previously mentioned a cached update call will only update last_update_at if the car has self reported data back since last cached update call. Common reasons for the car to report back data is being driven. If parked an unused I wouldn't expect it to report any data back. As such last_update_at will start to age. The force update logic configured in your settings trigger how old this data can be before it wakes the car up using a force update call - which also consumes 12v power. The reference to location last updated confuses me on how it relates to a timezone issue. Also hard for me to understand without knowing the 1. current time in local time. 2. log data time. 3. home assistant displayed time. 4. Mobile app displayed last updated time. And how those all relate. This would need to be done with no force calls executed as that sounds like brings it to current as we expect it to. Hope this helps! |
|
I'm having the same issues here. I moved my car at 8:09am (UTC+2). The IOS App is showing last updated correctly as 08:09am (correct time in my time zone) entity_id,state,last_changed
Hope this helps to find the issue. |
|
Again tested a few minutes ago. |
|
Forced update is fine. Cached update is showing wrong result about 50% of the time. And I do use the 'Last Updated At' on my dashboards, and then it doesn't look nice it's jumping between the correct time and a 2 hours earlier time. To help the developers look into this I did another two hour test in which i didn't do a forced update, only cached updates every 15 minutes while having the debug logging turned on. My actions and observation timeline in local times:
in the attached debug logs you can see this as well, the get_cached_vehicle_status response is sometimes getting time': '20240923123000' and sometimes time': '20240923103000'. '20240923123000' seems to be the UTC+2 time (my local time in the Netherlands) It looks like the server is sometimes unclear in which time zone to format the date/time. |
|
@steps56 what kind of issue do you have with this sensor? I don't understand it from your posts full of pictures 🧐 @Steven77nl thanks for the observation. I also noticed that it is sometimes randomly showing wrong and correct time. I would swear that I have seen correct time in the HA App on the phone while it was showing wrong time in the browser. |
|
The pictures/screens just shows what I do to get shown correct time. |
|
@Steven77nl excellent data and summary. Thank you for that work. The key finding is here. It shows two cached calls. This raw data response shows the data going back in time. This is the raw server data, not adjusted by us. This puts it in a bind as the data is incorrect. The time stamp is attached to the location section, not the car data however only one timestamp exists so not much we can do. The specific lines with the data don't show timezones. My gut? They use some form of eventual consistency DB like nosql, this causes some data to be wrong from time to time. In theory you may catch it in the native app, maybe with a automation to tell you when this happens. If you can catch it you could report to Kia but not sold they will fix it. Other option we can do is add logic that if the last updated goes back in time ignore the value. Any other datapoints we could drive this off of? |
|
@steps56 sorry, but then you completely missed what this reported issue is all about. @cdnninja so finally we have the root cause🎉 Nicely spotted! |
|
It could be that simple as well. Unfortunately hard for us to know! I'll add some logic and we can give that a go. |
|
Instead of waiting @cdnninja to make a change, you can create a template sensor given that last_updated_at is part of attributes of debug sensor, right? By the way, it is a very crucial sensor that helps us to decide when to enforce force update or stay with cached values, so great finding but weird issue. |
|
Thanks @fuatakgun for your workaround idea. |
|
A possible workaround could be to add 2 (or timezone) hours (or convert from UTC to local timezone) when the latest last_updated_at is less than the previous last_updated at. But this needs to be done at the client side and it needs to know the previous last_updated_at. |
|
@ZuinigeRijder this can be done in the library but it won't solve it for your monitor client based on my understanding on how it consumes the library. |
|
I used your idea @ZuinigeRijder to improve my temporary workaround. // Load global context for homeassitant
const ha = global.get("homeassistant")
// get the updated_at time received from the integration
var received = ha.homeAssistant.states["sensor.niro_last_updated_at"].state
// get the updated_at time stored in the date/time helper
var stored = ha.homeAssistant.states["input_datetime.niro_last_updated_at_max"].state
// convert to Unix TimeStamps
var recv_date = new Date(received)
var recv_uts = recv_date.getTime() / 1000
var stor_date = new Date(stored)
var stor_uts = stor_date.getTime() / 1000
// add two hours if last received is back in time
if (recv_uts < stor_uts) { recv_uts += 7200 }
// return additional values for debugging
msg.received = received
msg.stored = stored
msg.recv_date = recv_date
msg.recv_uts = recv_uts
msg.stor_date = stor_date
msg.stor_uts = stor_uts
// output to 1 if update is needed, output to 2 if update is not needed
if (recv_uts > stor_uts) {
msg.update = true
return [msg, null]
} else {
msg.update = false
return [null, msg]
}
Still not aways the correct time, but a lot more often than the previous workaround :) |
|
@Steven77nl Problem is that you disregard older timestamp if I read your code correctly. But it is possible the data has been changed and you get still an older timestamp, which is not 2 hours before the previous one, but still older than the previous datetime...... I have a fix ready for hyundai_kia_connect_monitor, will make a fix release soon. Here is my python code (newest_updated_at and previous_updated_at are both datetime objects with timezone information): There is still one situation, which cannot be solved. Assume previous timestamp was more than 2 hours ago. The new last_updated_at, is that the timestamp with the wrong 2 hours or is that the correct timestamp? |
|
Workaround added in hyundai_kia_connect_monitor R3.26.0. HA or hyundai_kia_connect_api could maybe something similar, when the previous latest_updated_at is known. |
|
Hi @ZuinigeRijder, the date is also included in my workaround, so no issues there. I agree that in that last situation you mention, there is no solution, and we will still end up with a time of two hours too early. Forced updates I only do when there is a reason to do so, based on triggers that I can get from other sources, like:
This way I stay within the API limits, as I have the latest important status information always on my HA dashboard and in the original Kia Connect App. Example, last night the Wallbox went into pause, because the car was full. So the automation request a force update to show on the dashboard the battery is 100%, that was at 4:50am. After this for me there is no need to get new information until I start driving my car later today.
|
Sometimes EU reports old time stamps Hyundai-Kia-Connect/kia_uvo#931 --------- Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
|
Could someone edit the manifest file of the integration to 3.23.3 and reboot? Let me know how it goes. |
|
@cdnninja As I understand the changes, you fixed this now only for ccs2 vehicles. My IONIQ 5 from 2021 has the same issue, but will not call _update_vehicle_properties_ccs2. So it will only partly fix the issue for HA users. Also I do not understand the implementation in _update_vehicle_properties_ccs2. I think the previous code was also wrong, Date is not in UTC, so it should have been in the first place (also self.data_timezone in first part): And the new changes, the first check, should that be if vehicle.last_updated_at is NOT filled, e.g. like: And I even expected an else in the new changes, see my solution here. I would expect a fix in the setter of vehicle.last_updated_at, with my solution. |
|
Good catch on CCS2. Lets move this chat to a PR to fix it. Thank you for the help! |
|
I can make a proposal Pull Request, but I cannot test for ccs2, but I can test for non-ccs2. |
|
Lets hope that this workaround solves this issue and does not have side effects. Sure HA users will test this ;-) |
|
This has been released in kia_uvo. Everyone please update to latest and let us know how it goes. |
XRecorder_Edited_05102024_202357.mp4
Working nice as before 👌. |
|
Sloooow respons by the people which should have had 🤔 any "problems"... Some artificial "problems" occure by let the car sit a few days unused, but that's wanted by basic Hyundai setup of bluelink to save the 12V Battery and easy disappears by driving next time. |
|
@cdnninja @steps56 problem is not artificial - e.g. I am using last_updated_at in my integration to know if SOC that I am reading is up to date or I need to ask for "fresh" one. With time jumping here and there, I could not estimate correctly SOC during the charging. |
|
Yeah it would just not jump backward. Some bad data would still exist. |
Hello, Conclusion: Don't understand me wrong, I love this integration... but it's nothing to be really usable about Ecar charging. |
|
@steps56 are you referencing evcc from GitHub? I'm glad that works for you. It's a different purpose and also "home grown". This feels like you are trying to insult the work done on this. I'm not sure what your goal is here. An issue did exist that impacted some people's use case. Not caused by our code but corrected in it. The data proves that. I would appreciate you stop trying to create drama. |
|
@steps56 I am confused why you are spamming this conversation by useless posts even containing images and video, to boast about your nice HA dashboard for your car. @cdnninja thanks for the fix! ❤️ @artursulkowski yep, same here. I also use this sensor to know whether to ask for the update to have up-to-date SOC in HA as I am handling car charging by my own automation. |
|
Credit goes to @ZuinigeRijder |
|
After running 2.26.8. for two days I can confirm that workaround works: |
|
Same here, I can confirm the new logic is working as expected. Thank you ! |
|
I can also confirm, that the workaround is working fine. |
Region and Brand of car
Europe
Hyundai Kona 2020
Version of the integration
2.26.6
Describe the bug
I have weird issue with a timestamp of the
last_updated_atsenzor. Most probably some timezone issue.As I live in CET it now translates to +2, but here is what I am getting today:
Here I called the force update at 17:59, it succeeded, but in the UI it tells me the data were last updated at 15:59.
Almost as if the integration somehow shifted the time based on my TZ, thinking it got the time from the server in CET, while it got it in GMT.
Here you can see server clearly defines the TZ as GMT:
Could this be some new change in the API? Did it return the time in local time instead of GMT previously?
The text was updated successfully, but these errors were encountered: