Draft of the fouth part of a projected multi-part guide

This is part 4 of the series of posts about installing a home automation system around Domoticz on a Raspberry Pi. It covers installing additional hardware.

Raspberry Pi GPIO

Older RaspberryPi models had a 26 pin header along the right edge of the board. Newer Raspberry Pi models also have a header along the same edge but it has 40 pins as shown with the model 4 B below on the left. In both cases, pin 1 is at the top, pin 2 is to the right, pin 3 is below pin 1 and so on. A few pins are connected to the system ground and to power (3.3 and 5 volts). Others were connected to some of the input/output (GPIO) pins of the Broadcom system on a chip (SOC) as can be seen on the schematic of the different Raspberry Pi models: Schematics and Mechanical Drawings.

As can be seen on the following figure, GPIO pins are not all the same. Some implement communications protocol in hardware (I2C, 1-wire, Serial...) while others are simple input or output connections.

Source: GPIO in Raspberry Pi Documentation: Usage
Click on the pinout for a larger view

Some of the sections that follow describe various hardware additions that are connected to the Raspberry Pi GPIO. In some cases, there is some latitude in choosing the GPIO pins to connect to the device, but in other cases, there is no choice or it is limited to certain sets of pins.

Debug Serial Connection

If you have a USB to Serial adapter that operates on 3.3V and you know how to use a terminal program such as

Screen,
tmux,
cu (part of the uccp package)
minicom,
picocom,
or C-Kermit,

then it is relatively simple to connect to a Rapsberry Pi. Here is the pinout.

Raspberry Pi			USB Serial Adapter Connection
Pin	GPIO	Function	USB Serial Adapter Connection
6, 9 or 14	Ground		Ground pin
8	14	UART0_TXD	RX pin
10	15	UART0_RXD	TX pin

USB cable to GPIO connection

Make sure to shutdown the Pi correctly.

and then turn off all power to it before

If the Raspberry Pi is an older model without built-in Bluetooth, then there is no further preparation needed, because the single true hardware UART is brought out to the header pins in these models. Go on to Using the Serial Port.

Serial Port on Raspberry Pi with Onboard Bluetooth

In newer Raspberry Pi models the UART is used to communicate with the Bluetooth chip. So a serial connection on these newer models involves making a choice.

Keep Bluetooth capabilities and connect the less capable mini-UART to the serial port and accept a reduced cpu core frequency.
Disable Bluetooth and connect the hardware UART to the serial port.
Use the mini-UART to communicate with Bluetooth and connect the hardware UART to the serial port.

Option 2 will make sense in my case because my automation server will be moved to a remote corner of the basement with no real use for wireless communication. Option 3 does not appeal to me, if Bluetooth is needed then it probably involves the user directly, such as using an input device (a mouse or keyboard for example) or streaming audio, and a less than optimal experience would not be acceptable. To be honest, I have not tested this option and I am just trying to justify the use of option 1. Besides, debugging whicj is presumably a short term operation may very well involve looking at the Bluetooth service.

nestor@domus:~ $ sudo nano /boot/config.txt

Add the following line at the end of the file, making sure that it is in the [all] section and not in a [piXX] section that would apply to only one model of the Pi.

... [all] #dtoverlay=vc4-fkms-v3d gpu_mem=16 start_x=1 enable_uart=1

In addition to enabling the mini-UART, this will lock the core frequency at 250Mhz disabling turbo mode. In older versions of the OS, pre 2016, it was necessary to explicitely do this with the core_freq=250 directive. If we were to reboot at this point, we would see that mini-UART has been assigned to /dev/serial0 which is brought out to the header pins.

nestor@domus:~ $ ls -l /dev/serial* lrwxrwxrwx 1 root root 5 Oct 29 14:37 /dev/serial0 -> ttyS0 the mini-UART lrwxrwxrwx 1 root root 7 Oct 29 14:37 /dev/serial1 -> ttyAMA0 the hardware UART

Many tutorials recommend removing console=serial0,115200 at the start of /boot/cmdline.txt. I have found that if I do that I cannot reach a login. Perhaps because the baud rate is no longer set to 115200? Something to look into. So leaving the file unchanged, I find that it is possible to open a session over the serial port without problem. However, when rebooting the system, every message is lost until the reboot starts.

