Units on monitor.dailystats spreadsheet

[gyveri]

It's great to see trip info now being shown on the monitor.dailystats spreadsheet. Thank you for adding this information to the spreadsheet.
However, units shown on the idle time column G are minutes. One of my trips today showed an idle time of 146 minutes, (over 2 hours), way longer than this 8-mile (13km) took overall. Do the numbers in this column actually represent seconds? Same question with regard to the trip times shown in col P and the idle time shown in col. U.
As well as correcting the units, it would be nice if the trip time and idle time could be shown in hours, minutes, and seconds so they would be easier to comprehend.

[ZuinigeRijder]

The idle time in Europe looks for me correct, the unit in minutes seems plausible. You really have to check if the units returned in HyundaiBlueLinkAPIUSA.py are minutes or seconds. Note that the idle time is (probably) measured till the car is totally shut off.

I will have a double check too, if the idle time unit in Europe are possibly in seconds.

The trip time and idle time in column P and U are just helper columns for the diagrams, and the minutes are easier to show in a diagram.

[gyveri]

I've sent to your personal email copies of yesterday's debug results and a snippet of the monitor.dailystats spreadsheet showing yesterday's trips. I can't find any indication in the debug results of the time units for TripInfo. However, traffic was bad on the trip I started 09:33, so the trip took about 20 minutes. This is consistent with the units of the trip time of 1278 being seconds. The idle times shown in the debug results are presented verbatim in col G of the spreadsheet, and the trip times and idle times are presented verbatim in cols P and U, i.e., there is no conversion of the raw trip times to minutes in this version.
I agree that the idle time is the cumulative time between key on and key off during which the car is not moving.

[ZuinigeRijder]

For Europe it is definitely in minutes, I checked today.
Therefore I expected it also to be in minutes for HyundaiBlueLinkAPIUSA.py. But apparently unit 3 means seconds in e.g.

  'duration': 
            {
                'unit': 3,
                 'value': 794
            },

That means it has to be solved in HyundaiBlueLinkAPIUSA.py. Already stored trips in monitor.tripinfo.csv you have to convert manually from seconds to minutes.

See attached a patch.

HyundaiBlueLinkAPIUSA.zip

[gyveri]

Patch installed. Thank you. Will test tomorrow.

[gyveri]

Drove to supermarket this morning and returned home by a different route. Snippet of monitor.dailystats spreadsheet is attached. Total trip times in col. P look correct, but idle times in cols G and U do not.
monitor.dailystats snippet 2.xlsx

[ZuinigeRijder]

@gyveri My bad programming, subtracting without converting to minutes of all parts is not a good idea ;-) That is why it is so important someone (as you) can test it. Thanks for testing again. New attempt.....

HyundaiBlueLinkAPIUSA.zip

[gyveri]

Your new attempt produces good results - see attached snippet.
However, a coder's work is never done ....
Now that the way that HyundaiBlueLinkAPIUSA.py. generates trip information and that information is displayed in the monitor.dailystats spreadsheet, it appears that there are differences between the way trip information is displayed between the the monitor.dailystats and the hyundai-kia-connect-monitor spreadsheets.
I've included a copy of part of the hyundai-kia-connect-monitor spreadsheet in the above snippet. You'll see that on 22 Sep, 2 trips are shown rather than 3, and, on 21 Sep, 3 trips are shown rather than 4.
monitor.dailystats snippet 3.xlsx

[ZuinigeRijder]

@gyveri I created a pull request for the conversion of seconds to minutes.

Your remarks about the difference between hyundai-kia-connect-monitor spreadsheets and monitor.dailystats spreadsheet is by design.

hyundai-kia-connect-monitor spreadsheet is based on the build up of history of snapshots over time. See FAQ.

Why is my trip not detected in summary.py? monitor.py makes a snapshot of the latest server values at the time run, if two trips are made between 2 snapshots this will not be detected

monitor.dailystats spreadsheet is based on history from the server, so less chance that trips are missing (for Europe practically not possible, for Hyundai USA when more than 4 trips have been done before asking for them).

Note that in the monitor.dailystats spreadsheet some matching is tried with summary.py output between round brackets "()", not the other way around.

[gyveri]

Thanks for doing the pull request to convert seconds to minutes.
I'm curious as to why, now that trip information can be extracted from the HyundaiBlueLinkAPIUSA api, such trip information cannot be used to provide the trip information in the hyundai-kia-connect-monitor (HKCM) spreadsheet. Even though we in the U.S. are subject to Hyundai's 20-access daily limit, surely it would be better for the HKCM spreadsheet to show trip information for up to 4 trips in one hour, rather than just one.
I'm also curious as to exactly how the 20-access limit is applied. Is it 20 log-ins, or 20 downloads? If it's the latter, I can't see a way around this. If it's the former, then maybe the script could log on for, say, 2 hours and request downloads every 15 minutes. The python script I wrote to download usage data from my Tesla Powerwall does this, except that it remains logged in throughout each day and, every 10 minutes, requests the PowerWall to download new data. You can't do that running the script using a crontab, but my script goes to sleep after it's received the requested data, then wakes up when it's time to submit another request. I'll be happy to share this script with you if you promise not to laugh at my unsophisticated coding.

[ZuinigeRijder]

First there was no daily stats and trip info in the hyundai_kia_connect_api. I started with gathering snapshots with monitor.py and do computation with the snapshots in summary.py. One part of the summary was to also find detected trips.

Later on I sniffed the Bluelink App and implemented/contributed the daily stats and trip info in hyundai_kia_connect_api, so I could use it in hyundai_kia_connect_monitor in dailystats.py. So these are different tools and both have value. There is another tool to generate kml from the monitor.csv file, to show addresses in Google Maps.

If you want to know your daily stats/trip stats, you should look at dailystats spreadsheet. If you want summaries of the snapshots you look at the hyundai_kia_monitor spreadsheet. Also daily stats and trip info was first only available in Europe and still is not available in all regions. The information in summary.py is just based on monitor.csv data and process it. Intermixing this with dailystats/trip info is also difficult, because the odometer and other information is not available there, so what would you display in the spreadsheet?

There is a difference in the access-limit between regions, e.g. I run monitor.py 3 times an hour between 6.00 and 22:00 in Europe without a problem. I think the access limit is not the number of logins, maybe it is the number of refresh of the token?

But of course you could try to determine this yourself by adapting monitor.py to keep asking for values in a loop with a sleep.
I made a quick hack by adapting method handle_vehicles() in monitor.py:

import time

