At least the BE and the NL DSMR devices use MBUS.
Therefore we make the MBUS obis reference generic, and convert the V5
telegram to use MBUS values.
Finally set self.maxDiff = None to have a full test output on some
tests.
Sometimes peak usage is not yet visible in the 13 months history code.
It gives a 0.0kW value with timestamp (632525252525W).
Also the peak usage value can be invalid, handle this case also.
* fix index offset for month timestamp in BELGIUM_MAXIMUM_DEMAND_13_MONTHS
* add timestamps to test case
---------
Co-authored-by: Emilio Jose Palacios Garcia <epalacio@emilio.esat.kuleuven.be>
* issue-51-telegram improved mbus device parsing; refactored TelegramParser.parse to return Telegram object which is backwards compatible with the dict result
Sometimes the timestamp in the DSMR message is invalid (when no data
read read from the mbus meter?), and then parsing fails.
Fixing this by handling the exception and returning None for invalid
timestamps. Fixes: #120
The smart meter uses the DSMR/P1 standard and embeds the data in an encrypted and authenticated "DLMS General Global Cipher" frame.
The encryption/decryption is handled by the "dlms_cosem" lib.
Test cases are included.
Adds OBIS codes for reactive energy.
In example telegrams there a few mistakes in header strings. Using '\'
in strings have special feature to add to string some non-printable
characters, for example to add new line we can add \n for tab \t etc. So
whenever we want to just print backslash as normal character we have to
add another '\' before. In short string "On\\Off" prints "On\Off" ascii
string.
In enquired telegrams there are few strings with \2 sign in header,
'/ISk5\2MT382-1000\r\n' and when we calculate CRC for whole given
telegram part of "..\2.." is interpreted as one character (value 0x02)
instead of two characters ('\', '2').
I think in a header in the example enlosed in P1 DSMR Companion Standard
/ISk5\2.. stand for printable '\' and '2' character instead of
"converted" to special '\2' character.
