From Newsgroup: comp.sys.raspberry-pi

As part of my enhancements to the home controller, I want to send email warnings of low heating oil level.

So I removed exim which was too much like hard work, installed PostFix
and all is well...,except it isn't.

If I send a mail out of the blue after a a few hours delay, the mail immediately *always* gets stuck in the queue with a message about being
unable to determine the IP address of the SMTP relay.

If I send another message everything Just Works, and indeed the h mail
queue gets flushed eventually as well with a successful delivery.

I have looked on line but not found this exact behaviour mentioned
anywhere..

I am not sure what is running DNS on that Zero W right now. But its
clo9ck is up to date with the internet...,
--
Future generations will wonder in bemused amazement that the early twenty-first century’s developed world went into hysterical panic over a globally average temperature increase of a few tenths of a degree, and,
on the basis of gross exaggerations of highly uncertain computer
projections combined into implausible chains of inference, proceeded to contemplate a rollback of the industrial age.

Richard Lindzen
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

The Natural Philosopher <tnp@invalid.invalid> wrote:

As part of my enhancements to the home controller, I want to send email warnings of low heating oil level.

So I removed exim which was too much like hard work, installed PostFix
and all is well...,except it isn't.

If I send a mail out of the blue after a a few hours delay, the mail immediately *always* gets stuck in the queue with a message about being unable to determine the IP address of the SMTP relay.

If I send another message everything Just Works, and indeed the h mail
queue gets flushed eventually as well with a successful delivery.

'Greylisting'? SMTP servers often delay mail from unrecognised senders as a spam block - spammers tend not come back when told to try again later.

Also the message needs to be correct to match SFP/DKIM/DMARC rules,
otherwise it may get delayed or discarded. It may also be delayed/discarded due to sending from a 'consumer' IP.

Perhaps by the time the second message arrives the spamfilter has decided you're ok and to let the message straight through.

I would not be doing direct SMTP in this day and age - send using an SMTP account (with username/password) at the company who runs the SMTP server for the sender's mail domain.

If the SMTP relay is indeed your domain's mail server, perhaps the first
time DNS lookup is too slow?

Theo
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 18/11/2025 14:37, Theo wrote:

The Natural Philosopher <tnp@invalid.invalid> wrote:

As part of my enhancements to the home controller, I want to send email
warnings of low heating oil level.

So I removed exim which was too much like hard work, installed PostFix
and all is well...,except it isn't.

If I send a mail out of the blue after a a few hours delay, the mail
immediately *always* gets stuck in the queue with a message about being
unable to determine the IP address of the SMTP relay.

If I send another message everything Just Works, and indeed the h mail
queue gets flushed eventually as well with a successful delivery.

'Greylisting'? SMTP servers often delay mail from unrecognised senders as a spam block - spammers tend not come back when told to try again later.

Its my smtp server. Sorry I didn't make that clear. No greylisting that
I am aware of

Also the message needs to be correct to match SFP/DKIM/DMARC rules,
otherwise it may get delayed or discarded. It may also be delayed/discarded due to sending from a 'consumer' IP.

Again, there is no issue as its set to accept any mail from anywhere
that is addressed to my home network.

Perhaps by the time the second message arrives the spamfilter has decided you're ok and to let the message straight through.

Seriously,m its not the server, its the DNS.

It (the PI) cant even *find* the SMTP server
Nov 18 10:46:56 heating-controller postfix/pickup[8654]: CC05B1F270:
uid=0 from=<oil-monitor@heating-controller>
Nov 18 10:46:56 heating-controller postfix/cleanup[10455]: CC05B1F270: message-id=<20251118104656.CC05B1F270@heating-controller>
Nov 18 10:46:56 heating-controller postfix/qmgr[1295]: CC05B1F270: from=<oil-monitor@heating-controller>, size=387, nrcpt=1 (queue active)
Nov 18 10:46:57 heating-controller postfix/smtp[10457]: CC05B1F270: to=<superroot@templar.co.uk>, relay=none, delay=0.38,
delays=0.19/0.14/0.04/0, dsn=4.4.3, status=deferred (Host or domain name
not found. Name service error for name=vps.templar.co.uk type=MX: Host
not found, try again)
Nov 18 10:56:42 heating-controller postfix/qmgr[1295]: CC05B1F270: from=<oil-monitor@heating-controller>, size=387, nrcpt=1 (queue active)
Nov 18 10:56:43 heating-controller postfix/smtp[10697]: CC05B1F270: to=<superroot@templar.co.uk>,
relay=vps.templar.co.uk[185.113.128.151]:25, delay=587, delays=586/0.22/0.64/0.08, dsn=2.0.0, status=sent (250 OK
id=1vLJO7-0000r9-GS)
Nov 18 10:56:43 heating-controller postfix/qmgr[1295]: CC05B1F270: removed

I would not be doing direct SMTP in this day and age - send using an SMTP account (with username/password) at the company who runs the SMTP server for the sender's mail domain.

Sigh. I do for mail outward bound, but this is actually inward boiund.

If the SMTP relay is indeed your domain's mail server, perhaps the first
time DNS lookup is too slow?

Its something like that.

Let me say that all other boxes inside the network that are equipped for
mail work fine

Theo

--
For every complex problem there is an answer that is clear, simple, and
wrong.

H.L.Mencken

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

In message <10fhnjv$1gvnc$5@dont-email.me>
The Natural Philosopher <tnp@invalid.invalid> wrote:

As part of my enhancements to the home controller, I want to send email warnings of low heating oil level.

Have a look at Pushover to see if it would be an alternative way to
meet your needs. I use it to alert myself of problems in my heating
system.

David
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 18/11/2025 16:19, David Higton wrote:

In message <10fhnjv$1gvnc$5@dont-email.me>
The Natural Philosopher <tnp@invalid.invalid> wrote:

As part of my enhancements to the home controller, I want to send email
warnings of low heating oil level.

Have a look at Pushover to see if it would be an alternative way to
meet your needs. I use it to alert myself of problems in my heating
system.

David

my system is tailored to my needs. It works perfectly. I just need to
extend it a little. Nothing I can buy suited, so I rolled my own with
Pis and Picos.

Its actually one of the best bits of hardware and software I have ever done.

BUT it seems that the Pi will retry the queued mail and get it right on
the second attempt, so I may just leave it...
--
“A leader is best When people barely know he exists. Of a good leader,
who talks little,When his work is done, his aim fulfilled,They will say,
“We did this ourselves.”

― Lao Tzu, Tao Te Ching

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

The Natural Philosopher <tnp@invalid.invalid> wrote:

Seriously,m its not the server, its the DNS.

It (the PI) cant even *find* the SMTP server
Nov 18 10:46:56 heating-controller postfix/pickup[8654]: CC05B1F270:
uid=0 from=<oil-monitor@heating-controller>
Nov 18 10:46:56 heating-controller postfix/cleanup[10455]: CC05B1F270: message-id=<20251118104656.CC05B1F270@heating-controller>
Nov 18 10:46:56 heating-controller postfix/qmgr[1295]: CC05B1F270: from=<oil-monitor@heating-controller>, size=387, nrcpt=1 (queue active)
Nov 18 10:46:57 heating-controller postfix/smtp[10457]: CC05B1F270: to=<superroot@templar.co.uk>, relay=none, delay=0.38, delays=0.19/0.14/0.04/0, dsn=4.4.3, status=deferred (Host or domain name
not found. Name service error for name=vps.templar.co.uk type=MX: Host
not found, try again)

If it's the only network activity the thing does regularly, maybe
the WiFi interface has gone into some sort of sleep mode and the DNS
resolver isn't waiting for it to wake up. If you leave ping running
(eg. "nohup ping -s 1 vps.templar.co.uk &") to keep the interface
active, maybe it will work the first time?

Or if it doesn't change, you could set the IP address for
vps.templar.co.uk in /etc/hosts.
--
__ __
#_ < |\| |< _#
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 18/11/2025 21:08, Computer Nerd Kev wrote:

The Natural Philosopher <tnp@invalid.invalid> wrote:

Seriously,m its not the server, its the DNS.

It (the PI) cant even *find* the SMTP server
Nov 18 10:46:56 heating-controller postfix/pickup[8654]: CC05B1F270:
uid=0 from=<oil-monitor@heating-controller>
Nov 18 10:46:56 heating-controller postfix/cleanup[10455]: CC05B1F270:
message-id=<20251118104656.CC05B1F270@heating-controller>
Nov 18 10:46:56 heating-controller postfix/qmgr[1295]: CC05B1F270:
from=<oil-monitor@heating-controller>, size=387, nrcpt=1 (queue active)
Nov 18 10:46:57 heating-controller postfix/smtp[10457]: CC05B1F270:
to=<superroot@templar.co.uk>, relay=none, delay=0.38,
delays=0.19/0.14/0.04/0, dsn=4.4.3, status=deferred (Host or domain name
not found. Name service error for name=vps.templar.co.uk type=MX: Host
not found, try again)

If it's the only network activity the thing does regularly, maybe
the WiFi interface has gone into some sort of sleep mode and the DNS
resolver isn't waiting for it to wake up. If you leave ping running
(eg. "nohup ping -s 1 vps.templar.co.uk &") to keep the interface
active, maybe it will work the first time?

I was logged in over ssh at the time, so that hound don't hunt :-(

Or if it doesn't change, you could set the IP address for
vps.templar.co.uk in /etc/hosts.

That could be a workaround. Good idea
--
All political activity makes complete sense once the proposition that
all government is basically a self-legalising protection racket, is
fully understood.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 18/11/2025 12:08, The Natural Philosopher wrote:

As part of my enhancements to the home controller, I want to send email warnings of low heating oil level.

This sounds rather like something I have been planning to do. AAMOI how
are you measuring the oil level?
--
Cheers,
Daniel.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On Tue, 18 Nov 2025 15:27:01 +0000, The Natural Philosopher wrote:

Seriously,m its not the server, its the DNS.

What are you running as your DNS server?

Nov 18 10:46:57 heating-controller postfix/smtp[10457]: CC05B1F270: to=<superroot@templar.co.uk>, relay=none, delay=0.38, delays=0.19/0.14/0.04/0, dsn=4.4.3, status=deferred (Host or domain
name not found. Name service error for name=vps.templar.co.uk
type=MX: Host not found, try again)

You could try doing a lookup (using host or dig) to your DNS server
from the Raspberry pi at the same time as the MTA is reporting
problems, and see if your manual query reports the same problem.

Does your /etc/resolv.conf contain the right info? Is it a symlink to
somewhere else?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 18.11.2025 15:27 Uhr The Natural Philosopher wrote:

from=<oil-monitor@heating-controller>

