January 10, 2019
With the New Year, I decided it was time to tackle once again the task of
updating the Raspbian operating system on my
Raspberry Pi (Model B Plus Rev 1.2) to the latest version of
Stretch updating the home automation system Domoticz at the same time. I had been holding back because
of problems using the newest version of Lighttpd
found in Raspbian Stretch to stream the
output from Mpjg-Streamer over a secure connection. I
have not solved that problem yet, but I have been experimenting with running
a VPN server on the Raspberry Pi and that would be a secure work around.
I expected that updating to Raspbian Stretch from
Jessie would be without problems. Especially since
Stretch has been out for a while now and the
Raspberry Pi Foundation has issued a number of updates. And I have tested it,
with Bluetooth notably and managed to do better with the newer
version. But I did run into little problems that nevertheless took some
time to figure out. Also, I have gotten better at setting up the
Raspberry Pi so I decided that this recounting of my experience might
be of use to others.
To be clear then, this post is just another one of my series on setting up a Raspberry Pi. I suspect that it would be of interest mostly to new fans of small single-board computers, in this case the Raspberry Pi. Assuming that many of these would be new to Linux, I have added sidebars entitled Information for neophytes in which I ramble about what that I think could be of help to beginners.
Table of Contents
- Getting Stretch on an SD card
- Headless Setup
- Initial Boot
- Change the Default User
- Updating the Operating System
- Installing Domoticz
- Installing mosquitto
- Installing MJPG-Streamer for Use With a Webcam
- Using MJPG-Streamer with a Raspberry Pi Camera Module
- Installing Mochad
- Real-Time Clock
- Temperature and Humidity Sensor
- Logs
- Conclusion
Getting Stretch on an SD card
The home automation system cannot be offline while I am experimenting with updates. Instead everything is being done on a Raspberry Pi Model 3 B. Once that new system is running, I hope to do the same thing on the old Model B which I have found more than adequate as a home automation server.
As usual, I downloaded the latest Lite version of
Raspbian:
Raspbian Stretch Lite Minimal image based on Debian Stretch Version: November 2018 Release date: 2018-11-13 Kernel version: 4.14
from https://www.raspberrypi.org/downloads/raspbian/. I followed the instructions to copy the image onto a micro-SD card in Installing operating system images but there was a minor glitch.
An older version of Etcher was causing an error
similar to that reported in Ubuntu 18.04 cannot launch etcher 1.4.6. Getting a newer
version of the program from balena at https://www.balena.io/etcher/ resolved the issue. I
removed the older version, by deleting the application
etcher-electron-1.4.6-x86_64.AppImage, which I had installed in
a directory named ~/.local/bin (short form for
/home/michel/.local/bin). I also removed the configuration
directory /home/michel/.config/etcher-electron and the
application desktop file:
/home/michel/.local/share/applications/appimagekit-Etcher.desktop.
Installing the current version of Etcher in a
Linux system is quite simple. I extracted the application,
balena-etcher-electron-1.4.9-x86_64.AppImage from the downloaded
archive and copied it to ~/.local/bin (it could be just about
anywhere else). I then started the application and let it install a desktop
file. From then on I could start Etcher in the usual
way. And, as before, it was a breeze to copy the operating system image onto
the SD card with the application. It is not even necessary to decompress the
downloaded archive containing the image file.
All these file management chores, copying, deleting, extracting from archives and so on, can all be done with "point and click" ease using Double Commander. It is one of the first utilities I install in all the Linux distributions I use. It even works in Windows, macOS and FreeBSD. Highly recommended.
raspi-config.
Headless Setup
Do something often enough, you should get better at it.
The Raspberry Pi is used as a headless server with no monitor and no keyboard. It is a hassle to dig out a monitor and keyboard just for the initial configuration of such a system. Since connectivity with the local network will be by Wi-Fi, it would be great if that could also be set up before the first boot. Well, it can; even more can be achieved if the desktop computer used to create the SD image is running Linux.
I followed the instructions from Raspian France: Mettre en place une Raspberry Pi sans écran ni clavier, but similar information is available in many places. For example, Brian Lough has a YouTube video, A Truly Headless Setup for your Pi.
The setup is in two or three parts. I am assuming that the (micro) SD card
containing the Raspbian image is still connected to
the desktop computer and its boot partition is showing up as
drive connected to the system. If not, remove the card from the reader,
wait awhile and insert it in the reader again. The partition should show up
as its file system is the ubiquitous FAT32 which most operating system can
read. If the desktop is running Linux the second,
much bigger partition, rootfs will also show up. Windows will not read a Ext4 partition. I don't know about
macOS.
- Enable ssh.
All that is needed for this is to create a file of any size, any content,
named
sshin thebootpartition. It can even be an empty file.michel@hp:~$ cd /media/michel/boot michel@hp:/media/michel/boot$ touch ssh michel@hp:/media/michel/boot$ ls -l ssh just checking -rw-r--r-- 1 michel michel 0 jan 3 11:04 ssh
Information for neophytesThese commands, shown on a greenish background, are typed out in a virtual console or a terminal which is a wrapper program that runs a shell or command processor on my desktop Ubuntu system. The terminal is easily started with the simultaneous three key press: AltCtrlT.
The desktop computer name is
hpand my user name ismichel, hence the shell starts each command line withmichel@hp:. After the colon, comes the present working directory (pwd in the jargon). In this case it is initially~which is short for the current user home directory which here is/home/michel. Finally, the shell writes the prompt which here is$. It can be different dependant on the shell being used. That's Linux for you, there is more than one shell.The first command,
cd(for change directory), changes the present working directory. The second command,touch, is used to change the time stamp of a file. But here we are exploiting a side effect of the command; if the named file does not exist, it is created. The third command,ls, lists the content of the present working directory if no parameters follow it. In this instance, the-lparameter asks for a detailed listing. The added filenamesshwill limit the listing to matching files. We can then see that the filesshhas indeed been created and that its size is 0.Instead of using
touch, a file with minimal content namedsshcould have been created with a text editor such asnano(see below). It would not matter what the file contained.Do not forget to press the Enter key after typing each command. That is how the shell knows that you are done and that it is time for it to do its job. A long time ago, back when most computer programs were punched on cards made of light cardboard, I caused the reboot of a laboratory system when I first used an interactive terminal because I hadn't realized the need for the Enter. I will not go into the details, suffice it to say I am still red-faced about ruining someone's experiment. We all have to learn.
Because Double Commander allows me to launch a terminal in a specific directory, I did not even have to do the three-finger salute mentioned, nor issue the change directory commandcdshown above. - Create the wpa_supplicant configuration file with Wi-Fi credentials.
I used
nanofrom the command line, but any text editor such as Geany could probably be used. The file,wpa_supplicant.conf, goes in thebootpartition alongside thesshfile created in the previous state. You have to adjust the network credentials of course.michel@hp:/media/michel/boot$ nano wpa_supplicant.confcountry=ca <<-- 2 letter country code update_config=1 ctrl_interface=/var/run/wpa_supplicant network={ scan_ssid=1 ssid="wifi_network_name" psk="wifi_password" }
Information for neophytesGNU
nanois a small text editor found on mostLinuxdistributions including Ubuntu and, as we shall see later, Raspbian. It is a relatively simple to use; all keystrokes, with the exception of control and meta sequences, enter text into the file being edited at the current cursor position. The most important control sequences are displayed at the bottom. There is an on-line manual. - Add static IP address for Ethernet and wireless network interfaces.
This requires access to the
rootfspartition. As far as I know it cannot be done in the Windows. The fixed IP address is added to thedhcpcdconfiguration file. I prefer to back up that file found in therootfs/etcdirectory before modifying it.michel@hp:/media/michel/rootfs/etc$ sudo cp dhcpcd.conf dhcpcd.bak michel@hp:/media/michel/rootfs/etc$ sudo nano dhcpcd.confAlternatively,
nanocan be made to backup the original when saving a changed version of the file.michel@hp:/media/michel/rootfs/etc$ sudo nano -B dhcpcd.confThe following lines, with appropriate changes, need to be added to the configuration file.
... interface eth0 static ip_address=192.168.1.100/24 static routers=192.168.1.1 static domain_name_servers=192.168.1.1 interface wlan0 static ip_address=192.168.1.101/24 static routers=192.168.1.1 static domain_name_servers=192.168.1.1
Information for neophytesAll the IP addresses shown above need to be adjusted to take into account the parameters of the local area network. The router IP address (often called
gatewayelsewhere) and the DNS server IP address are usually the same and often, but not always, similar to the one shown above. But some local area networks (LAN) use the so-called 24-bit address block starting at 10.0.0.0 and others use the 20-bit block starting at 172.16.0.0. All the LANs I have used were in the 16-bit block starting at 192.168.0.0, with the only exceptions being a virtual private network and the virtual machines in Oracle VM VirtualBox. If you want to learn more about these private networks look at the Wikipedia article.I think it is best to assign different IP addresses to the two interfaces, unless it is certain that the Ethernet and wireless interfaces will never be simultaneously connected to the same local network.
Of course, if Wi-Fi is not needed then there is no need to create the
wpa_supplicant.conf file and there is no need to set up the
wlan0 network interface in dhcpcd.conf. Similarly,
if the Ethernet interface will not be used, if using a Raspberry Pi
Zero for example, then there is no need to define a static address for
it in the configuration file. If physically possible, I would still
recommend setting up the Ethernet interface, just in case the Wi-Fi
connection initially fails?
Initial Boot
It is now time for the initial boot. All that needs to be done is to safely eject the SD card from the desktop reader, then place it in the SD slot of the Raspberry Pi and, lastly turn the power on. You may have to wait until the LED activity stops and the red LED is steadily on to open an ssh session.
Since I was able to set up a static IP, it was very easy to open a
remote session with ssh.
Opening a remote session on the Raspberry Pi means that shell commands
(things like cd, ls and cat) can be
executed on the Rapsberry Pi from another computer on the same network
as the Raspberry Pi. It comes down to using the desktop keyboard and monitor
as if they were connected to the Raspberry Pi.
Of course you have to use a program on the desktop to do this. On Linux systems, it would most likely be the command line
utility calledssh, part of the OpenSSH
suite of tools which implements the SSH (Secure Shell) protocol. Most Windows users would probably use PuTTY instead of ssh
to open a remote session on the Raspberry Pi. From what I can make out, Mac OS X users can use the built-in ssh client
in a terminal window as shown above but there are
alternatives.
It is necessary to log into an existing user account and provide
the correct password when starting a remote session or a local session with
a keyboard and monitor connected to the Raspberry Pi. Initially there is only
one user account: pi and the password is raspberry.
Note how ssh doesn't recognize the secure key returned by the
Raspberry Pi (ECSDA is the cryptography algorithm used to generate the key)
so it asks if it is alright to connect. Once you have answered yes,
in full, it will store the key and will not ask again.
ssh is a secure replacement for telnet. Anyone else
remember using NCSA telnet over a Crynwr packet driver on PC running MS-DOS? I would open
sessions on the IT department minicomputer, a PDP-11 as I remember. I forget
exactly why? Probably to send e-mails, which was a complicated thing to do in
the mid '80s. I do remember accessing gopher sites that way in
the early '90s and even building a demonstration gopher site for
our department trying to get the institution to get on with it. It never did,
but then HTTP took over. If it had not been possible to set a static IP address, then try to connect
to raspberrypi.local as shown here.
This will work in a Linux system where the Avahi utility is installed which is the case for most major distributions. It should also work in MAC OS (where Bonjour takes care of the zeroconf protocols). It probably will not work in a fresh install of Windows, but it might if Bonjour was added to connect to a networked printer, for example.
If another Raspberry Pi with the default raspberrypi hostname
was already connected to the network, then the newer Pi's hostname would be
mangled to avoid conflicts. Its qualified host name address could be
something like raspberrypi-1.local. You could use a zeroconf
service browser to try to find it.
If none of the above worked, then you will have to find the IP address of the Raspberry Pi. There are at least two ways to do this. One way is to log into your router with a web browser and see the IP addresses of the devices connected to it. By scanning these addresses with the Raspberry Pi connected and not connected to the network, it should be fairly easy to identify the Raspberry Pi. This is not a foolproof method, I find that my router does not show all connected devices and does not react quickly when a device is disconnected.
If you do not know the IP address of the router to access its web server
in the first place, then have a look on the back or bottom of the device
itself. If you are still out of luck, try running the ipconfig
in a command window on a Windows desktop. You could
use the ifconfig in a Linux or the
ip address command if net-tools (which contains
ifconfig is not installed which is the case in Ubuntu). Even simpler, look at the interface settings on the
desktop; the IP address of the default route and DNS server is probably the
IP address of the router. Below are a couple of screenshots taken in
virtual machines, the first running Mint19 (another
variant of Debian) and the second
Windows XP.
Another approach is to use an IP scanner. Angry IP Scanner is available for
Windows, Linux and Mac OS X. I use Zenmap, a graphical
interface for nmap which is available in the Ubuntu software library. If you have a wireless router, you
can try NetX on an Android tablet or phone. I am sure there is
something equivalent on IOS. Just as before,
do two scans for valid IP addresses on the local area network. One
scan is done with the Raspberry Pi powered on and connected to the network
and one scan with the Raspberry Pi powered off. A comparison of the
valid IP addresses should reveal the IP address of the Raspberry Pi.
It would be very awkward to run a home automation server such as Domoticz on a computer with a dynamically assigned IP address. Accordingly, if it had not been possible to set a fixed IP address previously, it should be done at this point.
You just need to add the static addresses as shown in part 3 of the previous section.
As suggested by the log-on screen, you really should change the password
and I strongly suggest that you change the hostname to avoid collisions with
other Raspberry Pi you may connect to the network. For illustrative purposes,
I set the host name to goldserver. There are a couple of other
changes that I always do. I set the correct time zone, but I do not bother
changing the locale or keyboard map. Minimizing the amount of memory
allocated to the GPU is a good idea. Use the configuration utility
raspi-config to change these settings.
Reboot as suggested, and then after a while reconnect with
ssh.
Change the Default User
For added security, it is not a bad idea to change the default user. In
the past, I would simply add a new user and eventually removed the
default user pi. But that was a hit-or-miss approach which usually
meant hunting down a missing group membership for the new user when something
new did not work. Luckily, Jim McDonnell at Unix etc.
has a very good explanation of how to proceed systematically to avoid such
problems. I just followed the instructions in How to Rename the Default Raspberry Pi User, executing
the scripts found in that article. There were a couple of error messages.
Because the listed configuration files are not present in the Lite
version of Raspbian there were no real errors, as
mentioned in the article.
sudo
would complain that it could not resolve host goldserver, which meant it
could not obtain its IP address. It turned out that I had to edit the
hosts file.
raspi-config utility.
Updating the Operating System
Before installing any major new piece of software, it is always important
to update the operating system. This is something that is done more or
less automatically in full blown desktop systems such as
Ubuntu. On the Lite version of
Raspbian, it has to be done manually.
This operation can take some time, especially with the single core Raspberry Pi 2 model B and even longer for the old Raspberry Pi 1. Nevertheless, the Raspberry Pi 2 manages quite well as a home automation server.
You may want to automate the procedure somewhat by adding the
-y switch.
Now you may be time to get a coffee, tea or other beverage.
Newcomers to Debian Linux might wonder what these
commands do. The first, apt-get update, scans the default Debian repository and any other repositories that you may
have added (see below for an example) to update the list of currently
available software packages in the repositories. The second, apt-get
upgrade will replace currently installed packages with any newer
version if available. It is important to realize that apt-get
upgrade uses to local list of available packages to decide if a newer
version is available, it does not scan the repositories itself. That why it
is important to execute apt-get update first.
If the -y option were to be added to the sudo apt-get
upgrade command, it would not be necessary to confirm, with a
y, that the operation is to be completed. I prefer not to do in
order to see clearly how much disk space will be occupied by the upgrade.
Other Linux
distributions have different package managers: Red Hat
and CentOS uses yum,
Arch Linux uses pacman and so on.
Even within Debian the story is rather more complex. As far as I know, APT (Advanced Packaging Tool) is actually a "front end" for DPKG the Debian Package Management System. There are other front ends, such as Synaptic, which I occasionally use on my Ubuntu desktop, and Aptitude.
With its inclusion in Ubuntu 16.04 in 2016, a new
front end called simply apt started to become popular. Basically,
it aggregates the commands spread across the apt-get and
apt-cache utilities. You will find in my posts that I sometimes
use apt update and apt upgrade instead of
the apt-get versions shown above. They are basically
interchangeable. The same is true for apt show and
apt-get show, but I prefer to use apt-cache policy
to get pithier information about available versions of a package as well
as the installed version when a package is already installed.
For more information see Difference Between apt and apt-get Explained.
Here are three commands that could prove useful to new users
of the Linux shell. First, to end a session,
use the exit command. If you were running a remote
session with ssh then that will bring you back into the
desktop terminal program.
The Raspberry Pi will continue to chug along when you logout. Processes including servers such as a Web server and a home automation server that were running will continue to function.
To reboot the Raspberry Pi, issue the reboot command which is
not too surprising. But this has to be done as a superuser (with
adminitrator priviliges in Windows jargon), which
requires using the sudo prefix as done on a number of occasions
above.
You may not see the connection closed messages. The other command is used to shut down the Raspberry Pi in an orderly fashion. It is always best to issue that command and waiting for a little while before removing power to a Rasbperry Pi.
Be careful with these commands. I have lost a lot of work when I carelessly typed the command without looking at the prompt. Instead of shutting down a Raspberry Pi, I entered the command in a Ubuntu shell with the obvious consequence that my desktop computer became very quiet very quickly. You have been warned.
Installing Domoticz
Installing Domoticz has always been a very simple matter in the past when following The "easy" way instructions. But for some reason, I was getting an error.
That means that the shell, bash, was choking on the first
line of the installation script which was <!DOCTYPE html>. That was
strange but after some thought, and running the curl
command without the pipe to bash, I realized that the
default index page was being returned from domoticz.com and
not the script which was presumably at install.domoticz.com.
Then it dawned on me that this was probably a consequence of a broken or
missing redirection of secure HTTP requests. Something which I have
struggled with on my site. So using the full URL solved the problem.
The installation script will install the git and
libudev-dev packages.
In the past, I would copy the database, various bash and python scripts and floor plan images from a running Domoticz installation to a new one and it worked flawlessly. It was a bit more complicated this time because of changes between the newest version of the software and the older version I was using. It was a minor problem, floor plans had to be deleted and rebuilt in the new version.
I get browser cache refresh failures when opening the freshly installed Domoticz web page. I caught on that this problem shows up in very specific circumstances. With Firefox the failure occurs when using HTTPS, but not when using private browsing. Presumably in the latter case, there is no cache to refresh. With Chromium, the cache failure occurred whenever HTTPS is used no matter if incognito browsing is used or not. It seems that the problem is independent of Domoticz and stems from the use of a self-signed TLS certificate.
When using my Android tablets to access the server, I got cache problems even with insecure access. Some tabs, notably Scenes and Temperature, were empty at first and then after some time would become populated with garbled entries. I deleted home screen icons to start Domoticz and the complete browser history and that fixed the problems.
This is a good place to express all my gratitude to the Domoticz development team as well as to the community.
Installing mosquitto
An MQTT broker is a necessary part of my home automation
system. The mosquitto broker is available in the
Rasbian Stretch repository, so I proceeded to
install it and the optional utilities to get mosquitto_sub
and mosquitto_pub.
After rebooting, I checked and found that the broker was running automatically.
Version 1.4.10 of the broker was installed, while version 1.5.5 had been
working on the old home automation system. The reason is that I had manually
installed a newer version of Mosquitto in Jessie. This can be done in Stretch
contrary to what I wrote in the first version of this post. Here is how I did
on another Raspberry Pi 3 with a fresh installation of Raspbian. Its host name was testbed.
This perhaps cryptic sequence of commands is equivalent to the somewhat dated instructions found in a document perhaps inaptly named Mosquitto Debian repository. I also consulted the repository read me txt.
Verification that it all worked was not too difficult.
To be doubly sure, I opened two session on the home automation server. In the first I subscribed to all topics with the newly created mqtt broker.
A message was sent to the broker in the second session.
This message was then displayed in the first session.
This confirmed that version 1.5.5 of the Mosquitto mqtt broker was functioning. However, I have not encountered problems with the older version of the broker on the home automation system and decided to keep it.
Installing MJPG-Streamer for Use With a Webcam
I have already documented how to use MJPG-Streamer in conjunction with Domoticz to stream video from a USB webcam. Everything in part 2. Software works without change in Rasbian Stretch. There is no point going into detail again, here is the sequence of commands needed to install the video streaming software with its prerequisites.
The executable binary file is placed in the /usr/local/bin
directory, the input and output libraries in
/usr/local/lib/mjpg-streamer/ and the served web pages in
/usr/local/share/mjpg-streamer/www. Here is the command
to stream the video from a webcam (Logitech
HD Webcam C270) running at 10 frames per second at a 1280x720 pixel
resolution. Of course the webcam should be connected to the Raspberry Pi
before this command is given.
Given the specified port, the URL of the MJPG-Streamer
Web page is http://goldserver.local:8085. Use the IP address
of the Raspberry Pi if mDNS host names cannot be resolved.
Satisfied with the result I removed the installation directory but kept the installation archive moving it to a download directory and renaming it.
Using MJPG-Streamer with a Raspberry Pi Camera Module
I also have a V.1 Raspberry Pi camera module (Rev 1.3). To test it with MJPG-Streamer, I powered down the Raspberry Pi, removed the USB webcam, and connected the ribbon cable as shown in How to install / use the Raspberry Pi Camera. Use the connector between the 3.5mm RCA jack and the HDMI connector. Pull up the black tab on the connector about 2 mm, slide the ribbon into the slot with the metallic connectors facing the HDMI port. Press down the black tab to lock the ribbon cable.
After powering up, use the configuration utility raspi-config
to enable the camera.
It is the first option in the Interfacing Options screen. It
will be necessary to reboot for the change to take effect and then to open a
new session on the Raspberry Pi. Using the default values of the input
library for the camera module provided with MJPG-Streamer is very simple.
I wanted to use the same parameters as used with the Webcam. It is possible but options are defined differently with this input library.
More information about the input module can be found on the mjpg-streamer github.
I found the results acceptable, but the camera module seemed more sluggish than the webcam. Something to investigate later.
Installing Mochad
For the sake of completeness installation of the Mochad daemon will be presented here. This was already covered in a previous post: Domespic [3] Gateways - Install Mochad. The daemon (or service) is used in conjunction with a CM19A USB PC Transceiver to receive RF transmissions from a battery powered remote control, the HR12A PalmPad, and pass them on to Domoticz to control IoT devices. I had hoped to remove all X10 based technology from my home automation system and just a few days ago the last X10 module was retired from service. However, the RF remote is simple, quite versatile and it is often used. Given its high WAF, it will stay.
Sourceforge still serves mochad version 0.1.16 as
the latest version of the service even though version 0.1.17 is available and
needed in newer versions of Raspbian. The following
shows how to install the later version. However you should check for a newer
version here: https://sourceforge.net/projects/mochad/files/ and adjust
the wget commands accordingly.
I then plugged in the CM19A into a free USB port and waited a little while for the system to find it. After that I tested that it received RF codes from the remote.
Use a CtrlC combination
to exit the netcatprogram.
Using the remote with Domoticz is quite simple since it is directly supported hardware. For details see Domespic [4] Domoticz - Add X10/Mochad to Domoticz.
As before, I cleaned up the home directory, saving the downloaded archive.
Real-Time Clock
A real time clock, based on the DS3231 chip is connected to the Raspberry Pi. The instructions, showing how to install modules for that little daughter board, written back in March 2017 (with an update in May of the same year), Real Time Clock, DS3231, for Domoticz on the Raspberry Pi, work in the newer version of Raspbian. This is a recap of the information.
First check that the I2C interface has been enabled.
If nothing is displayed, use the configuration utility raspi-config
to enable loading the I2C kernel module in the Interfacing Options
page. Once I2C has been enabled, a couple of packages are installed.
The first command installed 81.8 kB of archives. The second verified
that the clock module was found at address 0x68. If you are willing to
skip that step, it is not necessary to install i2c-tools.
Add the real time clock module to the kernel which involves adding
a line in the modules file.
The real-time clock can be used once the system is rebooted. The utility
used to do that, hwclock, requires superuser rights
and should be called with the sudo prefix. There is really no
use case for manually reading the clock of a headless server, instead the
internal clock is updated from the hardware (real-time) clock whenever the
system reboots. But for that to work, the address of the chip has to be set.
The changes take effect after a reboot.
The real-time clock could drift over time. So a cron task is
defined to update the system time from NTP (network time protocol) servers on
the internet once an hour. After that, the real-time clock is updated from the
system time.
That way, if power is interrupted, the hardware clock has a reasonably accurate value and will keep time more or less accurately because of its internal battery. When power is restored, the Raspberry Pi will reboot and set its time from the real-time clock even if it cannot reach an NTP server.
Temperature and Humidity Sensor
As for reading the temperature and humidity sensor, a DHT11, things
appear to be simpler than what I wrote in Temperature Sensors on a Raspberry Pi hosting Domoticz back in
June of 2017. It looks like it is not necessary to edit the
/boot/config.text file. On the other hand, I had to install
python pip which was not mentioned in that post.
Installation and testing of the Adafruit python library for DHT11 and DHT22 (AM2302) sensors is relatively straight forward. Instead of cloning the Github repository, I just downloaded a zip archive, extracted its content and installed it.
Since that was working I removed the installation directory but kept the installation archive moving it to a download directory and renaming it.
My original post, Temperature Sensors on a Raspberry Pi hosting Domoticz, contains Python scripts that update a virtual temperature and humidity sensor in Domoticz with values read from the DHT11.
Logs
I changed the system configuration to save wear on the SD card by keeping the system journal in a file in RAM .
I also enabled the UDP module of the log server on the Raspberry Pi. The configuration file is new slightly different from what I wrote in my previous post: Syslog Server on Raspbian.
This change is to capture log messages from IoT devices running Tasmota by Theo Arends. Logging has to be enabled in those devices for this to function.
Conclusion
The last major piece of software to install is a web server. As explained before, I used Lighttpd but I am having some problems with it. If I cannot get the latest version to act as a secure reverse proxy for the MJPG-Streamer web server, I could try installing another package or I could try to revert to the older version that worked in Jessie.
To be honest, this is just being pigheaded. I just hate being stumped by something that worked previously, so I would really like to solve the problem. However, I am pretty sure I will not use the reverse proxy. I will install the latest version of Lighttpd, mostly to support OTA updates of IoT devices on the local network. But I will also install a VPN server on the Raspberry Pi to secure access to the system from outside the local network (i.e. over the Internet).
OpenVpn is presently operating rather well on the older Raspberry Pi running Jessie. It might be a good time to check out WireGuard. There is a project on Github by Arian Mihalko to facilitate its installation onto a Rapsberry Pi and Dr Zzs has a video on the subject.
So this is a good point to back up the SD card. As I experiment with all the above, I could very well want or have to come back to this point which will be easy with the backup. Here is how I do it on my Ubuntu desktop.