search

aesculus / EVTO-App-Feedback

A project to track bugs and ideas for the EVTO App
MIT License
1 stars 0 forks source link

Trip Browser: Elapsed time for trip in summary section incorrect #446

Closed EVGrokker closed 7 years ago

EVGrokker commented 7 years ago

Car Data: X90D, Charger: 48, Wheels: 20, Tires: 0, Pano: 0, 5 Seat: 1, Rear CC: 0, Bat Life: 100, Payload: 100, PF: 6, SA: 0, Temp: 20 Device Info: iPhone; CPU iPhone OS 10_3_2 like Mac OS X Settings: Reserve SoC:20, Default SoC: 90, Region: 0, Units: 0 Version: 1.2.0 (37) IAP: Pro:1, Sub:1 Location: Unknown Trip: Oxford Suites Portland - Jantzen Beach, [1l60p8sw41jg2wyk3q0ndw]

This trip from Seattle WA to Portland is 167 miles, with an elapsed time estimate of 2:42.

The summary section shows an elapsed time 1d 2:41. It should be 2:42.

aesculus commented 7 years ago

Rounding error. The date plugin decided not to round anymore but drop to nearest 0. So I had to add rounding to the nearest minute in V 1.2 (38)

EVGrokker commented 7 years ago

v 1.2.0 (38)

Still incorrect. See attached screenshot.

tripbrowser

aesculus commented 7 years ago

Ah the 1 d

Before the times did not match. Another problem.

aesculus commented 7 years ago

Fixed in V1.2 (39)

EVGrokker commented 7 years ago

v 1.2.0 (39) Even after viewing individual segments in a multi-segment trip, the elapsed time summary is not correct - it only shows the elapsed time of the last segment.

aesculus commented 7 years ago

That was not my experience. Can you share thE exact trip?

EVGrokker commented 7 years ago

Car Data: X90D, Charger: 48, Wheels: 20, Tires: 0, Pano: 0, 5 Seat: 1, Rear CC: 0, Bat Life: 100, Payload: 100, PF: 0, SA: 0, Temp: 20 Device Info: iPhone; CPU iPhone OS 10_3_2 like Mac OS X Settings: Reserve SoC:20, Default SoC: 90, Region: 0, Units: 0 Version: 1.2.0 (39) IAP: Pro:1, Sub:1 Location: Unknown Trip: Sand Dollar Inn & Cottages, [uaqu4d3xszndobadq7ayp]

Car Data: X90D, Charger: 48, Wheels: 20, Tires: 0, Pano: 0, 5 Seat: 1, Rear CC: 0, Bat Life: 100, Payload: 100, PF: 0, SA: 0, Temp: 20 Device Info: iPhone; CPU iPhone OS 10_3_2 like Mac OS X Settings: Reserve SoC:20, Default SoC: 90, Region: 0, Units: 0 Version: 1.2.0 (39) IAP: Pro:1, Sub:1 Location: Unknown Trip: Bend OR, [hhwwdeesie5zhfh4juj6h]

Car Data: X90D, Charger: 48, Wheels: 20, Tires: 0, Pano: 0, 5 Seat: 1, Rear CC: 0, Bat Life: 100, Payload: 100, PF: 0, SA: 0, Temp: 20 Device Info: iPhone; CPU iPhone OS 10_3_2 like Mac OS X Settings: Reserve SoC:20, Default SoC: 90, Region: 0, Units: 0 Version: 1.2.0 (39) IAP: Pro:1, Sub:1 Location: Unknown Trip: Grants Pass Supercharger, [tt2ddao9i0j82riyqiz88c]

aesculus commented 7 years ago

The problem lies not in my perfect algorithm for the Trip Browser elapsed time, but in the default segment start time algorithm. These trip segments all start at the same date and time.

So we need to figure out how to keep that from happening.

aesculus commented 7 years ago

If you look at your trip note they all reflect starting June 14th at 8am

If I adjust each one to start the next day this is what you see:

image

aesculus commented 7 years ago

But this begs a question: I am showing elapsed trip time, not elapsed travel time. Should it be travel time? If so the whole day thing should go away.

EVGrokker commented 7 years ago

In my opinion, elapsed time should represent the door-to-door time. It is the difference between the 'Start' and 'End' time. It's how long, in real time, it will take me to get from A to B.

aesculus commented 7 years ago

OK. The that is what we have.

Now to figure out how to fix the segment start dates. Did you change these at all? Were these the default dates/times? I have not looked at the code but I suspect I screwed up and forgot to add a day to the segment start time.

Most importantly before I go into the code let's decide what SHOULD happen in these cases:

EVGrokker commented 7 years ago

I did not edit the start times. They are the defaults.

Some time ago, my recollection is that we agreed to start new segments by default the following day at the default start time. Changing an upstream date or time should ripple everything with the same relative offset. For example, if they changed their segment 1 departure time from 8am to 9am, and segment 2's departure time previously was 8am, it would ripple to 9am to maintain the 24 hour delta.

If user segments at a charging stop, to me that means they're thinking "I'm going to spend the night nearby. I'll figure out where later, but it doesn't matter to EVTO, since my charging will be done at the SC." In that case, you still would set the next segment to depart the following day at the default time.

If user segments at a non-charging stop, again, the next segment starts the next day at the default departure time.

The simple rules would be:

aesculus commented 7 years ago

I will look at the code. This is how I thought it was set-up but I suspect the day add thing got dropped or is not working as designed. At least the start time was correct. :-)

aesculus commented 7 years ago

This has now been fixed. Any segmentation will start the next day at the default start time. Any further segments will be pushed down accordingly. Applied in V1.2 (40)

I changed the behavior of issue #97 to be consistent here. In the case of extending a segment the model used to just start right after the current segments arrival time. Now it is a day later.

See issue #463 for a discussion on a possible alteration of this feature.

EVGrokker commented 7 years ago

Car Data: X90D, Charger: 48, Wheels: 20, Tires: 0, Pano: 0, 5 Seat: 1, Rear CC: 0, Bat Life: 100, Payload: 100, PF: 0, SA: 0, Temp: 20 Device Info: iPhone; CPU iPhone OS 10_3_2 like Mac OS X Settings: Reserve SoC:20, Default SoC: 90, Region: 0, Units: 0 Version: 1.2.0 (40) IAP: Pro:1, Sub:1 Location: Unknown Trip: Sand Dollar Inn & Cottages, [t8dak6ubyue5grm8p5fyf7]

Not fixed in 1.2.0 (40).

This is a round trip from Seattle to Moclips WA. The segments both start at 8am on 6/15.

aesculus commented 7 years ago

I swear I tested this but just tried it again and it did not work correctly. What it is doing is not starting the next day but right after the arrival time. And on top of that it has the 'update' issue so you actually get an invalid date when looking at the Trip Browser.

aesculus commented 7 years ago

This was hidden in another place. It now starts the day after arrival of the first segment at the default start time in V1.2 (41)