That is your first problem. Us a real existing address for that.

Do you want to run you own mail domain or do you just want to use a
freemail account for sending that out?
--
kind regards
Marco

Send spam to 1763476021muell@stinkedores.dorfdsl.de

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

The Natural Philosopher <tnp@invalid.invalid> writes:

On 18/11/2025 21:08, Computer Nerd Kev wrote:

The Natural Philosopher <tnp@invalid.invalid> wrote:

Seriously,m its not the server, its the DNS.

It (the PI) cant even *find* the SMTP server
Nov 18 10:46:56 heating-controller postfix/pickup[8654]: CC05B1F270:
uid=0 from=<oil-monitor@heating-controller>
Nov 18 10:46:56 heating-controller postfix/cleanup[10455]: CC05B1F270:
message-id=<20251118104656.CC05B1F270@heating-controller>
Nov 18 10:46:56 heating-controller postfix/qmgr[1295]: CC05B1F270:
from=<oil-monitor@heating-controller>, size=387, nrcpt=1 (queue active)
Nov 18 10:46:57 heating-controller postfix/smtp[10457]: CC05B1F270:
to=<superroot@templar.co.uk>, relay=none, delay=0.38,
delays=0.19/0.14/0.04/0, dsn=4.4.3, status=deferred (Host or domain name >>> not found. Name service error for name=vps.templar.co.uk type=MX: Host
not found, try again)

If it's the only network activity the thing does regularly, maybe
the WiFi interface has gone into some sort of sleep mode and the DNS
resolver isn't waiting for it to wake up. If you leave ping running
(eg. "nohup ping -s 1 vps.templar.co.uk &") to keep the interface
active, maybe it will work the first time?

I was logged in over ssh at the time, so that hound don't hunt :-(

Was the SSH session actually doing anything? An idle SSH session doesn’t
have to exchange any packets at all.

But “it’s always DNS” is a pretty reliable starting point for network debugging, and I think it’s the right one here.

What are you using as a name server? i.e. what is in resolv.conf on this machine?

Nov 18 10:46:57 heating-controller postfix/smtp[10457]: CC05B1F270: to=<superroot@templar.co.uk>, relay=none, delay=0.38,
delays=0.19/0.14/0.04/0, dsn=4.4.3, status=deferred (Host or domain
name not found. Name service error for name=vps.templar.co.uk type=MX:
Host not found, try again)
^^^^^^^^^^^^^^^^^^^^^^^^^

It’s a temporary failure, ‘TRY_AGAIN’ ultimately from something in resolv.h or netdb.h, but with a lot of Postfix-specific DNS code around
it.

vps.templar.co.uk. 3600 IN MX 5 vps.templar.co.uk.

Your MX record has 1-hour TTL, so an hour after the last successful
query, your local (or ISP-provided) name server will have to ask domaincontrol.com again. That may explain why ‘a few hours delay’ brings the condition back.

domaincontrol.com seems to be pretty fast from here but if for whatever
reason the network between you and domaincontrol is slow or unreliable,
or the name server you’re using is underprovisioned, then that could
explain the temporary failures here. By the time you send the another
message everything has caught up, explaining why it works on the second attempt.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 18/11/2025 23:15, Daniel James wrote:

On 18/11/2025 12:08, The Natural Philosopher wrote:

As part of my enhancements to the home controller, I want to send
email warnings of low heating oil level.

This sounds rather like something I have been planning to do. AAMOI how
are you measuring the oil level?

Oh. I designed a board with

- a Pi Pico W.
- a three pin temperature sensor ( TMP36) to monitor outside temperature
- an ultrasonic transmitter/receiver ( HCRS04) on it
- a nano power timer that (Was a sparkfun nano power switch TPL5110
until I blew it up and replaced it with a sub-board with an Adafruit
TPL5110 Low Power Timer ) wakes up every 2 hours, tries to make contact
with the wifi, sends a short message to the server, and then commits
suicide and shuts the timer down again.

Board designs all available if you want.

Also source code, suitably modified to remove my wifi password

At the far end is a Pi Zero with a very simple daemon running under
inetd, to listen to the call and write the data to a file in a ramdisk.

A web server then parses that data and calculates the oil level and
displays it. (along with room temps and central heating states which it
also controls)

The intention is to run code under cron as well, and send warning emails.

I may not bother to fix the DNS problem since it seems to resend the
mail within the hours successfully.
--
No Apple devices were knowingly used in the preparation of this post.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 19/11/2025 07:56, Marco Moock wrote:

On 18.11.2025 15:27 Uhr The Natural Philosopher wrote:

from=<oil-monitor@heating-controller>

That is your first problem. Us a real existing address for that.

No. I wont. Because it is effectively private intra domain email.

Do you want to run you own mail domain or do you just want to use a
freemail account for sending that out?

As I said. I already run my own domains under half a dozen domain names
that I own.

The SMTP server will accept anything so long as it is addressed to one
of my domains. And is not from a blacklisted domain.
--
I would rather have questions that cannot be answered...
...than to have answers that cannot be questioned

Richard Feynman



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 19/11/2025 08:50, Richard Kettlewell wrote:

The Natural Philosopher <tnp@invalid.invalid> writes:

On 18/11/2025 21:08, Computer Nerd Kev wrote:

The Natural Philosopher <tnp@invalid.invalid> wrote:

Seriously,m its not the server, its the DNS.

It (the PI) cant even *find* the SMTP server
Nov 18 10:46:56 heating-controller postfix/pickup[8654]: CC05B1F270:
uid=0 from=<oil-monitor@heating-controller>
Nov 18 10:46:56 heating-controller postfix/cleanup[10455]: CC05B1F270: >>>> message-id=<20251118104656.CC05B1F270@heating-controller>
Nov 18 10:46:56 heating-controller postfix/qmgr[1295]: CC05B1F270:
from=<oil-monitor@heating-controller>, size=387, nrcpt=1 (queue active) >>>> Nov 18 10:46:57 heating-controller postfix/smtp[10457]: CC05B1F270:
to=<superroot@templar.co.uk>, relay=none, delay=0.38,
delays=0.19/0.14/0.04/0, dsn=4.4.3, status=deferred (Host or domain name >>>> not found. Name service error for name=vps.templar.co.uk type=MX: Host >>>> not found, try again)

If it's the only network activity the thing does regularly, maybe
the WiFi interface has gone into some sort of sleep mode and the DNS
resolver isn't waiting for it to wake up. If you leave ping running
(eg. "nohup ping -s 1 vps.templar.co.uk &") to keep the interface
active, maybe it will work the first time?

I was logged in over ssh at the time, so that hound don't hunt :-(

Was the SSH session actually doing anything? An idle SSH session doesn’t have to exchange any packets at all.

I used it to compose and send the mail...from the command line

But “it’s always DNS” is a pretty reliable starting point for network debugging, and I think it’s the right one here.

What are you using as a name server? i.e. what is in resolv.conf on this machine?

Stuff that apparently isn't used.
It was set to 127.0.0.1 and IIRC dnsmasq was running.
I set it to my internal servers that run BIND but I dont think its
actually using them

Nov 18 10:46:57 heating-controller postfix/smtp[10457]: CC05B1F270: to=<superroot@templar.co.uk>, relay=none, delay=0.38, delays=0.19/0.14/0.04/0, dsn=4.4.3, status=deferred (Host or domain
name not found. Name service error for name=vps.templar.co.uk type=MX:
Host not found, try again)
^^^^^^^^^^^^^^^^^^^^^^^^^

It’s a temporary failure, ‘TRY_AGAIN’ ultimately from something in resolv.h or netdb.h, but with a lot of Postfix-specific DNS code around
it.

Well I figured that it was temporary by the way the thing turns up a few minutes later...

vps.templar.co.uk. 3600 IN MX 5 vps.templar.co.uk.

Your MX record has 1-hour TTL, so an hour after the last successful
query, your local (or ISP-provided) name server will have to ask domaincontrol.com again. That may explain why ‘a few hours delay’ brings the condition back.

Ah, cache timed out. But local servers contacting that address to fetch
mail every few minutes, so the local dns servers will always have it.
Question is whether the pi is actually using them

When I tried to discover what was being used it turns out that there are
(at least) three possible mechanisms in use whose config files did not
match anything on the Pi. Usual 'lets change it all for this release' stuff.

So no, I don't know what it is now using as a DNS client.

Its very odd. I just did this...

# dig vps.templar.co.uk

; <<>> DiG 9.16.50-Raspbian <<>> vps.templar.co.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24512
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 7f7ca1b95493f5c601000000691d9a18750f0123b174788b (good)
;; QUESTION SECTION:
;vps.templar.co.uk. IN A

;; ANSWER SECTION:
vps.templar.co.uk. 3726 IN A 185.113.128.151

;; Query time: 9 msec
;; SERVER: 192.168.0.101#53(192.168.0.101)
;; WHEN: Wed Nov 19 10:21:12 GMT 2025
;; MSG SIZE rcvd: 90
...then this...
root@heating-controller:/var/ramlog# echo "This is more bollox isn't
it?" | mail -a "From: oil-monitor@heating-controller" -s "another
message" superroot@templar.co.uk
...and this...
root@heating-controller:/var/ramlog# mailq
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
C459D1FE2E 387 Wed Nov 19 10:21:48 oil-monitor@heating-controller
(Host or domain name not found. Name service error for
name=vps.templar.co.uk type=MX: Host not found, try again)
superroot@templar.co.uk

-- 0 Kbytes in 1 Request.

Now unless dig is using some other means than postfix to look up DNS, it
looks like the problem is in postfix somehow.

I don't know how to work that out.

Maybe I should forget postfix and code up a simple SMTP client

Just like the old days....:-)

and finally a few minutes later...

# mailq
Mail queue is empty

...so it finally figured out how to send it..

Curiously the headers reveal this

Received: from [212.69.38.60] (helo=heating-controller)
by vps.templar.co.uk with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
(Exim 4.72)
(envelope-from <oil-monitor@heating-controller>)
id 1vLfOk-0006a6-4z
for superroot@templar.co.uk; Wed, 19 Nov 2025 10:26:50 +0000
Received: by heating-controller (Postfix, from userid 0)
id C459D1FE2E; Wed, 19 Nov 2025 10:21:48 +0000 (GMT)

Indicating a 5 minute delay between being queued and being sent...

domaincontrol.com seems to be pretty fast from here but if for whatever reason the network between you and domaincontrol is slow or unreliable,
or the name server you’re using is underprovisioned, then that could explain the temporary failures here. By the time you send the another
message everything has caught up, explaining why it works on the second attempt.

All other machines work just fine. I wonder if in fact something is
swapped out on the zero.
--
“The urge to save humanity is almost always only a false face for the
urge to rule it.”
– H. L. Mencken

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

Daniel James <daniel@me.invalid> wrote:

On 18/11/2025 12:08, The Natural Philosopher wrote:

As part of my enhancements to the home controller, I want to send email warnings of low heating oil level.

This sounds rather like something I have been planning to do. AAMOI how
are you measuring the oil level?

FWIW I had one of those Watchman ultrasonic oil tank sensors and I could
pick up the reading via rtl_433 and a cheap RTL2832-based DVB TV dongle.
(as well as the tyres on the car, and various other gizmos locally).

Perhaps a wires-free option if you already have such a sensor?

Theo
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

The Natural Philosopher wrote:

Indicating a 5 minute delay between being queued and being sent...

grep 300 /etc/postfix/main.cf
maybe tweak smtpd_timeout=nn if that matches
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 19/11/2025 10:34, Theo wrote:

Daniel James <daniel@me.invalid> wrote:

On 18/11/2025 12:08, The Natural Philosopher wrote:

As part of my enhancements to the home controller, I want to send email
warnings of low heating oil level.

This sounds rather like something I have been planning to do. AAMOI how
are you measuring the oil level?

FWIW I had one of those Watchman ultrasonic oil tank sensors and I could
pick up the reading via rtl_433 and a cheap RTL2832-based DVB TV dongle.
(as well as the tyres on the car, and various other gizmos locally).

Perhaps a wires-free option if you already have such a sensor?

Theo

I do indeed and its utter failure to provide a reliable link is the main reason I am building this one.

I thought about doing what you mention but the 433MHz never talked
reliably to the house., ever. And then when I started playing with Pico
Pi Ws it seems sane to use the same technology as I had already sort of
- if not mastered - at least got working, for the thermostats.

The problem is that the tank is fairly remote - between 15 and 40 metres
from various bits of the house and 433MHz never quite was reliable.
Especially in the wind or rain. And it never reliably told me the
battery was low either. Or that all the oil in the tank had been stolen,
or run out.

Whereas I can do wifi to a particular wifi point at a reliable -90dbm or
so from the tank location as far as I have tested it.

I with I could monitor the oil quality somehow. I always order premium
but the last lot exploded the Aga last night blowing soot everywhere.
Sigh. Another strip down and clean...

That what happens when you run out and order stuff in a hurry. They
disregard the order and deliver whatever shit is on the tanker.

Hence why the oil sensor project is top priority.

Anyway, wrench time.
Cy'all later...
--
If you tell a lie big enough and keep repeating it, people will
eventually come to believe it. The lie can be maintained only for such
time as the State can shield the people from the political, economic
and/or military consequences of the lie. It thus becomes vitally
important for the State to use all of its powers to repress dissent, for
the truth is the mortal enemy of the lie, and thus by extension, the
truth is the greatest enemy of the State.

Joseph Goebbels




--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 19/11/2025 10:47, Andy Burns wrote:

The Natural Philosopher wrote:

Indicating a 5 minute delay between being queued and being sent...

grep 300 /etc/postfix/main.cf
maybe tweak smtpd_timeout=nn if that matches

Ah. That file actually exists.

Now can you see anything in this section that is odd?

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = heating-controller
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = $myhostname, heating-controller, localhost.localdomain, localhost
relayhost = vps.templar.co.uk
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = loopback-only
inet_protocols = all
--

When plunder becomes a way of life for a group of men in a society, over
the course of time they create for themselves a legal system that
authorizes it and a moral code that glorifies it.

Frédéric Bastiat

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 19/11/2025 10:08, The Natural Philosopher wrote:

Oh. I designed a board with

- a Pi Pico W.
- a three pin temperature sensor ( TMP36) to monitor outside temperature
- an ultrasonic transmitter/receiver ( HCRS04) on it
- a nano power timer that (Was a sparkfun nano power switch  TPL5110
until I blew it up and replaced it with a sub-board  with an Adafruit TPL5110 Low Power Timer ) wakes up every 2 hours, tries to make contact
with the wifi, sends a short message to the server, and then commits
suicide and shuts the timer down again.

OK, thanks. What sort of oil tank do you have and how do you fit the
sensor to it?

I'm part-way through designing something similar myself, but using an
ESP8266 to control the sensor and talking mqtt to a Pi (happens to be a
Pi3B, because I have one always-on for other things but I could have
used a ZeroW). It's really at Proof-of-Concept stage at present.