def handle_vehicles() -> None:
    """handle vehicles"""
    retries = 10
    while retries > 0:
        try:
            if retries > 9:  # only do once
                # get information and add to comma separated file
                manager = VehicleManager(
                    region=int(REGION),
                    brand=int(BRAND),
                    username=USERNAME,
                    password=PASSWORD,
                    pin=PIN,
                    geocode_api_enable=USE_GEOCODE,
                    geocode_api_use_email=USE_GEOCODE_EMAIL,
                    language=LANGUAGE,
                )
            manager.check_and_refresh_token()
            manager.update_all_vehicles_with_cached_state()  # needed >= 2.0.0

            number_of_vehicles = len(manager.vehicles)
            error = False
            for _, vehicle in manager.vehicles.items():
                error = handle_one_vehicle(manager, vehicle, number_of_vehicles)
                if error:  # something gone wrong, exit loop
                    break

            if error:  # something gone wrong, retry
                retries -= 1
                sleep(retries)
            else:
                retries = 9  # unendless run while loop
                log("Sleeping 15 minutes")
                time.sleep(15 * 60)

        except exceptions.AuthenticationError as ex:
            retries = handle_exception(ex, retries)
        except exceptions.RateLimitingError as ex:
            retries = handle_exception(ex, retries)
        except exceptions.NoDataFound as ex:
            retries = handle_exception(ex, retries)
        except exceptions.DuplicateRequestError as ex:
            retries = handle_exception(ex, retries)
        except exceptions.RequestTimeoutError as ex:
            retries = handle_exception(ex, retries)
        # Not yet available, so workaround for now in handle_exception
        # except exceptions.ServiceTemporaryUnavailable as ex:
        #    retries = handle_exception(ex, retries)
        except exceptions.InvalidAPIResponseError as ex:
            retries = handle_exception(ex, retries, True)
        except exceptions.APIError as ex:
            retries = handle_exception(ex, retries, True)
        except exceptions.HyundaiKiaException as ex:
            retries = handle_exception(ex, retries, True)
        except Exception as ex:  # pylint: disable=broad-except
            retries = handle_exception(ex, retries, True)

Previously I exited the while loop when I did get a snapshot. Now I only ask once for the VehicleManager (and the associated login) and do the rest in a loop. You can change the sleep period yourself in the above fragment:

                retries = 9  # unendless run while loop
                log("Sleeping 15 minutes")
                time.sleep(15 * 60) 

Note that I did not test the above, but I am sure you will do?

[gyveri]

Interesting!
I'll test your new script. Let me see if I understand how?
Replace handle_vehicles() in monitor.py with the new script.
Edit run_monitor_once to remove /usr/bin/python -u ~/hyundai_kia_connect_monitor/monitor.py >> run_monitor_once.log 2>&1
Run monitor.py in Thonny (so we can see error messages) and see how many times monitor.py before it's kicked off the server.
Is the above correct?

[ZuinigeRijder]

Yes, this is correct. But make sure that summary.py and dailystats.py is run between the 15 minutes sleep. Or just do not run them for the test, to see how many times you can ask for the snapshots.

[gyveri]

Commented out crontab. In Thonny, loaded monitor.py, commented out existing handle_vehicles(), pasted in new handle_vehicles() and hit Save, Run.
monitor.csv now has an entry timestamped 13:50, and Thonny says script is sleeping 15 mins.
I'll check again in 30 mins & let you know if anything unexpected happens.

[gyveri]

It looks like the script is doing a sort of double tap spaced nearly 3 minutes apart - here's a snippet from monitor.csv
The timestamps on lines 2 & 3 are not 15 minutes apart because my RPi reset itself some time between 13:53 and 14:05 and I had to restart the script. The script is still running at 15:04, but monitor.csv has not updated since the update at 14:16.
2024-09-25 13:50:21-07:00, -121.906275, 36.97326666, False, 82, 5346, 76, False, 0, 180; 259
2024-09-25 13:53:19-07:00, -121.906275, 36.97326666, False, 81, 5346, 76, False, 0, 180; 259
2024-09-25 14:13:37-07:00, -121.906275, 36.97326666, False, 81, 5346, 76, False, 0, 180; 259
2024-09-25 14:16:35-07:00, -121.906275, 36.97326666, False, 81, 5346, 76, False, 0, 180; 259

[ZuinigeRijder]

monitor.csv will not be written if the snapshot entry is the same as last entry. So only if you have driven, it will update monitor.csv.

[gyveri]

I ran the modified script again today and let it run til it failed. While the script was running, took 2 trips. Attached are copies of the output of Thonny and the last few entries in monitor.csv. From the latter, you will see that, each 15 minutes, the script puts two entries into monitor. csv spaced about 3 minutes apart. It's not clear what caused the script to start throwing Unexpected line errors after running nicely for several hours.
monitor_snippet_20241002.csv
Thonny_output_20241002.txt

[ZuinigeRijder]

The 3 minutes apart, I see this also, when a trip is ended only a few minutes later the SOC% change is send. You can see this also by the fact that SOC% is changed or the EV range is changed.

I think that the session has been invalidated and that causes the Unexpected line errors (SOC%, charging, plugged is None). Or there is the limit already reached, because there are 21 entries before it goes wrong?

Probably it is the last problem, limit reached. So than there is nothing I can do about that.

[gyveri]

I'm going to run it again today and, it I get the Unexpected line errors again, I'll stop the script and then will try restarting it about an hour later, just to see what happens.

[gyveri]

I started the script just after 9:00 yesterday. It's still running!
monitor_thru_20241004.csv
Thonny_output_20241004.txt

[ZuinigeRijder]

Hmm, interesting. So it looks the number of logins is limited not the rest of the calls. But it also was going wrong earlier, so I think there is a problem in hyundai_kia_connect_api that not always the Token is refreshed when it is expired?

[gyveri]

I finally stopped the script at about 17:30 this afternoon. So your modified script has run flawlessly for about 32 hours and 128 measurements. I stopped the script because I wanted to try modifying it to run at 0, 15, 30 and 45 minutes past the hour. This would allow me to try running daily stats and summary at fixed times using frontal. My first attempt to run the script crashed the computer, but it appears to be running OK now. We’ll see what happens overnight.
Regarding the issues I had earlier, are the exceptions in the script set up to properly handle Unexpected line errors?

[ZuinigeRijder]

Yes, it retries 9 times, if it still does give None in the output it stops.

[gyveri]

I think that stopping after 9 tries is an entirely appropriate response when the script scheduling is done using crontab, because after the stop, the script will run at the next time scheduled by crontab. But when scheduling is done using a sleeping loop, stopping permanently kills execution of the loop. Instead of stopping, would it not be better simply to stop doing whatever caused the exception and then wait for the next iteration of the loop? It might also be a good idea, for certain exceptions at least, to reduce the number of tries and to increase the time between tries to give a bit more time for the cause of the exception to resolve itself.

[ZuinigeRijder]

