You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today, we encountered an issue where alphanumeric transactionIds are not supported by the transparenzsoftware. This brings up a question regarding whether this is intended behavior or if it's considered a bug.
With the adoption of OCPP 2.0.1, the transactionId is now - as far as I know - represented as a UUID, resulting in an alphanumeric string rather than a numeric one. This marks a departure from the previous numeric representation.
Could you clarify whether the lack of support for alphanumeric transactionIds is a bug or a deliberate design choice? Additionally, we are curious to know if there are any plans to address this in a future release.
Thank you for your attention to this matter.
The text was updated successfully, but these errors were encountered:
If fact OCPP defines it as an identifierString of a length up to 36 characters.
An identifierString is a case-insensitive data type and can only contain characters from the following character set: a-z, A-Z, 0-9, '*', '-', '_', '=', ':', '+', '|', '@', '.'
Today, we encountered an issue where alphanumeric transactionIds are not supported by the transparenzsoftware. This brings up a question regarding whether this is intended behavior or if it's considered a bug.
With the adoption of OCPP 2.0.1, the transactionId is now - as far as I know - represented as a UUID, resulting in an alphanumeric string rather than a numeric one. This marks a departure from the previous numeric representation.
Could you clarify whether the lack of support for alphanumeric transactionIds is a bug or a deliberate design choice? Additionally, we are curious to know if there are any plans to address this in a future release.
Thank you for your attention to this matter.
The text was updated successfully, but these errors were encountered: