This is part 3 of the series of posts about installing a home automation system around Domoticz on a Raspberry Pi. It covers installing additional services that I find useful, but that are not truly required for the home automation system. This is still a work in progress but I wanted to make it available sooner rather than later, especially because of the improvement in the presentation about video streaming. Expect additions and corrections in the upcoming weeks.

Table of Contents

1. Installing the WireGuard VPN Server
2. Installing the Syncthing File Synchronization Application
3. Installing the MJPG-Streamer Video Streamer
   1. Using a Webcam
   2. Controlling the Video Streaming Service
   3. Integration into Domoticz
   4. Secured Streaming
   5. Using a Raspberry Pi Camera Module
4. Installing the Radicale Calendar and Contact Server
5. Installing the chrony Network Time Client and Server
   1. NTP Client
   2. NTP Server
   3. Tasmota NTP Settings

Installing the WireGuard VPN Server

One of the perks of having a home automation system is that it allows one to control devices in the house from outside. Perhaps the simplest way of going about that is to use port forwarding which involves opening a TCP or UDP port of the local area network (LAN) for each service or device to be reached from the outside world. This can become an administrative nightmare if many ports have to be forwarded, and it does introduce security risks. For the last two years or so, I have been using a virtual private network (VPN). The point of hosting a VPN on the local area network is that it makes it possible to securely access all resources on the LAN while opening a single port (or UDP port in the case of Wireguard). Once the connection to the VPN server is established (this is often referred to "establishing or opening a tunnel") from outside the LAN, all IP addresses on the LAN can be reached and the "tunnel" takes care of encrypting the IP traffic meaning that unsecured protocols like HTTP or telnet (anyone still use that?) can be used safely.

Initially, I used OpenVPN (probably PiVPN; be careful, the advice about running downloaded bash scripts applies here too) with success, but I quickly switched to WireGuard and I am pleased with the results. Lately the wireguard package has become available in the official repository

so installation of WireGuard is now as simple as can be.

There is not much to check until the server and clients have been configured. At a minimum verify that the wg-quick utility is installed and that is configuration directory ias created although it is empty.

Let's create an empty configuration file and then bring up the VPN server and see that it is running.

Because WireGuard has not been configured, the virtual network interface has been created but it is inactive. Enabling automatic start of the wg0 interface at boot time makes sense on a server.

At this point, it makes sense to stop the server and proceed with the configuration of the VPN.

This remaining task is now the most complex part of setting up the virtual network. Luckily, some kind and clever individuals have provided scripts that simplify the whole procedure considerably. I will shamelessly suggest reading my post entitled Installing and Configuring WireGuard on Raspberry Pi OS (September 2021) for details on configuring the VPN server and on installing "clients" or "peers" that will access this self-hosted VPN server.

Installing Syncthing

In the previous edition of this post, I showed how to install Synchthing a decentralized file synchronization program saying that I wanted to use it to synchronize directories that contained scripts and the Domoticz database. As it turned out, I never did use Synchthing for backing up the many scripts on the Raspberry Pi. And lately I have stopped using Synchthing for backing up the Domoticz. Nevertheless, here is an update to how to install the service because I think it could be useful. The installation procedure has not changed much

Using apt-cache policy, it became clear that Syncthing in the Debian and Raspbian repository are rather out of date.

So I more or less followed the instructions at Syncthing, Debian/Ubuntu Packages to get the latest stable version (1.18).

Now start the program manually to verify that it functions.

Since I want to control the application through its Web interface from my desktop computer, I need to modify the configuration as explained in the FAQ.

Locate the gui entry and change the <address> value from 127.0.0.1:8384 to 0.0.0.0:8384.

Restart syncthing

and note how the message

[NTGKU] 16:30:28 INFO: GUI and API listening on 127.0.0.1:8384

changed to

[NTGKU] 16:50:02 INFO: GUI and API listening on [::]:8384

which means it will be possible to open the Syncthing web interface from the desktop using a Web browser pointed to 192.168.1.139:8384. There was a warning about the lack of security, so I followed the instruction to add a user and password to access the GUI interface.

At the same time, I disabled all connections except for Local Discovery because I want to limit the activity of this application to the local network.

After shutting down the service from the GUI (Actions / Shudown), I restarted it from the command line

and saw that it was no longer connecting to outside relay servers.

If you wanted syncthing to start automatically when the Raspberry Pi is booted, then enable the service as follows.

[NTGKU] 16:50:02 INFO: TCP listener ([::]:22000) starting
2021/09/25 16:50:02 failed to sufficiently increase receive buffer size (was: 176 kiB, wanted: 2048 kiB, got: 352 kiB). See https://github.com/lucas-clemente/quic-go/wiki/UDP-Receive-Buffer-Size for details.
[NTGKU] 16:50:02 INFO: QUIC listener ([::]:22000) starting

For information on setting up Syncthing on other computers and Android tablets and sharing directories see the documentation.

Installing the MJPG-streamer Video Streamer

Ostensibly, this guide is about setting up Domoticz on a Raspberry Pi. To be truthful, the video capabilities of the home automation software are minimal. Up to now at least, Domoticz is only capable of displaying single JPEG images or snapshots taken by supported cameras. Video streaming is actually just a series of snapshots taken at short intervals. I suspect that many would want more from a video camera connected to the Pi. So below, I rehash a previous post on streaming a USB webcam connected how to a Raspberry Pi over HTTP. It just happens that the streamer can also provide snapshots that Domoticz can use.

MJPG-streamer takes JPGs from Linux-UVC compatible webcams, filesystem or other input plugins and streams them as M-JPEG via HTTP to webbrowsers, VLC and other software. It is the successor of uvc-streamer, a Linux-UVC streaming application with Pan/Tilt. The author, Tom Stöveken, has abandonned the project but the code has been forked many times. However, the fork by jacksonliam is the "designated successor".

There is no binary package in the repository, mjpg_streamer has to be built from the source code and before that can be done some prerequisites must be installed.

Let's locate the executable and its input and output libraries.

The input module to use for USB webcam is input_uvc.so, while the output module is output_http.so. As far as I can determine the UDP and RTSP output modules are not functionnal and I have not tried the other modules.

Using a Webcam

We are now in a position to test the video streaming service with default values. Plug a USB webcam into the Raspberry Pi and enter the following command. Since both MJPG-Streamer and Domoticz use TCP port 8080 by default, it is necessary to change one of those. I decided to change the TCP streaming port to 8085.

Despite all the error messages that have to do with non-existent capabilities of my old webcam, the video stream can be seen on a web browser at the following address: http://192.168.1.139:8085/?action=stream. Single JPEG images, snapshots, can be obtained with the following HTTP request: http://192.168.1.139:8085/?action=snapshot. Of course, the local host name of the Pi, damus.local, could be used instead of the IP address, if the operating system and web browser support mDNS.

The output_http module has another ouput option that will provide access to a number of web pages designed to show the video stream or snapshots in various ways. Use this command.

The simple URL to access these pages is http://192.168.1.139:8085/ or http://damus.local:8085/. There is a menu on the left of the page. The screenshot below shows the Static page which displays a snapshot taken with the webcam when the HTTP request for the page is received.

And yes, what you are seeing is a fuzzy image of the Raspberry Pi 3 B taken with a webcam while a camera module is also connected to the Pi. More about that later. Note that there is a Control page. It is worth looking at it because the input module has many options which can have a great deal of impact on the performance and quality of the video stream. It will pay to experiment with those. Here is the list of the options.

Of course, the parameters will have to be adjusted according to the webcam used. Here are the basic settings for two old models I have used:

Logitech C270

-i "input_uvc.so -n -f 10 -r 1280x720"
gives a 1280 by 720 pixel video stream at 10 frames per second.

Microsoft VX2000

-i "input_uvc.so -n -softfps 10"
gives a 640 by 480 pixel video stream at 10 frames per second although the video is captured at 30 frames per second.

Controlling the Video Streaming Service

In the currently running home automation system, a single Logitech C270 is permanently connected to the Raspberry Pi. It is turned of or on with a bash script as described in a previous post. This time around I wanted to do something similar but using a systemd unit file and the systemctl utility.

This file should be stored in the /etc/systemd/system/. Since it must belong to root, I created the file with the usual sudo nano mjpg_streamer.service command. A couple of comments about this unit file are in order.

• The Logitech webcam is not used for tests because it has a nasty startup bug. The older LifeCam works just fine.
• The -w /usr/local/share/mjpg-streamer/www option in the output module is not necessary.

If this were the typical service, it would be automatically started when the Pi is booted. In other words, the service needs to be enabled.

It is a simple matter to reboot the Pi and the verify that the camera is on which is kind of obvious because its LED remains on once the Pi has started. One could check by looking at the status of the service.

Of course the real test is to stream the video with a web browser at damus.local:8085/?action=stream which should work even when the -w /usr/local/share/mjpg-streamer/www option is not included in the unit file.

The streamer can be stopped and started with the usual commands.

My spouse is adament that cameras inside the house should not be on, spying on us, as it were. Because I concur, the service was disabled after the above tests were completed.

It is a simple matter to start and stop the streamer when needed such as when we leave the house. More on that later. Before moving on to that topic, a warning is in order. This configuration is only meant for a single USB webcam that is permanently connected to the Pi. If the camera is unplugged and then plugged back in, there is a high probability that the video stream will not work without manually stopping and then starting the service.

Integration into Domoticz

Adding a webcam to Domoticz is quite simple. It involves clicking on the menu choices, Setup, More Options, Cameras, and finally Add Camera to get to a form that must be filled out.

Provide an appropriate name for the camera, chose HTTP for the protocol, enter the Raspberry Pi IP address or the local host name as shown if supported, the TCP port specified for the output_html.so module, and finally the query part of the URL to obtain a single image from the streamer which, as we have seen, is ?action=snapshot. Don't forget to click on the Add button at the button.

Once the webcam has been added, it will show up in the Cameras table.

If the webcam icon to the right of the camera name in the table is clicked, a pop-up window will display a pseudo-video stream from the webcam. What is shown is actually a series of independent snapshots taken one at a time. If the still camera icon is clicked then a snapshot is taken and a pop-up menu will appear in which the user can choose to save the file on the device used to open the Domoticz web interface or to open it directly with an image viewer.

Snapshots can be taken and the pseudo-video stream can be viewed through the Domoticz web interface while the video stream at damus.local:8085/?action=stream is concurrently viewed in a browser.

Of course, nothing will be visible if the mjpg_streamer.service is not running. We can set up a Domoticz virtual switch to take care of turning the service on and off. That virtual switch will need the help of a script to perform its task but that is not too difficult to create. Here is one such script.

The script named webcam (available for download) is saved in the /home/nostra/.local/bin directory. Don't forget to make it executable.

Before moving on, test the script.

Now, let's create a virtual switch. This has been covered in the first part of this guide in the section Adding a Virtual Switch in Domoticz. But quickly, click on the following sequence of buttons.

• Setup
• Hardware
• Create Virtual Sensors

Then in the Create Virtual Sensor window

• set its name to Webcam or something else that seems appropriate,
• set the Sensor Type: to Switch
• click on the OK button.

To complete the installation, go to the Switches tab.

Click on the Edit button of the Webcam virtual switch.

The important task here is to specify the On Action and Off Action fields. In both cases, the webcam script is run, the only difference being the command line option which is start when turning on the streamer and stop when turning it off. Be careful there are 3 forward slashes between script: and home/.... That's because in typical request syntax, the action to perform is script:// and the fully qualified path to the script begins with an / also.

I also changed the Switch Icon from the default light bulb to the Generic on/off icon. Custom icons could be defined, say webcam48_On.png, webcam48_Off.png, but how to install them is outside the scope of this section.

Do not forget to press the Save button. The next time you want to take a snapshot or view the pseudo-video stream with the Domoticz web interface, clik on Setup / More Options / Cameras. If there is not preview in the webcam entry as shown here

then go back to the Switches tab and turn the webcam on by clicking on its icon.

Secured Streaming

Looking at the help for the HTTP output module shows that a user name and password can be required to see the video output.

Unfortunately, the web server does not use the secure HTTPS protocol. Instead, everything is done with the HTTP protocol without encoding; even the password and the user name will be sent in plaintext. So enabling this feature does not really provide security. In other words, I would never open up port 8085 for access from outside the LAN.

Accessing the video stream from outside the local network through a VPN (as shown in the first section of this post) is secure. If this approach cannot be used, then setting up a secure reverse proxy is certainly possible with NGINX that is already installed on the Pi, if the first post in this guide has been followed.

SSL Certificate

There is a prerequisite before the secure HTTPS protocol can be enabled in NGINX, or any other web server for that matter. An SSL certificate must be present on the Pi. This certificate can be "self-signed" or it can be a full fledged SSL certificate obtained from a certificate authority. If you want the latter, then look into obtaining a free certificate from the Let's Encrypt nonprofit authority. NGINX has a blog on the topic: Update: Using Free Let’s Encrypt SSL/TLS Certificates with NGINX.

If you have installed Domoticz, perhaps following the instructions in the first post in this guide, then a self-signed certificate is already available. Instead, one could use the self signed snake-oil certificate which the ssl-cert package installed by default on the Pi. Failing that one could always create one. The details of that will not be covered here, there are numerous guides on the Web.

Reverse Proxy

We have already modified the default nginx configuration file, default.conf, in the /etc/nginx/sites-available directory. That was set up to change the default HTTP TPC port used by HTTP to avoid a conflict with another server. Now a second configuration file will be added in the same directory.

Here is the content of the file. Notice that the SSL certificate supplied with Domoticz is being used.

Replace the two ssl_certificate... entries with the snakeoil certificate or any other SSL certificate if desired or needed.

A symbolic link to the newly created file must be created in the /etc/nginx/sites-available directory from which nginx reads its configuration.

Restart the server and check that everything works.

Just to test, open a web browser and go to the following site: https://damus.local:8085/?action=stream. Note that HTTPS is used, not HTTP. The first time this site is reached, the web browser will complain that the site is not secure unless a CA signed SSL certificate is used. To get access to the video stream,t will be necessary to create an exception. Do not worry, the problem is not with the security of the site per se, full TLS encryption will be used. The web browser will show the site as insecure because it does not recognize the authority of a self-signed certificate. I actually don't mind setting up the exception in the web browser. Furthermore that ominous warning by the web browser just might discourage someone with a little bit too much curiosity.

Outside Access

To have easy access to the video stream, other things must be put in place. I have already described the extra steps needed after setting up a server. The TCP port which is listened to by the reverse proxy must be forwarded to the proxy by the router. See port forwarding. And then see Creating a dynamic domain name, because it is much cleaner to use a dynamic host name instead of trying to find the public IP address of the local area network which I would imagine is next to impossible to do from outside the LAN.

Using a Raspberry Pi Camera Module

It is entirely possible to use a Raspberry Pi camera module plugged into the CSI connector of the Pi with a flat flex cable while one or indeed more than one webcam is connected to the Pi. The camera module will not work until its kernel driver is enabled. That is a one-time operation easily done with the Raspeberry Pi configuration utility.

Answer Yes when asked to confirm that the camera is to be enabled and when asked to reboot.

First let's test that the Raspberry Pi camera module is working by taking a snapshot. Of course, the module has to be connected with the Pi as explained above./p>

Adding the camera module to Domoticz is quite simple and similar to adding the webcam.

• Click on Setup
• Click on More Options
• Click on Cameras
• Click on Add Camera
• Fill out the Add New Camera form:

  

  Take care to enter the IP address and port of the Domoticz web server.

The camera module will then appear alongside the webcam in the Cameras table.

It is possible to stream the video output from the camera module. Look up Application-specific Settings, raspivid in the Raspberry Pi documentation. As a starting point try raspivid -v -t 0 -l -o tcp://0.0.0.0:8087 and then read the stream at tcp://damus.local:8087 in a media player such as Celluloid (formerly GNOME MPV, installed by default in Mint 20.1) or VLC. It must be pointed out that both raspistill and raspivid are both based on the legacy Raspicam camera stack that may soon be deprecated.

It is also possible to stream using MJPG-Streamer using -i "input_raspicam.so -fps 10 -x 1280 -y 720" will give a video output equivalent to that obtained with the Logitech Webcam.

I find there's an annoying amount of stuttering and using the default dimensions of the camera modules (-x 1920 -y 1080) is better. I have a lot of experimenting to do yet.

Installing the Radicale Calendar and Contact Server

Radicale is a "Free and Open-Source CalDAV and CardDAV Server" that is surprisingly easy to install. It is a way of self-hosting calendars and contact lists instead of relying on email accounts. To be honest, testing out Radicale can be very easy, but I did run into problems when it came time to create a viable permanent installation. As usual, someone else solved that conundrum about a year ago: see bomben question How to install radicale (CardDAV & CalDAV) on a headless RaspberryPi? and answer. So here's my take on those instructions.

As bomben suggested, the system should be updated and upgraded. I was surprised at the time it took to do this at this point, as Raspberry Pi OS had been updated just a week or two before.

While there is usually no harm in running apt autoremove, you may not need to do it. As can be seen, I had tried installing the radicale package, but I had run into some problems with it so it was removed. Radicale is a Python 3 script that will be installed with pip3 which is not installed by default in the Lite version of Raspberry Pi OS.

The Radicale script can now be installed.

Let's test the server by manually starting it.

This is a server, so do not expect to see anything. The server will run until interrupted (with CtrlC) or any other method. Wait until the test is completed before interrupting it.

Some explanations about this command might be in order.

• The --config "" command line option instructs the server to ignore any configuration file that may be present. Radicale normally tries to load the configuration files /etc/radicale/config and ~/.config/radicale/config. Since I had been playing with the script, it is best to bypass anything I might have left in place for the initial test.
• By default the Radicale web interface only accepts HTTP connections from the local host (IP 127.0.0.1). But our Raspberry Pi is a headless machine running the Lite version of the OS which does not have a GUI desktop. I suppose one could test using the Pi with curl or wget on the Pi to see the web page source. It is easier to include the --server-hosts 0.0.0.0:5232 command line option which "binds the server to all addresses". This is jargon for saying that the builtin web server will now accept HTTP requests from any IP address, so it will be possible to reach it from another machine on the local network.
• Calendars and contacts will be stored in the /home/nostra/.var/lib/radicale/collections directory because of the --storage-filesystem-folder=~/.var/lib/radicale/collections command line option.

So just open a web browser on a machine on the same local area network as the Raspberry Pi and open the Radicale login page at damus.local:5232. A new user can be created by entering a user name and a password in that login screen. You can then create or import an address book ar calendar in the next page entitled Collections. Once you have finished testing the server, get rid of the directory.

Let's go on with the "permanent" installation of the server. It will be run by a user called radicale which does not have a login for security reasons. That new user will be a member of a group also named radicale.

A single command can reverse this. Note how the empty radicale group is automatically removed.

Now lets create a directory belonging to radicale to hold the calendars and contacts.

Let's create a minimal configuration file. I am using the nano editor as usual.