Yeah, this was a quick hack by adapting method handle_vehicles() in monitor.py, default there are only 3 retries. Problem with continuously running monitor.py is also that you do not know when to run summary.py and dailystats.py and they might interfere each other. And the situation that you encountered, that there seems to be a state that None values keep returning.....

[gyveri]

Attached is the output of Thonny from earlier today after I'd added some code to make handle_vehicles run at 0, 15, 30 and 45 minutes past each hour. You'll see that it runs just fine for a while, but there's a small drift in the execution time due to the fixed sleep time. Then the code throws some exceptions. The good news is that the exceptions are all handled, but the handling delays throw the execution timing off.
I've now changed the code so that it calculates the sleep time. This will prevent the execution time drift noted above and also will ensure that exception handing will not throw the timing off.
Testing now.

[gyveri]

Attached is the output of Thonny from earlier today after an overnight run. It looks like the modified script ends its sleep period at 0, 15, 30 and 45 minutes past each hour and continued to do so even after an exception occurred.
I've attached the modified version of handle_vehicles() for you to test if you wish.
Now that we can make monitor.py run at known times, is there any reason why we should not use crontab to run dailystats.py and summary.py at, say, 5 minutes after each time monitor.py has run? e.g., do these scripts do a log in to Hyundai to download additional data?
Thonny_output_20241006.txt
handle_vehicles.txt

[ZuinigeRijder]

summary.py and dailystats.py only use the .csv generated by monitor.py, so in principle they can run via crontab when you know the times when monitor.py should be ended, or even look at monitor.lastrun, so you are sure it has ended. Actually, summary.py and dailystats.py should not need to run when no new entries are written by monitor.py. So another solution would be to spawn a shell script to run summary.py and dailystats.py. So you do not need crontab for that then.

I will have a look at your changes and do some experimentation. However, I am a little bit scared that the problem with the None values is something more difficult to solve, because this is probably somethin in hyundai_kia_connect_api not taking care of correct refresh? Also a crash of monitor.py should be resulting in a restart of monitor.py. So a lot of tailoring probably, but worth to investigate further.

[gyveri]

I've now been able to make summary.py and dailystats.py work with the modified script. To do this, I had to use terminal to change the directory to hyundai_kia_connect-monitor and then run /usr/bin/python -u monitor. Then I modified run_monitor_once.sh to remove the line that runs monitor.py, leaving the lines that run summary.py and dailystats.py. Finally, I set up crontab to run the modified run_monitor_once.sh to run at 5 minutes past each hour. With this all running, the .csv files and spreadsheets appear to be updating OK.

I look forward to receiving you comments on the modified monitor.py. I share your concerns about dealing with a crash in monitor.py, although the exception handling you have in place seems to keep it running OK. I would suggest that we put the synchronization loop inside another loop that logs out of the Hyundai server at the end of each day and then logs back in 5 minutes later. That way, we don't test any log-in time limit that the server may have.

[ZuinigeRijder]

I am thinking about the following changes to monitor.py:

• indeed split login and getting cached results
• keep the possibility to run in the old way (everytime exit monitor.py after successful result)
• add possibility to run infinite (configuration)
• add possibility to end once per day, e.g. end of day (configuration)
• interval in minutes (configuration)
• when there is new data, run a command (configuration), e.g. summary.py and dailystats.py, so only those commands are run if there is something changed

But that is going to take some time and of course I am going to test this myself.

[gyveri]

Your "to do" list looks like a pretty impressive. I particularly like the idea of running summary.py and dailystats.py only when the data output by monitor.py changes.
May I make a plea for you to have mercy on we folks who measure our distances in miles and use the odometer readings (with tenths) included in the trip information as principal odometer data and for calculating trip distances instead of the odometer and distance data (without tenths) served up by the Hyundai api? This would reduce the likelihood of having zero-distance trips and improve the accuracy of distance-related stats, especially for short trips.
I'll be happy to assist you in this project and, of course, to do testing.

[ZuinigeRijder]

May I make a plea for you to have mercy on we folks who measure our distances in miles and use the odometer readings (with tenths) included in the trip information as principal odometer data and for calculating trip distances instead of the odometer and distance data (without tenths) served up by the Hyundai api? This would reduce the likelihood of having zero-distance trips and improve the accuracy of distance-related stats, especially for short trips. I'll be happy to assist you in this project and, of course, to do testing.

This needs to be solved at HyundaiBlueLinkAPIUSA.py, not in hyundai_kia_connect_monitor. In principle this can be done, by comparing the previous odometer trip with the current. Problem will be the earliest trip, nothing to compare with, so fallback to distance. But this would not be a problem for hyundai_kia_connect_monitor, assuming the earliest trip info is already written. This is a fragment of the trip details from one of your log files send to me:

DEBUG:urllib3.connectionpool:https://api.telematics.hyundaiusa.com:443 "GET /ac/v2/ts/alerts/maintenance/evTripDetails HTTP/11" 200 None
DEBUG:hyundai_kia_connect_api.HyundaiBlueLinkAPIUSA:hyundai_kia_connect_api - get_ev_trip_details response 
{
    'tripdetails': 
    [
        {
            'distance': 3,
             'odometer': 
            {
                'value': 5213.7
            },
             'accessories': 90,
             'totalused': 715,
             'realtotalpwrcsp': 0,
             'regen': 571,
             'avgspeed': 
            {
                'unit': 1,
                 'value': 21.0
            },
             'maxspeed': 
            {
                'unit': 1,
                 'value': 42.0
            },
             'climate': 52,
             'drivetrain': 573,
             'startdate': '2024-09-12 10:59:22.0',
             'mileagetime': 
            {
                'unit': 3,
                 'value': 591.0
            },
             'duration': 
            {
                'unit': 3,
                 'value': 618
            },
             'batterycare': 0
        },
        {
            'distance': 3,
             'odometer': 
            {
                'value': 5210.1
            },
             'accessories': 140,
             'totalused': 640,
             'realtotalpwrcsp': 0,
             'regen': 605,
             'avgspeed': 
            {
                'unit': 1,
                 'value': 23.0
            },
             'maxspeed': 
            {
                'unit': 1,
                 'value': 41.0
            },
             'climate': 54,
             'drivetrain': 446,
             'startdate': '2024-09-12 09:42:28.0',
             'mileagetime': 
            {
                'unit': 3,
                 'value': 550.0
            },
             'duration': 
            {
                'unit': 3,
                 'value': 900
            },
             'batterycare': 0
        },
        {
            'distance': 0,
             'odometer': 
            {
                'value': 5206.5
            },
             'accessories': 30,
             'totalused': 41,
             'realtotalpwrcsp': 0,
             'regen': 0,
             'avgspeed': 
            {
                'unit': 1,
                 'value': 1.0
            },
             'maxspeed': 
            {
                'unit': 1,
                 'value': 1.0
            },
             'climate': 6,
             'drivetrain': 5,
             'startdate': '2024-09-12 08:01:49.0',
             'mileagetime': 
            {
                'unit': 3,
                 'value': 18.0
            },
             'duration': 
            {
                'unit': 3,
                 'value': 93
            },
             'batterycare': 0
        },
        {
            'distance': 0,
             'odometer': 
            {
                'value': 5206.5
            },
             'accessories': 40,
             'totalused': 66,
             'realtotalpwrcsp': 0,
             'regen': 0,
             'avgspeed': 
            {
                'unit': 1,
                 'value': 1.0
            },
             'maxspeed': 
            {
                'unit': 1,
                 'value': 3.0
            },
             'climate': 19,
             'drivetrain': 7,
             'startdate': '2024-09-11 17:46:12.0',
             'mileagetime': 
            {
                'unit': 3,
                 'value': 13.0
            },
             'duration': 
            {
                'unit': 3,
                 'value': 146
            },
             'batterycare': 0
        }
    ]
}

