DIY: SDM630 Smart Meter Interface

smartmeter
diy
modbus
Tags: #<Tag:0x00007f0146867470> #<Tag:0x00007f0146867290> #<Tag:0x00007f0146867128>

(Mathias Dalheimer) #41

So you used the x64-Linux binaries?

The prediction is the hard part :wink: My colleagues here run PVCast, a prediction service for the power production of a specific PV plant based on weather predictions. I also investigated how to construct a generalized power consumption model for households, but they differ significantly. So far, I can easily describe my power consumption behaviour, but I don’t have a generic model that works for all households.

Do you have load/time-dependent energy tariffs? Or what is the reason you want to predict your energy cost?


(Mathias Dalheimer) #42

Hi,

I just had a look ebay. Currently, the following prices are asked:

  • SDM630: 129 Euro
  • SDM530: 90 Euro

If price is the main issue, I would recommend the SDM530. But beware: This is a rather big meter (7TE). If you have the space in your distribution cabinet you should consider the SDM530. Both meters are tested with my software and work fine. The SDM530 does not provide THD measurements, but for most people this is irrelevant anyways.


(Sir Leone) #43

Yes i use amd64 linux binaries and yes :slight_smile: , i have time-dependent energy tarrif so it is not so easy to write whole calculation :slight_smile: i It is made just for fun and cost planing :slight_smile:
I recommend to purachse SDM630 on ali - i bought mine for 80usd and after about month got it at home.


(Hallo Ween) #44

How can i see if this is the SDM630 modbus v2 Version?

Is there a big difference between v1 and v2? Is it recommended to buy v2?


(Mathias Dalheimer) #45

The v1 is slightly larger and requires 4,5TE, the v2 only 4TE. The button layout is different. The software version has been increased, but I cannot see a difference on the Modbus interface. So, in my opinion, get the cheaper one.


(Hallo Ween) #46

Here is what the German distributor told me:

Die Zuleitung der Phasen erfolgt nicht mehr von unten sondern von oben somit ist die funktion von Kammschienen gewährleistet.
Des weitern ist der N-Leiter durch das Gerät geführt und kann somit mit durchgeschliffen werden.
Desweitern sind die Zusatzklemmen nun auf eine Schiene aufgebracht welches den zugang zu allen Klemmen leichter gestaltet.
Die Modbuskommunikation erhilet eine GND Klemme um Potziale der RS485 Stecke mit auszugleichen.
Die Gehäuseform sowie das Display wurden angepasst und es leuchtet nun hellblau welches die Lesbarkeit vereinfacht.
Innerhalb der Modbuskommunikation sind neue register hinzugekommen welche eine Phasenseitiges auswerten von kWh und KVArh unterstützt.

(Mathias Dalheimer) #47

You’re right, they basically reorganized the position of the connectors. The new one works better™, but this is just an installation-time issue. I’m running the old one in my appartment and I see no reason to “upgrade”.

The additional GND line is a significant change. For longer RS-485 bus systems the ground potential can be different, leading to communication problems. Janitza has a great page explaining this:

https://www.janitza.com/communication-via-the-rs485-interface.html

In my appartment the cable is approx. 1m long, so I don’t have any grounding issues.


(Sir Leone) #48

After few hours of testing i have found that some errors are generated in daemon.log (cat daemon.log | grep sdm630 ) :

.....
.....

