
Nice, this is one of those automations that pays for itself the first winter. Two small things that might make it nicer to live with:
The loop with the namespace can be a one-liner, and you can limit it to the next couple of days so a cold snap six days out doesn’t nag you every morning all week:
{{ (daily['weather.forecast_home'].forecast[:2]
| map(attribute='templow') | min) < minTemp }}
And to stop repeat alerts once you’ve actually done the work, pair it with an input_boolean like outdoor_water_winterized: add it as a condition (only notify when off), send the notification with an actionable button (“Done”) from the companion app, and have the button event flip the boolean on. Then a second automation turns it back off when the forecast lows climb above, say, 8 °C for a few days in spring. That also covers curbstickle’s point if you ever add more taps, one boolean per tap.
Adding to the Workers theory: if it is a Worker, Cloudflare adds a
CF-Workerrequest header to every subrequest a Worker makes, and its value is the zone the Worker belongs to (e.g.something.workers.devor the owner’s own domain). It’s not something the script can strip, so if you add that header to your reverse proxy’s log format you should be able to see exactly whose Worker is probing you.That gives you two practical options: report it through Cloudflare’s abuse form with the zone name (they do act on Workers being used for scanning), and/or drop any request that carries a
CF-Workerheader at the proxy, since nothing legitimate should be hitting a DNS-only Lemmy host through a Worker anyway. Federation traffic from other instances won’t have it.