nestor@domus:~$ sudo reboot � l��cp�� |c�no�� ls��B��c�n��|�s��ol[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 5.10.63-v7+ (dom@buildbot) (arm-linux-gnueabihf-gcc-8 (Ubuntu/Linaro 8.4.0-3ubuntu1) 8.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #1459 SMP Wed Oct 6 16:41:10 BST 2021 [ 0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d

However if I get rid of the console=tty1 command in /boot/cmdline.txt, so that the start of that one line file is

console=serial0,115200 root=PART...

instead of

console=serial0,115200 console=tty1 root=PART...

then all messages to the standard output as the system shuts down are visible.

nestor@domus:~$ sudo reboot [ OK ] Stopped target Graphical Interface.[ OK ] Stopped Daily apt download activities. Unmounting RPC Pipe File System... [ OK ] Stopped Daily rotation of log files. [ OK ] Stopped Daily man-db regeneration. [ OK ] Closed Load/Save RF Kill Switch Status /dev/rfkill Watch. [ OK ] Stopped target Sound Card. ... [ OK ] Reached target Shutdown. [ OK ] Reached target Final Step. [ OK ] Started Reboot. [ OK ] Reached target Reboot. � �|l l ll2�|B�nn�� ls��C��c�o��|�r��nl[ 0.000000] Booting Linux on physical CPU 0x0

cd /media/michel/boot michel@hp:/media/michel/boot$ nano config.txt

Using the Serial Port

List the USB serial devices on the desktop machine before connecting the USB to serial (tty) adapter to it.

Now connect the serial end of the the USB to Serial adapter to the Raspberry Pi which should not be under power and then connect it to the desktop USB port. List serial devices to find the newly added adapter, start up the terminal program connecting to that port and then apply power to the Raspberry Pi. You should then see the Linux boot messages which end with a login prompt.

If using Screen the terminal should be launched with the following command on the desktop.

If using cu the terminal should be launched with the following command on the desktop.

that you may see later on in this post unless you have connected to the Raspberry Pi over the local area network, which is not necessary when there is a direct serial connection with the Pi. Skip ahead to the Basic Configuration section.

Real Time Clock

Many devices in the Domoticz home automation system are scheduled to turn on or off at defined times of the day. Other scheduled tasks have been relegated to the cron daemon. The system is also a log server which typically adds timestamps to all incoming messages. All this requires relatively accurate time which can be a problem on a Raspberry Pi which has is no real-time clock (RTC) and which therefore relies on timestamps obtained from Simple Network Time Protocol servers. Unfortunately, on more than one occasion we have een without Internet access for a few days following a power outage because of a bad storm. In such circumstances the time kept by the Raspberry Pi can be quite incorrect because, on start up, it will use the last time saved in a system file before the power went off and that will not be updated until an NTP server can be reached. A cheap real-time hardware clock with an independant power source such as the two shown below can be used to restore the correct time automatically in those situations. Both of these I²C modules use the DS3231 chip, but many other modules using different chips can be used.

As explained by Gus (Angus Young) in Raspberry Pi RTC: Adding a Real Time Clock (April 12, 2019) and Lady Ada (Limor Fried) in Adding a Real Time Clock to Raspberry Pi (last updated October 25, 2021) a simple modification of the boot configuration file is all that is needed to load the RTC drivers and activate the I2C bus used by the hardware clock.

Find the three lines beginning with #dtparam= and add the dtoverlay line after.

What if the RTC is not based on the DS3231? Well the i2c-rtc overlay supports quite a few chips. The following command will provide the complete list of the more than 25 supported devices and the list of options that can be passed on to the overlay.

Reboot the system and then, after opening a new session, check that the real time clock device has been created by the kernel and that the real time clock can be accessed.

There is only one hardware clock connected to the Pi and it shows up as device /dev/rtc0 in the OS. The dev/rtc is a symbolic link to the "preferred" clock device, which of course in our case must be the only clock device. As far as I know, /dev/rtc is never used.

By default the systemd-timesyncd or chronyd service will synchronize the system time at regular intervals and update the real time clock at the same time. Unfortunately, there is no default provision to update the system time from the real time clock when the system boots. That means that should the Pi not have access to the Internet after booting, the system time will not be correctly updated even if the real time clock does have a valid date and time. One could always do that by entering a command in a terminal.

The hwclock utility cannot be run without administrative privileges, so the sudo is necessary. The --hctosys (or -s) option stands for hardware clock to system clock which does what we want. If the -verbose (or -v)) option is not present, then the system time will be udpated but the command will not send any output to the terminal.

Note the abscense of the sudo prefix, because as stated it is root that runs that script.

Instead of doing that, Gus, Lady Ada, and many others included myself staring in 2019, levearage a udev rule that runs a hwclock-set script when the rtc0 device is created. Here is the rule.

I did write "levearage" because the script is modified to do something other than what it was intended to do.

Look carefully at the comment: the script is meant to fixup any problem that could be caused by having the RTC set to local time, whereas the system clock must be set to UTC (coordinated universal time, the successor to GMT or Zulu time if you have a military background). And look further, the script stops if the system manager is systemd. In other words, the script does nothing as is in Raspberry Pi Os, other Debian based distributions and many more Linux systems. The first change is to disable this test.

Gus, Lady Ada and others then go on and disable half of commands executed by the script.

I have never bothered to comment out the hwclock --rtc=$dev --systz, with and without --badyear, lines and have not had detected problems so far. Why is that? Reading the manual ($ man hwclock), suggests to me that running that option would not do much harm as it does not read the hardware clock but merely makes sure that the system clock is set to UTC.

Hardware Watchdog

In the previous post in this series, a software watchdog was installed that will reboot the computer if Domoticz no longer feeds it. For even better protection for a headless server, I have been looking at adding a hardware watchdog that, as a last resort, will restart the Raspberry Pi in the hope that it will recover.

Right now I am using a Cheap Of-the-Shelf Raspberry Pi Hardware Watchdog but I hope to replace that with something more sophisticated that tries to reboot a non responsive Pi before performing a hard reset. However, I have made significant progress in replacing this less than optimal watchdog with something more appropriate. See Rethinking the Raspberry Pi Hardware Watchdog.

A lot of things have been added to the operating system. This would be a good time to perform an overview.

That's 52 services none of which have failed, thankfully. As can be seen some services are no longer running, so limiting the list to running services would be more informative.