Since IPv6 is disabled on the Pi, the server is bound to only IPv4 addresses, but you may want to bind to all addresses if IPv6 is enabled. And we point the

I think it may not be necessary to specify the filesystem_folder given the systemd unit file about to be created. However it causes no harm and it will allow for manual launching of the server with the command sudo python -m radicale. Time to create the unit file, using nano once again.

Here is the file.

Let's enable the service so that it will automatically be started whenever systemd initializes the system.

We can manually start the server and check its status.

If you compare this long-winded description of the installation process to its source, it will be clear that all the instructions pertaining to the encrypted passwords have been removed. Again, this server is meant to be run behind a firewall and the only remote access to it will be done through WireGuard which will be encrypt all traffic end to end.

Installing the chrony Network Time Client and Server

All Tasmota devices are set up to use a remote network time server (using SNTP) to obtain the time. Having all these devices synchronizing with an outside server is a problem given the objective to have a home automation system that is running locally. Consequently, I want to make the Raspberry Pi act as an SNTP server. The Pi will have a hardware clock connected to it, so that even when access to the Internet is lost, it can be a reasonable accurate time server. Certainly accurate enough to turn lights on and off automatically. Adding the hardware clock will be left to the next part of this guide, for the remainder of this section, there will be no RTC connected to the Pi.

The default time synchronization service on Raspberry Pi OS, systemd-timesyncd, is stricly an NTP client and cannot be used as the NTP server. But it does work nicely with some servers. Here is part of the configuration file of the service.

Because VBoxService looks very much like something that would be used in a Virtual Box virtual machine only, it seems that should any one of the other three NTP servers be installed, systemd-timesyncd will not start. The reference server is surely ntpd by the Ntp Project, while OpenNTPD is the lightweight contender from OpenBSD but ported to Linux. I have seen chrony included in other Linux distribution. Looking at its features (see Comparison of NTP implementations done by chrony itself), it seems to be a good choice.

NTP Client

The chrony version 3.4 package available in the repository is three years out of date, something that is not unusual for Debian based releases. Nothwithstanding that defect, I installed that older version.

I decided to reboot, and check the situation with the new NTP package. As expected, the systemd-timesyncd.service is no longer active and the new service is operational. The systemd time control utility timedatectl is a bit confused, but the chronyc control utility should be used instead.

There is an unnecessary Run 'systemctl daemon-reload' to reload units warning from the systemd-timesyncd.service which can be safely ignored. The source servers used by chrony were shown in that last command for later comparison when the NTP server pool will be changed.

From past experience I know that power failures accompanied by longer loss of Internet access can play havoc with the time on the home automation system. In those particular instances, it is worthwhile to set the time manually in those circumstances. When this is done, chrony will update the system clock very slowly (like OpenNTP and other clients perhaps). I tend to be impatient and thankfully, the service can be configured to update the clock quickly. As usual, that is done by editing a configuration file.

At the end of the file, change makestep 1 3 to makestep 1 -1

While editing the configuration file, I also changed to the NTP server pool at the very beginning of the file to the Canadian pool that is ostensibly closer.

I then restarted the system and set the date and time manually to test that it worked. Note that it was necessary to enable the settime functionality before using it.

It was possible to set the date back a few months, meaning that manual adjustment of the time will be possible when access to the Internet is lost again. With a working Internet connection, it did not take long before the NTP client updated the system date and time to the correct value as can be seen. But again, this is because of the change in the makestep values. With the default values, the adjustment would have been stretched over a long period.

Changing the source did not bring about substantial differences as far as I can make out.

If you check the status there should be no error.

NTP Server

Bringing up the NTP server is remarkably easy as it comes down to a one-line addition in the configuration file.

Restart the service for the change to take effect.

Tasmota NTP Settings

When the Tasmota firmware boots, it sets its real-time clock at 00:00:00. It will then try to get the correct time from an NTP server, but this will be a hit-or-miss proposition given the default settings. It goes without saying that the Tasmota firmware needs the correct real time to trigger timers correctly. The time stamp of entries shown in the web interface console also uses the real-time clock value. Now that we have a local NTP server, we will attempt to use it with the Wi-Fi wall plug running Tasmota firmware already installed in the test home automation system.

The firmware stores up to 3 NTP server host names or IP addresses named ntpserverx (x=1,2,3). When Tasmota wants to know the time, it tries each URL in order stopping when it gets the current time.

[...] the time sync request is forced to NTPSERVER1. If can't connect, it tries NTPSERVER2. And finally NTPSERVER3. Ensure that these parameters are set appropriately and that the device can reach at least one of these time servers.

(Source: Timers trigger at the wrong time)

To start the test, I removed the default URL names and restarted the wall plug thus ensuring that the device had no valid time. This could easily be done in the web interface console of the device, but I chose to use my own MQTT client lazmqttc.

Be careful, do not use the tasmotas topic on a running home automation system, replace it with the topic of a single Tasmota module until everything is thoroughly tested. The point is moot in our example installation since there is only one device in place.

The Tasmota real time clock will not work properly until the time zone is set up correctly. The geographical coordinates of the device should also be set since they are needed to calculate sunset and sunrise times used in timers. Here is the pertinent information for my time zone which is AT (Atlantic Time). The offset between local time and UTC (coordinated universal time) depends on the date because we advance the clock by one hour in the winter.

• AST (Atlantic Standard Time) is UTC - 4 hours

AST starts on the first Sunday in November at 02:00 ADT.

• ADT (Atlantic Daylight Time) is UTC - 3 hours

ADT starts on the 2nd Sunday in march at 02:00 AST.

Here is the information about the Tasmota commands for setting for the start of the standard and daylight times.

    TimeStd H,W,M,D,h,T

    TimeDST H,W,M,D,h,T

        H = hemisphere (0 = northern hemisphere / 1 = southern hemisphere)
        W = week (0 = last week of month, 1..4 = first .. fourth)
        M = month (1..12)
        D = day of week (1..7 1 = sunday 7 = saturday)
        h = hour (0..23)
        T = timezone (-780..780) (offset from UTC in MINUTES - 780min / 60min=13hrs)

The proper Tasmota commands for the Atlantic time zone are as follows.

    TimeStd 0,1,11,1,2,-240
        H = O    : north
        W = 1    : first week
        M = 11   : November
        D = 1    : Sunday
        h = 2    : 02:00 (2 AM)
        T = -240 : AST is UTC-4 hours

    TimeDst 0,2,3,1,2,-180
        H = O    : north
        W = 2    : first week
        M = 3    : March
        D = 1    : Sunday
        h = 2    : 02:00 (2 AM)
        T = -180 : ADT is UTC-3 hours

Tasmota has to be told to use the settings for standard and daylight time periods with the Timezone 99 command and also it is best to make sure that NTP is enabled (Time 0) even if it is the default value. With all that I was able to set up a single Backlog command to take care of everything at once.

Instead of the IP address of the Raspberry Pi, its local host name damus.local could be entered as the first NTP server (NtpServer1 damus.local;) in the Backlog command.

Here is the exchange of MQTT messages as recorded in lazmqttc.

And here is what was displayed on the wall plug console. At the start, the time is 00:00:00 because I had just restarted the device after clearing the ntpserver<x> settings. After about a minute and 14 seconds, the backlog message was sent with the MQTT client and echoed as stat messages to the MQTT broker (as seen above) and shown on the console (as shown below). After a minute or so, I entered a time command in the console and the result was the correct local time.

It works. Given that success, I installed chrony on the "production" home automation system and sent the backlog MQTT message to all the tasmotas devices. I checked that they all got the current time from the NTP server.

This did not change anything substantial since none of the devices used timers, but at least the entries in their console screen will have meaningful time stamps and my Tasmota devices will no longer be unnecessarily polling NTP servers on the Internet.