So it would be something to compute the delta miles from "odometer - previous odometer" and if there is no previous odometer fallback to "distance". You can have a look at HyundaiBlueLinkAPIUSA.py and see if you can add above approach, e.g. for line 536, 549, 611, 624:

                            distance=trip.distance,

[gyveri]

Thank you for thinking about this. I basically concur with your thoughts. I'll defer to your expertise in these scripts when you say the most appropriate place to generate the trip distances is in HyundaiBlueLinkAPIUSA.py
I have a suggestion: rather than reverting to distance for the oldest trip saved, could one simply save the last odometer reading from the previous data capture, and then read the saved file to get the previous odometer reading for said oldest trip? Actually, I think the distance calculation may be a bit more complicated, because you'd only have to compute the distance for those more-recent trips whose distance was not computed when the previous data captured was processed. You probably will want to look at time stamps to see whether a trip's distance has previously been computed.
Finally, I suggest that the odometer reading from the most recent trip be also used as the odometer value (col. D) in the hyundai-kia-connect-monitor spreadsheet, so that we can see tenths there too. It currently displays one decimal place that's always zero.

[ZuinigeRijder]

I have a suggestion: rather than reverting to distance for the oldest trip saved, could one simply save the last odometer reading from the previous data capture, and then read the saved file to get the previous odometer reading for said oldest trip?

hyundai_kia_connect_api is stateless, only in memory state can be stored, so no file saves/reading back possible. And also if you start the first time, you also want the odometer values to be used for the distance calculation. So I still think the distance needs to be computed with the odometer values based on the filled_trips at line 495:

        if len(trips) > 0:
            state["filled_trips"] = trips

So before these lines you could overwrite distance with the delta of odometer, so later on you do not need to take care anymore.

[ZuinigeRijder]

I have now a version running from yesterday 22:00, still running today at 12:30.

• I login only once
• thereafter I just request the data infinite with an interval of 5 minutes.
• Only when there are changes or an error is occurred, I will run summary.py and dailystats.py and summary.py will show the last error
• Once per day I will login

Unfortunately, I reach the limit of API calls, so at least for Europe the limit is NOT the number of logins:

