Feature Request: Eastron-SDM-Serie: instantaneous electrical information

[Xander0823]

Hello,

I use electric meters of the SDM series of the manufacturer EASTRON.
These slaves have the property to return only the meter value in standard queries.
The also available instantaneous values (voltage, current, power, frequency, etc) are not present in the response telegram.

To get the values, the query must look like in the attached protocol document chapter 6.1:

SDM630-Mbus-protocol.pdf

In the pyMeterBus project the behavior has been discussed before:

pyMeterBus

Unfortunately I can't implement the solution myself, but I would be willing to work on it for tests etc.

Greetings Alex

[lategoodbye]

Can you provide the current behavior of libmbus with this meter as a trace?

[Xander0823]

of course:

init_slaves: debug: sending init frame #1
[2022-08-05 14:55:34Z] SEND (005): 10 40 FD 3D 16
init_slaves: debug: sending init frame #2
[2022-08-05 14:55:35Z] SEND (005): 10 40 FD 3D 16
[2022-08-05 14:55:35Z] SEND (005): 10 5B 02 5D 16
[2022-08-05 14:55:36Z] RECV (099): 68 5D 5D 68 08 02 72 99 76 69 05 24 40 01 02 55 00 00 00 0C 04 01 07 00 00 0C 04 00 00 00 00 0C 04 01 07 00 00 0C 04 01 07 00 00 0C 04 00 00 00 00 0C 04 00 00 00 00 0C FD 3A 49 32 00 00 0C FD 3A 00 00 00 00 0C FD 3A 49 32 00 00 0C FD 3A 49 32 00 00 0C FD 3A 00 00 00 00 0C FD 3A 00 00 00 00 30 16
mbus_frame_print: Dumping M-Bus frame [type 4, 99 bytes]: 68 5D 5D 68 08 02 72 99 76 69 05 24 40 01 02 55 00 00 00 0C 04 01 07 00 00 0C 04 00 00 00 00 0C 04 01 07 00 00 0C 04 01 07 00 00 0C 04 00 00 00 00 0C 04 00 00 00 00 0C FD 3A 49 32 00 00 0C FD 3A 00 00 00 00 0C FD 3A 49 32 00 00 0C FD 3A 49 32 00 00 0C FD 3A 00 00 00 00 0C FD 3A 00 00 00 00 30 16

<SlaveInformation>
    <Id>5697699</Id>
    <Manufacturer>PAD</Manufacturer>
    <Version>1</Version>
    <ProductName></ProductName>
    <Medium>Electricity</Medium>
    <AccessNumber>85</AccessNumber>
    <Status>00</Status>
    <Signature>0000</Signature>
</SlaveInformation>

<DataRecord id="0">
    <Function>Instantaneous value</Function>
    <StorageNumber>0</StorageNumber>
    <Unit>Energy (10 Wh)</Unit>
    <Value>701</Value>
    <Timestamp>2022-08-05T14:55:36Z</Timestamp>
</DataRecord>

<DataRecord id="1">
    <Function>Instantaneous value</Function>
    <StorageNumber>0</StorageNumber>
    <Unit>Energy (10 Wh)</Unit>
    <Value>0</Value>
    <Timestamp>2022-08-05T14:55:36Z</Timestamp>
</DataRecord>

<DataRecord id="2">
    <Function>Instantaneous value</Function>
    <StorageNumber>0</StorageNumber>
    <Unit>Energy (10 Wh)</Unit>
    <Value>701</Value>
    <Timestamp>2022-08-05T14:55:36Z</Timestamp>
</DataRecord>

<DataRecord id="3">
    <Function>Instantaneous value</Function>
    <StorageNumber>0</StorageNumber>
    <Unit>Energy (10 Wh)</Unit>
    <Value>701</Value>
    <Timestamp>2022-08-05T14:55:36Z</Timestamp>
</DataRecord>

