The goal of this installment is to dig in a bit deeper to the options to securing home automation devices on a home network and possible tradeoffs of privacy for convenience.
Overview of IoT
IoT is the internet of Things and typically implies a Cloud-based Server and some connection to this well known (trusted) location from a device itself or some kind of Hub (this may be specific to the manufacturer or a general home automation / voice assistant, such as Google Home, Amazon Alexa, or Apple Home Pod).
These Cloud-based solutions have the advantage of Secure transport of information over the Internet and thus control from anywhere. They have a low technical adoption threshold, allowing someone with minor technical expertise to get the device up, running and connected. Locally they depend upon the security of the Wifi / home network they are connected to in order to prevent external parties from gaining access to the devices.
One possible downside is that each type of device might have a separate account to manage it. If the device is a permanent fixture, transfer (at least relinquishing) of ownership may be time consuming in addition to the transfer of knowledge to the new owner. This aspect may not be as big of a deal if the devices are Plugged into the Wall and you can just take them with you. Interaction between devices might require some cross authentication between these separate accounts, a smart home assistant can help ease this, but NOT ALL DEVICES ARE COMPATIBLE WITH ALL off-the-shelf home automation assistants.
A significant downside is when there is an interruption in the Internet connection. Some of these devices may not operate especially when it comes to actions between devices. This issue can vary, depending on the device, but higher level features likely stunted. For example, Changing the "Wall Switch" to control an independent "Wall Socket" or connected light bulb may not work with different manufacturers of the devices. Single branding can assist with these two downsides, however, if the brand decides to go out of the market, one might be stuck with significant loss of cross communication.
Do It Yourself (to varying degrees)
Enter the engineer (real or imagined), maybe they know a bit about coding, home wiring, networking. They know enough, at least, that they might be concerned if a large company who sells their product interests of internet clicks might also be interested in sells when you are at home or turned on various appliances in your home. Or they are concerned that the guy walking down the street (or not even anywhere near his street) has found an unpatched vulnerability in a manufacturer's Cloud and is able to control an appliance or door lock.
Other considerations are if the device becomes hacked, how do you limit the exposure to other information on your home network from leaking out or prevent virus infections.
On one extreme one can Make a device, the parts and tutorials are out there to create your own way to control things. This is a FUN Hobby and filled with adventure, learning and typically the most expensive way to accomplish a result. But, the result is not always the goal of these projects, it is the learning and then the replacement in a year with the "better one".
Another way is to take an inexpensive, prebuilt device which is fairly feature rich (or change the device's programming to make it feature rich), using a prebuilt building block. This becomes less expensive and has the benefit of being tested and engineered to not catch fire when wired up correctly.
Communicating with Rogue Devices
The whole point of Home automation is having "soft connections" to the traditionally hardwired devices or appliances. Although interruptions to the Internet at a home location is rare in many areas, there are cases in other locations which can have interruptions last for significant amounts of time. Further, a home made device or an inexpensive DIY one may not be hardened for exposure onto the Internet.
For these considerations, limiting the ability for a non-commercial device to have access to the entire internal home network as well as controlling the exposure of these devices from the home network is a priority to take into account.
If one has a large number of devices, having them each understand the other devices in the network that they might want to control becomes a large interconnection and configuration challenge. A simple protocol (a was for devices to communication with one another) which helps to address this issue is called MQTT. Effectively, there is a central location which each device published status changes to and subscribes to change requests. The devices need not know about each other directly or how they are connected, there is an abstraction called a topic which any one of them can publish to and / or subscribe to. A "Wall Switch" can publish when it changes from off to on and a "Light Bulb" can subscribe to that topic in order to react to the position of the "Wall Switch".
The center of an MQTT network is managed by a "Broker" who sets about doing the capture of the Publications and sending out these responses to those who subscribed to them. This is a popular method especially when one is incrementally enhancing their connected device control by adding in new devices. The central point becomes the place to do the logical wiring. The Broker can be an Open Source MQTT software package on an inexpensive computer (Raspberry Pi is very popular) or it can itself be a Cloud Service (allowing for control outside of the home network from someone authorized to use the service). Or it can be a combination of the two with some limited functions exposed through the Cloud Service and the heart of the interaction described in the local service. There are Open Source packages (such as "Home Automation") which has the ability to control MQTT devices, becoming their Broker, as well as a number of commercial devices.
The key to using something on local hardware for the central control is it can guard against Internet interruption and ensures the action device interactions are kept privately in one's own control.
A term for this kind of deployment is NoT (Network of Things) which eliminates the Internet dependence. In this case, folks implement a separate network for their Connected Devices and don't allow the devices themselves to access the Internet itself or perhaps even the local network that the remainder of the Wifi users (Laptops, Smartphones, etc.). Isolation of these, especially when they control Windows, Door Locks or Garage Door Openers is very important to have peace of mind when it comes to someone hacking one of these physical entry barriers.
For Wifi based Smart devices or Hubs, this typically means having a separate network access point. The speed and throughput for these NoT devices does not have to be great, since the messages being sent are infrequent and typically very small during normal operation.
Once again a Raspberry Pi can be an inexpensive device to provide this separate Access Point with a different SSID from the normal network. It can be configured to only allow data to flow to and from the central MQTT Broker or Home Automation software.
Organizing Devices Physically
If one commits to having some inexpensive local computer providing the Wifi connectivity to the Connected Devices / Appliances, then one couple place multiple of these in different zones of the hours with different Access Point SSID names and ensure that the Connected Devices do not try to connect to a Wifi provider which is too far away just because the near by device has gone offline for a period of time.
If one adheres to MQTT as the major means of communications, then each of the local computers (Raspberry Pi) could be the actual "Broker" for the devices connecting to it and then provide a subset of the messages to other "Broker" Zones or into one which acts as the primary Broker or Home Automation Hub for the household.
This cascaded MQTT using Zones, when Connected Devices are likely not physically moving it the house, can also isolate automation limited to that zone between connected devices. This is the typical minimum automation where one turns off the main light in the kitchen and ALL of the other Lights go off.
Living on the Edge
The term that describes this type of interconnection could be Edge of Things or EoT. Some local intelligence over the local devices and separate broadcasting of messages to a parent "Broker".
Lights and Switches in the Kitchen typically have more relevance to other Lights and Switches in the Kitchen than they would with Lights in the Bedroom. In many of the emerging IoT controlling solutions, there is the organization by "Room". With central dispatch of messages, there is still the ability to check the status of the kitchen light from the Bedroom or turn it off, but the hard automation for the kitchen is likely to be in the kitchen.
The focus here has been Wifi connection, other Radio transmission types (Bluetooth, Z-Wave, Zigbee, etc.) can be added to the mix and "bridged" easily into MQTT with a general purpose local computer providing the Wifi Hotspot as well - given that the manufacturer is willing to allow it to be leveraged by a Maker Type.
Although, one can upgrade their Networking to allow for the wiring to have vLan tags controlled by Firewall rules. By limiting the actual connection to the local computer (Raspberry Pi) and having it proving the filtering, the upgrade in Network equipment might be at a minimum delayed.
Simple Switch / Light Solution
One key consideration is to have the "interface" for the humans coming through be as familiar as possible. Most of the IoT switches on the market have the form of a Pushbutton and it is tempting to put a bunch of Pushbuttons crowded near each other. DIY folks are not always thinking that someone is going to be unwilling to read a manual to turn the light on. In addition, the Analog "Wall Switch" is carrying voltages of 120 in the US / Canada and 240 in Europe. This can be a shocking discovery your first time out. Further, if one uses their OWN circuits connected to the "Mains", there is a risk of Fire in the Wall. This is not a desired outcome. Unless one is willing to rewire their home to be low voltage, it is best to consider off-the-shelf devices which are properly rated and designed for the voltage and amperage that it is required to carry.
The "Sonoff" series of devices has been very popular, although not all of them are UL rated and typically to have them removed from a Cloud connection in China requires a little bit of rework of the software inside of them — there is a lot of good stable development around this in order to get these devices to speak MQTT to your local "Broker". They are inexpensive and one might choose them if there is a massive number of devices to be deployed.
The "Shelly" series has see the success of the Sonoff with DIY enthusiasts and have produced an impressive line of devices. The cool part is that it can be configured to use MQTT and disconnect from the use of their Cloud with no additional Firmware change (one can change the Firmware just like in the "Sonoff" solution, if one had a mix of devices and wanted them all to be consistent). The baseline "Shelly 1" is also very small and fits easier into an electrical box with other standard Switches and Outlets. There is also significant documentation on the http-based API for control / configure as well as the various Topics that the devices publish / subscribe when MQTT is configured and enabled.
In either of these solutions, one is risking a good deal by trying to control High Voltage Mains with a Home Brewed Device, especially when it is inside of a Wall. And one would be hard pressed to make such a device less expensively. If one is NOT controlling High Voltage electronics, something one Makes themselves can be easily created, programmed and hooked into the same MQTT infrastructure while having a good time doing it.
So for an initial toe in the water, I recommend the "Shelly 1" (with UL certification) when ducking it behind a Wall Switch or a Switched Outlet. Don't have your toe literally in the water when you are hooking it up, by the way. It can be configured using their Smart Phone App or by visiting some URLs to perform the setup to configure Wifi to a Local Raspberry Pi and have the Raspberry PI be the MQTT Broker. This becomes a quick proof of concept that adding a second "Shelly 1", then putting Automation Rule in place becomes a next level of delight.
Here is a detailed comparison of the Sonoff vs. the Shelly:
Comentarios