Avoid possible geocode_name exception

• avoid exception on geocode_name by checking for None in monitor.py
• added asking for tripinfo in debug.py

summary.py: clearing and writing Google spreadsheet in one go

One slower computers (I have an old raspberry Pi from 2012), the time between clearing Google Spreadsheet and writing new data can be relative long, especially with data over a year. That means, that if you look at the Google Spreadsheet on a phone or another computer, the spreadsheet can be cleared and only after e.g. a minute the new data is visible.

Changed summary.py, that clearing and writing is done in one go, at the end.

Requirements.txt: reference hyundai_kia_connect_api v3.10.8, because it solved a problem: fix(EU): strptime error #444

USA: string error on odometer

fix requirements.txt, point to new release of hyundai_kia_connect_api v3.10.7
https://github.com/Hyundai-Kia-Connect/hyundai_kia_connect_api/releases/tag/v3.10.7

Fix odometer for hyundai bluelink USA

See issue Vehicle.odometer is string instead of float for HyundaiBlueLinkAPIUSA.py and pull request fix: vehicle.odometer can be float-string instead of float

Fix in convert to miles

Fix in convert to miles.

Convert to miles when configured odometer_metric = mi:

• Forgotten to add/commit monitor.py
• Also convert in monitor.tripinfo.csv and monitor.dailystats.csv to miles when configured.

Note 1: configuration item "odometer_metric = km" is moved from summary.cfg to monitor.cfg and the default is "km"
Note 2: when you configure "odometer_metric = mi" in monitor.cfg, make sure to remove all *.csv files, because they might contain not converted values
Note 3: When converting to miles, sometimes one decimal digit is used to have a more accurate conversion from km to miles

Convert to miles when configured odometer_metric = mi and returned API unit is km

Convert to miles when configured odometer_metric = mi and returned API unit is km.

Note 1: configuration item "odometer_metric = km" is moved from summary.cfg to monitor.cfg and the default is "km".
Note 2: when you configure "odometer_metric = mi" in monitor.cfg, make sure to remove all *.csv files, because they might contain not converted values
Note 3: When converting to miles, sometimes one decimal digit is used to have a more accurate conversion

EU: Fix for Kia no longer working since 29 june 2023

The hyundai_kia_connect_api stopped working for EU. Both for Kia and Hyundai, since 29 June 2023.
See this issue: Hyundai-Kia-Connect/hyundai_kia_connect_api#348

A fix is found for EU Hyundai and EU Kia.

The Hyundai Bluelink server appeared to have a stricter check on pushRegId.
Also for EU Kia the problem is fixed, besides stricter pushRegId, there is a new AppId and stamp generation made for EU Kia.

hyundai_kia_connect_monitor is not updated (only README.md and requirements.txt).

How to fix it for EU Hyundai and EU Kia:

• Download the source code of hyundai_kia_connect_api v3.3.11 here
• Extract this source code
• Replace the hyundai_kia_connect_monitor/hyundai_kia_connect_api folder with the hyundai_kia_connect_api-3.3.11/hyundai_kia_connect_api folder

EU: Fix for Hyundai only no longer working since 29 june 2023

The hyundai_kia_connect_api stopped working for EU. Both for Kia and Hyundai, since 29 June 2023.
See this issue: Hyundai-Kia-Connect/hyundai_kia_connect_api#348

A fix is found for EU Hyundai, the Hyundai Bluelink server appeared to have a stricter check on pushRegId.

For EU Kia the problem is NOT fixed yet in hyundai_kia_connect_api and there is worked on by @cdnninja and others. There needs to be at least a new AppId and stamp generation to be made for EU Kia.

hyundai_kia_connect_monitor is not updated (only README.md and requirements.txt).

How to fix it for EU Hyundai:

• Download the source code of hyundai_kia_connect_api v3.3.8 here
• Extract this source code
• Replace the hyundai_kia_connect_monitor/hyundai_kia_connect_api folder with the hyundai_kia_connect_api-3.3.8/hyundai_kia_connect_api folder

Fixed bug with elapsed days

The elapsed days was computed wrong, so the averages were wrong for:

• YEARLY
• MONTH AVG
• WEEK AVG
• DAY AVG
• TRIP AVG

The result was, that the expected km/miles driven for a year was too high.

fix timezone mismatch

In monitor.py and monitor_utils.py the timezone is not filled when datetime is None.

monitor_utils.py (added timezone parameter):

def get_safe_datetime(date: datetime, tzinfo: timezone) -> datetime:
    """get safe datetime"""
    if date is None:
        return datetime(2000, 1, 1, tzinfo=tzinfo)
    return date

monitor.py (extra parameter vehicle.timezone):

    last_updated_at = get_safe_datetime(vehicle.last_updated_at, vehicle.timezone)
    location_last_updated_at = get_safe_datetime(
        vehicle.location_last_updated_at, vehicle.timezone
    )