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
- USB Wi-Fi Dongles
- Real-Time Clock
- Temperature and Humidity Sensor (forthcoming)
- HA Bridge to Alexa (forthcoming)
- Mochad Bridge to X10 RF USB transceivers
- Heyu as Bridge to X10 PL Serial transceivers
- Video Cameras (forthcoming)
- Removing Bluetooth
- Backup (forthcoming)
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
0bda. The Product ID are different.
|8179||RTL8188EUS 802.11n Wireless Network Adapter||FAST on the black end and FAST FW1 150US 2.0 180101 on the metal shield|
|0179||RTL8188ETV Wireless LAN 802.11n Network Adapter||802.11n in small italic font on side of black end and 2 holes in the metal shield|
|8176||RTL8188CUS 802.11n WLAN Adapter||802.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.
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.
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
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
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 line beginning with
#dtparam and remove the
# and add the
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
Find the test for the existence of
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
rtc0 is created by the kernel during the boot
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
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
/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
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.
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
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
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...
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.
Rest to come...
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
mochad does work as verified by using
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  Gateways.
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
then you will be asked to select the editor you want to use. Of course,
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
grep to keep only those lines in which
appears. It confirms that Heyu is up which can
be verified with the
heyu info does not begin by starting the
relay module because it was started at boot.
Much more to come...
If Bluetooth is to be used, then it is best to
add the default user to the
It will now be possible to start
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.
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.
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.