The prediction is the hard part 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?
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.
Yes i use amd64 linux binaries and yes , i have time-dependent energy tarrif so it is not so easy to write whole calculation i It is made just for fun and cost planing
I recommend to purachse SDM630 on ali - i bought mine for 80usd and after about month got it at home.
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.
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.
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:
In my appartment the cable is approx. 1m long, so I donāt have any grounding issues.
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.
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.
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.
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.
It depends 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
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.
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.
@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?
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
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.
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.
, i have time-dependent energy tarrif so it is not so easy to write whole calculation 