Earth Notes: On Website Technicals (2026-10)

I am watching in my logs a very persistent bot pulling about 1 page per second, claiming to be Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36, which when blocked at a firewall comes in from a new address within seconds, often in a different country, always apparently from a hosting company.

This is well-resourced content theft by the smell of it.

# 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-10-19T11:04+00:00 (UTC)
# MAXHITSPERUAPERDAY: 10
# MAXUAS: 25
#----------------
# request-count User-Agent
# MD5hash approx-hits-per-day
#----------------
# 202 Spotify/1.0
4582d9bdbcef42af27d89da91c6eb804 202
# 142 Google-Podcast
8dea568b39db0451edd6b30f29238eaf 142
# 59 iTMS
97f76eb7e02c5ff923e1198ff1c288cd 59
# 47 Amazon Music Podc
d69be2563c9f1929edf2906d41809aea 47
# 46 atomstr/0.9.13
fed9820e6b1b919d848e718e0bf49e41 46
# 37 axios/1.6.8
b534882134248c9a5957e0c011a37037 37
# 35 Mozilla/5.0 (Maci
dbb1533fc27ea415389d2e9c70c8e051 35
# 35 Mozilla/5.0 Apple
fac378ac3b3d3886829021b3309d4fd1 35
# 31 MuckRackFeedParse
62b46fff1cf5f8af7b4b37a2f783b57a 31
# 27 Mozilla/5.0 (Wind
6b9a00393fb1607b0ada13520f814ab5 27
# 20 itms
2e7f714a929b3f52f3c094710819a99a 20
# 11 TPA/1.0.0
86e71fcf5ba78d28f18270f7f83256bb 11

In script/heat-battery-target.sh I have just pushed out the maximum interval between pasteurisation runs, eg from the grid even in the absence of 'green' (low-carbon-intensity) hours, from 30 days to 33 days to slightly reduce demand, avoid any multiple of 7 days, and still keep such last-resort runs to roughly monthly.

When the router is off-grid (~10W) and the MBA shows that it is getting ~20W, the solar controller shows ~40W being drawn, ie ~10W goes missing.

I have checked/swapped/measured various points in the system, and do not seem to be losing more than ~1–2W in the wiring to upstairs, and nothing obvious in the 12V switched cigar-lighter circuit at my desk. Even swapping out the final USB-C cable for a fatter one seems nugatory. Maybe the 12V car charger really is turning ~8W into heat, though it does not seem hot enough for that...

I will recheck my wiring run at leisure to make sure that resistance has been minimised by use of cores etc.

Apparently the scheduler bug I reported 3 years ago is about to be fixed.

Since I am trying to keep my MBA entirely off-grid while at home, though may not succeed as the days get shorter, yesterday and today I simplified my AlDente setup by disabling half the schedule rules (leaving 3). Now all that happens is being forced into lowpowermode as peak time starts (but not out afterwards, so leaving it low), and halving the charge limit during peak time to deter charging.

If I want out of lowpowermode I will adjust it manually; easy.

Seeing AlDente-reported MBA power consumption under 3W in light evening use; down to ~2.3W at times.

Importing

This week we started to import from the grid overall:

Last October had net electricity emissions of 11kgCO2e:

Net electricity utility energy kgCO2e over last 12 calendar months (before 2026-10): -64

Net kgCO2e for each of the last 12 full calendar months: 11 27 42 52 28 -2 -22 -40 -52 -60 -40 -8

Possible HTML output micro-optimisation

Looking at minified HTML output it seems that almost any paragraph close at EOL (and preceding and trailing whitespace) could be safely stripped, such as with a *</p> *$ regex. An exception is a paragraph wrapped in <ins>.

Every time I have tried Enphase ToU tariff stuff it has been very broken, but I would like another go, in case it still exists and is better now!

My aim is to avoid putting on the grid in winter in the peak demand window our typical cooking load of 1kWh+ between ~17:00 and ~18:00.

I think that to achieve this, all year or from October to February, during the day accumulate a reserve of ~xkWh of battery charge. If the battery has >xkWh stored, or after 17:00 (to midnight nominally), then the battery can cover loads automatically in the normal way. x is somewhere between 1 and 3; mid-winter generation is ~1.5kWh/d.

The Enphase response (2026-10-21) was:

The AC Batteries can only discharge to power your home; they cannot intentionally export stored energy back to the grid. This feature is only available on IQ Battery 5P. We can only enable grid charging to charge the batteries during off-peak hours.

If you want true ToU management with grid export capabilities, you would need to upgrade your system to an IQ Battery 5P.

2026-10-30: discharge to grid not required

I am not asking to export to the grid on demand.

To repeat:

What I'd like to have is that all year or from October to Feb, during the day accumulate a reserve of ~1kWh of battery charge to allow to discharge between 5pm and 6pm local time. If the battery has > 1kWh stored, or after 5pm, it can cover loads.

Can that be done please?

2026-11-03: Enphase firmware says no

Unfortunately, this isn't possible with your AC batteries; they can't be set up through the settings. If they are sufficiently charged by 5 PM, they will discharge to cover the home's energy load.

2026-11-06: fixed winter overnight charge?

With my equipment is it possible for it to be set up to charge up to AT MOST (say) 25% charge LEVEL between 03:00 and 05:00 between October and February inclusive?

That is, if the battery was already at or above the specified level it would not attempt to charge?

I don’t have a ToU tariff but I am interested in adjusting my grid demand profile.

A second best would be to have the system charge for an hour or two from 03:00 between October and February inclusive.

This would waste some energy ~10%?) being cycled through the battery, but would significantly reshape our morning demand curve, silently.

A more extreme load profile reshape might be to fully charge the battery (~6kWh) from November to February inclusive by ~05:30 when demand is starting to ramp, which implies starting at ~00:30 (ie ~5h for a full charge. Running loads such as the DHW morning 'comfort' heat-up or pasteurisation, and any dishwasher overnight wash, while the batteries charge (or at least may be set not to discharge) would save for later the battery capacity that these loads would otherwise have used (~0.5kWh, ~0.7kWh). It would then be possible to serve most of a typical winter day's total ~10kWh consumption from battery rather than grid. The battery charge probably would not last into the early evening cooking peak, especially on the coldest days, but might help, with any PV generation during the day a bonus. The battery round-trip losses would inflate demand a bit, but the demand curve would be a lot kinder to the DNO at least.

There is typically a little GB demand peak at ~00:30, probably from Economy 7, so starting around 01:00, not on the half-hour boundary, might be better. Letting the batteries start to discharge for the SSES morning peak of 08:00 might conserve a little charge for later in the day. Moving the DHW early run back to finish before 05:30 would help avoid contributing to the morning demand rise slew. The present Eddi Grid Limit of 8A should probably rise to ~10A to help ensure that a pasteurisation cycle, now competing with battery charging, can complete within any window of low carbon intensity in one session.

Inspecting mean all-days consumption data for 2026-01, hourly net grid import W (column 4) from 08:00 up to 19:00 end of peak:

08:00,31,NaN,718,NaN,271
09:00,31,NaN,482,NaN,290
10:00,31,NaN,407,NaN,349
11:00,31,NaN,355,NaN,351
12:00,31,NaN,205,NaN,205
13:00,31,NaN,199,NaN,194
14:00,31,NaN,244,NaN,232
15:00,31,NaN,309,NaN,238
16:00,31,NaN,378,NaN,354
17:00,31,NaN,997,NaN,655
18:00,31,NaN,397,NaN,185

yields cumulative net Wh consumption up to the end of each given hour:

08:00,718
09:00,1200
10:00,1607
11:00,1962
12:00,2167
13:00,2366
14:00,2610
15:00,2919
16:00,3297
17:00,4294
18:00,4691

Thus 6kWh of capacity released starting from 08:00 onwards might cover net (of PV) consumption though the evening peak. The cut-over should be some minutes before 08:00 to avoid 'herding' at the SSES and half-hourly pricing boundary. Avoiding the 00:30 Economy 7 bump would be good, if possible.

2026-11-09: amended request

Having not yet had a response, and given the above thinking, I sent an email to set my Enphase system do the following:

• During the months of November, December, January, February only
• Set the battery to charge from grid (and not discharge to support loads) between 00:45 and 07:45 each morning, or as close as possible.

2026-11-10: bot

Trying to hurry this along ... the online Enphase AI chat bot this evening says:

This kind of seasonal, time-based charging schedule requires manual setup by Enphase Support — it's not something homeowners can configure directly in the app for your AC Battery system.

That connection was dropped after about 40 minutes, so I started a new one, which in passing said:

Seasonal timing: The schedule tool can't limit itself to November through February, so you'd need to disable or remove the schedule outside those months in the Enphase app.

I have spent ~2h waiting so far, with no available information on wait time, or if I am waiting for someone in the UK to answer, well out of hours...

Eventually the session got more and more broken and I tried switching browser (from Firefox to Chrome), and this time I get to see the number in the queue ahead of me. Which the AI agent claimed was not available...

Finally got through to a human at midnight after ~4.5h waiting!

I am having real difficulty getting support to understand that I do not want to discharge to the grid, and that I want to charge from the grid overnight as above. It used to be possible in some form, it just did not work well.

Infuriating

Enphase Agent

Sure! I am reviewing the details with my resources. Please allow me 4-5 minutes.

Enphase Agent

It seems you've been inactive for 4 minutes. Reply now or this session will end due to inactivity.

Better, just before 1am...

I have set the charge from the grid option in the backend.

By ~01:30 no charging was yet happening. There will be follow-up by email, I am told.

The System -> Live Status page is working for the first time in months, and is showing a new 'Profile' gear wheel set to Self-Consumption.

Currently the system has been set by support to charge from 00:00 until 08:00, not limited to Nov–Feb.

(It seems that timing granularity for grid charge is whole hours, which is slightly unfortunate from a 'herding' point of view.)

No charging is happening as of 01:42Z as I write.

2026-11-11: partial charge but overnight fight

The battery seems to have acquired a ~40% (~2.4kWh) charge by 06:00 and stopped charging. (The 5 ACB units are at between 31% and 43% SoC at 08:32Z.)

Naturally, that coincided at least partly with an attempted pasteurisation in a very brief 'super-green' grid window from about 02:45, which meant that the pasteurisation attempt got only ~2kWh and did not complete.

I am bumping the Eddi grid limit to 12A (from 8A) to reduce that grid boost pasteurisation failure risk.

Just before 09:00 I am in chat to see if we can resolve at least why charging stopped at 06:00. The Enphase AI bot has observed:

• Charging started: around 03:45, with the state of charge rising from 0% to 45% by 05:45.
• Charging stopped: at 06:00. Grid charge energy dropped to near zero, and the state of charge was 44% at that point.
• Discharge began: at 06:00, as the batteries started supplying the home. The state of charge then fell to 37% by 08:30.

Did not get through on chat before I had to leave the house. Tried again at ~11:00 and got to a human ~12:30. I am promised (13:00) an email back.

As of 19:42 (and with ~2kWh of PV generation) there is still ~1.5kWh left in the battery, and more than half of peak time (cooking) consumption was covered from the battery. Hurrah!

2026-11-12: full charge and pasteurised!

By goodness, I think we have it! Full Enphase ACB charge (6.2kWh) and DHW pasteurisation cycle (~3.1kWh/~3h20), with the heat pump providing space heat from the grid after 07:00, mainly kept to under 2kWh to reduce I^2R losses!

Enphase support notes in response to my email asking why in this case the transitions where not exactly on the hour (which is good):

So, while the schedule is configured for 12:00 AM to 8:00 AM, it is normal to see charging begin slightly after midnight and the battery start supporting loads a little before 8:00 AM. As you noted, this can help avoid abrupt transitions and generally results in smoother operation.

(In Enphase Enlighten the System -> Live Status has stopped working again.)

Today has been sunny enough (3.7kWh of PV generation by 13:25Z) that the battery refilled, and PV spilled a little to grid (0.4kWh) and Themino (0.4kWh)! One way or another total consumption will go up a bit from battery losses, and self-consumption will drop a bit from effects such as this.

(The following day was similar with a bit more spilled to grid and Thermino by late afternoon: possibly switching to discharge before 07:00 would have balanced things a bit better.)

By the end of typical GB peak demand at 19:00 the battery was still nearly 75% full. Over half of demand during cooking had been covered 17:00–17:45, limiting demand to ~1kW at most. At midnight the battery was over one third full still.

It is possible that a slightly better demand profile would come from charging 01:00–07:00 sinking slightly deeper into the grid demand overnight dip, but that would require carrying an extra ~900Wh demand from 07:00, which might endanger mitigating peak-time loads around 18:00 on cold days (high space heat demand) and little PV generation.

2026-11-14: manual support required

I had asked support if this grid-charge setting could be set to be seasonal as used to be the case, but:

Unfortunately, the current battery profile and tariff configuration do not support automatically enabling "Charge from Grid" only during specific months of the year (for example, November through February) and then disabling it for the remainder of the year.

The charging schedules and battery profiles can be configured with time-of-day settings, but there is currently no seasonal scheduler that automatically switches the Charge from Grid setting on and off based on the month.

So I shall have to set myself diary entries and contact support for manual adjustments in early November and late February, aiming for ~90 days (ie one quarter) centred on the winter solstice. That would be more like 6th November to 4th Feb, so maybe Nov/Dec/Jan rounded?

Added today, charts for gen vs net grid flow.

I do not want to let 12GB be absorbed by features that I do not want to use. (The 12GB is visible when examining About this Mac ... Storage ... macOS.)

% df -h .
Filesystem        Size    Used   Avail Capacity iused ifree %iused  Mounted on
/dev/disk3s5     926Gi   737Gi   164Gi    82%    3.6M  1.7G    0%   /System/Volumes/Data
% brew install omlahore/tap/removemacai
% removemacai
% df -h .
Filesystem        Size    Used   Avail Capacity iused ifree %iused  Mounted on
/dev/disk3s5     926Gi   736Gi   165Gi    82%    3.6M  1.7G    0%   /System/Volumes/Data
% removemacai status
RemoveMacAI 0.2.5  ·  macOS 27.0

Features
  Siri and Siri AI                        off (locked)
  ChatGPT and other AI extensions         off (locked)
  Writing Tools                           off (locked)
  Genmoji                                 off (locked)
  Image Playground                        off (locked)
  Mail summaries and smart replies        off (locked)
  Notification summaries                  off (locked)
  Messages summaries                      off (locked)
  Safari summaries                        off (locked)
  Notes transcription summaries           off (locked)
  Inline text predictions                 off (locked)
  Spatial Photos                          off (locked)
  Photos Clean Up                         off (locked)
  Xcode predictive code completion        off (locked)

Models on disk
  Apple Intelligence foundation models    none
  Image and Genmoji models                none
  Spatial Photos models                   none
  Photos Clean Up models                  none
  Xcode code completion models            none
  Total                                   0 MB
  macOS removes deleted model files itself, so System Settings can count them for a while.

Apple Intelligence is off. Undo with: removemacai revert

2026-10-09: going...

% df -h .
Filesystem      Size    Used   Avail Capacity iused ifree %iused  Mounted on
/dev/disk3s5   926Gi   728Gi   172Gi    81%    3.6M  1.8G    0%   /System/Volumes/Data

It is (now) possible to vary the Eddi's Export Margin via the app, ie remotely, but MyEnergi will not even informally publish that part of the API for the rest of us.

If I had the facility, rather than the current fixed 300W, I think I would lower the margin to 100W, or as low as reasonably possible (maybe 50W), to play nicely with the Enphase battery:

1. During a pasteurisation cycle, to maximise the chance of it completing.
2. When the grid is super-green (or pricing negative), ie has an abundance of low-carbon generation.
3. When the heat battery is cold and the grid carbon intensity not high/red.

I might also raise the Export Margin above 300W when the heat battery is nearly full to aim to just fill it by peak time.

Google-Podcast reported

I filled in the Google Search Central Overcrawling Report form for Google-Podcast, for its ~140 polls per day of an RSS feed that is unchanged since January, and where an initial 429 response is followed by another five requests that each also receive 429.

Completely ignores 429 status and Retry-After and repolls *immediately* 5 times after the first 429. The RSS podcast feed it polls has not changed since January. This is an absurd waste of energy and carbon budget.

www.earth.org.uk:443 173.194.94.68 - - [05/Oct/2026:19:07:03 +0000] "HEAD /rss/podcast.rss HTTP/1.1" 429 5204 "-" "Google-Podcast"
www.earth.org.uk:443 173.194.94.68 - - [05/Oct/2026:19:07:04 +0000] "GET /rss/podcast.rss HTTP/1.1" 429 5768 "-" "Google-Podcast"
www.earth.org.uk:443 173.194.94.68 - - [05/Oct/2026:19:07:10 +0000] "HEAD /rss/podcast.rss HTTP/1.1" 429 5204 "-" "Google-Podcast"
www.earth.org.uk:443 173.194.94.68 - - [05/Oct/2026:19:07:10 +0000] "GET /rss/podcast.rss HTTP/1.1" 429 5768 "-" "Google-Podcast"
www.earth.org.uk:443 173.194.94.68 - - [05/Oct/2026:19:07:21 +0000] "HEAD /rss/podcast.rss HTTP/1.1" 429 5204 "-" "Google-Podcast"
www.earth.org.uk:443 173.194.94.68 - - [05/Oct/2026:19:07:21 +0000] "GET /rss/podcast.rss HTTP/1.1" 429 5768 "-" "Google-Podcast"

See also Googlebot Still Rogue...