Jul 14 21:03:30 Santiago sdm630_httpd[4604]: 2017/07/14 21:03:30 Failed to retrieve opcode - retry attempt 1 of 5
Jul 14 21:03:55 Santiago sdm630_httpd[4604]: 2017/07/14 21:03:55 Failed to retrieve opcode - retry attempt 1 of 5
Jul 14 21:04:25 Santiago sdm630_httpd[4604]: 2017/07/14 21:04:25 Failed to retrieve opcode - retry attempt 1 of 5
Jul 14 21:10:28 Santiago sdm630_httpd[4604]: 2017/07/14 21:10:28 Failed to retrieve opcode - retry attempt 1 of 5
Jul 14 21:23:03 Santiago sdm630_httpd[4604]: 2017/07/14 21:23:03 Failed to retrieve opcode - retry attempt 1 of 5
Jul 14 21:23:04 Santiago sdm630_httpd[4604]: 2017/07/14 21:23:04 Failed to retrieve opcode - retry attempt 1 of 5
Jul 14 21:24:04 Santiago sdm630_httpd[4604]: 2017/07/14 21:24:04 Failed to retrieve opcode - retry attempt 1 of 5
Jul 14 21:24:43 Santiago sdm630_httpd[4604]: 2017/07/14 21:24:43 Failed to retrieve opcode - retry attempt 1 of 5
Jul 14 21:29:12 Santiago sdm630_httpd[4604]: 2017/07/14 21:29:12 Failed to retrieve opcode - retry attempt 1 of 5
Jul 14 21:35:20 Santiago sdm630_httpd[4604]: 2017/07/14 21:35:20 Failed to retrieve opcode - retry attempt 1 of 5
Jul 14 21:35:41 Santiago sdm630_httpd[4604]: 2017/07/14 21:35:41 Failed to retrieve opcode - retry attempt 1 of 5
Jul 14 21:40:55 Santiago sdm630_httpd[4604]: 2017/07/14 21:40:55 Failed to retrieve opcode - retry attempt 1 of 5
Jul 14 21:43:59 Santiago sdm630_httpd[4604]: 2017/07/14 21:43:59 Failed to retrieve opcode - retry attempt 1 of 5
Jul 14 21:46:57 Santiago sdm630_httpd[4604]: 2017/07/14 21:46:57 Failed to retrieve opcode - retry attempt 1 of 5
Jul 14 21:55:47 Santiago sdm630_httpd[4604]: 2017/07/14 21:55:47 Failed to retrieve opcode - retry attempt 1 of 5
Jul 14 21:56:57 Santiago sdm630_httpd[4604]: 2017/07/14 21:56:57 Failed to retrieve opcode - retry attempt 1 of 5
Jul 14 22:01:04 Santiago sdm630_httpd[4604]: 2017/07/14 22:01:04 Failed to retrieve opcode - retry attempt 1 of 5
Jul 14 22:08:31 Santiago sdm630_httpd[4604]: 2017/07/14 22:08:31 Failed to retrieve opcode - retry attempt 1 of 5
Jul 14 22:09:06 Santiago sdm630_httpd[4604]: 2017/07/14 22:09:06 Failed to retrieve opcode - retry attempt 1 of 5
Jul 14 22:09:18 Santiago sdm630_httpd[4604]: 2017/07/14 22:09:18 Failed to retrieve opcode - retry attempt 1 of 5
Jul 14 22:10:29 Santiago sdm630_httpd[4604]: 2017/07/14 22:10:29 Failed to retrieve opcode - retry attempt 1 of 5
Jul 14 22:11:18 Santiago sdm630_httpd[4604]: 2017/07/14 22:11:18 Failed to retrieve opcode - retry attempt 1 of 5
Jul 14 22:22:56 Santiago sdm630_httpd[4604]: 2017/07/14 22:22:56 Failed to retrieve opcode - retry attempt 1 of 5


(Mathias Dalheimer) #49

Actually, this is quite normal for the SDM630 (or all other Eastron SDM meters) . There errors are read errors from the RS485 bus - mostly just one bit errors. Nothing to worry about. sdm630_httpd just attempts to re-read the value from the device and produces this log message.

For comparison: I am implementing support for Janitza DIN rail meters right now. My setup was running over the weekend. These are the stats:

$ curl --silent http://localhost/status | jq

{
    "Starttime": "2017-07-14T16:06:54.298318459+02:00",
    "UptimeSeconds": 238135.331374839,
    "Goroutines": 13,
    "Memory": {
        "Alloc": 8067040,
        "HeapAlloc": 8067040
    },
    "Modbus": {
        "TotalModbusRequests": 7784409,
        "ModbusRequestRatePerMinute": 1961.3407943435868,
        "TotalModbusErrors": 25,
        "ModbusErrorRatePerMinute": 0.006298939310433158
    }
}

Of the 7784409 requests, only 25 failed. The Janitza meters are much faster and more reliable than the Eastrons, but still, they are not perfect. You have to expect some corrupted messages over MODBUS/RTU for all devices.


(Sir Leone) #50

Ok, thanks, now i’m calm :slight_smile:


(Mathias Dalheimer) #51

OK, the benchmarks are in. Over the same 9600 Baud connection meters perform like this:

  • Eastron SDM230: 716 Requests/Min.
  • Janitza B23: 1970 Requests/Min.

There is no practical difference between these meters if you only need a reading a minute. But in some of my usecases, we regulate things based on the meter readings - and having a higher resolution always helps.


(Hallo Ween) #52

But 716 Requests/Min are 12 readings per second… I think this is fast enough.

How much readings can openhab2 do? Can you make a realtime display with it or is openhab to slow for this?

Now i read out my power meter with an usb ir-reader. It´s with sml protocol, so i can read out about every 30 seconds. For real time display it´s to slow.


