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

USB Wi-Fi Dongle

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.

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

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.

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.

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

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

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.

Rebooting will load the service.

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

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

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.

Now proceed with the installation proper.

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

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:

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.

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.

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.

Now reboot and make sure that heyu is started.

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.

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

Video Cameras

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

Much more to come...

Bluetooth

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

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.

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

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

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.

Raspberry Pi GPIO

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 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 created equal. Some implement communications protocol in hardware (I2C, 1-wire, Serial...) while others are simple input or output connections.

Source: Raspberry Pi Documentation: GPIO and the 40-pin Header

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 I²C real time clock discussed in the next section for example, there is no choice.

Real Time Clock

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.

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 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.

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.

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.

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.

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.

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

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.

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

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 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 has decided to exclusively support CircuitPython (its own version of MicroPython) for its own devices. Nevertheless, 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.

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.

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

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

#!/home/woopi/.syspy/bin/python
# 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))
    else:
        print('Temperature and humidity could not be read')
    # wait
    time.sleep(0.3)
    # 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.

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:

• Temperature Sensors on a Raspberry Pi hosting Domoticz
• Temperature Sensors - Take 2
• Remote Logging of the Orange Pi Zero Core Temperature

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

Reboot and Shutdown Switch

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.

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,

• Combined Restart / Shutdown Button for Raspberry Pi by Stewart C. Russell (SCRUSS)
• Raspberry Pi Shutdown/Reset/Start Button by George Ilyes (gilyes)

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.

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

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.

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.

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.

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

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

The script uses GPIO17. Some will prefer to use GPIO3 because when that GPIO pin is grounded, it will awaken a Raspberry Pi shutdown with a halt, shutdown or poweroff command. I did test that this does work. As far as I know, GPIO3 is the only 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. Howver, 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 as shown in the script.

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.