I have a 3V-compatible HCSR04 to play with, but was wondering whether an
ir laser ToF device might be better. Those ultrasonic sensors are a bit
chunky ... (I'm told there is no chance of the laser in,say, a VL53L1X igniting heating oil vapour!)

I haven't yet put either anywhere near the oil tank, yet. I'm using
readings from a BME280 to test the logic.

I have a "Cheap Yellow Display" (ESP32 with LCD) that acts as a mqtt
client and display panel ... it can record data (but doesn't yet) but
I'll probably want something more sophisticated later ... as I say, it's
all PoC at present.
--
Cheers,
Daniel.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 19/11/2025 10:33, The Natural Philosopher wrote:

# dig vps.templar.co.uk

dig -t any .......
--
Mike Scott
Harlow, England
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 19/11/2025 11:11, Daniel James wrote:

On 19/11/2025 10:08, The Natural Philosopher wrote:

Oh. I designed a board with

- a Pi Pico W.
- a three pin temperature sensor ( TMP36) to monitor outside temperature
- an ultrasonic transmitter/receiver ( HCRS04) on it
- a nano power timer that (Was a sparkfun nano power switch  TPL5110
until I blew it up and replaced it with a sub-board  with an Adafruit
TPL5110 Low Power Timer ) wakes up every 2 hours, tries to make
contact with the wifi, sends a short message to the server, and then
commits suicide and shuts the timer down again.

OK, thanks. What sort of oil tank do you have and how do you fit the
sensor to it?

One of these basically

https://www.fueltankshop.co.uk/2500-litre-oil-tank-titan-h2500gr/p5305

The tank already had a hole in the top to take an oil watchman sensor,
so I 3d printed a case to use the same mounting holes and gasket. I will
need to open up the hole a bit for the ultrasonics

I'm part-way through designing something similar myself, but using an ESP8266 to control the sensor and talking mqtt to a Pi (happens to be a Pi3B, because I have one always-on for other things but I could have
used a ZeroW). It's really at Proof-of-Concept stage at present.

Well since I am 100% custom I didn't bother with mqtt - I simply send a
short text string . The more problematical bit is establishing a wifi connection and what to do if it fails to connect.

If I had Ethernet out there I would never have gone to the complexity of battery operation....

I have a 3V-compatible HCSR04 to play with, but was wondering whether an
ir laser ToF device might be better. Those ultrasonic sensors are a bit chunky ... (I'm told there is no chance of the laser in,say, a VL53L1X igniting heating oil vapour!)

Good with the 3v version Mine isn't and I expect it to get sketchy at
around 3.9V.
If that proves to be a problem I'll probab;y make a new board up and
transfer the modules from the existing...

I haven't yet put either anywhere near the oil tank, yet. I'm using
readings from a BME280 to test the logic.

I have a "Cheap Yellow Display" (ESP32 with LCD) that acts as a mqtt
client and display panel ... it can record data (but doesn't yet) but
I'll probably want something more sophisticated later ... as I say, it's
all PoC at present.

Well the history of my controller goes back 20 years when I installed everything and just threw in 'enough to get it working'

But I never had proper control. And the RF thermostat was bulky and not especially reliable. So I finally decided to mess around with a Pi.

Because the website I built on the zero has everything I want to know
exactly where I want it, the experience is MUCH better.

Sometimes stuff gets stuck after a power cut. But hard resets have
always fixed it.

I don't like the commercial solutions that rely on a cloud somewhere.
--
Truth welcomes investigation because truth knows investigation will lead
to converts. It is deception that uses all the other techniques.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 19/11/2025 11:13, Mike Scott wrote:

On 19/11/2025 10:33, The Natural Philosopher wrote:

# dig vps.templar.co.uk

dig -t any .......

essentially the same result, but thanks anyway...
--
Renewable energy: Expensive solutions that don't work to a problem that doesn't exist instituted by self legalising protection rackets that
don't protect, masquerading as public servants who don't serve the public.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 19/11/2025 12:18, The Natural Philosopher wrote:

On 19/11/2025 11:13, Mike Scott wrote:

On 19/11/2025 10:33, The Natural Philosopher wrote:

# dig vps.templar.co.uk

dig -t any .......

essentially the same result, but thanks  anyway...

Hmm, interesting, the result depends, it seems, on the dns server:

dig -t any vps.templar.co.uk

; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> -t any vps.templar.co.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48113
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;vps.templar.co.uk. IN ANY

;; ANSWER SECTION:
vps.templar.co.uk. 6346 IN A 185.113.128.151

;; Query time: 7 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (TCP)
;; WHEN: Wed Nov 19 16:30:45 GMT 2025
;; MSG SIZE rcvd: 62

dig -t any @8.8.8.8 vps.templar.co.uk

; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> -t any @8.8.8.8 vps.templar.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48917
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;vps.templar.co.uk. IN ANY

;; ANSWER SECTION:
vps.templar.co.uk. 8600 IN A 185.113.128.151 vps.templar.co.uk. 3600 IN MX 5 vps.templar.co.uk.

;; Query time: 37 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (TCP)
;; WHEN: Wed Nov 19 16:31:18 GMT 2025
;; MSG SIZE rcvd: 78
--
Mike Scott
Harlow, England
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 19/11/2025 12:16, The Natural Philosopher wrote:

One of these basically

https://www.fueltankshop.co.uk/2500-litre-oil-tank-titan-h2500gr/p5305

The tank already had a hole in the top to take an oil watchman sensor,
so I 3d printed a case to use the same mounting holes and gasket. I will need to open up the hole a bit for the ultrasonics

Ours is a steel tank, but it has a tube poking out of the top that has previously accommodated a Watchman sensor.

Housing the electronics is the problem - I had hoped that oil tank
sellers would sell a screw-in cap for the tank opening that I could cannibalize to make an appliance housing, but I haven't found anything suitable (yet).

I really needed an excuse to get into 3D printing. :-)

Well since I am 100% custom I didn't bother with mqtt - I simply send a short text string . The more problematical bit is establishing a wifi connection and what to do if it fails to connect.

If I had Ethernet out there I would never have gone to the complexity of battery operation....

I used MQTT because I already had Mosquitto running on the Pi3B (as part
of a HomeAssistant setup controlling a few Tasmoto switches). I should
not have gone that route otherwise ... but it does work well.

Yes, if I had Ethernet running out to the tank it would all be so
different ... but I'm not drilling a hole through a 60cm stone wall to
get it there!

I have a 3V-compatible HCSR04 to play with ...

[snip]

Good with the 3v version Mine isn't and I expect it to get sketchy at around 3.9V.
If that proves to be a problem I'll probab;y make a new board up and transfer the modules from the existing...

Mine is actually an RCWL-1601, which claims HC-SR04 compatibility. It
also claims to support i2c as well as the usual trig/echo signalling,
which will help as me ESP8266 is running out of pins. I may have to
switch to an ESP32 ... but I have a handful of 8266s not doing a lot ...

I don't like the commercial solutions that rely on a cloud somewhere.

No, indeed. I avoid those as much as possible.
--
Cheers,
Daniel.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

The Natural Philosopher <tnp@invalid.invalid> writes:

So no, I don't know what it is now using as a DNS client.

Its very odd. I just did this...

# dig vps.templar.co.uk

; <<>> DiG 9.16.50-Raspbian <<>> vps.templar.co.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24512
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 7f7ca1b95493f5c601000000691d9a18750f0123b174788b (good)
;; QUESTION SECTION:
;vps.templar.co.uk. IN A

;; ANSWER SECTION:
vps.templar.co.uk. 3726 IN A 185.113.128.151

;; Query time: 9 msec
;; SERVER: 192.168.0.101#53(192.168.0.101)
;; WHEN: Wed Nov 19 10:21:12 GMT 2025
;; MSG SIZE rcvd: 90
...then this...
root@heating-controller:/var/ramlog# echo "This is more bollox isn't
it?" | mail -a "From: oil-monitor@heating-controller" -s "another
message" superroot@templar.co.uk
...and this...
root@heating-controller:/var/ramlog# mailq
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
C459D1FE2E 387 Wed Nov 19 10:21:48 oil-monitor@heating-controller
(Host or domain name not found. Name service error for
name=vps.templar.co.uk type=MX: Host not found, try again)
superroot@templar.co.uk

-- 0 Kbytes in 1 Request.

Now unless dig is using some other means than postfix to look up DNS,
it looks like the problem is in postfix somehow.

Maybe, but the above doesn’t prove it; you’ve asked for an A record but Postfix asks for an MX record, so your lookup won’t have populated the
cache (if there is one). (It’ll look for the A record next, but until
it’s got the MX record it doesn’t know what A record to ask for.)

If there is doubt about what name server is being used you could use
tcpdump to find out.

sudo tcpdump -np -i br0 udp port 53

Replace br0 with your own network interface. You’ll need to check at
least loopback (lo) and any real network interfaces.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 19.11.2025 10:11 Uhr The Natural Philosopher wrote:

On 19/11/2025 07:56, Marco Moock wrote:

On 18.11.2025 15:27 Uhr The Natural Philosopher wrote:

from=<oil-monitor@heating-controller>

That is your first problem. Us a real existing address for that.

No. I wont. Because it is effectively private intra domain email.

Then make sure your postfix doesn't check that. It seems for me it does.
--
kind regards
Marco

Send spam to 1763543504muell@stinkedores.dorfdsl.de

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 19/11/2025 17:24, Daniel James wrote:

On 19/11/2025 12:16, The Natural Philosopher wrote:

One of these basically

https://www.fueltankshop.co.uk/2500-litre-oil-tank-titan-h2500gr/p5305

The tank already had a hole in the top to take an oil watchman sensor,
so I 3d printed a case to use the same mounting holes and gasket. I
will need to open up the hole a bit for the ultrasonics

Ours is a steel tank, but it has a tube poking out of the top that has previously accommodated a Watchman sensor.

Housing the electronics is the problem - I had hoped that oil tank
sellers would sell a screw-in cap for the tank opening that I could cannibalize to make an appliance housing, but I haven't found anything suitable (yet).

I really needed an excuse to get into 3D printing. :-)

I have used mine fairly cosistently to make cases, duplicate broken bits
of plastic, and for all manner of things I simply never thought of.
I got a pair of RAACO cabinets that were not shipped with drawer
dividers. The cost of printng was less than the cost of buying them...etc.

The upfr9nmt cost is a bit steep, but hey - the more toys the better....

Well since I am 100% custom I didn't bother with mqtt - I simply send
a short text string . The more problematical bit is establishing a
wifi connection and what to do if it fails to connect.

If I had Ethernet out there I would never have gone to the complexity
of battery operation....

I used MQTT because I already had Mosquitto running on the Pi3B (as part
of a HomeAssistant setup controlling a few Tasmoto switches). I should
not have gone that route otherwise ... but it does work well.

Ah yes. I am a believer in 'use what you know of and have already'

Yes, if I had Ethernet running out to the tank it would all be so
different ... but I'm not drilling a hole through a 60cm stone wall to
get it there!

I have a 3V-compatible HCSR04 to play with ...

[snip]

Good with the 3v version Mine isn't and I expect it to get sketchy at
around 3.9V.
If that proves to be a problem I'll probably make a new board up and
transfer the modules from the existing...

Mine is actually an RCWL-1601, which claims HC-SR04 compatibility. It
also claims to support i2c as well as the usual trig/echo signalling,
which will help as me ESP8266 is running out of pins. I may have to
switch to an ESP32 ... but I have a handful of 8266s not doing a lot ...

I don't like the commercial solutions that rely on a cloud somewhere.

No, indeed. I avoid those as much as possible.

--
"When a true genius appears in the world, you may know him by this sign,
that the dunces are all in confederacy against him."

Jonathan Swift.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 19/11/2025 18:03, Richard Kettlewell wrote:

The Natural Philosopher <tnp@invalid.invalid> writes:

So no, I don't know what it is now using as a DNS client.

Its very odd. I just did this...

# dig vps.templar.co.uk

; <<>> DiG 9.16.50-Raspbian <<>> vps.templar.co.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24512
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 7f7ca1b95493f5c601000000691d9a18750f0123b174788b (good)
;; QUESTION SECTION:
;vps.templar.co.uk. IN A

;; ANSWER SECTION:
vps.templar.co.uk. 3726 IN A 185.113.128.151

;; Query time: 9 msec
;; SERVER: 192.168.0.101#53(192.168.0.101)
;; WHEN: Wed Nov 19 10:21:12 GMT 2025
;; MSG SIZE rcvd: 90
...then this...
root@heating-controller:/var/ramlog# echo "This is more bollox isn't
it?" | mail -a "From: oil-monitor@heating-controller" -s "another
message" superroot@templar.co.uk
...and this...
root@heating-controller:/var/ramlog# mailq
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
C459D1FE2E 387 Wed Nov 19 10:21:48 oil-monitor@heating-controller
(Host or domain name not found. Name service error for
name=vps.templar.co.uk type=MX: Host not found, try again)
superroot@templar.co.uk

-- 0 Kbytes in 1 Request.

Now unless dig is using some other means than postfix to look up DNS,
it looks like the problem is in postfix somehow.

Maybe, but the above doesn’t prove it; you’ve asked for an A record but Postfix asks for an MX record, so your lookup won’t have populated the cache (if there is one). (It’ll look for the A record next, but until it’s got the MX record it doesn’t know what A record to ask for.)

If there is doubt about what name server is being used you could use
tcpdump to find out.

sudo tcpdump -np -i br0 udp port 53

Replace br0 with your own network interface. You’ll need to check at
least loopback (lo) and any real network interfaces.

Dig...mx returns instantly with the correct answer too
--
“I know that most men, including those at ease with problems of the greatest complexity, can seldom accept even the simplest and most
obvious truth if it be such as would oblige them to admit the falsity of conclusions which they have delighted in explaining to colleagues, which
they have proudly taught to others, and which they have woven, thread by thread, into the fabric of their lives.”

― Leo Tolstoy

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On Wed, 19 Nov 2025 08:56:56 +0100, Marco Moock wrote:

On 18.11.2025 15:27 Uhr The Natural Philosopher wrote:

from=<oil-monitor@heating-controller>

That is your first problem. Us a real existing address for that.

If that were the problem, then the mail would not eventually go
through. It would be blocked, and that’s that.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On Wed, 19 Nov 2025 10:33:19 +0000, The Natural Philosopher wrote:

[/etc/resolv.conf] was set to 127.0.0.1 and IIRC dnsmasq was
running. I set it to my internal servers that run BIND but I dont
think its actually using them

dnsmasq by default uses /etc/resolv.conf, unless you point it at
another such file with the --resolv-file option -- obviously you have
to do this to avoid circularity, if dnsmasq is supposed to be the one
handling DNS requests sent to the 127.0.0.1 address.

So no, I don't know what it is now using as a DNS client.

It is normal for DNS clients to use /etc/resolv.conf. Can’t see any
reason to configure any of them to use some special setting -- apart
of course from a local caching DNS server like dnsmasq, or special DNS diagnostic tools like dig and host. In other words, everything that
just expects to use the DNS, rather than be part of administering/troubleshooting the DNS infrastructure, should just be
using /etc/resolv.conf.

Now unless dig is using some other means than postfix to look up
DNS, it looks like the problem is in postfix somehow.

dig has nothing to do with Postfix. DNS tools like dig and host
implement their own low-level DNS clients, which can be configured to
do queries in all kinds of ways, precisely to help with
troubleshooting DNS problems.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On Wed, 19 Nov 2025 16:32:49 +0000, Mike Scott wrote:

On 19/11/2025 12:18, The Natural Philosopher wrote:

On 19/11/2025 11:13, Mike Scott wrote:

On 19/11/2025 10:33, The Natural Philosopher wrote:

# dig vps.templar.co.uk

dig -t any .......

essentially the same result, but thanks  anyway...

Hmm, interesting, the result depends, it seems, on the dns server:

Some DNS admins don’t like the idea of any kind of “wildcard” or “all information” queries: they want you to specifically ask for what you want, no casual browsing permitted.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

Marco Moock <mm@dorfdsl.de> writes:

On 19.11.2025 10:11 Uhr The Natural Philosopher wrote:

On 19/11/2025 07:56, Marco Moock wrote:

On 18.11.2025 15:27 Uhr The Natural Philosopher wrote:

from=<oil-monitor@heating-controller>

That is your first problem. Us a real existing address for that.

No. I wont. Because it is effectively private intra domain email.

Then make sure your postfix doesn't check that. It seems for me it does.

That is obviously not going to cause a temporary failure looking up the
MX for vps.templar.co.uk. Just look at the logfile fragment rather than guessing blindly. We know what the error is and it’s absolutely nothing
to do with source address validity.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.21a-Linux NewsLink 1.2