steve-community
ChargingProfilePurpose missing parameter for TxProfile
In a request from SetChargingProfile.req, when the field is set to chargeProfilePurpose TxProfile, we should have the transactionId parameter. regarding the specification Open Charge Point Protocol 1.6, edition 2 FINAL, 2017-09-28, we can see that this parameter is optional, but we must define it when a transaction is already in progress
[2,"8effebba-c4d6-4b43-96a1-eb16a7be3d9b","SetChargingProfile",{"connectorId":1,"csChargingProfiles":{"chargingProfileId":3,"stackLevel":0,"chargingProfilePurpose":"TxProfile","chargingProfileKind":"Absolute", "chargingSchedule":{"duration":160,"startSchedule":"2020-07-02T12:01:00.000Z","chargingRateUnit":"A","chargingSchedulePeriod":[{"startPeriod":0,"limit":8,"numberPhases":1},{"startPeriod":50,"limit":11,"numberPhases":1},{"startPeriod":140,"limit":16,"numberPhases":1},{"startPeriod":200,"limit":6,"numberPhases":1},{"startPeriod":240,"limit":12,"numberPhases":1}],"minChargingRate":10}}}]
[4, "8effebba-c4d6-4b43-96a1-eb16a7be3d9b", "PropertyConstraintViolation", "Validation failed: Transaction Id is empty for TxProfile", {}]
sorry, this was indeed a mistake. but the mistake is not that transaction id cannot be set for TxProfile.
TxProfile should not be there at all (in the possible values for selection), because in the current charging profile implementation we do not support setting it for a transaction. since this is a quite specific case, i could not figure out what the process and flow should be. and i had a lot of open questions. therefore, i left it out. maybe we can use this issue to talk about it.
one of the things i was not sure about is the list of sanity checks we might do. is this overengineering:
- transaction should be at the same connector id as the charging profile definition
- transaction should be ongoing (no transaction-stop yet)
- transaction's time period should overlap with transaction (startSchedule does not necessarily have to be before or after transaction-start)
or should steve allow any input and hope that the charging station handles these cases?
additional question is whether we should store this in a database table. current db schema allows to assign a profile to a connector. we probably need another table for profile->transaction mappings. but.. is this too much complexity? maybe we need to define a charging profile in a fire-and-forget fashion, since transactions a short-lived. in this case, current profile management flow is not fitting.
the list goes on and on :)
one of the things i was not sure about is the list of sanity checks we might do. is this overengineering:
* transaction should be at the same connector id as the charging profile definition
Maybe we should look at the user perspective. The charging profile purpose defines different use cases (transaction related or not). So it might be better to select this at first. Based on this we can filter for the suitable charge profile IDs. In case of ChargePointMaxProfile and TxDefaultProfile the interface offer the connector ID as an input field (as before). But in case of TxProfile only the ongoing transactions ID as a select field. So Steve could retrieve the connector ID from the transaction data.
* transaction should be ongoing (no transaction-stop yet)
OCPP 1.6 has a hint about this:
It is RECOMMENDED to check the timestamp in the StartTransaction.req PDU prior to sending a charging profile to check if the transaction is likely to be still ongoing. The StartTransaction.req might have been cached during an offline period.
* transaction's time period should overlap with transaction (startSchedule does not necessarily have to be before or after transaction-start)
Personally i would leave out such checks.
or should steve allow any input and hope that the charging station handles these cases?
Hi @goekay, I am using Steve as a test Central System to validate our Charge Point software and I need to send a TxProfile. Would it be possible to simply add a transactionId field for charging profiles? As @whichnick pointed out, that field is optional, but required when TxProfile is used. Currently I am unable to test TxProfiles...
