Add a HexStringField parser.

[middelink]

Add a HexStringField parser which understands some DSMRs encode the equipement ids as hex strings.

For example my Dutch DSMR sends out 0-0:96.1.1(4530303639303030373138323035333231) but in reality this should be E0069000718205321 (which matches the id on the front of the unit).

[middelink]

ping?

[middelink]

more ping

[xabolcs]

Hi @middelink , thanks for adding this parser!

Would you mind changing electricity_tariff (0-0:96.14.0.255) parser to HexStringField?
From the documentation it's format is "S4, tag 9"

6.5 Representation of COSEM Data Type octet-string (tag 9)
COSEM Data Type octet-string is represented with Sn format where octets are formatted
with hexadecimal characters. Octet-string length is implicit.

1. XX Hexadecimal characters for first octet
2. XX Hexadecimal characters for second octet
3. XX Hexadecimal characters for m-th octet (m is octet-string length).
   Note: An octet string or bit string with a length of m, will result in a Alphanumeric string Sn
   with a length of n, where n is 2 times m

[xabolcs]

@glmnet , would you mind reviewing and merging this PR?
Looks like the electricity_tariff isn't just a text but a hex-encoded text.

[middelink]

@xabolcs I'm not 100% sure that would be advisable. Om my meter the value reads "0001" or "0002", which if interpreted as a hex string would become "\x00\x01" or "\x00\02", which is not a string normal humans handle well.

If anything it would require a HexIntField function, converting hex numbers to a int.

What are the values you are seeing? "3031" and "3032" ?

[xabolcs]

🤔

Meh, my values (from Hungary) don't follow the standard too, as my meter shows 0001 and 0002 too.

[15:54:07][D][uart_debug:158]: <<< "0-0:96.14.0(0002)\r\n"

It just doesn't make much sense to differ only in encoding from the standard and send an integer as a four bytes string (S4).

Sorry for the noise. 😕

[middelink]

@xabolcs no worries. Out of curiosity, what does your equipment_id string look like? 0-0:96.1.1

[xabolcs]

@middelink, its a Sanxing SX601/S12U16 (2022) from EON Hungary ... and it doesn't provide such element, just it's serial number (as the first line and in 0-0:96.1.0). 🙃

[16:28:47][D][uart_debug:158]: <<< "/AUX59903049099\r\n"
[16:28:47][D][uart_debug:158]: <<< "\r\n"
[16:28:47][D][uart_debug:158]: <<< "0-0:1.0.0(231104162850W)\r\n"
[16:28:47][D][uart_debug:158]: <<< "0-0:42.0.0(AUX1020303049099)\r\n"
[16:28:47][D][uart_debug:158]: <<< "0-0:96.1.0(9903049099)\r\n"
[16:28:47][D][uart_debug:158]: <<< "0-0:96.14.0(0002)\r\n"
[16:28:47][D][uart_debug:158]: <<< "0-0:96.50.68(ON)\r\n"

[geduxas]

According IEC standart, 0.96 are used for manufacture specific needs... So in different devices values maybe different..

[middelink]

yeah, thats why the hexstrings falls back to a normal string if the content is not "hexy" enough.