-
Couldn't load subscription status.
- Fork 18
Description
Note: This might be either a problem in this python library or a problem in the Geotab API. I've not conducted deep enough investigation of the internals of this library or tested raw queries to the API to be sure which one it is. I do however suspect it might be a problem with the API and not just this library.
It looks like when you set the includeOverlappedTrips to True, and use a device search it for some reason also finds a trip that has an ID that matched the ID of the device, although the start and end time of that Trip is far outside the requested ones.
This has been tested against a demo database that I got created when I signed up to Geotab.
Let's examine this simple python script, using the library:
from datetime import datetime
import mygeotab
def main():
client = mygeotab.API(
username=...,
password=...,
database=...,
)
client.authenticate()
trips = client.get(
"Trip",
search={
"deviceSearch": {"id": "b1"},
"fromDate": datetime.fromisoformat("2025-07-21T00:00:00Z"),
"toDate": datetime.fromisoformat("2025-07-21T00:35:00Z"),
"includeOverlappedTrips": True,
},
)
for t in trips:
print(
f"Trip ID: {t['id']}, start: {t['start'].isoformat()}, stop: {t['stop'].isoformat()}, nextTripStart: {t['nextTripStart'].isoformat()}"
)
if __name__ == "__main__":
main()With includeOverlappedTrips set to True it prints this:
Trip ID: b1, start: 2025-07-17T22:06:04.492000+00:00, stop: 2025-07-17T23:06:04.492000+00:00, nextTripStart: 2025-08-19T13:08:40.328000+00:00
Trip ID: bD8, start: 2025-07-20T23:55:02+00:00, stop: 2025-07-21T00:03:21+00:00, nextTripStart: 2025-07-21T00:03:22+00:00
Trip ID: bD9, start: 2025-07-21T00:03:22+00:00, stop: 2025-07-21T00:20:36+00:00, nextTripStart: 2025-07-21T00:31:39+00:00
Trip ID: bDA, start: 2025-07-21T00:31:39+00:00, stop: 2025-07-21T00:54:03+00:00, nextTripStart: 2025-07-21T01:04:32+00:00
As you can see it for some reason believes the trip with id b1 (first row) should be included in the returned data, although the start/stop/nextTripStart date are all less than the fromDate I've specified. It looks like the id from the deviceSearch somehow ends up as an extra ID for a trip to include in the response.
Actually, if I change the id in the deviceSearch to b2, b3 or b4 I instead get a trip with that ID as the first one in the response:
# b2
Trip ID: b2, start: 2025-07-17T22:06:04.492000+00:00, stop: 2025-07-17T23:06:04.492000+00:00, nextTripStart: 2025-08-19T13:12:05.910000+00:00
Trip ID: b43A, start: 2025-07-20T23:36:28+00:00, stop: 2025-07-21T00:01:50+00:00, nextTripStart: 2025-07-21T00:12:00+00:00
Trip ID: b43B, start: 2025-07-21T00:12:00+00:00, stop: 2025-07-21T00:20:19+00:00, nextTripStart: 2025-07-21T00:20:20+00:00
Trip ID: b43C, start: 2025-07-21T00:20:20+00:00, stop: 2025-07-21T00:37:34+00:00, nextTripStart: 2025-07-21T00:48:37+00:00
# b3
Trip ID: b3, start: 2025-07-17T22:06:04.492000+00:00, stop: 2025-07-17T23:06:04.492000+00:00, nextTripStart: 2025-08-19T13:15:02.719000+00:00
Trip ID: b14E6, start: 2025-07-20T23:53:26+00:00, stop: 2025-07-21T00:18:48+00:00, nextTripStart: 2025-07-21T00:28:58+00:00
Trip ID: b14E7, start: 2025-07-21T00:28:58+00:00, stop: 2025-07-21T00:37:17+00:00, nextTripStart: 2025-07-21T00:37:18+00:00
# b4
Trip ID: b4, start: 2025-07-17T22:06:04.492000+00:00, stop: 2025-07-17T23:06:04.492000+00:00, nextTripStart: 2025-08-19T13:15:25.334000+00:00
Trip ID: b10B8, start: 2025-07-20T23:43:47+00:00, stop: 2025-07-21T00:04:06+00:00, nextTripStart: 2025-07-21T00:10:24+00:00
Trip ID: b10B9, start: 2025-07-21T00:10:24+00:00, stop: 2025-07-21T00:35:46+00:00, nextTripStart: 2025-07-21T00:45:56+00:00
If I change the includeOverlappedTrips to False, then there is no Trip with an ID matching the ID of the requested device. So the problem seems to occur only when the includeOverlappedTrips is enabled.
It is of course easy to filter out the extra item in our own code, but a bit sad the client is returning stuff that needs extra filtering out of unwanted data.
If anyone from Geotab side wants to check the database it's my demo databse demo_jockes_longdistance_passenger that has been used and it was generated automatically when I signed up. I think it will be deleted automatically by your system in something like 60 days minus 1-2 weeks from now.