Thu 10 Oct 22:08:01 CEST 2024: starting run_monitor_infinite.sh
20241010 22:08:24: INFO: Login using VehicleManager
20241010 22:08:43: INFO: New data added, running configured commands
Thu 10 Oct 23:08:01 CEST 2024: run_monitor_infinite.sh still running
20241011 00:03:26: INFO: Login using VehicleManager
20241011 00:03:42: INFO: New data added, running configured commands
Fri 11 Oct 00:08:02 CEST 2024: run_monitor_infinite.sh still running
Fri 11 Oct 01:08:01 CEST 2024: run_monitor_infinite.sh still running
Fri 11 Oct 02:08:02 CEST 2024: run_monitor_infinite.sh still running
Fri 11 Oct 03:08:02 CEST 2024: run_monitor_infinite.sh still running
Fri 11 Oct 04:08:01 CEST 2024: run_monitor_infinite.sh still running
Fri 11 Oct 05:08:02 CEST 2024: run_monitor_infinite.sh still running
Fri 11 Oct 06:08:01 CEST 2024: run_monitor_infinite.sh still running
Fri 11 Oct 07:08:01 CEST 2024: run_monitor_infinite.sh still running
20241011 07:53:54: WARNING: Warning: handle_trip_info Exception: Server returned:  '5041' 'Unavailable remote control - vehicle server is not connected'
Traceback (most recent call last):
  File "/home/rick/hyundai_kia_connect_monitor/monitor.py", line 355, in handle_one_vehicle
    handle_trip_info(manager, vehicle, number_of_vehicles)
  File "/home/rick/hyundai_kia_connect_monitor/monitor.py", line 336, in handle_trip_info
    manager.update_month_trip_info(vehicle.id, yyyymm)
  File "/home/rick/hyundai_kia_connect_monitor/hyundai_kia_connect_api/VehicleManager.py", line 230, in update_month_trip_info
    self.api.update_month_trip_info(self.token, vehicle, yyyymm_string)
  File "/home/rick/hyundai_kia_connect_monitor/hyundai_kia_connect_api/KiaUvoApiEU.py", line 1099, in update_month_trip_info
    json_result = self._get_trip_info(
  File "/home/rick/hyundai_kia_connect_monitor/hyundai_kia_connect_api/KiaUvoApiEU.py", line 1081, in _get_trip_info
    _check_response_for_errors(response)
  File "/home/rick/hyundai_kia_connect_monitor/hyundai_kia_connect_api/KiaUvoApiEU.py", line 129, in _check_response_for_errors
    raise APIError(
hyundai_kia_connect_api.exceptions.APIError: Server returned:  '5041' 'Unavailable remote control - vehicle server is not connected'
20241011 12:03:55: WARNING: Warning: handle_trip_info Exception: Exceeds number of requests - Exceeds Number of Requests.
Traceback (most recent call last):
  File "/home/rick/hyundai_kia_connect_monitor/monitor.py", line 355, in handle_one_vehicle
    handle_trip_info(manager, vehicle, number_of_vehicles)
  File "/home/rick/hyundai_kia_connect_monitor/monitor.py", line 336, in handle_trip_info
    manager.update_month_trip_info(vehicle.id, yyyymm)
  File "/home/rick/hyundai_kia_connect_monitor/hyundai_kia_connect_api/VehicleManager.py", line 230, in update_month_trip_info
    self.api.update_month_trip_info(self.token, vehicle, yyyymm_string)
  File "/home/rick/hyundai_kia_connect_monitor/hyundai_kia_connect_api/KiaUvoApiEU.py", line 1099, in update_month_trip_info
    json_result = self._get_trip_info(
  File "/home/rick/hyundai_kia_connect_monitor/hyundai_kia_connect_api/KiaUvoApiEU.py", line 1081, in _get_trip_info
    _check_response_for_errors(response)
  File "/home/rick/hyundai_kia_connect_monitor/hyundai_kia_connect_api/KiaUvoApiEU.py", line 128, in _check_response_for_errors
    raise error_code_mapping[response["resCode"]](response["resMsg"])
hyundai_kia_connect_api.exceptions.RateLimitingError: Exceeds number of requests - Exceeds Number of Requests.
20241011 12:08:53: WARNING: Exception: Exceeds number of requests - Exceeds Number of Requests.
20241011 12:08:53: INFO: Sleeping a minute
20241011 12:09:54: WARNING: Exception: Exceeds number of requests - Exceeds Number of Requests.
20241011 12:09:54: INFO: Exception: Exceeds number of requests - Exceeds Number of Requests.
20241011 12:09:54: INFO: New data added, running configured commands
20241011 12:13:53: WARNING: Exception: Exceeds number of requests - Exceeds Number of Requests.
20241011 12:13:53: INFO: Sleeping a minute
20241011 12:14:54: WARNING: Exception: Exceeds number of requests - Exceeds Number of Requests.
20241011 12:14:54: INFO: Exception: Exceeds number of requests - Exceeds Number of Requests.
20241011 12:14:54: INFO: New data added, running configured commands
20241011 12:18:53: WARNING: Exception: Exceeds number of requests - Exceeds Number of Requests.
20241011 12:18:53: INFO: Sleeping a minute
20241011 12:19:53: WARNING: Exception: Exceeds number of requests - Exceeds Number of Requests.
20241011 12:19:54: INFO: Exception: Exceeds number of requests - Exceeds Number of Requests.
20241011 12:19:54: INFO: New data added, running configured commands
20241011 12:23:53: WARNING: Exception: Exceeds number of requests - Exceeds Number of Requests.
20241011 12:23:53: INFO: Sleeping a minute
20241011 12:24:54: WARNING: Exception: Exceeds number of requests - Exceeds Number of Requests.
20241011 12:24:54: INFO: Exception: Exceeds number of requests - Exceeds Number of Requests.
20241011 12:24:54: INFO: New data added, running configured commands
20241011 12:28:53: WARNING: Exception: Exceeds number of requests - Exceeds Number of Requests.
20241011 12:28:53: INFO: Sleeping a minute
20241011 12:29:54: WARNING: Exception: Exceeds number of requests - Exceeds Number of Requests.
20241011 12:29:54: INFO: Exception: Exceeds number of requests - Exceeds Number of Requests.
20241011 12:29:54: INFO: New data added, running configured commands

So for me about 168 API sequences can be made, before I reach the limit. So I could run it every 10 minutes 24 hours, but safer is to use every 15 minutes, so you can still use the Bluelink App now and then.

[gyveri]

Very interesting. But I'm not surprised that the EU and US versions behave differently. The good news is that we can both do data capture every 15 minutes for 24 hours.
I've attached a copy of the terminal output from my latest run which shows over 200 data captures and some interesting exception recovery at about 22:00 yesterday.
I'm planning on adding the after midnight restart to my modified script. Can you please help me out and let me know the logoff command for the HyundaiBlueLink api? Thank you.
Terminal_output_20241011.txt

[ZuinigeRijder]

There is no logout possible in HyundaiBlueLink api. You can do a new login or exit the monitor.py and start again.

[ZuinigeRijder]

@gyveri I made a new release R4.0.0: Major update: introduction of running monitor.py infinitely. Hope this works as expected for you, it is running for some time for me in region Europe.

[gyveri]

Thank you for this upgrade. I've installed it on a different server.and it's already started to populate some of its files. I'll do a test trip in a while.

[gyveri]

Just back from test trip 40 mins, 22 miles 5 kWh consumed per the Hyundai app. Started at ~15:10, ended at ~15:50. Noticed the following:

1. Measurement interval set to 15 mins, but monitor.csv only updated at 15:54 and at 15:57
2. Measurement times are at increments of 15 mins past start time, not past the hour
3. summary.log and dailystats.log have not been created. Nor have the spreadsheets updated. Anonymized versions of .cfg files are attached.
   monitor_anon.cfg.txt
   summary_anon.cfg.txt

[ZuinigeRijder]

@gyveri Thanks for testing. I made a fix for the problem that summary.py and dailystats.py were not called: R4.0.1.

1. monitor.csv is only updated when there are new cached server values, so I think this is as expected.
2. That is correct, I do it by 15 minutes intervals after start-time.
3. see fix above.

For monitor.cfg, I have prefixed python with /usr/bin, so my configuration:

monitor_execute_commands_when_something_written_or_error = /usr/bin/python -u summary.py sheetupdate > summary.log; /usr/bin/python -u dailystats.py sheetupdate > dailystats.log

[gyveri]

Installed & running. summary.log and dailystats.log have now appeared. Will do a test drive later this morning & report.

[ZuinigeRijder]

@gyveri I have a bonus for you, calculating distance with use of odometer, if available. The delta is on top of version 3.23.8. I could only do limited testing, sure you will test better ;-)

hyundai_kia_connect_api.zip

[gyveri]

Thank you for doing this. Installed. Will test later this morning.

[gyveri]

We're making progress. Just back from 3-leg test trip, final one of which was 0.3 miles per the car end-of-trip display (which, interestingly, shows tenths).
dailystats.log and monitor.csv recorded these trips, but no tenths (final trip has distance 0).
Neither spreadsheet is updated.
run_monitor_infinite.log has an interesting error message - see below.

Mon 14 Oct 2024 02:09:01 PM PDT: starting run_monitor_infinite.sh
20241014 14:09:03: INFO: Login using VehicleManager
20241015 00:09:03: INFO: Login using VehicleManager
Tue 15 Oct 2024 08:43:06 AM PDT: run_monitor_infinite.sh exited
Tue 15 Oct 2024 08:49:20 AM PDT: starting run_monitor_infinite.sh
Traceback (most recent call last):
File "/home/pi/hyundai_kia_connect_monitor/monitor.py", line 47, in
from hyundai_kia_connect_api import VehicleManager, Vehicle, exceptions
File "/home/pi/hyundai_kia_connect_monitor/hyundai_kia_connect_api/Vehicle.py", line 9, in
from .utils import get_float, get_safe_local_datetime
ModuleNotFoundError: No module named 'hyundai_kia_connect_api.utils'
Tue 15 Oct 2024 08:49:21 AM PDT: run_monitor_infinite.sh exited
Tue 15 Oct 2024 09:00:52 AM PDT: starting run_monitor_infinite.sh
20241015 09:00:53: INFO: Login using VehicleManager
20241015 09:01:16: INFO: New data added or first run today or errors, running configured commands
20241015 09:30:54: INFO: New data added or first run today or errors, running configured commands
20241015 11:00:58: INFO: New data added or first run today or errors, running configured commands
20241015 11:15:54: INFO: New data added or first run today or errors, running configured commands
20241015 11:31:08: INFO: New data added or first run today or errors, running configured commands
20241015 11:45:54: INFO: New data added or first run today or errors, running configured commands

[ZuinigeRijder]

The first error is a strange one, because this is a compile error. It could not find ~/hyundai_kia_connect_monitor/hyundai_kia_connect_api/utils.py

You see also that this was a crash:

Tue 15 Oct 2024 08:49:21 AM PDT: run_monitor_infinite.sh exited

But you have started the script again exactly at 9:00, so then it compiles OK and does not have a problem?????

Tue 15 Oct 2024 09:00:52 AM PDT: starting run_monitor_infinite.sh
20241015 09:00:53: INFO: Login using VehicleManager

Was this the first time you did run the scripts on this machine?

I looked at the source code if HyundaiBlueLinkAPIUSA.py and at line 499 the float is converted to int. So that is the cause why the digits do not show up. Note that I changed in Vehicle.py distance from int to float, so still I could have missed some places, although I think monitor.py is already prepared for distance: float. See below the next fix.

hyundai_kia_connect_api.zip

[gyveri]

New version installed. Will be taking a trip later this morning. Let's hope we see tenths and the spreadsheets updating. I'm assuming that monitor_execute_commands_when_something_written_or_error = /usr/bin/python -u summary.py sheetupdate > summary.log; /usr/bin/python -u dailystats.py sheetupdate > dailystats.log updates the spreadsheets automatically when the .logs are updated.
Regarding timing - I think it was a coincidence that I started the script more or exactly on the hour on 10/15. Today, crontab started the modified script at about 8:09 and it's run again at 8:39.

[ZuinigeRijder]

Yes, fingers crossed.

[gyveri]

Here's an update after my 2 trips this morning:
Today's entries in dailystats.log, monitor.dailystats.csv and monitor.tripinfo.csv show tenths:
2024-10-16 Recuperation Consumption Engine Climate Electr. Batt.Care
6.5kWh 3.2kWh 2.9mi/kWh 2.6kWh 0.4kWh 0.3kWh 0kWh
18.9mi 49.6% 34.4kWh/100mi 40% 5.7% 4.5% 0%
Trip (5.1mi/kWh) Distance Avg mi/h Max mi/h Idle
(1.5kWh) 10:59-11:27 (6.7mi/kWh) 9.4mi 19mi/h 41mi/h 2min
(2.2kWh) 09:28-09:52 (4.1mi/kWh) 9.5mi 23mi/h 68mi/h 1min

20241016 09:28, 9.5, mi, 1654, 1910, 1257, 267, 130, 0
20241016 10:59, 9.4, mi, 1619, 1312, 1359, 100, 160, 0

20241016,092843,24,1,9.5,23,68
20241016,105912,28,2,9.4,19,41

But ...
Today's entries in monitor.csv, summary.log and monitor.lastrun don't have tenths:
2024-10-16 08:09:17-07:00, -121.90629166666666, 36.97326388, False, 81, 5759, 66, False, 0, 180;
2024-10-16 08:25:38-07:00, -121.90629166666666, 36.97326388, False, 80, 5759, 66, False, 0, 180;
2024-10-16 10:09:20-07:00, -122.02733611111111, 36.96662777, False, 80, 5768, 63, False, 0, 8
2024-10-16 10:16:06-07:00, -122.02733611111111, 36.96662777, False, 81, 5768, 63, False, 0,
2024-10-16 11:39:03-07:00, -121.90629444444444, 36.97325833, False, 81, 5778, 63, False, 0,
2024-10-16 11:51:22-07:00, -121.90629444444444, 36.97325833, False, 81, 5778,

TRIP, 2024-10-16, 10:09, 5768.0, 9.0, , -2.2, 4.0, 24.9, 0.55, 63, 66, 63, 66, 80, 80, 80, 81, , 1,
TRIP, 2024-10-16, 11:51, 5778.0, 10.0, , -1.5, 6.7, 14.9, 0.37, 61, 63, 61, 63, 81, 82, 80, 81, , 1,

last run ; 2024-10-16 13:54 Wed
vin ; KM8KR4DE5RU271472
vehicle update; 2024-10-16 11:51:22-07:00
gps update ; 1999-12-31 16:00:00-08:00
2024-10-16 11:51:22-07:00, -121.90629444444444, 36.97325833, False, 81, 5778, 61, False, 0,

Today's entries in summary.trip.csv and summary.day.csv have tenths, but they are all zero
2024-10-16 10:09, 5768.0, 9, -2.2, 0
2024-10-16 11:51, 5778.0, 10, -1.5, 0

2024-10-16, 5778.0, 19, -3.7, 0

It's not clear to me whether these differences are what you intended, or if there are still some ints lurking there that should be floats

And the spreadsheets are not updating - last update was on Monday when I ran the first version of the new scripts..

[ZuinigeRijder]

And the spreadsheets are not updating - last update was on Monday when I ran the first version of the new scripts

For me it is working. There was a problem in R4.0.0 that indeed the commands were not run. This has been fixed already in R4.0.1. Also the run-once was no longer working. That has been fixed R4.0.2. For both only monitor.py has been updated. Did you not use R4.0.1 or R4.0.2????

It's not clear to me whether these differences are what you intended, or if there are still some ints lurking there that should be floats

When the odometer and/or distance is 0, in most cases it will not show those .0 in the output. monitor.csv shows only odometer. But it is NOT the odometer from the dailystats, it is the odometer from other calls to the Bluelink server. If I check the debug.py output of the log-files you did send me, I see that there the odometer is NOT in one-tenth, e.g.:

"vehicleDetails":
            {
                "svrStatus":"NONE",
...
                "trim":"LIMITED",
                "modelCode":"IONIQ 5",
                "sideMirrorHeatCapable":"YES",
                "ownersuccession":"1",
                "odometer":"5019",

Trip in formation of summary.py is computed from the odometer values in monitor.csv. For example 5778.0 - 5768.0 is exactly 9.0.

Only dailystats.py is using the new overruling mechanism for distance and also only for HyundaiBlueLinkAPIUSA.py. You are lucky there, because the odometer value IS in one-tenth miles, so I could make this workaround of distance. So in monitor.dailystats.csv you should see the delta's in one-tenth miles.

Thinking about this, there could be also a workaround for the regular odometer to have this in one-tenths. When getting the dailystats information, overwrite the odometer value if this is greater than the Vehicle._odometer value. I am not sure if the odometer is rounded off or truncated, otherwise the odometer needs always to be overruled with the last trip instead of only of greater than.

I am sure you will test this extra feature workaround.

HyundaiBlueLinkAPIUSA.zip

[gyveri]

Thank you for that suggestion - that was the problem, caused by my running the latest versions on a different Raspberry Pi server. I added the client email for this server, ran summary.py and dailystats.py and now the spreadsheets are updated with the latest data.
I'll now leave things running on this server for a few days to see what happens when Hyundai's access limit is exceeded.
BTW, is there any chance that you might add the ability for the user to set the number of minutes past the hour that the first measurement in the hour takes place? This could be an additional parameter in monitor.cfg right after the setting for the measurement interval.

[ZuinigeRijder]

Actually you can already control that, by the crontab. For example, checking if it is still running or starting the first time at 9 minutes past the hour:

9 * * * * ~/hyundai_kia_connect_monitor/run_monitor_infinite.sh >> ~/hyundai_kia_connect_monitor/crontab_run_monitor_infinite.log 2>&1

Make sure you have copied the example run_monitor_infinite.sh to ~/hyundai_kia_connect_monitor and made executable (chmod +x).

Of course you need to kill already running scripts once before the crontab does its work at the right time.....monitor.py takes care of the sleep time, so if the measurement interval is 15 minutes, the next measurement will be at exactly 24 minutes, and so on.

[gyveri]

Yes, good point. Because I often finish working on these scripts shortly before I go somewhere in the car, I have been starting the shell script manually, rather than waiting for crontab to start it at 9 past the hour.
Is there anything special about 9 minutes past the hour, or can it be changed?

[ZuinigeRijder]

yes, it was just an example, you can put in 0 to 59 minutes, whenever you want to start it. I try to keep others scripts running at different timing, because I have a slow old Raspberry Pi from 2012 with only 2 MB memory. But still manage to run other scripts, like sending 2 times solar inverter data to PVOutput and reading out powermeter readings.

[gyveri]

Thanks. I understand why you want to run the crontab at that particular time. I'm impressed that you can run so many apps on one RPi. I have your app, my Powerwall app and my solar monitor app all running on their own RPis.

[gyveri]

Took a couple of longish trips. The hyundai-kia-connect-monitor spreadsheet, monitor.csv and summary.log are all updated with the new info. The dailystats spreadsheet and monitor.dailystats.csv are not (the latest info they have is for 1018, the day on which I previously drove the car. crontab_run_monitor_infinite.log looks normal, but there's a lot going on in run_monitor_infinite.log (copy attached)
Do you have any suggestions?
run_monitor_infinite.log

[gyveri]

I'm impressed by the way your exception handling is working to keep the script running.
I rebooted and started using crontab. The hkcm spreadsheet has today's data, ddailystats is still stuck on 10/18 i.e. the 18th of October.
Requested files are attached.
monitor.dailystats.csv

[ZuinigeRijder]

I removed the Thonny output from your post, because it might contain sensitive data. But the response of the trip details does NOT give data after 2024-10-18 15:37:34.0.

DEBUG:hyundai_kia_connect_api.HyundaiBlueLinkAPIUSA:hyundai_kia_connect_api - get_ev_trip_details response 
{
    'tripdetails': 
    [
        {
            'distance': 0,
             'odometer': 
            {
                'value': 5794.7
            },
             'accessories': 20,
             'totalused': 26,
             'realtotalpwrcsp': 0,
             'regen': 0,
             'avgspeed': 
            {
                'unit': 1,
                 'value': 0.0
            },
             'maxspeed': 
            {
                'unit': 1,
                 'value': 0.0
            },
             'climate': 6,
             'drivetrain': 0,
             'startdate': '2024-10-18 15:37:34.0',
             'mileagetime': 
            {
                'unit': 3,
                 'value': 0.0
            },
             'duration': 
            {
                'unit': 3,
                 'value': 62
            },
             'batterycare': 0
        },
        {
            'distance': 0,
             'odometer': 
            {
                'value': 5794.7
            },
             'accessories': 20,
             'totalused': 23,
             'realtotalpwrcsp': 0,
             'regen': 0,
             'avgspeed': 
            {
                'unit': 1,
                 'value': 0.0
            },
             'maxspeed': 
            {
                'unit': 1,
                 'value': 0.0
            },
             'climate': 3,
             'drivetrain': 0,
             'startdate': '2024-10-18 11:25:12.0',
             'mileagetime': 
            {
                'unit': 3,
                 'value': 0.0
            },
             'duration': 
            {
                'unit': 3,
                 'value': 39
            },
             'batterycare': 0
        },
        {
            'distance': 0,
             'odometer': 
            {
                'value': 5794.7
            },
             'accessories': 30,
             'totalused': 94,
             'realtotalpwrcsp': 0,
             'regen': 178,
             'avgspeed': 
            {
                'unit': 1,
                 'value': 13.0
            },
             'maxspeed': 
            {
                'unit': 1,
                 'value': 26.0
            },
             'climate': 7,
             'drivetrain': 57,
             'startdate': '2024-10-18 11:21:24.0',
             'mileagetime': 
            {
                'unit': 3,
                 'value': 134.0
            },
             'duration': 
            {
                'unit': 3,
                 'value': 196
            },
             'batterycare': 0
        },
        {
            'distance': 0,
             'odometer': 
            {
                'value': 5794.2
            },
             'accessories': 40,
             'totalused': 285,
             'realtotalpwrcsp': 0,
             'regen': 283,
             'avgspeed': 
            {
                'unit': 1,
                 'value': 16.0
            },
             'maxspeed': 
            {
                'unit': 1,
                 'value': 29.0
            },
             'climate': 66,
             'drivetrain': 179,
             'startdate': '2024-10-18 11:13:58.0',
             'mileagetime': 
            {
                'unit': 3,
                 'value': 253.0
            },
             'duration': 
            {
                'unit': 3,
                 'value': 321
            },
             'batterycare': 0
        }
    ]
}

Can you check with the Bluelink App if the trip data is shown there?
You can also try a refresh inside the Bluelink App, see if this gives after the next run the new data.
Another possibility is that the car has a Bluelink issue or no mobile coverage, so it cannot send the data to the Bluelink server.

Sometimes people here in Europe complain about this and this is often the solution (probably not everything will be exactly the same for the USA version):

Fix Strange Bluelink Problems:

a) Live services are not accessible (voice control, traffic information, live charging stations, etc.). This can happen, for example, if the Bluelink conditions have changed, you did not see the new conditions when starting the car, or you deliberately did not confirm them because you did not have time to read them. Then in Settings, Bluelink, confirm both the Terms of Use and Privacy Policy. But it can also happen that the mobile modem is hung up. To do this, simply reset the infotainment with a small pointed object in the small hole to the right of the passenger temperature display. This is a "soft reset", all settings are retained.

b) Valet mode activated via app can no longer be deactivated or a message in the car that a function does not work because a service has been deactivated. To fix this, click "More" in the bottom right corner of the Bluelink app and select "Service List". Then change/deactivate and save the status of one of the switches (e.g. info services) and then reset/activate and save again.

[gyveri]

I checked the Blue link app. It shows the 2 trips I made today and the two zero-distance trips I made the afternoon of Friday 10/18 as I was adjusting the maximum charge level to make sure I had enough charge to do the trips planned for the weekend.
After I returned from today's trips, the dailystats spreadsheet updated to show these two trips. So it looks like rebooting the script has caused things to work normally again, although the data on yesterday's trips appears to have vanished for ever.
Thankyou once again for your most helpful suggestions. I'll keep you posted.
Meanwhile, how do I get the graphs you show on the website to appear in my spreadsheets?

[gyveri]

Yesterday, at a location with a strong signal, I exited the Bluelink app, restarted my iPhone and, with key on, did the small pointed object reset. The app is still not showing data for any trips taken after my trip to the gym on Monday 10/21, although odometer, SOC and range are current. I even stopped running monitor.py last evening, but still no trip data. I was not able to try doing b) above, because the Bluelink app on my phone doesn't have a Service List or anything that looks like one. I've now restarted monitor.py. And anyway, the app shows that valet mode is off. Very puzzling.

[gyveri]

On Friday, since the EV Trip Details in the app had not updated since Monday 10/21, I went into the Hyundai virtual assistant in the app and asked why my EV Trip Details were not updating. I never heard anything back, but on Sunday afternoon, when I got home after a 160-mile round trip, I noticed that the app showed a single 414.5-mile trip, i.e., the sum of distance of all the trips I've taken since EV Trip Details stopped updating on 10/21. Today, this trip and the 3 trips I took today showed up on the monitor.dailystats spreadsheet.
So it looks like problem solved, at least for now. Thanks for all your help in trouble-shooting this issue.

[ZuinigeRijder]

I do not think rebooting the script made to cause things to work normally, because debug.py did also NOT show the data. Probably the checking the data/refresh of the Bluelink App caused that the car values were retrieved by the server?

I have an example spreadsheet with those graphs. Of course you can add/change graphs with Google Spreadsheet yourself too. Here is the example spreadsheet with the graphs, as described in the README.

Remove your old monitor.dailystats spreadsheet. Make a copy (File-> Copy) of that example spreadsheet with the name monitor.dailystats AND share it with the client_email. Then those graphs should appear after new data has been added. You can also run dailystats.py manually once to populate your data.

[gyveri]

My dailystats spreadsheet is now displaying graphs. Thank you.
You were correct in saying that rebooting the script was not what caused things to work normally. Things worked normally on Monday Oct 21 (although the first trip of the day included the 100 or so miles that were not registered on Sunday Oct 20). But the trips I did yesterday 10/23 are shown in monitor.csv but do not appear in dailystats.log. And the detailed trip info doesn't appear in EV Trip Details in the BlueLink app. The car is generating trip info, because it displays trip info at key off at the end of each trip, but it appears that the trip info is not getting into Bluelink, even though Bluelink is getting such things as the odometer, range and SOC info that get captured by monitor.py.
I tried restarting the Bluelink app, and when that didn't work, tried restarting my iPhone and then starting the Bluelink app without success. I ran debug.py just now and the trip info therein corresponds to that in the Bluelink app, i.e., trip info for 2 trips on 10/18, 2 trips on 10/21 and no trips yesterday. I guess that this means that the trip info is not getting from the car to the Bluelink server, or the Bluelink server is not accepting the trip info. The mobile phone signal is not strong in my garage, but this has not been an issue in the past (From what I've read, Hyundai uses Verizon as its mobile carrier, which is the same carrier as my phone). But I'll go and park for a while somewhere where the signal is stronger to see if that makes a difference.
Do you have suggestions of other things to try?

