Hello everybody, I would like to present my own private system and regulation for zero feed-in.
The own consumption in the house is covered first. If there is still power left, the battery will also be charged.
0. Tube fan in tube as active cooling, thermal sensor from 9
- Esmart3 MPPT charge controller (this cheap part is offered under various names) guidance and specification, manufacturer page, Configuration software Windows, alternative link
- Soyosource GTN 1200W (900 W in battery mode), Please make sure that this device can be connected to the grid in your country. guidance and specification
- AC emergency stop switch
- Collecting screw for PV+
- Disconnect switch for PV-
- Circuit breaker and RCD for L1
- Combined fuse and RCD for L2
- Step-Up MPPT controller for the 390 W module, elejoy EL-MU400SP, guidance and specification
- Thermal switch for tube ventilation
That just about fits in a 60x60 cm control cabinet. Not visible in the picture:
- PV Module with 1690 Wp (5x 260 W Poly, 1x 390 W Mono), not optimally aligned, the poly are 20 years old.
- Raspberry Pi (or other (micro)computer)
- Reading head for the electricity meter (modern measuring device)
- 16s LiFePO4 battery with 25 Ah, so 1,28 kWh
The price for the entire system was just under €2k.
The system basically works like an island: PV, battery and the Soyosource grid inverter (as a load) are connected to the charge controller. (Further grid inverters must be connected directly to the battery because of the 40A limit of the Esmart3.) The feed-in power of the Soyosource inverters can be regulated via RS485 (Modbus). Measuring clamps are also offered for this, but you cannot balance phases with them. The Raspberry Pi, which runs the Volkszaehler software, is responsible for the regulation. The Volkszähler reads the calibrated to the second by means of a reading head on the house electricity meter! real consumption data. The OBIS data record with the id "1-0:16.7.0" indicates the current balanced consumption. With negative values when feeding, even with counters with a backstop! At least that's what mine (DD3 BZ06) does.
This is where my script zeroinput comes into play, it reads the consumption data from the home electricity meter via the Volkszaehler and calculates the necessary feed-in power to set the meter to zero. In principle, the script would also work without a Volkszähler and could read the reading head itself. Then it would run on much "smaller" hardware, but without monitoring it would be too risky for me. The "unusual way" of redirecting the log file instead of using the Volkszaehlers own methods (database access via network) increases the reliability considerably. Even if the database of the Volkszaehler crashes, the script continues to work! I already had that... If you don't want to lay a cable to the meter, you could use a WIFI read head and transmit the consumption data via the WLAN network.
In practice, the value on the meter fluctuates minimally around 0, by the way, my "smart meter" also shows feed-in without a minus sign as a positive value on its display. (there are A- and A+ with arrows, these show demand / export)
The script has these functions:
- Battery undervoltage protection below 48V
- Power adjustment battery from 48 V to 51 V, using control curve, possible total power always plus PV
- "Over"feed from 53 V to "Saturation charging voltage" (on the esmart3), 0.2 W / 0.1 V, "pulls the zero line down", if there is an excess
- Battery discharge current limitation, possible total power always plus PV
- Night limit (a small battery doesn't last all night)
- Minimum power
- Maximum power
- Permanent shifting of the zero line in the direction of demand or export.
- Correction of battery cable loss
- Alarm for increased battery temperature or internal temperature of the esmart3
- Ramp mode for high changes in consumption
- Suppression of the oscillation of the control loop
- Time-controlled battery discharge
These values can and should be adjusted to the respective system and battery size! Of course you could also integrate other charge controllers, such as Epever or Victron. The battery voltage and PV power are very important values for the control! Any other grid inverter can also be used if it can be regulated. A controllable DC-DC converter on a micro-inverter is also conceivable. For example, my system can only deliver the full inverter power if the PV is delivering enough power at the moment - so as not to overload the battery. The "hard" limit values for undervoltage and overvoltage etc. are set both in the charge controller and in the grid inverters.
As far as I can tell, you have to register the system described here in Germany with both the network operator and the market master data register. if you want to comply with all legal regulations. But you can't! Because in plain language: The mentioned Soyosource inverter may not be connected to the power grid in Germany because of the missing certification.
The values for PV (yellow, power of the PV modules) and Soyo P (green, current fed in) are displayed negated! The script supplies the data for PV, Soyo P and battery U (red, battery voltage), whereby Soyo P is calculated. PV and battery U are read by the esmart3 controller and passed on to the Volkszähler for display. This creates a one-second time offset to the curves of the house electricity meter.
(2 soyo gti)
The daily values were: PV generation 7.7 kWh, feed-in 7.3 kWh, deliberately given away 0 kWh.
On this day, the oven, microwave, well pump, split air conditioning, and so on were running. At the end of the day, the battery was already empty.
You can see the on and off regulation in the morning and evening along the PV curve. Around 11 the maximum feed.
After that and very nice at about 5:30 p.m. the power adjustment for the battery power.
(2 soyo gti)
The daily values were: PV generation 6.1 kWh, feed-in 5.7 kWh, deliberately given away 0.9 kWh.
The largest consumer was the split climate. The battery charge lasted far into the night.
Here you can see the adjustment in the morning and the night limit in the evening.
The dark green area is excess current because the battery - see voltage curve - is full.
(Meanwhile, the overfeed in the standard setting is much lower!)
As long as the power of the PV does not exceed the consumption, all power goes directly to the grid inverter. The battery is not charging. Essentially, this corresponds to the mode of operation of a module/micro-inverter.
(2 soyo gti)
The data in the table refer to the entire visible section.
Here the "Sum L1+L2+L3" (OBIS "1-0:16.7.0") is displayed in black.
Above the zero line, it corresponds almost exactly to the red line for the network reference ("1-0:1.8.0").
The part below the zero line is the actual feed into the power grid, i.e. energy that goes "through the meter into the grid".
This is not "calculated" by the counter, it would be the second direction in a bidirectional counter.
In total, that was 430 Wh paid purchase and 418 Wh "physical purchase". So 12 Wh were fed in without remuneration.
The continuous wave from 10:10 comes from the constantly running drum motor, the script follows this increasing consumption.
But since the motor also suddenly switches off again, the inertia of the control results in an actual feed-in.
The ripples in the green line come from outside the heating phase due to this inertia.
During the heating phase, the ripple comes from the power adjustment to the battery voltage. (The washing machine just ran too early, the battery was barely charged.)
The drop in performance at around 10:33 a.m. is due to the restart of the MPP tracker in the charge controller. (Green and Yellow)
The increase in PV power can also be seen at the moment when the heating phase begins.
Conversely, the PV power decreases with slowly increasing battery voltage after the heating phase.
(2 soyo gti)
The red areas are the purchased reference. The green areas the own feed.
The gray areas are the inertial overfeed, energy fed in for free.
(1 soyo gti)
(3 soyo gti)
Here you can see how the oven clocks the battery empty.
The following components of the regulation interact:
- Limitation of the discharge current of the battery, here 2kW from the battery + PV power
- Ramp mode, for large jumps in consumption
- Battery voltage correction
- Power adjustment to the battery voltage, the discharge curve of LFP falls rapidly
The house counter shows the black values without a minus sign.
Red must be paid. The feed was 400 to 450 W in this section.
The output of the script in verbose mode, updated every second:
09:59:47, voltage 52.6 V, PV power 578 W, load power 152 W
timer active: bat discharge 50 %, input 100 %, energy 137/1000 Wh
voltage correction 52.5 V, dif 0.1 V
no saw detected
input history [167, 163, 166, 163] 1:2 1.8 % 3:4 2.4 %
meter 5 W (5 W import), interval 1.02 s
input 163 W
1 soyo
2 soyo
1 eSmart3
primary SOC 46 Mode CC
PV 59.1 V 5.0 A 263 W
Battery 52.6 V 5.0 A 263 W
Load 52.5 V 2.9 A 152 W
Temp int 37 °C bat 20 °C
secondary SOC 53 Mode CC
PV 56.0 V 6.1 A 322 W
Battery 52.9 V 6.1 A 322 W
Temp int 32 °C out 14 °C
2 eSmart3
As for the accuracy of the data from the esmart3, the author of the esmart3 library, which I use modified, published a review. According to my observation, the power fed in by the Soyosource Inverter corresponds quite exactly with the requested value. There is also the delayed response time (ramp speed) of 400 W/s, as far as I know. So the Soyo takes 2+ seconds to go from 0 to 100% power. (this is intentional, not a bug) That's why I just controlled the Soyos in parallel to have the shortest possible response time, with more Soyos it is be even better, but only one works also! (The 2-phase connection of my system would not be necessary and comes from experiments with phase-based zero feed-in, which I have since discarded! Still nice to have.) When does another inverter make sense? According to the manufacturer, the basic consumption is < 2 W. Calculated with 3 W, this results in 72 Wh / day. So you get 72 Wh / 900 Wh * 60 minutes = 4.8 minutes full load feed-in. So if the "other" inverter runs for more than 5 minutes at full load per day, it's worth it, roughly speaking.
The output of the script above shows: injected power 643W, while the esmart shows 692W load. That gives ~93% efficiency at that moment. Of course, charging and discharging the battery also costs energy. With the example data of the days (above) an overall efficiency can be calculated:
- PV generation 7.7 kWh, feed-in 7.3 kWh, results in ~ 95%
- PV generation 6.1 kWh, feed-in 5.7 kWh, results in ~ 93%
The more energy goes through the battery, the worse the efficiency of the entire system.
- Bring the electricity meter with PIN to (extended) data output if necessary. The PIN is available from the metering point operator or network operator (not electricity provider). There is a practical app for PIN entry for the impatient.
- Get the Volkszähler working. Instructions, the forum Without Volkszähler the script doesn't run! So start with that first.
- It makes a lot of sense to assign a own, fixed device name to the IR read head and RS485 adapter using the udev rule give. For my devices are .rules files in /dev/udev/rules.d/ with these rules:
SUBSYSTEMS=="usb-serial", DRIVERS=="cp210x", SYMLINK+="lesekopf"
SUBSYSTEMS=="usb-serial", DRIVERS=="ch341-uart", SYMLINK+="rs485"
Or with identical devices separated by the connector:
SUBSYSTEMS=="usb" ATTRS{devpath}=="1.1" SYMLINK+="esm0"
SUBSYSTEMS=="usb" ATTRS{devpath}=="1.3" SYMLINK+="esm1"
- Assemble all the devices as described above.
- Connect the RS485 port of the Raspi (usually a USB stick with clamps) to the RS485 ports of Soyo and esmart3: A+ to A+, B- to B-.
- Modify the Volkszähler for zero feed-in a bit.
If your own Volkszähler runs successfully, then channels can be created according to this vzlogger.conf. In any case, "identifier": "1-0:16.7.0*255" and "verbosity": 15 must be included so that the script can calculate with them. The path for the "log" in vzlogger.conf must also be adjusted: "/tmp/vz/vzlogger.fifo" Although it is not necessary for operation, the handling of data quantities should be observed, otherwise "the database will overflow at some point"!
as root:
apt install python3-serial
cd /home/vzlogger
wget https://raw.githubusercontent.com/E-t0m/zeroinput/main/zeroinput.py
wget https://raw.githubusercontent.com/E-t0m/esmart_mppt/master/esmart.py
chmod 744 /home/vzlogger/*py
chown vzlogger: /home/vzlogger/*py
su vzlogger
mkdir /tmp/vz
touch /tmp/vz/soyo.log
mkfifo /tmp/vz/vzlogger.fifo
python3 /home/vzlogger/zeroinput.py -v (cancel with ctrl+c)
or if you know screen (man screen):
screen -dmS zeroinput nice -1 python3 /home/vzlogger/zeroinput.py -v (screen -r "to open", ctrl-a and ctrl-d "close")
Then again in another terminal - as root - restart the vzlogger
systemctl restart vzlogger
To start the script automatically when booting up the Raspi, use
su vzlogger
crontab -e
this line:
@reboot mkdir /tmp/vz; touch /tmp/vz/soyo.log; mkfifo /tmp/vz/vzlogger.fifo; screen -dmS zeroinput nice -1 python3 /home/vzlogger/zeroinput.py -v
enter in the crontab.
To get the output later, as user "vzlogger" (su vzlogger), screen -r. Then use ctrl-a, then ctrl-d to "close".
Once this entry has been made, the control restarts automatically after a power failure. With a little delay due to the inverters themselves and the Raspi's startup process. If the reading head is removed, the feed-in simply stops and the counter increases to the consumption value. As soon as the reading head is attached again, the feeding starts automatically.
This is what the Esmart3 for Windows configuration software, alternative link looks like.
There is something that cannot be set on the device itself: Li-Ion. The other values are of course dependent on the battery used. I have set quite high and low values because the line to the battery is not quite optimal. So far, however, they have not been used because the script operates far away from them! (Update: values reduced!)
The configuration of the Soyosource Inverter is very clear
- Battery buffer for emergency power supply. (Requires an additional island inverter!)
- Anticipatory control for recurring consumption patterns, e.g. washing machine, microwave, hob
- Integrate other charge controllers, it doesn't always have to be the Esmart3
- A ready-made Volkszähler image, where you only have to adjust the reading head.
More information is available on the (german) forums: