Closed EVGrokker closed 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)
v 1.2.0 (38)
Still incorrect. See attached screenshot.
Ah the 1 d
Before the times did not match. Another problem.
Fixed in V1.2 (39)
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.
That was not my experience. Can you share thE exact trip?
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]
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.
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:
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.
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.
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:
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:
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. :-)
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.
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.
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.
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)
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.