(Mathias Dalheimer) #53

It depends :wink: If you consider the 21 parameters I’m reading in a loop an update of e.g. the L1 power reading takes almost 2 seconds. In my main usecase (not related to OpenHAB in any way) we’re controlling big batteries based on PV production and household consumption. I have at least two meters involved, and the update rate is - depending on the setup - in the 2-3 second range. This is rather slow for a battery management system :wink:

So, for this usecase, a faster meter is highly desirable.

I’ve never tried this - others are more competent to answer this. But if you mean “1-2 second updates”, I think OpenHAB should be able to do this.


(Ssalonen) #54

A comment on openhab performance.

Users have reported pretty good performance using modbus binding alone, around 1700 requests per minute. This was in openhab1 so performance might be better or lower with openhab2. Naturally depending on details your mileage might vary, as discussed in this thread also.

With openhab1 some users have complained high cpu usage with many events in the event bus. Not sure how it goes with openhab2.

So from performance perspective the openhab itself should easily handle vast amount of updates per second.

Best
Sami


(Mathias Dalheimer) #55

Thanks for sharing this!

-Mathias


(Hallo Ween) #56

Youd should add some more infos about Janitza B23 power meter:

B23-312 is the one with RS-485 Output (Modbus), which can be used with your software.

B23-311 is only s0 and B23-313 is M-Bus.


(Mathias Dalheimer) #57

@halloween: Thank you for pointing this out. I added this to the README.

-Mathias


(nicco demi) #58

@sirLeone can you please provide details regarding intergration with Openhab2? Which transformation is required: JSONpath or Javascript?


(nicco demi) #59

@gonium I managed to make it work with OH2 following your instructions for OH1.8. It didn’t work at first because I had no http binding installed.
I am able to get L1-L3 power readings. What is json transform structure to get Total power?

This is for Phase 1:

JSON.parse(input).Power.L1;


(Sir Leone) #60

Hi @nicodemi, i have 3 files: SDM630GetLXPower.js where x is 1-3 to each phase and for now thats all - unfortunatelly due to lack of time i did not do much more in my openhab2.

After few months of flaweless working i had problems with my ups and had unforeseen restart of my server. After everything went up connection to sdm630 stopped working. I thought that there is a problem with my meter but not - using python i can read values, using gosdm630 not :confused:

root@Santiago:/opt/sdm630# ./sdm630_get.sh /dev/ttyUSB0 1
236.68
2.34
548.54
236.84
0.57
107.56
238.49
0.78
139.62
12714.01
-124.85
0.03
3238.43
155.29
root@Santiago:/opt/sdm630# ./sdm630_httpd -u 192.168.2.100:8082 -s /dev/ttyUSB0
2017/11/15 09:06:46 Starting API httpd at 192.168.2.100:8082
2017/11/15 09:06:51 Device 1 failed to respond - retry attempt 1 of 5
2017/11/15 09:07:02 Device 1 failed to respond - retry attempt 1 of 5
2017/11/15 09:07:03 Device 1 failed to respond - retry attempt 1 of 5
2017/11/15 09:07:03 Device 1 failed to respond - retry attempt 2 of 5
2017/11/15 09:07:03 Device 1 failed to respond - retry attempt 3 of 5
2017/11/15 09:07:03 Device 1 failed to respond - retry attempt 4 of 5
2017/11/15 09:07:03 Device 1 failed to respond - retry attempt 5 of 5
2017/11/15 09:07:04 Failure - deactivating meter 1: Device 1 did not respond.
2017/11/15 09:07:04 Device 1 failed to respond - retry attempt 1 of 5
2017/11/15 09:07:04 Device 1 failed to respond - retry attempt 2 of 5
2017/11/15 09:07:04 Device 1 failed to respond - retry attempt 3 of 5
2017/11/15 09:07:04 Device 1 failed to respond - retry attempt 4 of 5
2017/11/15 09:07:04 Device 1 failed to respond - retry attempt 5 of 5
2017/11/15 09:07:04 Failure - deactivating meter 1: Device 1 did not respond.
2017/11/15 09:07:04 Device 1 failed to respond - retry attempt 1 of 5
2017/11/15 09:07:04 Device 1 failed to respond - retry attempt 2 of 5
2017/11/15 09:07:05 Device 1 failed to respond - retry attempt 3 of 5
2017/11/15 09:07:05 Device 1 failed to respond - retry attempt 4 of 5
2017/11/15 09:07:05 Device 1 failed to respond - retry attempt 5 of 5
2017/11/15 09:07:05 Failure - deactivating meter 1: Device 1 did not respond.