In https://github.com/EVerest/everest-demo/issues/64 we experimented with getting an end to end demo of departure time to work. We hoped to cover the following scenarios. However the hookup between the OCPP side and the ISO side is clunky and only appears to support setting a single limit at a time (and thus, returning a single SASchedule at a time). So we are scaling down initial demo, and creating this new issue for plumbing through multiple schedule periods and potentially, multiple SASchedules sent in ISO 15118-2
High level scenario using AC L2:
Grid -> CSMS sends two separate charging profiles to the station
10A or 2.4 kW starting an hour before the start of the demo and running for 4 hours
20A or 4.8 kW starting 5 hours later and running for another 4 hours
32A or 7.680 kW starting 10 hours later and running for another 12 hours
EV plugs in with a requested departure time of 7 hours and requested energy of 16kWh (~ 2.4 * 7)
EVSE returns a single SA schedule with 10A for 8 hours
EV plugs in with a requested departure time of 6 hours and requested energy of 21kWh (~ 2.4 3 + 4.8 3)
EVSE returns two SA schedules (10 A for 3 hours and 15 A for 3 hours)
EV plugs in with a requested departure time of 16 hours and requested energy of 85kWh [1]
EVSE returns three SA schedules (10 A for 3 hours, 20 A for 4 hours, 28 A for 9 hours)
(0.24 10) 3 + (0.24 20) 4 + (0.24 28) 9 = 86.88
3 + 4 + 9 = 16
(bonus, if we have time) EV plugs in with a requested departure time of 4 hours and requested energy of 21kWh
EVSE returns zero SA schedules (is this what should happen? not super clear from the spec)
[1] This is a real-life example from our recent trip to Arcata. We got to the hotel at around 8pm with a Tesla that was almost empty. We wanted to walk to a concert the next morning (9am - 11am) and then leave at noon rather than deal with parking at the concert venue. The hotel had validated parking in the public lot, but the charger was not smart, and there was no communication between the network and the hotel - the validated permit was a piece of paper to put on the windshield. So we got a notification at around 6am indicating that we would start getting charged for parking since the charging was complete. In this case, the fast charging was actually bad - my husband had to run down to the lot and move the car right after he woke up.
In https://github.com/EVerest/everest-demo/issues/64 we experimented with getting an end to end demo of departure time to work. We hoped to cover the following scenarios. However the hookup between the OCPP side and the ISO side is clunky and only appears to support setting a single limit at a time (and thus, returning a single SASchedule at a time). So we are scaling down initial demo, and creating this new issue for plumbing through multiple schedule periods and potentially, multiple SASchedules sent in ISO 15118-2
High level scenario using AC L2:
[1] This is a real-life example from our recent trip to Arcata. We got to the hotel at around 8pm with a Tesla that was almost empty. We wanted to walk to a concert the next morning (9am - 11am) and then leave at noon rather than deal with parking at the concert venue. The hotel had validated parking in the public lot, but the charger was not smart, and there was no communication between the network and the hotel - the validated permit was a piece of paper to put on the windshield. So we got a notification at around 6am indicating that we would start getting charged for parking since the charging was complete. In this case, the fast charging was actually bad - my husband had to run down to the lot and move the car right after he woke up.