Various Hardware with Raspbian Buster Lite
Draft: January 29, 2020
<-Home Automation Servers on Raspbian Buster Lite --
<-Installation and Configuration of Raspbian Buster Lite

This is a draft of a forthcoming third post about Raspbian Buster Lite. I have made it available much too soon because some sections which were in the original version of the first post on installing and configuring Raspbian Buster Lite have been moved to this third instalment in the series.

Table of Contents

  1. USB Wi-Fi Dongles
  2. HA Bridge to Alexa (forthcoming)
  3. Mochad Bridge to X10 RF USB transceivers
  4. Heyu as Bridge to X10 PL Serial transceivers
  5. Video Cameras (forthcoming)
  6. Bluetooth
  7. Removing Bluetooth
  8. Backup
  9. Raspberry Pi GPIO
  10. Real-Time Clock
  11. Temperature and Humidity Sensor
  12. Reboot and Shutdown Switch
  13. Hardware Watchdog (forthcoming)

USB Wi-Fi Dongle toc

On the older Raspberry Pi there is no built-in Wi-Fi but a Wi-Fi USB dongle can be used to get wireless connectivity. I have three slightly different dongles that are not treated equally in the new version of Raspbian. Using the lsusb command, it was possible to identify the chipset used in each after plugging in the dongle.

woopi@goldserver:~ $ lsusb ... Bus 001 Device 004: ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter ...

All three are from the Realtek Semiconductor and thus share the same Vendor ID: 0bda. The Product ID are different.

Product IDDescription
8179RTL8188EUS 802.11n Wireless Network AdapterFAST on the black end and FAST FW1 150US 2.0 180101 on the metal shield
0179RTL8188ETV Wireless LAN 802.11n Network Adapter802.11n in small italic font on side of black end and 2 holes in the metal shield
8176RTL8188CUS 802.11n WLAN Adapter802.11n in bold font on side of black end and 4 holes in the metal shield (2 for LEDs)

While I am rather sure that all have worked in the past, only the last would work with Raspbian Buster Lite. Here is what the network interface configuration utility shows with a non-functioning Wi-Fi dongle.

