Workaround for server often returns last_updated_at 2 hours earlier

Since August 2024 the server in Europe often returns a 2 hours too old vehicle.last_updated_at.
The problem is that the cached update "last_updated_at" shows an incorrect result in about 50% of cases.

@Steven77nl is reporting this issue here in Home Assistant.

I have the same problem in monitor.py and it appears to be started at August 2024.
I see a difference of two hours repeated in the monitor.csv, example:

2024-09-28 00:00:57+02:00, ...
2024-09-27 22:00:57+02:00, ...
2024-09-28 00:00:57+02:00, ...
2024-09-27 22:00:57+02:00, ...
2024-09-28 00:00:57+02:00, ...
2024-09-28 08:14:06+02:00, ...
2024-09-28 10:14:06+02:00, ...
2024-09-28 08:14:06+02:00, ...
2024-09-28 09:03:20+02:00, ...
2024-09-28 11:03:20+02:00, ...
2024-09-28 09:03:20+02:00, ...
2024-09-28 11:03:20+02:00, ... 

I've looked at hyundai_kia_connect_api but can't find the problem, so it seems that the server might be sending the wrong date/time for cached latest_updated_at. Can be that one of the servers has the date/time wrongly set?

You cannot just disregard older timestamp. 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......

Here is part of my python code workaround (newest_updated_at and previous_updated_at are both datetime objects with timezone information):

            if newest_updated_at < previous_updated_at:  # new entry older than previous?
                utcoffset = newest_updated_at.utcoffset()
                newest_updated_at_corrected = newest_updated_at + utcoffset
                if (
                    newest_updated_at_corrected
                    >= previous_updated_at  # newest not too old?
                ):
                    newest_updated_at = newest_updated_at_corrected

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?

HyundaiBlueLinkAPIUSA Vehicle.daily_stats NOT consistent with other region implementations

Support daily_stats cumulative data for HyundaiBlueLinkAPIUSA.

See Hyundai-Kia-Connect/hyundai_kia_connect_api#617

Introduced setting for including regeneration in consumption daily stats

Added to monitor.cfg the setting include_regenerate_in_consumption.

In R3.23.0 the regeneration is taken into account for the consumption in daily stats, to better match the boardcomputer values. However, some users have better results in the old situation. Included a setting, default is the old situation before R3.23.0.

dailystats: fix that the consumption matches the boardcomputer by including the regeneration

It turns out that the consumption shown in the car is calculated including regeneration. This release fixes the calculation of daily stats. Now the daily stats consumption figures should better match with the consumption figures shown in the car.

Changed SOC% into float, because newer Kona and ccNC cars can return half percentages

Changed SOC% into float, because newer Kona and ccNC cars can return half percentages.

summary.py takes now into account the half percentages of SOC% and computation is done with floats.

Allow % sign in password

By default, the % sign is used by configparser to allow interpolation of entries, so you can chain things together. As that won't be used here, and people might have a % sign in their passord, it is better to disable interpolation.

See #59

Same construct used in debug.py

Show distance with 1 decimal and strip .0 in many places

The Kona 2024 model uses the newer ccNC infotainment system and the hyundai_kia_connect_api is different in several aspects. The API returns distances sometimes 1 decimal. There was a request to show this, e.g. for daily stats it is interesting for small trips.

Changed that 1 decimal is shown for distance/odometer.

Also changed in many places that when a float with one decimal is displayed, the .0 is stripped off. The effect is that it will show only the decimal when it is interesting.

Added examples of supported cars to README.

Updated requirements.txt to refer to latest hyundai_kia_connect_api (for support of ccNC infotainment).

Support for new EU models, e.g. Kia EV9, Hyundai Kona model 2024

hyundai_kia_connect_api v3.12.3 supports now newer EU models, like Kia EV9 and Hyundai Kona model 2024, which have an connected car Navigation Cockpit ccNC infotainment system.

Updated requirements.txt.

When you have a newer EU model, make sure to update the hyundai_kia_connect_api subdirectory with v3.12.3 or above.
Note that not all information is available yet, like EV range is currently missing. But hyundai_kia_connect_monitor should be usable for the EU new models.

New: Read .cfg files in current directory or in python script directory

Previously the .cfg files were read in the directory where the python scripts were located.

See this discussion: #56

Now the reading of .cfg files first looks in the current directory and then look into the python script directory. monitor.cfg is also read in the other scripts and also summary.cfg and translations.csv.

summary.py: fix trip was wrongly on the next day

• summary.py: removed skipping identical lines with only date-stamp difference, because of side-effects: trip was wrongly on the next day
• monitor.py: avoid exception when odometer is not filled
• made it possible to run the python scripts in another directory, the configuration files are searched on the directory where the python scripts are located