Earth Notes: On Website Technicals (2026-07)
Updated 2026-07-25 17:32 GMT.By Damon Hart-Davis.
: More Tuning
I could almost certainly run the poll from much later in the morning without significant loss of transfer opportunity outside the height of summer, eg instead of 4-20 use 9-20 to run for a 12h window. (The window close must stay late enough to ensure that mi1 is off, and does not run all night draining the battery.)
# Per-10-minute superdump control, just after 10m powermng update, not at night. 1-51/10 9-20 * * * cd Env && sh .work/script/micron10.sh
This probably does not need to run in December (or January) at all, and mi1 could be physically disconnected from both DC and AC sides to eliminate nugatory quiescent consumption. The cron entry could reflect that and not run at all those months.
Now that I have super-dumping with battery only HIGH (or above), I have added an extra guard of the battery being in 'absorbing' or better charge state, ie it is not being run down to transfer. Logically: isDumping && isHIGH && isAbsOrBetterOrUnknown.
: Tuning
Based on observing today's overcast but bright day, and less super-dumping than might be warranted, the super-dumping logic has also been made more aggressive:
isDumping && (!isNOTHIGH). (Currently there is no isHIGH!)
% egrep ' (H|(VH)) D ' /var/log/powermng/2025????.log | wc -l 7772 % egrep ' (H|(VH)|F) D ' /var/log/powermng/2025????.log | wc -l 8630
So ~1440h of super-dumping might have been permitted in . (Though super-dumping would likely reduce the HIGH+ hours.) At 40W super-dump that is ~4h/d or ~160Wh/d or ~60kWh/y.
: more 'e' (super-)dumping
To make more use of the above, I created a new EXPORTINGH ('exporting high') flag, that is only set when exports exceed the nominal G98 16A/phase level. Dumping and super-dumping are now not inhibited during 'e' state until that higher export level.
This allows, for example, off-grid energy to be diverted to heat storage, but not to contribute to very high exports to grid.
That change allowed transfer of ~180Wh today, inducing ~410Wh to be drawn from the primary off-grid array.
: Micro-optimisation
Switching/polling of the super-dump need only happen when there might be sun, and a fair amount of it, as the logic works now. So never between Z and Z inclusive. That avoids 7h/d of polling even mid-summer, a 29% reduction. The polling is reasonably cheap, but avoiding it is almost certainly cheaper.
# Per-10-minute superdump control, just after 10m powermng update, not at night. 1-51/10 4-20 * * * cd Env && sh .work/script/micron10.sh
: Server uptime
sencha% uptime 07:44:12 up 321 days, 19:14, 2 users, load average: 0.64, 0.64, 0.55
40W
Z: the mi1 power limit was set to just over 40W.
This may increase bright-sun energy capture and conversion efficiency, but may also increase I^2R losses and battery wear.
The super-dumping logic has also been simplified to
isDumping && isVHIGH, else super-dumping may simply not happen meaningfully often. This may be too aggressive.
For , counting 10-minute intervals where that was true:
% egrep ' VH D ' /var/log/powermng/2025????.log | wc -l 4525
That indicates 754h of super-dumping might have been permitted. (Though super-dumping would likely reduce the VHIGH hours.) At 40W super-dump that is 30kWh over the year or ~80Wh/day (ie ~2h/d), or ~1% of gross household consumption. 30kWh is ~£10 if imported.
: Created mi1
I created the variable
mi1
with monthly cadence conversion script from (daily) Local Bytes logs, with a faked initial month archive from data from today and yesterday.
Shifted a little under 70Wh today, with a peak primary-array power of over 80W.
Tomorrow I may increase the super-dump power slightly from ~30W to ~40W, to match the load from the current router dump (~12W) plus (~18W) for MacBook plus losses (~10W) plus some phone charging. A total of ~80W remains well below the 200W Morningstar SSMPT-15L conversion power limit, and also the recent observed noon-ish ~100W primary array output. It is not a huge demand on the battery if the sun goes in with such load for at least the 10-minute update interval.
This raised power nominally allows a higher proportion of otherwise unused power to be transferred and used.
: Logging Change
Making gentle progress on the proof-of-concept...
I have turned off the temporary every-minute Local Bytes logging of the last few days.
I have adjusted the date format in the log name from data/.private/tmp/LBplug-2022-10-10.log
to data/.private/tmp/20260719-LB.log
for brevity and to match the (compact) form used elsewhere.
I have allowed the specification of a log name on the logger command line, resulting in data/logname/log/live/yyyymmdd-LB.log
live log filenames.
I am now logging (after a delay to allow for start-up and settling) for log name mi1 in each 10-minute slot when the microinverter is enabled.
Usually there is no logging when it is disabled, since power should be 0. But once per day an attempt to poll and log is made, to get some view on coverage, ie on days with no reported flow was the system enabled/connected at all?
Yesterday I placed a small order with a new-to-me supplier,
12 Volt Planet, for some bits and pieces such as circuit breaker and fuses. The order was dispatched before noon on Monday (standard delivery), hurrah, though Royal Mail claimed ... Received at Royal Mail's Midlands Super Hub
Tuesday ... The goods arrived Thursday (I asked for a day's delay) through the letter box.
I fitted the 12V 7.5A circuit breaker for mi1 Thursday afternoon.
: 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. (Note that connecting 12V seems to cause a significant inrush current, enough to blow a 15A glass fuse, which is one reason that it is kinder to have this powered directly from the battery, not via the solar controller load terminals. So repeated isolation/reconnection would seem to be a bad idea too, possibly inducing a difficult surge each time.)
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. (Though power factor is reported as very low (≤0.25) when the microinverter is not generating, which may help separate such unproductive self-consumption.)
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.