all pattern matching ops on ChargingPointType now cover all cases #1941
Conversation
…ding a test class is recommended.
| @@ -99,6 +99,12 @@ object ChargingPointType { | |||
| case ChargingStationCcsComboType2 => 50 | |||
| case TeslaSuperCharger => 135 | |||
| case CustomChargingPoint(_, v, _) => v | |||
| // legacy charging points (values taken from 2018 BEAM code) | |||
There was a problem hiding this comment.
@johanneshiry plz double-check the values i put in place for the legacy types, if you don't mind - both AC/DC and the KwH. i just grabbed them from the old implementation. i think it should work as expected.
There was a problem hiding this comment.
The "worse" thing about the old definitions is, that Level1 / Level2 Charging rate are not fixed defined but more of a range of installed charging capacity. Anyway the values you picked are in range or close to the definitions of Level1/2 charging. So we can keep them for now until the personal ev branch will be merged in.
|
@robfitzgerald there is scala formatiing failure: Could you please apply formatting? Thanks! |
|
test! |
|
@REASY @johanneshiry if you would be so kind to review, that would be rad 🙏 |
| @@ -99,6 +99,12 @@ object ChargingPointType { | |||
| case ChargingStationCcsComboType2 => 50 | |||
| case TeslaSuperCharger => 135 | |||
| case CustomChargingPoint(_, v, _) => v | |||
| // legacy charging points (values taken from 2018 BEAM code) | |||
There was a problem hiding this comment.
The "worse" thing about the old definitions is, that Level1 / Level2 Charging rate are not fixed defined but more of a range of installed charging capacity. Anyway the values you picked are in range or close to the definitions of Level1/2 charging. So we can keep them for now until the personal ev branch will be merged in.
| case Level1 => AC | ||
| case DCFast => DC | ||
| case UltraFast => DC | ||
| case NoCharger => AC |
There was a problem hiding this comment.
doesn't make sense as a call on NoCharger should throw an IllegalArgumentException but we can keep this anyway for now to make it work.
errors were occurring because the legacy
ChargingPointTypes were not properly "cased out" in pattern matching overChargingPointTypevalues.i also modified the ChargingPointType Regex so that it is "unanchored" and can grab occurrences of the named charging point from a row at any position. that is consistent with the design, but, now that i'm thinking about it, if a user used a reserved ChargingPointType or PricingModel name in their TAZ name, then the regex would find that. maybe we should restrict our parsing to the row/column instead of the entire row.
anyhow, this fixes the bug. perhaps additionally we should add test class(es) for the charging code.
Closes #1940.
This change is