Earth Notes: On Website Technicals (2026-07)
Updated 2026-07-16 15:19 GMT.By Damon Hart-Davis.
: Plug-in Proof of Concept, continued
The 'from battery' microinverter variant draws ~1mA from its 12V input without mains connected, so low enough (~12mW) not to need isolating. The mains input draws ~1.3W with no 12V input connected. So the control via Local Bytes scheme remains good for this temporary test.
I adjusted the power-limiter to be minimum ~2.2A, with ~13.2V at the microinverter input, so ~30W. Battery voltage is ~13.9V, so apparently significant wiring losses... ~63W is being pulled from the off-grid array at the moment:
2026/07/16T12:56:10Z AL 4530 B1 13910 B2 -1 P 13312 BV 12635 ST VH D A A1P 63022 B1T 28 UC 100 A1V 30719
Turning off the microinverter via the Local Bytes device reduces A1P to ~36W.
~20Wh was shifted during testing.
Control with powermng requires something like this:
# Per-10-minute superdump control, just after 10m powermng update. 1-51/10 * * * * cd Env && sh .work/script/micron10.sh
: Plug-in Proof of Concept
I want to do some quick proof-of-concept testing around plug-in solar PV now that 16WW's FiT administrator is OK with it.
As part of the test set-up today I have set up the Local Bytes smart socket both to allow disconnecting a microinverter under server control, but also to monitor the power flows.
Power flow through the Local Bytes device shows as positive, whether to or from the mains, which will complicate things a little.
As measured by the Maplin N67HH, the Local Bytes device itself seems to draw <0.1W with the relay off, and ~1.3W with the relay on. Consuming this power only when the microinverter is likely to be able to supply it seems reasonable. And manually turning everything off at the (mains) plug when excess power seems unlikely, eg in gloomy mid-winter, also seems easy and sensible.
Naturally the day that I play with this it has been overcast all morning, with direct sunshine breaking through around noon.
A small test with the better-lit (further from the apple tree) 255Wp panel via a test microinverter has ~110W (with power factor 1.0) reported by LB, with the off-grid Morningstar pulling over 50W from the other, cf ~3.4kW being generated by the grid-tied system. The sun is fairly high in the sky. Nominally that energy is helping cook my lunch pasta on the induction hob!
2026-07-14T11:38:18Z {"StatusSNS":{"Time":"2026-07-14T12:38:17","ENERGY":{"TotalStartTime":"2022-10-05T19:17:26","Total":3.085,"Yesterday":0.003,"Today":0.055,"Power":110.3,"ApparentPower":110.3,"ReactivePower":0.0,"Factor":1.00,"Voltage":245,"Current":0.451}}}
The microinverter was in direct sunshine and the red 'heat' light came on, and was probably limiting power output, though the fan was barely audible. ~Z I moved it to shade.
See the raw data.
% gzip -d < img/LocalBytes-monitoring-plug/2026-07-14-microinverter-PoC/LBplug-2026-07-14.log.gz | \
sh script/LBPowerExtract.sh
2026-07-14T08:09:02Z 0.0
2026-07-14T08:10:01Z 0.0
2026-07-14T08:11:01Z 0.0
...
2026-07-14T14:26:18Z 54.9
2026-07-14T14:27:01Z 12.5
2026-07-14T14:28:01Z 45.1
% gzip -d < img/LocalBytes-monitoring-plug/2026-07-14-microinverter-PoC/LBplug-2026-07-14.log.gz | \
sh script/LBPowerExtract.sh | \
awk '{s+=$2}END{print s/60}'
225.418
Thus ~200Wh was generated by the microinverter.
% gzip -d < img/LocalBytes-monitoring-plug/2026-07-14-microinverter-PoC/LBplug-2026-07-14.log.gz | \
sh script/LBPowerExtract.sh > input.dat
% gnuplot graphing/gnuplot-LB-power-plot-v2p1.txt
% svgo -i output.raw.svg -o output.svg img/LocalBytes-monitoring-plug/2026-07-14-microinverter-PoC/LBplug-2026-07-14.svg
I have added a SUPERDUMPING output flag for powermng
to signal that dumping to a larger load or transfer to grid is requested.
Super-dumping is enabled only when normal dumping is allowed, and there is PV generation (not dark), and with one of a few triggers (but no ride-through):
F, V, u, E. All but E indicate strong generation that may not be fully captured by off-grid storage, thus use/transfer it or lose it.
There is a special case for 'T' to super-dump providing that the battery level is at least VHIGH.
A super-dump of ~30W would be 5Wh (about a mobile phone battery capacity) per 10 minute slot, and at ~2.5A would likely not overtax the 12V wiring.
I tweaked 'V' to be quicker to start, for the more aggressive non-LESS_DoD case in use.
: More 12M Net Export
The current ~0.3kWh/day non-netted import (imp) is good, and about the expected minimum for the year.
But the ~12M figure of net -2.0kWh/d (net) is unexpectedly better! The avoidance of most diversion unless the grid is green is helping, it seems.
: Cadence
For the by-month grid CO2 calculations, I have moved the monthly intermediate/cache files from out/yearly
to the more appropriate out/monthly, eg:
... Enphase-1h-202605.csv.gz FUELINST-1h-202605.csv.gz Enphase-join-FUELINST-1h-202605.csv.gz 16WW-elect-kgCO2-202605.txt Enphase-1h-202606.csv.gz FUELINST-1h-202606.csv.gz Enphase-join-FUELINST-1h-202606.csv.gz 16WW-elect-kgCO2-202606.txt ...
: Edge Cases Worked!
Elexon's API went down for scheduled maintenance this morning, so after a while (~2h) the diversion control code decided that grid intensity data was too stale and stopped diversion as fail-safe. Graceful success/failure in unusual circumstances #1!
The API came back (ahead of schedule) and diversion started again because even though the grid was not green (G), a large rise in grid intensity over the next ~2d was predicted (P), so the system went into "fill your boots" mode. Success in unusual circumstances #2!
2026-07-07T13:51Z MT 0 GI 85 IT 40 F FqP2TCN ES 3
: Export/Dump for Red Grid
In line with attempting to provide more (indirect) assist to the grid when most useful (though tiny, ~12W!) from the off-grid system, I have re-enabled 'E' dumping when the grid intensity is red (top quartile) alongside the cron-set grid-peak flag.
That GBGRIDPEAK.flag timing still looks good, around Z. Maybe it could start a little later.
#Ansible: 16WW: set /run/GBGRIDPEAK.flag in winter months 19 16 * 11-12,1-3 1-5 touch /run/GBGRIDPEAK.flag #Ansible: 16WW: clear /run/GBGRIDPEAK.flag 39 18 * * * rm -f /run/GBGRIDPEAK.flag
: red ahoy!
The 'E' took effect again for the first time quite soon, as the grid went 'red':
2026/07/07T16:30:06Z AL 754 B1 12674 B2 -1 P 18834 BV 12249 ST OK D E A1P 9543 B1T 31 UC 100 A1V 25538 2026/07/07T16:40:06Z AL 708 B1 12589 B2 -1 P 22296 BV 11240 ST OK D E A1P 8818 B1T 31 UC 100 A1V 25489 2026/07/07T16:50:06Z AL 508 B1 12549 B2 -1 P 22262 BV 12030 ST OK D E A1P 6402 B1T 31 UC 100 A1V 24421 ...
I have also tweaked to maybe better avoid sulphation by reducing dumping after failing to achieve a decent level of charge (VHIGH) for several days.
: gated on imports
I have gated 'E' behind there being significant imports, ie to operate only when the AC-coupled battery is unable to hold the line. That gets state back to 'e':
2026/07/08T20:20:06Z AL 0 B1 12491 B2 -1 P 15814 BV 12091 ST OK D e A1P 0 B1T 32 UC 100 A1V 12970
'E' could also operate when there are significant exports, but may then inflate spill to a grid already flooded, so we might as well preserve LA battery life.
I have added to 'e' to dump when high SoC and grid red intensity (may be exporting) to reduce grid emissions.
: Tweaking Solar Noon Dumping
The time at which the last parts of heat/DHW storage can be filled by diversion has moved forward a little more, after inspection of June's grid export graph, to Z. The aim is a flatter smoother summer export curve, while continuing to reduce exports when other grid-connected solar generation is likely around maximum.