[DSMR] unrecognized values received from the meter

logs from things discovery:

2023-04-18 20:42:24.798 [INFO ] [.discovery.DSMRMeterDiscoveryService] - There are unrecognized cosem values in the data received from the meter, which means you have values that can't be read by a channel: obis id:1-0:9.7.0, value:(00.595kVA) , obis id:1-0:10.7.0, value:(00.000kVA) , obis id:1-1:31.4.0, value:(040A)(-040A) . Please report them and your raw data as reference: /Lux5\253663629_D 1-3:0.2.8(42) 0-0:1.0.0(230418204222S) 0-0:42.0.0(53414731303330373030323433383835) 1-0:1.8.0(053800.033kWh) 1-0:2.8.0(000000.002kWh) 1-0:3.8.0(010160.785kvarh) 1-0:4.8.0(003458.784kvarh) 1-0:1.7.0(00.522kW) 1-0:2.7.0(00.000kW) 1-0:3.7.0(00.000kvar) 1-0:4.7.0(00.200kvar) 0-0:17.0.0(027.6kVA) 1-0:9.7.0(00.595kVA) 1-0:10.7.0(00.000kVA) 1-1:31.4.0(040A)(-040A) 0-0:96.3.10(1) 0-1:96.3.10(0) 0-2:96.3.10(0) 0-0:96.7.21(00054) 1-0:32.32.0(00011) 1-0:52.32.0(00012) 1-0:72.32.0(00011) 1-0:32.36.0(00000) 1-0:52.36.0(00000) 1-0:72.36.0(00000) 0-0:96.13.0() 0-0:96.13.2() 0-0:96.13.3() 0-0:96.13.4() 0-0:96.13.5() 1-0:32.7.0(233.0V) 1-0:52.7.0(233.0V) 1-0:72.7.0(234.0V) 1-0:31.7.0(000A) 1-0:51.7.0(000A) 1-0:71.7.0(000A) 1-0:21.7.0(00.150kW) 1-0:41.7.0(00.225kW) 1-0:61.7.0(00.146kW) 1-0:22.7.0(00.000kW) 1-0:42.7.0(00.000kW) 1-0:62.7.0(00.000kW) 1-0:23.7.0(00.000kvar) 1-0:43.7.0(00.000kvar) 1-0:63.7.0(00.000kvar) 1-0:24.7.0(00.155kvar) 1-0:44.7.0(00.045kvar) 1-0:64.7.0(00.000*kvar) !F5F3

I did some analysis:

Per OBIS for IEC62056 specifications:	OBIS Code	Description
9.7.0	Apparent instantaneous power (S+) [kVA]

And other possible related OBIS codes in the specs:	OBIS Code	Description
29.7.0	Apparent instantaneous power (S+) in phase L1 [kVA]
49.7.0	Apparent instantaneous power (S+) in phase L2 [kVA]
69.7.0	Apparent instantaneous power (S+) in phase L3 [kVA]

However the following codes are not found in the specifications I have (neither in IEC62056 nor in DSMR 5.0.2):

10.7.0
31.4.0

31.4.0 could be related to maximum current on phase L1 (31.6.0) but defining both +40A and -40A (for consumption vs injection, even if usually different registers are used for both). .4. generally corresponds to the Demands in a current demand period registers.

Could you check if 40A corresponds to your subscribed / installed power?

For 10.7.0... 9.7.0 corresponds to Apparent instantaneous power (S+) [kVA] however the standard does not define a code for injection (kind of "Negative Apparent instantaneous power (S-)?) and since its value is 0.000 kVA it may be a potential. Since your register 2.8.0 is next to nil, I assume you don't have energy production so it will be difficult to confirm the assumption.

Unless someone who is doing injection could provide similar traces?

PS: I am not using this module but had to build something similar in python with MQTT hence why I took the time to analyze. Hope this helps someone.

The LUX specifications can be found here: https://www.luxmetering.lu/pdf/SPEC%20-%20E-Meter_P1_specification_20210308.pdf They define: 10.7.0 as Instantaneous exported apparent power (S+) (kVA) 31.4.0 as Threshold for maximum imported and ex-ported current (A)

- Could you check if 40A corresponds to your subscribed / installed power? I can confirm that the installed power is 40A.

- Unless someone who is doing injection could provide similar traces? I have a second meter for the production part, below the raw date (same errors/alerts):

2023-04-21 10:11:19.393 [INFO ] [.discovery.DSMRMeterDiscoveryService] - There are unrecognized cosem values in the data received from the meter, which means some meters might not be detected. Please report your raw data as reference: /Lux5\253663629_D There are unrecognized cosem values in the data received from the meter, which means you have values that can't be read by a channel: obis id:1-0:9.7.0, value:(00.000kVA), obis id:1-0:10.7.0, value:(02.110kVA), obis id:1-1:31.4.0, value:(040A)(-040A). Please report them and your raw data as reference: /Lux5\253663629_D 1-3:0.2.8(42) 0-0:1.0.0(230421101110S) 0-0:42.0.0(53414731303330373030343539383334) 1-0:1.8.0(000004.362kWh) 1-0:2.8.0(000407.961kWh) 1-0:3.8.0(000004.629kvarh) 1-0:4.8.0(000053.007kvarh) 1-0:1.7.0(00.000kW) 1-0:2.7.0(02.113kW) 1-0:3.7.0(00.000kvar) 1-0:4.7.0(00.030kvar) 0-0:17.0.0(027.6kVA) 1-0:9.7.0(00.000kVA) 1-0:10.7.0(02.110kVA) 1-1:31.4.0(040A)(-040A) 0-0:96.3.10(1) 0-1:96.3.10(0) 0-2:96.3.10(0) 0-0:96.7.21(00013) 1-0:32.32.0(00001) 1-0:52.32.0(00002) 1-0:72.32.0(00002) 1-0:32.36.0(00000) 1-0:52.36.0(00000) 1-0:72.36.0(00000) 0-0:96.13.0() 0-0:96.13.2() 0-0:96.13.3() 0-0:96.13.4() 0-0:96.13.5() 1-0:32.7.0(232.0V) 1-0:52.7.0(232.0V) 1-0:72.7.0(231.0V) 1-0:31.7.0(003A) 1-0:51.7.0(003A) 1-0:71.7.0(003A) 1-0:21.7.0(00.000kW) 1-0:41.7.0(00.000kW) 1-0:61.7.0(00.000kW) 1-0:22.7.0(00.705kW) 1-0:42.7.0(00.705kW) 1-0:62.7.0(00.702kW) 1-0:23.7.0(00.000kvar) 1-0:43.7.0(00.000kvar) 1-0:63.7.0(00.000kvar) 1-0:24.7.0(00.009kvar) 1-0:44.7.0(00.013kvar) 1-0:64.7.0(00.006*kvar) !FB36

Thank you for the specifications

I add a look at the dsmr binding.

The electricity_smarty_v1_0 intends to comply with Luxembourg's Smarty V1.0 specification while latest approved specifications are V1.1.3. Not sure what was in V1.0 or not thought.

Proposal could be:

[ ] to define a new electricity_smarty_v1_1 thing (is that needed?) ( we could add new Cosem objects as optional to electricity_smarty_v1 thing as it does not break unit tests on previous smarty footprints - however it would not comply with the binding phylosophy)
[ ] to add any new channels which are in V1.1.3 specifications and not supported by the binding today, that is:
- [x] OBIS ~~1, 34, 4, 0~~ 1, 31, 4, 0, unit A, definition Threshold for maximum imported and exported current (see Notes). Already available as EMETER_FUSE_THRESHOLD_A for other things (notably belgium)
- [ ] OBIS 1, 9, 7, 0, unit kVA, description Instantaneous imported apparent power (S+)
- [ ] OBIS 1, 10, 7, 0, unit kVA, description Instantaneous exported apparent power (S+)
[x] additional ones to be checked (in the specs they are listed as 0 groupA while in the examples of the specs and in the user captures they are listed as 1 groupA. And they are implemented as 1 already in the binding so probably not worth touching):
- OBIS 0, 32, 32, 0, unit None, description Number of voltage sags L1
- OBIS 0, 52, 32, 0, unit None, description Number of voltage sags L2
- OBIS 0, 72, 32, 0, unit None, description Number of voltage sags L3
- OBIS 0, 32, 36, 0, unit: None, description Number of voltage swells L1
- OBIS 0, 52, 36, 0, unit: None, description Number of voltage swells L2
- OBIS 0, 72, 36, 0, unit: None, description Number of voltage swells L3
[x] check units because there could be inconsistencies with Smarty Luxembourg specs (eg 1, 17, 0, 0 is in A by default in the binding while it's in kVA in the Luxembourg specs or 0, 24, 2, 1 which can be in m³ or GJ in the specs while it's in kWh by default in the binding)
- This is covered by M3METER_VALUE, GJMETER_VALUE_V4 which must be part of definition
[x] Log additional issue on DSMR plugin => workaround found

Notes - Possibles errors in v1.1.3 specs:

the specifications table refer to OBIS 1, 34, 4, 0 however the sample in the specifications and all samples from @llouxi refer to 1, 31, 4, 0. I believe it is a typo on page 15 and 1-x:31.4.0 should be implemented.
Same inconsistency in the page 15 table and captures for voltage sags / voltage swells (specs say groupA should be 0 while in the implementation, specs example and all examples, groupA is 1)
Finally, the CRC in the P1 datagram example provided in Appendix A is to be confirmed.

Checked V1.0 specifications: P1 Port Specification for Smarty on Creos thanks to an old thread dsmr-reader issue 769.

This confirms:

That 1, 31, 4, 0, 1, 9, 7, 0 and 1, 10, 7, 0 did not exist in V1.0 specifications - and are the only additions of V1.1
However, Instantaneous voltage L1, L2, L3 (1, 32, 7, 0, 1, 52, 7, 0 and 1, 72, 7, 0) did not exist in V1.0 specs table but did exist in the V1.0 Example of P1 datagram.

openhab / openhab-addons

[DSMR] unrecognized values received from the meter #14844