Various Hardware with Raspbian Buster Lite
Draft: November 16, 2019
<-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. Real-Time Clock
  3. Temperature and Humidity Sensor (forthcoming)
  4. HA Bridge to Alexa (forthcoming)
  5. Mochad Bridge to X10 RF USB transceivers
  6. Heyu as Bridge to X10 PL Serial transceivers
  7. Video Cameras (forthcoming)
  8. Bluetooth
  9. Removing Bluetooth
  10. Backup (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 panza.local closed by remote host. Connection to panza.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.

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 service. 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 days without Internet access following a power outage after a bad storm. 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 line beginning with #dtparam and remove the leading # and add the dtoverlay lines

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

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.

... #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 am not sure that is necessary or even 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

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 is not necessary to edit the /boot/config.text file and enable the 1-Wire interface for the simple reason that DHT11 or DHT22 temperature and humidity sensors are not true 1-Wire devices.

Rest to come...

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 panza.local closed by remote host. Connection to panza.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
<-Home Automation Servers on Raspbian Buster Lite --
<-Installation and Configuration of Raspbian Buster Lite