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
Local communications on Pietro Fiorentini RSE gas meters do not use the system title in general-glo-ciphering APDU.
It is questionable if this is correct behaviour but we need to be pragmatic and solve it.
The system title is till used for the ciphered text, otherwise the encryption is not done correctly.
GeneralGlobalCiphering APDU is created in DlmsConnection.protect() and it would be possible to omit the system title but there also needs to be changes in the APDU class to allow for system_title=None and to encode it correctly into the byte representation.
This should not be default behaviour and we should introduce an optional argument to the DlmsConnection that handles complext settings for the connection. This could also adress the problem in #70
The more meters we aim to support the the more special cases we will find and it is better to have a serialziable object so we can easily transfer the settings in different environments and use cases.
Some manufacturers have spacial cases in the communication. To handle all these differences the settings object is introduced so it can be serialized and documented.
Also added support for first settings to suppoirt Fiorentini meters.
Fixes#72
Local communications on Pietro Fiorentini RSE gas meters do not use the system title in
general-glo-ciphering
APDU.It is questionable if this is correct behaviour but we need to be pragmatic and solve it.
The system title is till used for the ciphered text, otherwise the encryption is not done correctly.
GeneralGlobalCiphering APDU is created in
DlmsConnection.protect()
and it would be possible to omit the system title but there also needs to be changes in the APDU class to allow forsystem_title=None
and to encode it correctly into the byte representation.This should not be default behaviour and we should introduce an optional argument to the DlmsConnection that handles complext settings for the connection. This could also adress the problem in #70
The more meters we aim to support the the more special cases we will find and it is better to have a serialziable object so we can easily transfer the settings in different environments and use cases.
For example
The text was updated successfully, but these errors were encountered: