Skip to content

home automation

Jump to bottom Edit New page
ArtMG edited this page Jun 15, 2023 · 21 revisions

Introduction

Home Automation, Domotics, or Smart Home systems are intended to detect inputs from and send output controls to various devices typically found around the home. The great thing about putting a computer into this simple loop is the addition of logic, and the fact that it opens up a wider variety of interfaces.

In addition, using the Raspberry Pi as one of the computers in this kind of setup means that you can really make the most of those GPIO pins for detection and control.

So you could get a Samsung SmartThings hub, buy loads of z-wave connected devices, and use your Amazon Alexa to control it... or you could roll up your sleeves and discover...

Be aware, however, that protocols, systems, and even devices and services can quickly become obsolete in this arena. Some previously commercial software like Motorola Premise used to retail for £,000s but has since been given away for free. 7 see also:

Systems

Generally speaking there are four main types of platform technology:

  • Java is cross-platform but heavyweight, wider support at the price of performance

  • Compiled C programs are usually the most efficient, but are they available for your hardware?

  • Interpreted Python is flexible and hackable, it might perform ok but never the best

  • Node.js is powerful, and it compiles the code, but needs to be set up correctly for the Pi

  • Domoticz

    • C++ project with many devices and more community-supplied integrations
    • event handling logic via Blockly or Lua code

  • Home Assistant

    • python 3 project with docker deployment option
    • ready snapcast integration

  • OpenHAB

    • [http://www.openhab.org/]
    • Java-based for platform independence
    • see an example project at [http://makezine.com/projects/building-a-home-automation-system-with-openhab-to-control-leds-wirelessly/]
    • bindings available for wide variety of devices and technologies
    • includes iOS/Android apps
    • popular choice

  • PiDome

    • [https://pidome.org]
    • Java-based

  • pimatic

    • Node.js framework
    • related to ioBroker

  • Calaos

    • full stack from pre-conf Linux OS to iOS/Android apps
    • originally French project

  • Home Genie

    • C# software, requires Mono on Linux
    • Integrations via Program Editor support code in Javascript, Phyton, Ruby and C#

  • CoRE ?

  • FHEM

    • PERL based
    • ready snapcast integration

  • Freedomotic

    • java-based

  • OpenRemote

See also lists at:

  • [https://forum.mysensors.org/topic/175/open-source-home-automation-raspberry]
  • [https://randomnerdtutorials.com/9-home-automation-open-source-platforms-for-your-projects/]

There was a time when media centers like LinuxMCE were commonly used for home automation, and although their successors such as Kodi can interface, you might consider designing them as separate use-cases.

distros

At the time of writing, the only there are no Pi Distros as such specifically aimed at home automation, however the following have Pi OS images available:

  • Calaos

Distributions that could become a basis for home automation solutions include:

  • Nard is optimised for embedded applications, but might be tougher to build on
  • ResinOS is for embedded devices to run docker containers
  • PiBox is roadmapped for sensor response, but is still a 1-man project

Having said that, a general purpose Distro might be your best bet. So generally you should choose a reasonably lightweight distro (supporting armhf?) that makes available the key packages you might need: e.g.

  • Raspbian Lite
  • Minibian
  • Raspbian Server Edition
  • DietPi ?

other references

Here are some standards, software and protocols you might see mentioned in some of these projects

  • MySensors
    • open source software framework for RF signalling
    • also works over MQTT
    • used by many home automation platforms
    • supports encryption to protect signals in transit
  • IoTivity
    • [https://www.iotivity.org/]
    • based on standards from OCF (Open Connectivity Foundation)
    • open source reference implementation of OCF standards
    • supported by many technology giants
  • MQTT
    • Message Queue Telemetry Transport
    • Standardised protocol for lightweight signalling over TCPIP
    • Used by EVRYTHNG amongst others
  • KNX
    • standardised protocol for communicating over many wired and wireless mediums
  • IFTTT
    • cloud execution service for automation 'recipes'
    • allows conditional control of commonly-used web-based services
    • stands for IF This Then That
    • currently free
    • controlled primarily via Android or iOS apps
  • Qivicon
    • German alliance system to bring together manufacturers since 2013

Domoticz

This is a home automation platform worth trialling because it's

  • lightweight
  • extensible
  • well-documented
  • currently active project with thriving community
  • easy to install on a variety of systems

Raspberry Pi install

simple installation for Debian or Fedora -based OS

sudo curl -L install.domoticz.com | bash

This is an interactive install, rather than unattended. You can usually accept the default values as prompted.

I chose:

  • HTTP Server port: 80

For alternatives see [http://www.domoticz.com/wiki/Raspberry_Pi]

Configuration

  • Setup / Location

update

?? replace instructions at [https://www.domoticz.com/wiki/Linux#Script_to_update_almost_automatically] ??

# beta:
cd ~/domoticz
 ./updatebeta

Control inputs

Web server

The project includes a built-in webserver, that may be loosely derived from the Webem embedded web server from boost asio. This means that the web services are efficient and dependency free.

Because web service security is not a core issue for the project, they recommend using it behind a hardened proxy (such as nginx) if you plan to expose it on the public internet

  • see [https://www.domoticz.com/wiki/Secure_Nginx_Proxy_Setup]

If you want your devices to connect over https with no certificate issues, see [https://www.domoticz.com/wiki/Native_secure_access_with_Lets_Encrypt]

Bluetooth

There are a whole range of Bluetooth input devices available. They range up from cheap selfie shutters, though media play and buttons, gamepads and av-style remotes up to miniature full keyboards. If you choose well you can get any of these for between £3 and £20, even if the build quality is not what you'd get if you splashed out £80 on a brand named remote.

Although it focusses a lot on gamepads, the following article covers the bluetooth hardware, device stack, pairing and configuration [https://github.com/artmg/MuGammaPi/wiki/Ready-made-input-devices]

Voice

Using Google AIY Voice control

see also

  • MuGammaPi article on Google AIY project kit as voice interface
    • [https://github.com/artmg/MuGammaPi/wiki/Google-AIY-projects]

Device control examples

Denon / Marantz

e.g. Marantz Control Protocol [http://m.us.marantz.com/DocumentMaster/US/2013%20Marantz_AV_SR_NR_PROTOCOL_V07.xls] from Denon & Marantz Company

  • Latest Marantz [www.us.marantz.com/DocumentMaster/US/Marantz_FY16_AV_SR_NR_PROTOCOL_V01(2).xls]

  • Latest Denon [https://www.denon.ua/ua/product/homecinema/avreceiver/avrx3300w?docname=AVR-X1300W_X2300W_X3300W_PROTOCOL_V01.xlsx]

  • OpenHAB Denon binding [https://github.com/openhab/openhab1-addons/wiki/Denon-Binding]

  • pimatic control interface [https://forum.pimatic.org/topic/979/denon-marantz-avr-remote-control]

Music Player Daemon

The first step to controlling a Music Player Daemon (MPD) server is to install a Music Player Client (MPC) and the mpc package in the repos does the job just fine

sudo apt-get update
sudo apt-get install -y mpc
  • the basics of mpc control from Domoticz
    • [https://www.domoticz.com/wiki/MPD_%26_Domoticz#Controlling_via_Domoticz]
  • Simple bash scripts to send mpc controls
    • [https://www.domoticz.com/forum/viewtopic.php?t=7443]
  • Example Lua scripts to run mpc commands:
    • [https://www.domoticz.com/forum/viewtopic.php?t=11074]

To wait for the song to change, then get the name use:

mpc idle player # block until the player changes songs
mpc current     # outputs "Artist Name - Song Name" onto stdout
# Credit - https://stackoverflow.com/a/34905959

Snapcast audio distribution

For background on the Synchronous Network Audio Player multicast protocol see

https://github.com/artmg/MuGammaPi/wiki/multi-room-audio#snapcast

  • Snapcast API documentation showing how to control using JSON-RPC 2.0 API over a raw TCP-Socket interface

  • Example Kodi python plugin that uses JSON [https://github.com/domoticz/domoticz/blob/master/plugins/examples/Kodi.py]

  • Python Plugin can use [https://www.domoticz.com/wiki/Developing_a_Python_plugin#C.2B.2B_Callable_API]:

    • import Domoticz
    • Domoticz.protocol = JSON
    • Domoticz.Send ...

Plugins

  • Home Assistant [https://home-assistant.io/blog/2016/02/18/multi-room-audio-with-snapcast/]
  • FHEM [https://fhem.de/commandref.html#Snapcast]

Troubleshooting

  • Log file

Home Assistant

Also styled as HASS, or Hass.io, this is another strong contender for Pi-based automation. It is actually available for many platforms, because it is written in Python. This brings advantages for wide extensibility, although it remains to be seen how strong it is on security and performance.

It offers extremely flexible availability, as
it is published via a good number of package managers.

For more information, and how to install and configure, see https://github.com/artmg/MuGammaPi/wiki/home-assistant

Services

Voice input

Although Amazon Alexa and Google Home are well known, there are other ways to get voice input working. Some, like Mycroft are still web-based for now, but are planning to make their open source software run locally.

Others, like Snips, are already capable of being run on local devices including Raspberry Pis. If Pi is your platform, there is also Rhasspy, although it may not be as well backed as the others.

Communications

Here are some simple ones you might already be aware of:

  • IR - infrared - needs line-of-sight
    • signals can often be "learnt" by third party controllers
  • RF - radio frequency
    • individual vendors products are not necessarily compatible
    • common bands include 2.4 GHz, 5 GHz, 433 MHz, 868 MHz
      • these are Industrial, Scientific, Medical (ISM) bands
      • they now permit licensed-free, low power, error tolerant uses
      • 433 common for control applications, perhaps more interference than on more limited usage 868 ?
  • Wifi
    • specific case of RF in 2.4 & 5Ghz bands that we're all familiar with

ZigBee

  • conforms to IEEE 802.15.4
  • low b/w channel in 868 MHz band (Europe) as well as 2.4Ghz
  • USB adaptors still cost £40-60 as of early 2017
  • XBee units £15 still need Pi HAT c. £8
  • or older RaspBee £30

Z-Wave

  • proprietary design (perhaps a sole chip vendor?)

  • 868.42 MHz (in Europe)

  • designed for low latency and reliability rather than high throughput

  • Inter-node communication distance about 30 meters (40 meters with 500 series chip)

  • source-routed mesh network with ability to hop up to four times between nodes, to communicate even further

  • USB and Pi HATs similar price to ZigBee

    • examples of price range [http://www.vesternet.com/smart-home/controllers/adapters-software]

Security concerns

IoT devices introduce a wide range of security risks, so here are some with mitigations.

Cheap devices are often built with a focus on functionality, which often conflicts with security, especially when it comes to choosing which corners to cut. If you create a network where you know you may have less secure devices, you can logically separate it from important networks. For instance, Things with IP addresses might be on their own VLAN – you can stop traffic from leaving that network, or at least just let these devices 'phone home' to their own cloud servers without being able to go near you sensitive home data network.

Mesh networks are more difficult to monitor and control than traditional IP networks.

Some devices may provide physical access to premises, for instance an electric door strike controller used to remotely 'buzz someone in'. In cases like this you would want a physical backup latch or mortice that you can lock with a key for times when you are not there to check who might have found a way to let themselves in!

Much of the issue comes down to initialisation, where plaintext (or well-known keys which are equivalent) is used for the first connection, or even reconnection of devices. This appears to be a factor of the choice of making the mesh network easy to join and widely compatible.

Specific exploits

Z-Wave hit the news in spring 2018 with an attack call Z-Shave, which seemed damning but actually required the exploit to take place at the time of pairing, which kind of limits its value. However it demonstrates that pairing is a vulnerable moment in the lifetime of a secure network. And that compatibility (with older less secure standards) is a feature baked into designs (and even standards) that often runs contrary to security.

If you want to understand potential vectors for attack in a mesh device network, check out this paper from Vaccari, Cambiaso and Aiello at the Italian National Research Council (CNR) called "Remotely Exploiting AT Command Attacks on ZigBee Networks". Although it's now a couple of years since their work, they outline the known attack vectors of the time. Although there are many routes for Denial of Service (DoS) there are fewer routes to subvert functionality. They give very little detail of their Remote AT exploit, it it too seems to be to knock a device off the network, rather than specifically utilise it.

Wright's Killerbee seems to be one of the most widely used toolsets, and the Eichelberger/Cognosec's paper "Using Software Defined Radio to Attack "Smart Home" Systems" goes into more detail about the Zigbee architecture and explains the tools required to perform command injection on Zigbee devices.

Hardware

Zigbee + ZWave

Nortek HUSBZB-1

This device is very popular with home automation enthusiasts on forums. It has a good combination of being simple to use, reliable, cheap and feature rich – especially as it contains radios for the two most common home automation mesh networks.

I purchased one from amazon.com for around 40usd brand as a GoControl CECOMINOD016164 HUSBZB-1 USB Hub. In raspbian lsusb it shows up as

Bus 001 Device 004: ID 10c4:8a2a Cygnal Integrated Products, Inc.

Without any modifications to config.txt, two new entries also appear in ls -la /dev/tty*:

crw-rw---- 1 root dialout 188,  0 Dec 31 23:59 /dev/ttyUSB0
crw-rw---- 1 root dialout 188,  1 Dec 31 23:59 /dev/ttyUSB1

According to this post ZWave is on 0 and Zigbee on 1.

Zigbee

Elelabs Zigbee Shield

  • Elelabs ZigBee Raspberry Pi Shield
  • $26 incl post via Tindie
  • More minimalist and less polished than RaspBee, but at least $10 cheaper
# On Pi 3 please add the following line to config.txt
dtoverlay=pi3-miniuart-bt

See product page for more

NB: You should consider Elelabs firmware updates if you have found any inconsistencies with ZigBee device communications.

Alternatives

  • Linker ZigBee gateway module
    • c£11
  • dismantle a $15 smart bulb to use the chip inside
    • [https://www.hackster.io/BuddyC/20-zigbee-door-chime-98f016]
  • RasbBee hat c. $40

Z-wave

  • RaZberry hat

SDR RTL 433 DVB

Lots of names all to describe one main concept. There are a host of cheap (sometimes less than £10) DVB-T digital terestrial television broadcast receivers, often USB 'dongle' form factor, that are based on the Realtek RTL2832U controller chip. Open source software is available to control these 'RTL' chips and use them as Software Defined Radio (SDR) receivers. Applications include picking up aircraft telemetry data sent using Automatic Dependent Surveillance-Broadcast (ADS-B) and the purpuse described here, picking up 433Mhz sensor signals.

The software called rtl_433 can be used to detect and read data via this type of hardware.

rtl_433

Basic installation of rtl_433 built from source.

This will use the cmake instructions from https://github.com/merbanan/rtl_433/blob/master/docs/BUILDING.md#cmake

sudo apt-get install libtool libusb-1.0.0-dev librtlsdr-dev rtl-sdr build-essential autoconf cmake pkg-config git-core
git clone https://github.com/merbanan/rtl_433

# use the cmake from 
https://github.com/merbanan/rtl_433/blob/master/docs/BUILDING.md#cmake
# with sudo on the last

# install the udev rules
curl -O https://raw.githubusercontent.com/osmocom/rtl-sdr/master/rtl-sdr.rules
sudo cp ./rtl-sdr.rules /etc/udev/rules.d/
sudo udevadm control --reload-rules
# if that doesn't do the job then reboot

# test to find any common devices on 433.925Mhz band
rtl_433 -f 433.925e6

Domestic lighting systems

  • Philips Hue
  • Ikea TRÅDFRI
    • only US and certain Euro (incl IT) as yet
    • cheap and simple [http://www.gizmodo.co.uk/2017/03/ikeas-smart-lighting-is-here-to-save-us-all/]
    • warmth variable bulbs and panels (includes E27 & GU10 fittings)
    • Not overtly open system, but some potential for integration [https://community.smartthings.com/t/ikea-tradfri/59229]

Ikea Tradfri

  • most bulbs are "white spectrum", i.e. switch between 2700k Warm white, 4000k Cool white, 2200k warm Glow
  • Standby consumption per bulb is 0.5W
  • [http://www.ikea.com/gb/en/products/lighting/smart-lighting/]
  • Gateway controls up to 100 devices including 'steering' controls
  • Steering controls up to 10 bulbs
  • includes GU10 400lm bulbs for £12 product number 003.182.92
Tradfri protocols

Although the Gateway has no formally released API, it has been shown to use:

  • OMA Lightweight M2M (LwM2M) wrapped in CoAP with DTLS
  • DTLS encryption uses a Pre-Shared Key (PSK) shown on the base of the gateway

For details of the protocols used see [https://github.com/bwssytems/ha-bridge/issues/570] See also some info from Philips Hue integration [https://developers.meethue.com/content/philips-hue-and-ikea-tr%C3%A5dfri]

The ha-bridge article includes code samples where coap-tradfri has been built as a variant of coap-client to simplify communications

Energenie

Energenie market domestic power control switches in the UK, based on 433 MHz RF remote control.

Prompted by an original query by the Raspberry Pi Foundation, they have gradually introduced the following boards to attach to your GPIO pins (as well as combo packs that include power control sockets):

  • Pi-mote RF control board
    • Send RF signals to sockets
    • approx £10 (£6 from Maplin if available)
    • [https://energenie4u.co.uk/catalogue/product/ENER314]
  • Two-way Pi-mote board
    • Send and receive RF control signals
    • approx £20
    • [https://energenie4u.co.uk/catalogue/product/ENER314-RT]
  • Pi-mote IR control board
    • LIRC compatible IR receiver and sender
    • record and send IR controls for any remote and/or device
    • approx £10
    • [https://energenie4u.co.uk/catalogue/product/ENER314-IR]

See the Foundation article for more info, including some code samples. If these aren't compatible check out hobbyist alternatives like [https://github.com/barnybug/ener314] or [https://github.com/whaleygeek/pyenergenie].

Temperature sensors

There are a number of sensing chips and boards for Temperature and Humidity sensors also known as therometers and hygrometers. There are many add-on board versions for makers, but here are some integrated, ready made, packaged sensing devices.

Acurite

Acurite have a rather old fashioned looking weatherproof Wireless Temperature and Humidity Sensor 592TX / 06002RM which is hard to find in UK as a solo item, but comes with indoor sensor/displays for as cheap as £10. These sensors send updates every 16 seconds and can easily be detected using the rtl_433 software mentioned above.

Xiaomi

A more sleek modern looking sensor is from Xiaomi, their Aqara sensors have Zigbee versions around £10 and Wifi versions around £15. However these are powered by button cell batteries so they are likely to need replacing more frequently. It is also unclear whether the updates are broadcast frequently.

Another copycat brand is aqara

Others

  • Sonoff
    • the sensors are cheap but require a more expensive 'wifi switch' relay to power them and transmit data
    • not sure how open the protocol is
  • Ubiquiti mPort mFi-THS
    • £25-£40 Temperature only
  • Oregon Scientific have a THN132N for £20 using 433Mhz
    • but is temperature only
  • Heatmiser have an attractive indoor sensor for £15
    • only termperature, but is IP20 rated
    • frequency 868 Mhz
    • protocol unclear
  • Many weather-station display brands use 2.4Ghz which may be lower power and therefore penetrate walls less easily
  • John Guest / RWC JG Speedfit have a wireless system Aura
    • readily available in DIY stores
    • including probes for underfloor heating (UFH)
    • uses Zigbee for communication

Hardware Remotes

Many home automation systems assume a browser-type interface, for full customisation. However hand-held remote control transmitters have provided a familiar (if limited) interface for decades.

Combined remote control devices can be programmed to replace multiple device remotes. They generally work over IR, so if you want to control an HA system, it either needs an IR receiver built in, or a FLIRC USB adapter.

  • Logitech Harmony 650 (£50)
    • usually very well reviewed
    • easy to customise
    • integrated LCD screen for programmable "hard keys"
    • may consume batteries

Commercial controllers

For a (possibly biased) idea about the hardware inside some common home automation controllers, see this article comparing SmartThings, Wink and WigWag. Also here is a list of some commercial hubs available in 2016 in the UK, comparing specifications and interoperability.

Smart Meters in the UK

The Smart Metering Equipment Technical Specifications Version 2 (SMETS2) describes three main components: the Electricity Smart Meter Equipment (ESME), the Gas Smart Meter Equipment (GSME), and the In Home Display (IHD). The IHD communicates with the the meters via a Home Area Network (HAN) using the ZigBee Smart Energy Profile (SEP) v1 specification for connectivity.

A Communications Hub also connected to the HAN will send the billing information (usually via a cellular telephony provider) to the Data Communications Company (DCC) who will send this on to energy suppliers according to customer privacy choices.

As well as seeing their own consumption data on the IHD, domestic customers will be able to access it "by connecting additional devices to the Home Area Network" and "by requesting information from suppliers (eg through the Midata programme)"

Although the SMETS2 states functionality such as Read Operational Data including Consumption and Daily Read Log, as well as Privacy PINs to protect personal data, it does not specify any structures for such commands or data, so any additional devices the consumer may wish to attach to their HAN must be specifically configured to interface with their particular meters.

Consumer Access Devices (CAD)

A Consumer Access Devices (CAD) is an extension to this specification allowing the data to be accessed by third party equipment installed and configured into the HAN. Examples of such equipment include InHomeDisplays' SmartHub, Hildebrand's Glow Hub and the more generic Telegesis Zigbee Ethernet Gateway.

Although a UK government consultation concluded in February 2017 that "Local CAD Pairing will not be implemented at this time due to data privacy and consumer experience concerns", this article suggests that some smart meter installers will pair a consumer's CAD when they pair the IHD to the smart meters, or that some Energy providers accept pairing requests by telephone. However, Ofgem published a BEAMA Guide to CADs indicating that CAD Pairing might become a more mainstream request soon. BEAMA is a UK trade association for building electrical and environmental systems, who are advocating Consumer Access

Add a custom footer
Add a custom sidebar
Clone this wiki locally