<DataRecord id="4">
    <Function>Instantaneous value</Function>
    <StorageNumber>0</StorageNumber>
    <Unit>Energy (10 Wh)</Unit>
    <Value>0</Value>
    <Timestamp>2022-08-05T14:55:36Z</Timestamp>
</DataRecord>

<DataRecord id="5">
    <Function>Instantaneous value</Function>
    <StorageNumber>0</StorageNumber>
    <Unit>Energy (10 Wh)</Unit>
    <Value>0</Value>
    <Timestamp>2022-08-05T14:55:36Z</Timestamp>
</DataRecord>

<DataRecord id="6">
    <Function>Instantaneous value</Function>
    <StorageNumber>0</StorageNumber>
    <Unit>dimensionless / no VIF</Unit>
    <Value>3249</Value>
    <Timestamp>2022-08-05T14:55:36Z</Timestamp>
</DataRecord>

<DataRecord id="7">
    <Function>Instantaneous value</Function>
    <StorageNumber>0</StorageNumber>
    <Unit>dimensionless / no VIF</Unit>
    <Value>0</Value>
    <Timestamp>2022-08-05T14:55:36Z</Timestamp>
</DataRecord>

<DataRecord id="8">
    <Function>Instantaneous value</Function>
    <StorageNumber>0</StorageNumber>
    <Unit>dimensionless / no VIF</Unit>
    <Value>3249</Value>
    <Timestamp>2022-08-05T14:55:36Z</Timestamp>
</DataRecord>

<DataRecord id="9">
    <Function>Instantaneous value</Function>
    <StorageNumber>0</StorageNumber>
    <Unit>dimensionless / no VIF</Unit>
    <Value>3249</Value>
    <Timestamp>2022-08-05T14:55:36Z</Timestamp>
</DataRecord>

<DataRecord id="10">
    <Function>Instantaneous value</Function>
    <StorageNumber>0</StorageNumber>
    <Unit>dimensionless / no VIF</Unit>
    <Value>0</Value>
    <Timestamp>2022-08-05T14:55:36Z</Timestamp>
</DataRecord>

<DataRecord id="11">
    <Function>Instantaneous value</Function>
    <StorageNumber>0</StorageNumber>
    <Unit>dimensionless / no VIF</Unit>
    <Value>0</Value>
    <Timestamp>2022-08-05T14:55:36Z</Timestamp>
</DataRecord>

[vigeland]

The same feature request. I saw test frames from the 630 in the course with all data in the source package.
What change has lost the missing data. The 630 firmware is form 2019

[vigeland]

A quick implementation for SDM630MCT-MBUS V2 for the command mbus-serial-request-data.
You have to use the secondary address and set the prefix SDM360 before the secondary address.
mbus-serial-request-data -d -b 2400 /dev/ttyUSB0 SDM630-addressfromyourdevice-

Add new function and call it in case a secondary address start with SDM630

You will get all informations. 22 data records

p1.patch
p2.patch

[HindrikDeelstra]

The same issue exists for Eastron's single phase SDM220 Mbus energy meter. The regular REQ_UD2 request only causes the meter to respond with 12 energy data fields in its RSP_UD response frame(s), and I'd like to also receive the 23 Power-related data fields.

So, any possible solution should not just be limited to the SDM630, but to (all?) Eastron MBus meters in general ;)

Addendum 2024-03-24:

The patches supplied by @vigeland seem to work! I have used these patches successfully in compiling libmus into a Docker container I'm using to read my Eastron SDM220 MBus meter. I've used the repo https://github.com/packom/mbus-httpd to build it via the Dockerfile, patching the libmbus source files before compilation starts in the build.

Spawning the patched container immediately allows for readout of the instanteous power data via the meter's secondary address, notably without using the "SDM630" prefix!

I'm not sure how that works, as the code and your comments seem to indicate the prefix should be required, but it "just works (TM)" without it. Adding the prefix to the secondary MBus address even results in a "Failed to receive M-Bus response frame." error...

I currently have only the SDM220 on the MBus, so I'm not sure how it behaves with other (non-Eastron) meters on the same bus.