[ZuinigeRijder]

Probably you want to do these steps when there is good reception, so not in the garage, till one of them works.

1. Do a soft reset of the infotainment (just press the dot near the P of the parking sensors buttons with a pen). Turn the car thereafter completely off.

2. Inside the Bluelink App, do a refresh of the car status and also check the location of the car.

The following is how it works in Europe in the Bluelink App, maybe this is somewhat different in USA:
3. Click on “More” at the bottom right of the Bluelink app and select “Service list”. Then change/deactivate the status of one of the switches (e.g. information services) and save and then reset/activate it again and save again. However, if the car does not have a correct connection to the Bluelink services, please switch Bluelink offline and online again in the car under Settings/Bluelink.

And as last resort, you can detach the minus pool of the 12 volt battery for a minute:
4. Turn the car off completely, open the hood, open the front trunk lid, carefully pry open the 12 V battery cover, use a 10 mm wrench to remove the negative pole to disconnect the 12 V battery, wait a minute, reattach the negative pole, put the cover back on and close both flaps again, get in, start with the brake on, wait for READY. And then turn off.

[gyveri]

On Friday, since the EV Trip Details in the app had not updated since Monday 10/21, I went into the Hyundai virtual assistant in the app and asked why my EV Trip Details were not updating. I never heard anything back, but on Sunday afternoon, when I got home after a 160-mile round trip, I noticed that the app showed a single 414.5-mile trip, i.e., the sum of distance of all the trips I've taken since EV Trip Details stopped updating on 10/21. Today, this trip and the 3 trips I took today showed up on the monitor.dailystats spreadsheet.
So it looks like problem solved, at least for now. Thanks for all your help in trouble-shooting this issue.

[ZuinigeRijder]

Good to hear that it is working again. Probably this was just a problem with the Bluelink server software from Hyundai, which they fixed. The question is now: are the changes of me to the hyundai_kia_connect_api for better accuracy of miles working well enough?

If yes, I can make a Pull Request for that, so other USA Bluelink users can also benefit from that.

[gyveri]

Yes, it appears that the changes you made to show tenths of a mile are working well, so this would be a good time to do another pull request.
I wonder if the trip data from the Hyundai server can be used in a similar way to generate tenths for the SoC. As you say, a 1% SoC change represents a lot of power.

[ZuinigeRijder]

I made a Pull Request for the one-tenths of a mile. The other question I have to think about longer.

[ZuinigeRijder]

I wonder if the trip data from the Hyundai server can be used in a similar way to generate tenths for the SoC. As you say, a 1% SoC change represents a lot of power.

The trip data of the Hyundai Server does not return SOC%, only kWh used.
monitor.csv is getting the latest SOC% from the Hyundai Server and stores it as-is: vehicleStatus.battery.batSoc
Unfortunately this is a whole number for USA, also here in Europe.