Unnecessary automatic charging stop added

[EVGrokker]

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 shows a charging stop in Centralia with no added SoC. The arrival and departure SoC are both 57%.

[EVGrokker]

Here's another trip showing the same behavior, adding an unnecessary charging stop:

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: Fess Parker Inn, [w6ccxm7jsjpq31fhli2wmr]

I created a New Trip (Seattle - Fess Parker [HPWC]). I was going to do my normal pin and segment to chop it up, but I noticed that EVTO calls for a stop at Centralia with no charging (62>62), and the pin is colored in gray. What does a gray pin mean in this context?

[EVGrokker]

After posting the previous comment, I optimized and Centralia now shows a charging pin in green, from 58>72.

[aesculus]

What does a gray pin mean in this context?

A gray auto pin means that the server thought you needed to stop there but the app felt differently and did not want to use it after it did it's calcs.

Now you might want to know why this happens:

• One reason is that the server may have only had two data points to start with (origin and destination). The app used that to try to determine the efficiency you would have during the trip. After optimizing, new waypoints were added and the efficiency was more refined. In the case of the gray pin you were probably on the edge and the more granular model eliminated the need for that stop. There is less and less of this now with the new models but it can happen occasionally.

• You make a change in the trip segment (date/time, add/delete waypoint. speed adjust, power factor ...) and now the efficiency is different. This can result in you not having enough energy for the next stop (a green turns to yellow or red) or the opposite, a green turns into a gray - no longer needed.

• You have not calculated the segment. This is the next issue I will have to deal with once the optimization is firm. The dreaded 'visiting the segments in order' thing.

• Learning, which is sort of related to the first bullet. The app will refine it's estimates based on the prior pass. It's efficiency estimate is more refined. If you were on the edge before this can happen. Note this is not unlike you getting an arrival SoC that is slightly higher or lower than what you have set. The particular case just happens to negate the need to stop vs changing the SoC by a few %. You would never notice the few % arrival SoC changing if it did not force a color change in the pin.

The only way to eliminate this would be to make two passes, This would eat up a lot of time and also cause me to double the Google hits I want to reduce. Since this rarely happens now I don't think it's worth the overhead to eliminate it.

How to deal with it:

• Ignore it but then you have this stop you don't need or want, and that in itself is inefficient and wrong from a routing perspective
• Let the user delete these when they see them, knowing if they optimize they could reappear.
• Reoptimize - the server will get a more refined set of efficiencies between waypoints and may no longer need the charger - this sounds like your case above

[EVGrokker]

I can't remember seeing it before. Let's see how frequently it occurs as you continue refining the server algorithms.