woopi@goldserver:~ $ ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet netmask broadcast inet6 de08:82:fdff:1234:fedc:a33b:5412:31ab prefixlen 64 scopeid 0x0 ... ether 80:10:ab:cd:ef:00 txqueuelen 1000 (Ethernet) RX packets 579 bytes 47077 (45.9 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 142 bytes 23438 (22.8 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 ... wlan0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether 00:bb:33:00:11:32 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

A couple of answers on StackExchange for the Raspberry Pi lead me to a solution: Realtek USB wifi module - RTL8188EUS is not working and also it is disconnecting LAN connection as well on Raspbian Jessie, and more to the point Mosè Bottacini's answer pointing to MrEngan's script.

woopi@goldserver:~ $ sudo wget -O /usr/bin/install-wifi --2019-10-20 19:18:53-- ... 2019-10-20 19:18:54 (50.6 KB/s) - ‘/usr/bin/install-wifi’ saved [19641/19641] woopi@goldserver:~ $ ls woopi@goldserver:~ $ sudo chmod +x /usr/bin/install-wifi woopi@goldserver:~ $ sudo /usr/bin/install-wifi *** Raspberry Pi wifi driver installer by MrEngman. ...Installing driver module 8188eu.ko. install -p -m 644 8188eu.ko /lib/modules/4.19.75+/kernel/drivers/net/wireless Syncing changes to disk A version of the 8188eu driver is already loaded and running. You will need to reboot to load the new driver, 8188eu.ko. woopi@goldserver:~ $ sudo reboot Connection to goldserver.local closed by remote host. Connection to goldserver.local closed.

When logging back in with ssh after giving the Raspberry Pi some time to perform the start up tasks, it was a simple matter to verify with ifconfig that the wireless interface was working. And it turned out that driver also worked with the other Realtek Wi-Fi dongle.

HA Bridge to Alexa toc

The Alexa Dot Echo, the Google Home mini and other connected smart speakers are stand alone devices that are not peripheral devices physically connected to a home automation system. However they do provide voice control of smart switches and devices through the home automation system albeit in an indirect way. I find that the Alexa Dot Echo in combination with HA-bridge and Domoticz is a very usable system. The Google Home mini with IFTT is not as dependable and as quick and I have abandoned that approach.

In the home automation system, the bridge between Alexa and Domoticz was handled by another single board computer. But the Raspberry Pi 3 is quite capable of handling the HA-Bridge as well as all the other services mentioned in this series of posts.

Reference: HA Bridge on Armbian Working with Domoticz and Alexa

Rest to come...

Installing Mochad toc

Powerhouse Palm PadCM19A USB RF tranceiver
I still use an X10 wireless device in the living room to control lights in the same room and in the garage. I find that the combination of the Palm Pad and CM19A USB RF transceiver is relatively reliable given the visual feedback afforded by the lights.

The home automation server cannot communicate directly with the RF transceiver. It is necessary to install a "shim" or bridge called Mochad. The bridge is dependant on a library that needs to be installed also. SensorFlare forked Mochad on github. This modified version will connect to the SensorFlare IoT cloud service. Enough said, do not use this github fork, get the original package from SourceForge as shown next.

woopi@goldserver:~ $ sudo apt-get install libusb-1.0-0-dev -y Reading package lists... ... After this operation, 1,711 kB of additional disk space will be used. ... Setting up libusb-1.0-0-dev:armhf (2:1.0.21-1) ... woopi@goldserver:~ $ wget -O mochad.tgz woopi@goldserver:~ $ tar xf mochad.tgz woopi@goldserver:~ $ mv mochad-0.1.17 mochad woopi@goldserver:~ $ cd mochad woopi@goldserver:~/mochad $ ./configure checking for a BSD-compatible install... /usr/bin/install -c ... config.status: executing depfiles commands woopi@goldserver:~/mochad-0.1.17 $ make gcc -DPACKAGE_NAME=\"mochad\" -DPA... woopi@goldserver:~/mochad-0.1.17 $ sudo make install ... woopi@goldserver:~/mochad-0.1.17 $

Rebooting will load the service.

woopi@goldserver:~/mochad-0.1.17 $ sudo reboot Connection to goldserver.local closed by remote host. Connection to goldserver.local closed. michel@hp:~$ ssh woopi@goldserver.local ... woopi@goldserver:~ $ sudo systemctl status mochad ● mochad.service - Start mochad service Loaded: loaded (/lib/systemd/system/mochad.service; disabled; vendor preset: enabled) Active: active (running) since Sat 2019-01-19 17:20:26 AST; 1min 41s ago Process: 548 ExecStart=/usr/local/bin/mochad (code=exited, status=0/SUCCESS) Main PID: 551 (mochad) CGroup: /system.slice/mochad.service └─551 /usr/local/bin/mochad Jan 19 17:20:26 goldserver systemd[1]: Starting Start mochad service... Jan 19 17:20:26 goldserver mochad[548]: starting Jan 19 17:20:26 goldserver systemd[1]: Started Start mochad service. Jan 19 17:20:26 goldserver mochad[551]: usb_claim_interface failed -6 Jan 19 17:20:26 goldserver mochad[551]: Found kernel driver 1, trying detach Jan 19 17:20:26 goldserver mochad[551]: Found CM19A Jan 19 17:20:26 goldserver mochad[551]: In endpoint 0x83, Out endpoint 0x04

Notwithstanding the error message displayed by systemctl, mochad does work as verified by using nc (netcat) to connect to the TCP port of the bridge

woopi@goldserver:~ $ nc localhost 1099 01/19 17:23:07 Rx RF HouseUnit: C1 Func: On 01/19 17:23:09 Rx RF HouseUnit: C1 Func: Off 01/19 17:23:12 Rx RF HouseUnit: C2 Func: On ^C

Shown are the response as buttons on the Palm Pad were pressed.

More details are available in a previous post: Domespic [3] Gateways.

Installing Heyu toc

While there is no longer any power line X10 devices in the house, Domoticz on the old Raspberry Pi 1 will have to handle a number of devices of that type using a CM11A serial computer interface. But, just as there is no direct support for the CM15A/CM19A interfaces in, Domoticz, there is none for the CM11A. A "gateway" called heyu can be installed. It is actually a home automation program of its own but limited to devices that can work with the X10 powerline and RF protocols.

Installation of Heyu is quite similar to that of Mochad: get the source code, compile it and install the resulting binary. I have not had much success with the newer 2.11 and 2.10.1 versions so I use the Oct. 2015 2.10 version.

First connect the CM11A to a USB port with a USB to serial cable. Wait a little while and locate the device used.

woopi@goldserver:~ $ ls /dev/ttyUSB* /dev/ttyUSB0

Now proceed with the installation proper.

woopi@goldserver:~ $ wget -O downloads/heyu_v2.10.tgz ... woopi@goldserver:~ $ tar xf downloads/heyu_v2.10.tgz heyu-2.10/ woopi@goldserver:~ $ cd heyu-2.10/ woopi@goldserver:~/heyu-2.10 $ ./Configure woopi@goldserver:~/heyu-2.10 $ make ... plenty of time to do something else! ... woopi@goldserver:~/heyu-2.10 $ sudo make install ... I did not find a Heyu configuration file. Where would you like the sample Heyu configuration file installed? 1. In directory /home/woopi/.heyu/ 2. In subdirectory .heyu/ under a different user home directory 3. In directory /etc/heyu (for system-wide access) 4. No thanks, I'll take care of it myself Choice [1, 2, 3, 4] ? 1 The sample configuration file will be installed as /home/woopi/.heyu/x10config ... To which port is the CM11 attached? /dev/ttyUSB0 ...

Hopefully, Heyu is installed correctly. Check by invoking the application's information command and then try to turn a device on and off

woopi@goldserver:~/heyu-2.10 $ cd ~ woopi@goldserver:~ $ which heyu /usr/local/bin/heyu woopi@goldserver:~ $ heyu info starting heyu_relay Heyu version 2.10 Configuration at /home/pi/.heyu/x10config Powerline interface on /dev/ttyUSB0 Firmware revision Level = 7 Interface battery usage = Unknown Raw interface clock: Wed, Day 327, 00:03:28 (--> Civil Time: Wed 23 Nov 2016 00:03:28 AST) No schedule has been uploaded by Heyu. Housecode = A 0 = off, 1 = on, unit 16.......8...4..1 Last addressed device = 0x0000 (0000000000000000) Status of monitored devices = 0x0000 (0000000000000000) Status of dimmed devices = 0x0000 (0000000000000000) woopi@goldserver:~ $ heyu on b1 woopi@goldserver:~ $ heyu off b1

Note the first line about starting the relay. We'll come back to it.

Of course X10 commands take some time to travel along the power line. So don't expect instant responses. However what I actually got was something like a three second delay between invoking Heyu and the device reacting. However the program itself provides an explanation for the excessive delay:

woopi@goldserver:~ $ heyu on b1 RI serial line may be stuck. RI serial line may be stuck. woopi@goldserver:~ $ heyu off b1 RI serial line may be stuck. RI serial line may be stuck.

It turns out that the culprit is the serial <--> USB cable I used. It was cheap for a reason. The question is addressed in the Heyu FAQ:

If getting a long delay when switching lights on and off and report of
Q: I get the message "RI serial line may be stuck"
   after a long delay.

A: This is a problem with some adapters using an older Prolific chip.
   The workaround is to put the directive 'CHECK_RI_LINE  NO' in your
   Heyu configuration file.

The proposed solution works. Both the installation script and the information command say where the configuration file is located. It is a good idea to change the HOUSECODE at the same time. It is not a good idea to use the default house code A with X10 devices.

woopi@goldserver:~ $ nano /home/pi/.heyu/x10config

... # HOUSECODE A # A B C D E F G H I J K L M N O P HOUSECODE B # Workaround for "RI serial line may be stuck" problem with older Prolific chip # based USB-serial adapter: CHECK_RI_LINE NO ...

Note how the first invocation of Heyu started the relay, a service (daemon) that communicates with the CM11A. Whenever a Heyu command is issued, the program starts the relay if it is not already running. It takes a few seconds to start this service. Thus when a first "on" or "off" command is issued after a reboot, there will be a considerable delay before it is executed. It would be better to start the relay during the boot process. This can be done following the advice in X10 with CM11a wiki:

To restart Heyu at 10 minutes before the end of every hour (because it sometimes fails) and whenever the Rasberry Pi is rebooted, edit the crontab file. If this is the first use of crontab then you will be asked to select the editor you want to use. Of course, I chose nano.

woopi@goldserver:~ $ crontab -e

# For more information see the manual pages of crontab(5) and cron(8) # # m h dom mon dow command @reboot /usr/local/bin/heyu start 50 * * * * /usr/local/bin/heyu start

I have not found Heyu particularly flaky, but following the above advice means about restarting the program regularly means that a problem could resolve itself after an hour. This could be very useful when away for an extended period.

A final pointer: remove all timers and macros that could still be stored in the CM11A. I did not do this and for a while I was wondering what was turning on and off some of the living room lights at seemingly random times. It had been a couple of years since I had used the CM11A but still it contained some timers.

woopi@goldserver:~ $ heyu erase Erasing all blocks of data on the eeprom ................................................................ woopi@goldserver:~ $

Now reboot and make sure that heyu is started.

woopi@goldserver:~ $ sudo reboot woopi@goldserver:~ $ Connection to goldserver.local closed by remote host. Connection to goldserver.local closed. michel@hp:~$ ssh woopi@goldserver.local woopi@goldserver.local's password: <xxxx not echoed to screen ... woopi@goldserver:~ $ ps -aux | grep heyu woopi 297 0.0 0.2 2920 1436 ttyUSB0 Ss+ 17:17 0:00 heyu_relay bin/heyu start woopi 562 0.0 0.3 7332 1888 pts/0 S+ 17:18 0:00 grep --color=auto heyu

The last command lists all running processes and pipes the result through grep to keep only those lines in which heyu appears. It confirms that Heyu is up which can be verified with the info command.

woopi@goldserver:~ $ heyu info Heyu version 2.10 Configuration at /home/woopi/.heyu/x10config Powerline interface on /dev/ttyUSB0 ... Housecode = B ...

Notice that heyu info does not begin by starting the relay module because it was started at boot.

Video Cameras toc

Reference: Secure Webcam streaming with MJPG-Streamer on a Raspberry Pi

Much more to come...

Bluetooth toc

If Bluetooth is to be used, then it is best to add the default user to the bluetooth group.

woopi@goldserver:~ $ sudo adduser pi bluetooth

It will now be possible to start bluetoothctl without using the sudo prefix.

If audio Bluetooth devices will be used, then in all probability it will be necessary to install the Bluetooth Audio ALSA Backend bluez-alsa.

woopi@goldserver:~ $ sudo apt install bluealsa -y

This will give you a working setup although an error will be displayed by systemctl. It is possible to remove this error which does not affect the performance of the blueotooth stack. See Bluetooth, BlueALSA and Buster for details.

For details on how to pair a Bluetooth device and so on, you can look at two older posts on the subject: Baby Bluetooth Steps on Raspberry Pi 3 - Raspbian (Stretch) and Bluetooth Audio with Rasbian Stretch on the Raspberry Pi 3.

Removing Bluetooth toc

The Raspberry Pi hardware cannot handle the Bluetooth HSP profile. But according to Youness, if a Bluetooth-USB dongle is used, it is possible to connect a headset and record sound on the Raspberry Pi. While not explicitely said in that article, I would assume using the dongle entails disabling the on-board Bluetooth chip.

If Bluetooth is not to be used at all, then everything including the Bluetooth stack could be removed. I will not go into the details of this operation. Look at Disabling Bluetooth on Raspberry Pi, by SCRIBBLES, which describes both operations with exemplary succinctness. Something I should strive for perhaps.

Backup toc

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.

michel@hp:~/Documents/domotique$ df -h Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur udev 5,9G 0 5,9G 0% /dev tmpfs 1,2G 2,1M 1,2G 1% /run ... tmpfs 1,2G 16K 1,2G 1% /run/user/121 tmpfs 1,2G 52K 1,2G 1% /run/user/1000 /dev/sde1 44M 23M 22M 51% /media/michel/boot /dev/sde2 7,4G 1,2G 5,9G 17% /media/michel/rootfs michel@hp:~/Documents/domotique$ sudo umount /dev/sde2 michel@hp:~/Documents/domotique$ sudo umount /dev/sde1 michel@hp:~/Documents/domotique$ sudo dd bs=4M if=/dev/sde of=backup_2019_01_08_strech.img 1920+0 enregistrements lus 1920+0 enregistrements écrits 8053063680 bytes (8,1 GB, 7,5 GiB) copied, 474,673 s, 17,0 MB/s

Raspberry Pi GPIO toc

Older Raspberry Pi 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 on the right. 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.

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

GPIO Pinout Source: GPIO in Raspberry Pi Documentation: Usage

The sections that follow describe various hardware additions that are connected to the Raspberry Pi GPIO. In some cases, there is some latitude in which GPIO pins are used to communicate with the device, but in other cases, the real time clock for example, there is no choice.

Real Time Clock toc

RTC module Among other functions, the Domoticz home automation system is scheduled to perform certain operations 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 time stamps 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 time signals obtained from Simple Network Time Protocol servers. Unfortunately, we have been without Internet access following a power outage after a bad storm and in such circumstances the time kept by the Raspberry Pi is way off. A cheap real-time hardware clocks such as the one show here restored the correct time automatically in those situations.

I have already shown how to install such an RTC based on the DS3231 by Maxim on Raspbian Wheezy in a previous post: Real Time Clock, DS3231, for Domoticz on the Raspberry Pi. However on Raspbian Buster, the procedure is much simpler. As explained by Gus in Raspberry Pi RTC: Adding a Real Time Clock (April 12, 2019) 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 device.

woopi@goldserver:~ $ sudo nano /boot/config.txt

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

... # Uncomment some or all of these to enable the optional hardware interfaces #dtparam=i2c_arm=on #dtparam=i2s=on #dtparam=spi=on dtoverlay=i2c-rtc,ds3231 ...

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 supported devices and the list of options that can be passed on to the overlay.

woopi@goldserver:~ $ dtoverlay -h i2c-rtc

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.

woopi@goldserver:~ $ ls /dev/rt* /dev/rtc /dev/rtc0 woopi@goldserver:~ $ sudo hwclock --verbose hwclock from util-linux 2.33.1 System Time: 1573672406.546382 Trying to open: /dev/rtc0 Using the rtc interface to the clock. Assuming hardware clock is kept in UTC time. Waiting for clock tick... ioctl(3, RTC_UIE_ON, 0): Invalid argument Waiting in loop for time from /dev/rtc0 to change clock tick Time read from Hardware Clock: 2019/11/13 19:13:28 Hw clock time : 2019/11/13 19:13:28 = 1573672408 seconds since 1969 Time since last adjustment is 1573672408 seconds Calculated Hardware Clock drift is 0.000000 seconds 2019-11-13 15:13:27.408018-04:00

To update the system time from the RTC when the system boots is also much simpler than before. Again it is necessary to modifiy a text file, in this case a script that is executed by a udev rule.

woopi@goldserver:~ $ sudo nano /lib/udev/hwclock-set

Find the test for the existence of /run/systemd/system at the beginning of the file and comment out the three lines by adding a leading "#" character to each line.

#!/bin/sh # Reset the System Clock to UTC if the hardware clock from which it # was copied by the kernel was in localtime. dev=$1 #if [ -e /run/systemd/system ] ; then # exit 0 #fi ...

Here is the rule that will launch the script after the real time clock device rtc0 is created by the kernel during the boot process.

woopi@goldserver:~ $ cat /lib/udev/rules.d/85-hwclock.rules # Set the System Time from the Hardware Clock and set the kernel's timezone # value to the local timezone when the kernel clock module is loaded. KERNEL=="rtc0", RUN+="/lib/udev/hwclock-set $root/$name"

When I first installed an RTC, I was worried that it could drift much like cheap digital clocks did some years ago. As a way of avoiding that, I created a cron task to update the RTC once an hour from the system time just after using ntp to updated the latter from an NTP server. This is not needed. After rebooting and ensuring that the system time and RTC were both correct, I disabled the use of NTP by timesyncd and set a wrong date and time. I checked that both the real time clock and the system time were a month ahead before enabling NTP time updates by timesyncd. Initially, only the system time was updated to the correct date but as can be seen below, the hardware clock was also updated later on.

woopi@goldserver:~ $ sudo timedatectl set-ntp false woopi@goldserver:~ $ sudo timedatectl set-time '2019-12-10 15:40' woopi@goldserver:~ $ sudo hwclock; date 2019-12-10 15:40:28.564344-04:00 Tue 10 Dec 15:40:29 AST 2019 woopi@goldserver:~ $ sudo timedatectl set-ntp true woopi@goldserver:~ $ sudo hwclock; date 2019-12-10 15:40:57.647882-04:00 Tue 12 Nov 13:37:52 AST 2019 woopi@goldserver:~ $ sudo hwclock; date 2019-12-10 15:41:12.215440-04:00 Tue 12 Nov 13:38:07 AST 2019 ... woopi@goldserver:~ $ sudo hwclock; date 2019-11-12 13:55:13.125175-04:00 Tue 12 Nov 13:55:13 AST 2019

Just how often timesyncd updates the system time can be found by getting its status.

woopi@goldserver:~ $ timedatectl timesync-status --all; Server: ( Poll interval: 34min 8s (min: 32s; max 34min 8s) ...

The default poll interval can be changed by editing the values in the configuration file /etc/systemd/timesyncd.conf. I see no compelling reason to do that, as both the DS3231 and the Raspberry Pi are good timekeepers once the initial date and time have been set (see How accurately can the Raspberry Pi keep time? by Remi Bergsma).

There are two questions that I have yet to answer. First is there really a need to remove fake-hwclock? Our guide Gus says to do it, but, given my experience with an RTC with a dead battery, I don't believe that is a good idea. The second is about the need to modify /lib/udev/hwclock-set even further. I have read on more than one occasion that the lines with --systz should be removed.

... if [ yes = "$BADYEAR" ] ; then /sbin/hwclock --rtc=$dev --systz --badyear /sbin/hwclock --rtc=$dev --hctosys --badyear else /sbin/hwclock --rtc=$dev --systz /sbin/hwclock --rtc=$dev --hctosys fi ...

There is a discussion on why these lines were needed in the first place so I decided that for the time being I would not remove them, nor would I remove fake-hwclock.

Temperature and Humidity Sensor toc

Reading the temperature and humidity with a DHT11 or DHT12/AM2302 sensor is simpler than described in a previous post: Temperature Sensors on a Raspberry Pi hosting Domoticz written in June 2017. It is not necessary to edit the /boot/config.text file to enable the 1-Wire interface for the simple reason that these temperature and humidity sensors are not true 1-Wire devices. That means that multiple DHTxx devices cannot not share a "bus"; each DHTxx sensor must be connected to an individual Raspberry Pi GPIO pin.

Since the sensor does not use a standard communication protocol, getting data involves fairly complex "bit banging" programming which means emulating a UART in software. Luckily, there is a Python library by Adafruit that takes care of all that. Adafruit has deprecated the library because it only supports CircuitPython (its own version of MicroPython) for its own devices, but the library remains functional.

As explained before, I prefer to install Python scripts that are part of the home automation system in a virtual Python environment.

woopi@goldserver:~ $ ve .syspy (.syspy) woopi@goldserver:~ $ cd .syspy (.syspy) woopi@goldserver:~/.syspy $ pip install git+ Looking in indexes:, ... Successfully installed Adafruit-DHT-1.4.0

The DHTxx can be connected to any Raspberry Pi GPIO pin; I chose pin 18 on the Raspberry Pi header, which is GPIO 24 (also known as BCM 24, BCM for Broadcom the manufacturer of the system on chip) because ground and 3.3 Volts needed by the sensor are on adjacent pins.

     3.3 Volt  17 [o][o] 18  GPIO 24 (BCM 24)
                  [o][o] 20  Ground

The following script can be used to verify that the sensor data can be obtained.

(.syspy) woopi@goldserver:~/.syspy $ nano

# coding: utf-8

# parameters
DHT_type = 11
DHT_pin  = 24

import Adafruit_DHT
import time

while True:
    # read dht11 temperature and humidity
    humidity, temperature = Adafruit_DHT.read_retry(DHT_type, DHT_pin)
    # report it
    if humidity is not None and temperature is not None:
        print('Temperature: {0:0.1f}°C, humidity: {1:0.1f}%'.format(temperature, humidity))
        print('Temperature and humidity could not be read')
    # wait
    # and repeat

Running the test script makes it clear that while it does work, every now and then, the data cannot be read from the sensor.

(.syspy) woopi@goldserver:~/.syspy $ chmod +x (.syspy) woopi@goldserver:~/.syspy $ ./ Temperature: 18.0°C, humidity: 19.0% Temperature: 19.0°C, humidity: 18.0% Temperature: 18.0°C, humidity: 19.0% Temperature: 18.0°C, humidity: 19.0% Temperature: 18.0°C, humidity: 19.0% Temperature: 18.0°C, humidity: 19.0% Temperature and humidity could not be read Temperature: 18.0°C, humidity: 19.0% Temperature: 18.0°C, humidity: 19.0%

There can be two reasons for an inability to read the sensor date. The sensor should not be sampled more than once a second. If the delay between two attempts at reading the DHTxx is too short then it may not be able to respond. Bit banging is not an exact emulation of dedicated serial communication hardware. This is especially true in multitasking environments such as Linux where a procedure can be interrupted by background tasks. It is best to allow for the occasional error.

Reporting temperature and humidity measures in Domoticz has been touched upon in a number of previous posts such as:

I hope to come back to the subject with a cleaner post in the future.

Reboot and Shutdown Switch toc

The Raspberry Pi does not have a reset button but there is a provision for it on the motherboard. It is possible to solder wires from a normally open push-button switch to the through holes labelled RUN on newer models or P6 on older models, but it's probably best to solder header pins and use wires with Dupont connectors to the switch just like on desktop computers.

On older models the RUN or P6 connector provided one pin connected to ground, and a second pin connected to the RUN pin on the SOC which is pulled to 3.2 V by a voltage divider across the 5V rail. Be careful with newer 3 B+ and 4 models as the pin connections have been changed. According to the RPi 3B+ schematic, pin 1 is connected to the GLOBAL_EN input of the XR77004 pmic and pin 2, labelled RUN, is connected to PG2 of the same power management chip. Both are pulled to approximately 3.3 V, pin 1 through a voltage divider across the 5 V rail, pin 2 through a 10 K resistor connected to the 3.3 V rail. I would assume that these pins should not be shorted. To ground the RUN pin, it will be necessary to connect a wire to one of the ground pins on the GPIO header. The RPi 4 schematic shows that the RUN header has three pins, Pin 1 is again labelled GLOBAL_EN, Pin 2 is Ground and Pin 3 is labelled RUN_PG2. The following note appears to the right **NOTE RUN IS 3V3, GLOBAL_EN IS 5V**. Indeed, the connection for the GLOBAL_EN is pulled to 5 V through a 100 K resistor, but it could be grounded by a MOSFET controlled by a GLOBAL_RESET signal that I know nothing about. However it looks like pins 2 and 3 could be used directly as described here. I have verified none of this as I do not have either model of the Raspberry Pi. Also, I have no idea what to make of GLOBAL_EN and its relative merit to the RUN_PG2 input. Search on the Raspberry Pi Forum for "RUN reset header" for more information.

Shorting the RUN pin of the header immediately halts the operation of the processor. This is never a good idea as disk buffers may not have been written out to the SD card. In some circumstances, this may damage the operating system on the SD card to such an extent that it will no longer boot. The preferred way to stop a system is with a command such as halt or shutdown. woopi@goldserver:~ $ sudo shutdown now

Inspired by two informative posts,

I added a service that monitors a GPIO pin to which is connected a push-button switch. When the button is pressed quickly, the service will launch a reboot. When the button is pressed and held closed for at least 3 seconds, the service will shutdown the Raspberry Pi as soon as the button is release.

The service is a Python 3 script which requires the RPi.GPIO module. It was a simple matter to add it to the virtual environment reserved for system scripts.

woopi@goldserver:~ $ ve .syspy (.syspy) woopi@goldserver:~ $ cd .syspy(.syspy) woopi@goldserver:~/.syspy $ pip install rpi.gpio Looking in indexes:, ... Successfully installed rpi.gpio-0.7.0

I then cobbled the following script taking bits from each of the referenced blogs.

(.syspy) woopi@goldserver:~/.syspy $ ev woopi@goldserver:~/.syspy $ nano

#!/home/woopi/.syspy/bin/python3 #coding: utf-8 ########################## # User parameters ########################## shutdownPin = 11 # switch across pins 9 (GND) and 11 (GPIO17) shutdownMinSeconds = 3 # if button pressed &lt; 3 seconds reboot else shutdown debounceSeconds = 0.01 # button debounce time in seconds import RPi.GPIO as GPIO from datetime import datetime import time from signal import pause from subprocess import check_call GPIO.setmode(GPIO.BOARD) #GPIO.setup(shutdownPin, GPIO.IN, pull_up_down=GPIO.PUD_UP) # GPIO3 has external pull-up resistor GPIO.setup(shutdownPin, GPIO.IN) buttonPressedTime = None def buttonStateChanged(pin): global buttonPressedTime if not (GPIO.input(pin)): # button is down if buttonPressedTime is None: buttonPressedTime = else: # button is up if buttonPressedTime is not None: elapsed = ( - buttonPressedTime).total_seconds() buttonPressedTime = None if elapsed >= shutdownMinSeconds: # button pressed for more than specified time, shutdown check_call(['/sbin/poweroff']) elif elapsed >= debounceSeconds: # button pressed for a shorter time, reboot check_call(['/sbin/reboot']) # subscribe to button presses GPIO.add_event_detect(shutdownPin, GPIO.BOTH, callback=buttonStateChanged) pause() # wait forever

To test, I replaced the check_call(['/sbin/poweroff']) and check_call(['/sbin/reboot']) with print statements and then made the file executable and started the script.

woopi@goldserver:~/.syspy $ chmod +x .syspy/reboot_py woopi@goldserver:~/.syspy $ cd .. woopi@goldserver:~ $ sudo nano .syspy/reboot_py

After checking that the timing was reasonable, I removed the print statements, replacing them with the original check_call statements and tested that the Raspberry Pi was rebooted after a short press of the push-button and that it was shutdown after releasing the button held down for more than 3 seconds. I also tested that pressing the reboot/shutdown button again when the Pi is shutdown causes it to boot.

The script could be started at boot time with an entry in the root crontab file. I decided to imitate both authors and use a systemd unit file.

woopi@goldserver:~ $ sudo nano /etc/systemd/system/shudown_button.service

[Unit] Description=GPIO shutdown button [Service] Type=simple Restart=always RestartSec=1 User=root ExecStart=/home/woopi/.syspy/ [Install]

To test the unit file, start the service and look at its status.

woopi@goldserver:~ $ sudo systemctl start shudown_button.service woopi@goldserver:~ $ sudo systemctl status shudown_button.service ● shudown_button.service - GPIO shutdown button Loaded: loaded (/etc/systemd/system/shudown_button.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2019-12-18 13:49:41 AST; 7s ago Main PID: 606 (reboot_button.p) Memory: 3.0M CGroup: /system.slice/shudown_button.service └─606 /home/woopi/.syspy/bin/python3 /home/woopi/.syspy/ Dec 18 13:49:41 goldserver systemd[1]: Started GPIO shutdown button.

There remains enabling the service so that it is started at boot time.

woopi@goldserver:~ $ sudo systemctl enable shudown_button.service Created symlink /etc/systemd/system/ → /etc/systemd/system/shudown_button.service.

The script uses GPIO17. Some would prefer to use GPIO3 because, as far as I know, it is the only GPIO pin that can be used to awaken a Raspberry Pi in shutdown mode. Unfortunately, there's a conflict with the real time clock that needs to use the same GPIO pin for I2C communication with the Pi. A Pi in shutdown mode can be awaken by shorting the RUN pin to ground. Since I intend to install a reset switch connected to RUN, there will be no loss of functionality if the reboot/shutdown switch is connected to a GPIO pin other than 3.

Hardware Watchdog toc

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.

<-Home Automation Servers on Raspbian Buster Lite --
<-Installation and Configuration of Raspbian Buster Lite