Earth Notes: On Website Technicals (2026-03)
Updated 2026-03-16 11:08 GMT.By Damon Hart-Davis.
: RSS Abuse Snapshot
# Greedy podcast feed pullers: keys are MD5 hashed User-Agent.
# A non-empty txt map lookup of the %{md5:%{HTTP:User-Agent}} means bad!
# Built: 2026-03-16T09:16+00:00 (UTC)
# MAXHITSPERUAPERDAY: 10
# MAXUAS: 25
#----------------
# request-count User-Agent
# MD5hash approx-hits-per-day
#----------------
# 342 Podbean/FeedUpdat
54e0e9df937b06cc83fab29f44c02b7f 342
# 203 Spotify/1.0
4582d9bdbcef42af27d89da91c6eb804 203
# 138 Google-Podcast
8dea568b39db0451edd6b30f29238eaf 138
# 58 iTMS
97f76eb7e02c5ff923e1198ff1c288cd 58
# 53 Amazon Music Podc
d69be2563c9f1929edf2906d41809aea 53
# 31 MuckRackFeedParse
62b46fff1cf5f8af7b4b37a2f783b57a 31
# 21 Mozilla/5.0 (Wind
6b9a00393fb1607b0ada13520f814ab5 21
# 20 axios/1.6.8
b534882134248c9a5957e0c011a37037 20
# 17 itms
2e7f714a929b3f52f3c094710819a99a 17
# 15 atomstr/0.9.13
fed9820e6b1b919d848e718e0bf49e41 15
# 14 Gofeed/1.0
4a9d728c458902d6ff716779ff72841d 14
# 10 Mozilla/5.0 (Maci
54dc9f5354b7a13af97c59945268465e 10
I have updated the RSS efficiency page description to include hashtags for the worst offenders in the slight hope of making their sloppiness more visible across the Fediverse. Shame may yet have an effect...
: Low Frequency and Voltage
I am seeing quite a lot of low frequency (ie a national GB grid issue) and low voltage (probably local) today around . I wonder, not for the first time, if our DNO (UKPN) does automatic voltage reduction in response to persistent low frequency, but again I cannot quickly find anything on-line supporting that.
And low voltage might just be all my neighbours cooking lunch...
I also note that I have my low-voltage threshold set at ~235.5V, which results in few by some triggers here at 16WW, whereas the nominal target supply voltage is 230V (216.2V to 253V). Maybe I should drop my threshold a tad, not to exactly 230V however! It does not seem as if voltage at 16WW has ever been seen by the Eddi as below 230V (in 10-minute samples going back to ).
Import vs export diverting thoughts
Maybe the system should block or limit diversion, eg diversion to the heat battery above 'not cold' or 'nearly full', while net imports for the day are positive. Better might be to limit diversion while net carbon emissions for the day so far (or last 24h) are positive.
The former can be done very simply something like this, with the result being net kWh (or Wh in second case) imported today so far:
% sh script/myenergi/eddiDaySummary.sh | \
awk -F, '{print $5-$6}'
-0.507
% sh script/myenergi/eddiDaySummary.sh | \
awk -F, '{print int(1000*($5-$6))}'
-507
The latter integer value is easier to use in a shell test expression.
A more diagnostic by-hour view is given by:
% sh script/myenergi/eddiDaySummary.sh -byHour | \
awk -F, '{netimp+=$5-$6; print $1,netimp}'
2026-03-14T00:00Z 0.04
2026-03-14T01:00Z 0.075
2026-03-14T02:00Z 0.112
2026-03-14T03:00Z 0.153
2026-03-14T04:00Z 0.191
2026-03-14T05:00Z 0.233
2026-03-14T06:00Z 0.721
2026-03-14T07:00Z 0.81
2026-03-14T08:00Z 0.883
2026-03-14T09:00Z 0.962
2026-03-14T10:00Z 0.696
2026-03-14T11:00Z 0.362
2026-03-14T12:00Z -0.022
2026-03-14T13:00Z 0.066
2026-03-14T14:00Z -0.12
2026-03-14T15:00Z -0.302
2026-03-14T16:00Z -0.667
2026-03-14T17:00Z -0.585
2026-03-14T18:00Z -0.554
2026-03-14T19:00Z -0.46
2026-03-14T20:00Z 0.017
Some inspection of dates in suggests that restricting until net exporting may not add much value on top of waiting until solar noon.
Note that this Eddi import/output measure would be somewhat conservative, as the Eddi tends to over-read imports. Eg at ~ the Eddi reports import and export at ~2.1kWh each, whereas the Enphase reports ~1.3kWh import and ~2.1kWh export.
: high frequency
There are occasional excursions up to and above 50.1Hz. (Nothing is seen in all the Eddi 10-minute samples at 50.3Hz.) 16WW's response is only currently to frequencies below 49.1Hz.
% egrep -c '"frq":50.[12]' data/eddi/log/live/202603??.log
data/eddi/log/live/20260301.log:19
data/eddi/log/live/20260302.log:10
data/eddi/log/live/20260303.log:22
data/eddi/log/live/20260304.log:15
data/eddi/log/live/20260305.log:21
data/eddi/log/live/20260306.log:22
data/eddi/log/live/20260307.log:5
data/eddi/log/live/20260308.log:18
data/eddi/log/live/20260309.log:16
data/eddi/log/live/20260310.log:18
data/eddi/log/live/20260311.log:18
data/eddi/log/live/20260312.log:17
data/eddi/log/live/20260313.log:20
data/eddi/log/live/20260314.log:18
% wc -l data/eddi/log/live/202603??.log
144 data/eddi/log/live/20260301.log
% egrep -c '"frq":49.[0-8]' data/eddi/log/live/202603??.log
data/eddi/log/live/20260301.log:21
data/eddi/log/live/20260302.log:21
data/eddi/log/live/20260303.log:24
data/eddi/log/live/20260304.log:33
data/eddi/log/live/20260305.log:29
data/eddi/log/live/20260306.log:15
data/eddi/log/live/20260307.log:29
data/eddi/log/live/20260308.log:13
data/eddi/log/live/20260309.log:26
data/eddi/log/live/20260310.log:16
data/eddi/log/live/20260311.log:32
data/eddi/log/live/20260312.log:31
data/eddi/log/live/20260313.log:24
data/eddi/log/live/20260314.log:14
This means that there may be a case to allow diversion when otherwise blocked at or above 50.1Hz to help limit high-frequency excursions. Such response might roughly balance 'lost' diversion from responding to low frequency.
At the moment my focus is on reducing diversion to favour heat pump DHW production, but this may be a useful trick to hold in reserve.
: Thermino Monitoring Bugs
It turns out that there were multiple bugs in the script that monitors the Thermino heat battery, including not detecting and not reporting the new 'not cold' state upstream to the main server. Now fixed, having helpful live system state to test against...
Other factors today meant that in practice it made no difference to diversion. Reporting/logging is correct now too.
I have tweaked how the 'not cold' threshold is measured to reduce overshoot. That threshold detail might have made a slight difference to diversion today.
A late evening shower, during the DHW evening run, extracted much of the stored energy from the heat battery, which is good.
While having fun I stripped out some Enphase data dependencies that have been broken for a long time since the local data feed termination. This should save a bit of log space and CPU time.
: Mastodon Social Media Share Button
A new Share button for Mastodon has arrived, here as a plain link: Share on Mastodon
I will add this to all main/top desktop pages for two reasons. The obvious one is to help get EOU pages shared. The other is to increase visibility of Mastodon and the Fediverse generally!
I am going with an initial minimal foot-of-page button:
Yes, including the page's URL in the toot is the whole point, why do you ask?
: shunned
I have inserted a #EOU tag at the end of the generated toot text to make it easier to see if anyone has used this shiny new toy by searching for that tag. I do not think that anyone has, yet!
: End of Month Work Spread
An array of stats is captured around each EOM (End of Month). The process starts with meter readings taken nominally ~ local time of the last day of the month, after any evening meal has been cooked (and eaten). First thing in the morning of the first of the next month HDD and Enphase monthly stats are captured. Then in the hour after UTC, when there is most likely to be some incoming sunshine,
cron jobs on the main and heat-battery RPis capture (often compressed) monthly versions of various logs.
Those jobs were both running nearly at the end of the hour. I moved the smaller task (on pekoe for the Thermino heat battery) earlier a little so that manually committing that data to SVN and pulling it out elsewhere can be separated from the main server RPi work somewhat.
Pre-load?
For about an hour this afternoon the grid was 'green' intensity (G), with intensity predicted to rise by at least a fact of 3 over the next ~48h (P):
% egrep ' F[^ ]*P' data/heatBattery/log/live/20260301.log 2026-03-01T14:31Z MT 0 GI 44 IT 41 F FGqPbvx1N ES 1 2026-03-01T14:36Z MT 0 GI 44 IT 41 F FGqPbvx1N ES 1 2026-03-01T14:41Z MT 0 GI 44 IT 41 F FGqPbvx1N ES 1 2026-03-01T14:46Z MT 0 GI 44 IT 41 F FGqPbvx1N ES 1 2026-03-01T14:51Z MT 0 GI 45 IT 41 F FGqPbvx1N ES 1 2026-03-01T14:56Z MT 0 GI 45 IT 41 F FGqPbvx1N ES 1 2026-03-01T15:01Z MT 0 GI 46 IT 41 F FGqPbvx1N ES 1 2026-03-01T15:06Z MT 0 GI 48 IT 41 F FGqPbvx1N ES 1 2026-03-01T15:11Z MT 0 GI 51 IT 41 F FGqPbvx1N ES 1 2026-03-01T15:21Z MT 0 GI 51 IT 41 F FGqPbvx1N ES 1 2026-03-01T15:31Z MT 0 GI 55 IT 41 F FGqPbvx1N ES 1
There was a similar interval on .
It would possibly have been worthwhile from an emissions point of view to at least partly load up the heat battery, maybe just to the 'not-cold' level, to reduce subsequent heat-pump demand, though some gas generators were being turned up in England around that time.
: steeper
There was then half an hour or so of P (and G) coming up to midnight, and through this morning. But again, there were at least some constraints on the GB grid by ~
with wind turned down in Scotland and gas turned up in England.
There may be a case for boosting the Thermino a little, to at least 'not cold', or less controversially removing some daytime restrictions on PV diversion, in such G and P periods. But maybe only outside (GB or SSES) peak demand times. Ideally also only if there are no fossil generation turn-ups!
All of those P samples so far in , and in , seem to already be G.