It is always unfortunate when the garage door is left open when you leave for an extended period of time. This has happened to me a couple of times. By leaving the garage door open, I was inviting unwanted guests into the garage. An unwanted guest can be animals looking for a meal and spreading […]… Read More
Global IoT connectivity and the ubiquity of IoT connection, in general, have been thought of...
The post How To Achieve A Global Connectivity With Your Business appeared first on Binary Blogger.
If high-tech gadgets are on your holiday shopping list, it is worth taking a moment to think about the particular risks they may bring. Under the wrong circumstances, even an innocuous gift may introduce unexpected vulnerabilities. In this blog series, VERT will be looking at some of the Internet’s best-selling holiday gifts with an eye toward their […]… Read More
A roundup of UK focused Cyber and Information Security News, Blog Posts, Reports and general Threat Intelligence from the previous calendar month, November 2020.
Manchester United FC remains impacted by a seemly major cyber-attack, which I covered in a blog post titled The Multi-Million Pound Manchester United Hack. At this point, United have provided few details about their cyber-attack which has been impacting club's IT systems for well over a week. However, the UK media are widely reporting United's leaky IT defences was unable to prevent a ransomware attack and data theft. London's Hackney Borough Council have also been tight-lipped about what they describe as "a serious cyber-attack" which has impacted its service delivery to Londoners. Like United, this attack has all the hallmarks of a mass ransomware outbreak. Both Manchester United and Hacknet Council said they are working UK's National Cyber Security Centre (NCSC).
|Man.Utd hit by ransomware, who's next?|
Street Fighter games maker Capcom also reported to be compromised by a ransomware attack, with up to 350,000 people said to be affected, along some of Capcom's financial information stolen. The Ragnar locker hacker group were said to be behind the attack, although indications are that Capcom hasn't given in to their ransom demands after an ominous message appeared on the Ragnar group's website, which said Capcom didn't "make a right decision and save data from leakage".
The ransomware attacks will be going from bad to worse in 2021 according to Sophos. In its annual threat report, Sophos anticipates ransomware tactics, techniques and procedures are to become more evasive, with criminal threat actor operating more like nation-state attackers. Sophos also expects an increase in the number of entry-level, apprentice-type attackers looking for menu-driven, ransomware-for-rent, meaning the technical barrier preventing general nefarious folk orchestrating ransomware attacks is getting lower.
Its likely COVID-19 has saved Ticketmaster from a more substantial DPA/GDPR fine after the Information Commissioners Office (ICO) announced it had fined the gig ticket selling company a mere £1.25 million for failing to keep 9 million of its customer's personal data and payment cards secure. The ICO investigation concluded a vulnerability in a third-party chatbot installed on Ticketmaster's online payments page was exploited and used to access its customer card payment details. Following the breach, 60,000 Barclays bank customers were victims of fraud, while online bank Monzo had to replace 6,000 payment cards due to fraud. Ticketmaster said it would appeal against the ICO ruling.
An interesting new UK law is in the offing which proposes fines of 10% of turnover or more than £100,000 a day for telecoms operators that use of Huawei network equipment within their 5G networks. The bill provides the UK government new powers to force out Huawei usage with the UK telecoms giants, the threatened sum of £100,000 a day would only be used in the case of "continuing contravention" according to number 10.
Consumer group Which warned security flaws in popular smart doorbells are placing UK consumers at risk. The watchdog tested 11 smart doorbell (IoT) devices purchased from popular online marketplaces like Amazon, the dodgy products were said to have been made by Qihoo, Ctronics and Victure. The most common security flaws found by Which were weak password policies and a lack of data encryption. Two of the devices could be manipulated to steal network WiFi passwords, providing the opportunity for an attacker to then hack other smart devices within the home.
The NCSC released its annual review, confirming what we already know about the commonality of ransomware attacks on UK organisations. The NCSC also accused Russia of trying to steal vaccine-related information through cyber-espionage, advising an "ongoing threat" of nation-states targeting the UK vaccine research-and-delivery programmes. The NCSC were not alone in pointing the finger at nation-state threat actors going after COVID-19 vaccines, Microsoft also reported state-backed hackers from Russian and North Korea were targeting organisations working on a coronavirus vaccine. The Russian group "Fancy Bear" and North Korean groups "Zinc" and "Cerium" were fingered by Microsoft as the culprits behind a spate recent cyber-attacks. Microsoft said Fancy Bear were brute-forcing accounts with millions of different passwords combinations, while North Korean groups sent spear-phishing emails posing as World Health Organisation officials, in an attempt to trick researchers into handing over their login credentials and research data.
- The Multi-Million Pound Manchester United Hack
- Advice: Protecting Lone Workers Through Covid Restrictions
- Seven Debunked Myths of Cybersecurity
- Check, Please! Adding up the Costs of a Financial Data Breach
- One Step Beyond: Using Threat Hunting to Anticipate the Unknown
- Cyber Security Roundup for November 2020
- Manchester United Impacted by a Ransomware Attack
- Huawei Ban: UK Networks Facing £100,000 a Day Fines
- Capcom Hit by Ransomware with 350,000 Personal Records Taken from the Game-maker
- Ticketmaster fined £1.25m over Payment Data Breach
- Smart Doorbells ‘Easy Target for Hackers’ study finds
- Cyber Space will become 'most contested domain', warns UK Security Chief
What. A. Week. Blog post every day, massive uptick in comments, DMs, newsletter subscribers, followers and especially, blog traffic. More than 200,000 unique visitors dropped by this week, mostly to read about IoT things. This has been a fascinating experience for me and I've enjoyed sharing the journey, complete with all my mistakes 🙂 I topped the week off by spending a couple of hours talking to Scott Helme about our respective IoT experiences so that's the entirety of this week's update - Scott and I talking IoT. I hope you enjoy this temporary change in programming so here it is, the IoT unravelled livestream with Scott:
- IoT Unravelled Part 1: It's a Mess... But Then There's Home Assistant
- IoT Unravelled Part 2: IP Addresses, Network, Zigbee, Custom Firmware and Soldering
- IoT Unravelled Part 3: Security
- IoT Unravelled Part 4: Making it All Work for Humans
- IoT Unravelled Part 5: Practical Use Case Videos
- Sponsored by: 1Password is a secure password manager and digital wallet that keeps you safe online
This is the fifth and final part of the IoT unravelled blog series. Part 1 was all about what a mess the IoT landscape is, but then there's Home Assistant to unify it all. In part 2 I delved into networking bits and pieces, namely IP addresses, my Ubiquiti UniFi gear and Zigbee. Part 3 was all about security and how that's all a bit of a mess too, particularly as it relates to firmware patching and device isolation on networks. Then in part 4 I focussed on the user experience because whilst it's great having all that digitised stuff in the home, it can't degrade the experience of the less technical users of the house.
Now in part 5, let's look at how it all works together, and I've done 11 short videos showing different parts of my house and how the IoT bits work there. If you want to just watch them all back to back, I've put everything in a YouTube playlist embedded here:
Alternatively, you can watch each individual video below complete with some additional commentary about how things work or how I'd do them differently. All these videos are unedited, candid versions of precisely how my house works, enjoy 🙂
Opening the Garage Door Remotely
The original goal of this whole IoT journey! This is enormously useful and not a day goes by where I don't use Apple Home Kit to open the garage door in one way or another. Yesterday morning whilst out Christmas shopping, UniFi Protect popped up on my watch as there was someone at the door. A quick look showed it was the gardeners who normally give advanced notice, but this time showed up unannounced and didn't have access to the property. Over to Home Kit, pop open the garage door, job done!
Playing a Sonos Station with My Watch
This seems like a minor benefit but switching to the station I want via the Sonos app is a bit painful. Open it up, scroll through the favourites, choose the station, sync it to both my Sonos units, set the volume, done. But it's 2 taps on the Apple Watch; one to open the Home Assistant app and a second to "Play ABC Radio". It's the little things like this that I really appreciate.
The Washing Machine Just Finished
Raising alerts when events occur is one of the joys of home automation and whilst I didn't see the value in it at purchase time, having connectivity on the washing machine is actually kinda neat. There's a Samsung SmartThings integration in HA which makes it dead simple to track the washing machine state and let us know once a wash cycle is complete and the clothes are ready to hang on the line.
Is the Coffee Machine Out of Water?
This automation is far more useful than what it probably seems, namely because once the machine is out of water and cools down, there's a quite a lead time to warm back up again. It bugged me, and the solution was simple using the HS110 energy monitoring plugs. I'm using to track a bunch of other things around the house too, it just takes a little tweaking to associate the change in power usage to an event in the appliance you're tracking.
Ring Ring, Ring Ring, There's Someone at the Door
I couldn't wait to get this doorbell in place as it's another piece of the automation puzzle that gets a daily workout. The Ubiquiti UniFi Protect G4 doorbell has an awesome 1080p picture quality and not only does all the stuff in the video, but is also used as a motion sensor to trigger lights should someone walk up to the door after sunset. Plus, it's permanently recording everything and flagging the timeline with events based on motion within predefined zones.
Managing My Office Lights Based on Movement and Stream Deck Buttons
My office lighting was one of the first things I did with home automation as it's continuously changing. I'm writing this with lots of natural light flooding into the room, but later I'll be livestreaming with the curtains closed and 5 artificial lights on, all easily triggered on or off. What I didn't mention in this video is that that lights are only turned on automatically when the light is beneath a certain level; there's no need to automatically turn them on when it's already well lit.
Stair Lights and Kids' Bedroom Lights with Aqara Motion Sensors
The stair lighting is one of the most useful automations in the house and it's another IoT feature we use daily. The kids love their rooms and take great pleasure in showing visitors not just the lights themselves, but how they can ask Alexa to change them to their hearts' desire. I wouldn't do this in our master bedroom, but it's great fun for the kids 😊
Triggering Lights with Ubiquiti UniFi Protect Cameras
The UniFi Protect integration has been fantastic for triggering lights on, especially outdoors where different lights are triggered by movement in different areas. I love this as a security precaution, but do often find a little bit of lag for use in an indoor room where you want the light coming on pretty much immediately when motion appears (although strangely, it performed very well in the video below!)
It's Almost Sunset, Set the Lights
There's just something about coming back to a dark house that feels kinda... lonely. I've put Shellys behind a bunch of the lights both indoors and outdoors to make sure the place always feels welcoming after sunset. Combined with the Aqara button in the video, it's super easy for any family member to either turn them on earlier or turn them off all at once when heading to bed.
The Sun Has Set and the Garage Door is Open
This might seem like a minor one and it's only occasionally triggered as I'm pretty good at keeping the garage door shut, but I really don't want to be going to bed leaving it wide open. A combination of this automation and another Ubiquiti cam pointing at the garage door makes it easy to ensure the place is left how I want it before all the lights go out.
Backlighting Around the TV
I like the backlighting as it makes the black TV pop out from the (very dark blue) wall. I'm not completely happy with the diodes on the Hue being individually visible and would really like a diffuser on them but that said, they're only visible when you're offset from the TV like I am in the video. You only see a nice warm glow when you're directly in front of the TV.
I hope you've enjoyed this series, it's the culmination of many months of work I've been gradually adding to as I've progressed on my own IoT journey. I think this is a fascinating area of technology that's in its absolute infancy and clearly there are many rough edges to be ironed out. But that's also what makes it exciting, and I'm really looking forward to being more involved in the future of IoT.
Scott Helme and I will be livestreaming a discussion about our IoT journeys later today my time (Friday 27 November), watch for the video below 👇
The first few parts of this series have all been somewhat technical in nature; part 1 was how much of a mess the IoT ecosystem is and how Home Assistant aims to unify it all, part 2 got into the networking layer with both Wi-Fi and Zigbee and in part 3, I delved into security. Now let's tackle something really tricky - humans.
I love the idea of automating stuff in the home, but I love the idea of a usable home even more. What do I mean by a "usable" home? Let me explain it in mum and dad terms or in other words, let's talk about the UX my parents have when they visit my house.
To begin with though, I want to be clear about what I mean by UX:
User experience (UX or UE) is a person's emotions and attitudes about using a particular product, system or service. It includes the practical, experiential, affective, meaningful, and valuable aspects of human–computer interaction and product ownership. Additionally, it includes a person's perceptions of system aspects such as utility, ease of use, and efficiency.
In my IoT travels, I've seen way too many cases where connected homes have become (in my opinion) geek havens at the expense of UX. I want to go through some of those examples and talk about how I've tackled it at home in a fashion that gives us the best of both worlds: connected stuff that's usable by everyone.
My parents aren't as tech orientated as me and whilst the idea of a connected home appeals greatly to me personally, I doubt they share quite the same level of excitement. That's fine, I'm not expecting them to geek out at my YAML or get giddy about my Zigbee, but I do want them to be able to use my house.
Light switches are a perfect example of where connected home UX can go down the toilet. My parents are great with light switches, in fact, they have a lot more experience with them than I do. They're very familiar with the simple premise of flicking a switch to turn a light on and indeed, flicking it again to turn it off. Problem is though, connected lights can create a bit of a conundrum here:
I was looking at doing exactly this with my downlights, but the idea of the wall switch annoyed me - if it's off, I can't then voice turn on the lights. How are you getting around it, or just banning anyone from touching physical switches? :)— Adam Fowler (@AdamFowler_IT) August 13, 2020
Those lights are Atom WiZ Connected RGB LEDs and they talk directly to the Wi-Fi network. They need power to do that and the point Adam is making is that if the light switch on the wall is turned off and the connected light no longer has power, how can you control it digitally? I mean what if you turn it off at the wall then try to ask Alexa to turn it back on? It won't work as the light is now offline. The workarounds people create for this are, to my mind, sub-optimal:
Light switch guards. We have one over every switch that we don’t want used they come in colors or clear. They use the existing faceplate screws. pic.twitter.com/hN8VPt4g4n— iain (@iain_b) August 13, 2020
If I bring this back to the parents test, how do my mum and dad use these switches? Clearly, they can't because that's the whole purpose of the covers, so how do they turn the lights on? I'm not sure how Iain does it, maybe by voice, maybe by motion, maybe by something else altogether. All I know is that from a UX perspective, switch covers are unquestionably an anti-pattern.
The solution needs to involve both kinetic and digital controls that work in a harmonious fashion and there are a couple of ways of going about this. For example, there's the likes of Lutron Caséta which combines everything into a replacement switch:
A lot of people seem keen on this approach (and there are similar examples such as LIFX's), and I understand the value proposition, but I have a couple of fundamental issues with it. The first is that going down this route means there's a completely different light switch on the wall. I have light switches already and although I'm replacing some of them during renovations, I don't want to have to replace them just to automate the circuits behind them. If I did decide to go down this route, they're not always going to be the same physical dimensions as the existing switches which leads to replastering and repainting work. Then there's the price and it's looking like about A$83 for a simple switch which I don't actually think is unreasonable for the physical unit plus IoT capability (not when some of the other non-IoT switches I bought were A$60 alone), but that's quite a premium over the alternate solution I'll talk about in just a moment. But lastly (and to me this is the biggy), I just don't like the idea of tying physical switches I'll place my fingers on day in and day out for at least the next decade or two to a digital implementation with firmware I've got no idea how long will be supported for. I much prefer the idea of abstracting the physical switch gear from the digital IoT bits, which leads me to my ultimate solution:
Fixed! Not my work (licensed electrician only), but this is the end result and it works *perfectly*! pic.twitter.com/HGSEawEIgv— Troy Hunt (@troyhunt) September 8, 2020
The little blue units you see in foreground and background are the Shelly 1 relays I first mentioned in part 1 and their value proposition is that they're small enough to fit in behind existing switches. In fact, they're so small that the marketing around them compares them to the size of 2 Oreo biscuits:
They're also cheap at A$30 each which makes them a lot more financially accessible than, say, the Lutron approach, especially once you start doing a bunch of switches. Further, they're also approved for use in Australia which is super important as alternatives such as the SONOFF BASIC my mate Lars recently purchased are not. (Important side note: do check that stuff like this is approved for your part of the world. The SONOFF's were attractive at only A$10, each but Lars ultimately had to return them and get Aussie approved Shellys instead.) So, what does the Shelly ultimately give you? Perfect harmony between kinetic and digital switches:
It’s beautiful 😢— Troy Hunt (@troyhunt) September 8, 2020
This is precisely what I was after: digital and physical controls perfectly complimenting each other with neither suffering in the presence of the other. Will share a more full rundown of the room once work is complete but for now, the Shelly 1 just rocks 😎 pic.twitter.com/MKsefGQzbI
If my parents turn off the lights with the switch on the wall, I can turn them back on digitally either with the Shelly app or anything else that integrates with the devices (including HA). Same logic in the other direction too, in fact, there's no scenario in which either flicking the switch on the wall or toggling digitally doesn't do precisely what you think it should do. It's like everything works precisely as expected 😊 Almost...
Aligning Digital & Physical States
Let me explain the issue here with a simple visual representation; consider whether the following light switch is on or off:
To my mind, when the switch is down like this then the light is on. When it's up the other way, it's off. My house is full of light switches like this, as are most houses. The problem I have with this when it comes to IoT is that if lights are toggleable via both kinetic and digital switches, the physical state of the switch is no longer a true representation of the state of the light as the digital switch could have inverted it. Here's what I mean by that:
This is achieved via a simple configuration within the Shelly UI:
To be fair, I think it's a masterful implementation of the Shelly being able to toggle the circuit on every change of either kinetic or digital switch and I can't think of a better way of doing it with the equipment involved. (Incidentally, this YouTube video demonstrating the edge switch behaviour is what really sold me on the idea.) But it does leave the switch in that sort of inverted state. Mind you, that's no different to having multiple physical switches controlling the one light as many people (including myself) have in their homes. However, given the opportunity to make things a little more user friendly, I installed one of these in my entertainment room whilst doing some renovations:
These are Clipsal Saturn ZEN units and the main reason I wanted them is that the buttons always return to the same state. To use Shelly's nomenclature from the screen grab above, they're "momentary" buttons that turn either on or off with just a push. Light on or light off, the only representation of the state of the circuit is the blue LED in the centre of the switch. You can see this in the earlier tweet with the embedded video and to my mind, this is the most intuitive approach possible.
But then there's dimmers and they're much more of a problem. If we pursue the mantra of "enable both kinetic and digital controls and have them work equally and intuitively", there's a sticky point: rotary dimmers such as the one in the aforementioned video have, for example, 270 degrees of rotation. At zero degrees the light is all the way down then at 270 degrees it's all the way up. The rotary dial has hard stops on both ends and the amount of light incrementally increases or decreases as it's rotated (again, a UX paradigm my parents understand well). But what if I were to dim the lights digitally? I can't do that with the Shelly 1, but I could do it with a Shelly Dimmer 2 which is also approved for Australia. Problem then is that I could turn it all the way up on the wall but all the way down digitally then stuff is really out of sync.
One approach is do precisely what the Lutron obviously does in the earlier images and that's to have buttons to increase or decrease the light hence moving away from any physical state representing the circuit state. I have a major issue with this from a UX perspective and it's simply this: it's unintuitive. I've got a couple of lights with push button dimmers and IMHO, the experience totally sucks in comparison to rotating a dial and having a smooth transition between the minimum and maximum light scales. I felt so strongly that rotary dimmers are the best UX that I decided to completely forgo digital control. In both the embedded videos in the earlier tweets, those lights are only dimmable by walking over to the switch on the wall. Part of my decision-making process here was that I rarely change the amount of light used and the infrequent change didn't justify forgoing the UX. I believe this position is entirely reasonable to take: not everything has to be connected and indeed there are times where doing so may well make for a worse user experience.
In an ideal world, I'd like to see a rotary dimmer that can sit behind my existing switches and just rotate infinitely. At some point, the light won't go any lower and at some point, it won't go any higher, but rotating clockwise increases the light level and vice versa. I appreciate that's a fundamental change in dimmer circuitry but from a UX perspective, that seems optimal.
Other Human-Centric UX Considerations
The examples above were picked to highlight points where connectivity can come at the expense of usability and how IMHO, that's not a sacrifice connected homes should be making. That said, there are places where I'm more willing to make concessions, such as the "media room" between my kids' bedrooms:
This popped up on my watch the other day because the cleaners had turned off the 4 downlights in the roof via the light switch on the wall (they're like my mum and dad - got a great grasp of how light switches work!) With no more power to them, they dropped off the network and Tuya sent me the alert. Of course, you can always just turn the light switch back on again and the lights will do precisely what you think they should do, but they could no longer be turned back on via the Aqara motion sensor I installed in that room.
As I progress, I'm toying with different approaches to handling this, for example:
I’m still toying which the right UX for connected lights controlled by a physical switch. In the kids’ rooms, I’m giving this a go: pic.twitter.com/cBLulGk5HE— Troy Hunt (@troyhunt) October 19, 2020
To be clear, I don't think this is a particularly UX-friendly approach, but it's been fun toying with different connected things in order to see what actually sticks. I don't mind experimenting on the kids 🙂
A better option is to configure the Shelly as a "detached switch":
When in this mode, the actual physical light switch becomes "detached" from the light:
Detached mode is used when you don’t want the physical switch that is wired to the Shelly to directly control the light
This is great because it means that flicking the switch doesn't kill power to the lights (and remember, they're smart lights that can be digitally toggled themselves), but rather it can raise an event that can then be used as a trigger to perform an action. What action? Turn the lights on directly via, in this case, the Tuya integration. tl;dr - the light switch works precisely as mum and dad are used to, it's just the mechanics of how the lights are turned on and off that changes.
Continuing the theme of "does this normal everyday thing work the way I would expect it to", I recently installed Ubiquiti's G4 doorbell:
This rocks 😎 pic.twitter.com/S2doMzPxv4— Troy Hunt (@troyhunt) November 10, 2020
Connected doorbells are nothing new and the likes of Ring and Nest are now pretty common. Part of the value proposition is that ringing the doorbell can send a push notification to your smart phone which you can then use to have a 2-way conversation with the person at the door, regardless of where you may physically be at the time. But what happens inside the home? Back in the day, the doorbell would be physically wired to a ringer such that you had an audible alert when someone arrived at your house and yes, you can purchase a "chime box" for the modern digital equivalents, but it seems that many people forgo this in favour of just the app. Having something ring within the house was non-negotiable for me, so my doorbell now rings the Sonos:
I probably need to change that to something less annoying (like playing an actual ringing sound), but there's certainly no missing it when someone is at the door!
DIY or Professional?
This isn't strictly a UX issue (although it does relate to humans interacting with devices), but I'd be remiss not to mention it in this series. Throughout my IoT journey, I got a bunch of comments along these lines after sharing wiring pics:
Surprised the Aussie electrical licensing police are not onto you.— Richard Spaven (@EUCNut) September 3, 2020
Australia is actually very heavily regulated in this area, much more so than other parts of the world based on feedback I've had. I gave an example of that earlier on when Lars had to return his SONOFF units because they weren't approved for use here. There's a very simple rule of thumb in Australia as to when you need a licensed electrician:
The most work you're really allowed to do without the proper qualifications is to change a light bulb
Touching anything to do with 240V mains is absolutely out of the question here and yes, it obviously costs money to get a sparky (electrician) out, but keeping the house standards compliant and most importantly, not electrocuting yourself is rather important.
Bottom line: make sure devices are approved for use wherever you may be based and also make sure you're aware of how much of this you can do yourself versus needing to outsource to a licenced professional.
IoT should add to the user experience, not detract from it. Of course, it's just like UX in the digital realm insofar as it needs to be tailored to the audience; if you are the sole audience and you're happy with how things work, you're good to go. But if your partner or friends or relatives or other people who need to use your house can't get their heads around it, I suggest that's a serious shortcoming.
Lastly, and as I've mentioned at the end of each of the blog posts in this series so far, Scott and I will be doing our live IoT session tomorrow (Friday 27 November here in Australia and in the UK), via the video below 👇
In part 1 of this series, I posited that the IoT landscape is an absolute mess but Home Assistant (HA) does an admirable job of tying it all together. In part 2, I covered IP addresses and the importance of a decent network to run all this stuff on, followed by Zigbee and the role of low power, low bandwidth devices. I also looked at custom firmware and soldering and why, to my mind, that was a path I didn't need to go down at this time.
Now for the big challenge - security. As with the rest of the IoT landscape, there's a lot of scope for improvement here and also just like the other IoT posts, it gets very complex for normal people very quickly. But there are also some quick wins, especially in the realm of "using your common sense". Let's dive into it.
The "s" in IoT is for Security
Ok, so the joke is a stupid oldie, but a hard truth lies within it: there have been some shocking instances of security lapses in IoT devices. I've been directly involved in the discovery or disclosure of a heap of these and indeed, security is normally the thing I most commonly write about. Let me break this down into logical parts and use real world examples of where things have gone wrong and I'd like to cover it in two different ways:
- Risks that impact IoT devices themselves
- Risks that impact data collected by IoT devices
Let's take that first point and what immediately came to mind was the Nissan Leaf vulnerability someone in my workshop found almost 5 years ago now. Here we had a situation where an attacker could easily control moving parts within a car from a remote location. Fortunately, that didn't include driving functions, but it did include the ability to remotely manage the climate control and as you can see in the video embedded in that post, I warmed things up for my mate Scott Helme from the other side of the world whilst he sat there on a cold, damp, English night.
Same again with the TicTocTrack kids tracking watches which allowed a stranger on the other side of the world to talk to my 6 year old daughter. The thing with both the car and the watch hacks though is that the vulnerability was at the API layer, not the device itself and this is where we spear off into another 2 directions:
- Risks that impact IoT devices due to vulnerabilities in web APIs
- Risks that impact IoT devices due to vulnerabilities in the device itself
I've given 2 examples of the first point, so here's 2 examples of the second beginning with LIFX light bulbs. The vulnerability Context Security discovered meant exposing the Wi-Fi credentials of the network the device was attached to, which is significant because it demonstrates that IoT vulnerabilities can put other devices on the network at risk as well. Another example also from Context Security was the vulnerability in CloudPets talking (and listening) teddy bears that amounted to no auth on the Bluetooth allowing an attacker to take control of the toy. (Incidentally, Lixil Satis toilets had a similar vulnerability due to hardcoded PINs on all "devices".)
Back to the bit about risks impacting data collected by IoT devices and back again to CloudPets, Context Security's piece aligned with my own story about kids' CloudPets messages being left exposed to the internet. I can't blame this on the teddy bears themselves, rather the fact that the MongoDB holding all the collected data was left publicly facing without a password. Same again with VTech who collected a bunch of data via children's tablets (IMHO, an IoT device as they're first and foremost a toy) then left it open to very simple vulnerabilities. Are these examples actually risks in IoT? Or are they just the same old risks we've always had with data stored on the internet? It's both, here's why:
Let's use smart vibrators as an example (yes, they're a real thing), in particular the WeVibe situation:
At the August Def Con conference in Las Vegas, two New Zealand hackers demonstrated that the We-Vibe 4 Plus vibrator was sending information — including device temperature and vibration intensity — back to its manufacturer, Standard Innovation.
If this data was compromised, it could potentially expose a huge amount of very personal information about their owners, information that never existed in digital form before the advent of IoT. Whilst the underlying risk that exposes the data may well be a classic lack of auth CloudPets style, there'd be no data to expose were it not for adding internet to devices that never had it before. Adult toys have been around forever and a day, they're not new, but recording their usage and storing it on the cloud is a whole different story.
So, what's to be done about it? Let's got through the options:
I'll start with the devices themselves and pose a question to you: can you remember the last time you patched the firmware in your light globes? Yeah, me either, because most of mine are probably like yours: the simplest electrical devices in the house. Some of them, however, are more like the LIFX example from before in that they have little microprocessors and are Wi-Fi (or Zigbee) enabled. And, just like the LIFX devices, they're going to need patching occasionally. They're complex little units doing amazing things and they run software written by humans which inevitably means that sooner or later, one of us (software developers) is going to screw something up that'll require patching.
IoT firmware should be self-healing. This is super important because your average person simply isn't going to manually patch their light bulbs. Or talking teddy bear. Or vibrator. Can you imagine - with any of those 3 examples - your non-tech friends consciously thinking about firmware updates? How often would you think about firmware updates? How often would I? To test that last question, I fired up a bunch of IoT device apps to see which ones are auto-updating (so I don't have to think about patching) versus requiring a manual update (in which case, I should have been thinking about patching). I started with the Philips Hue app which was both auto-updating and at the latest firmware version:
Ok, that's good, not something I need to think about then. Let's try Nanoleaf which are the LED light panels both kids have on their walls:
Ok, so they're up to date, but will they stay up to date? By themselves? I honestly don't know because it's not clear if, to use my earlier term again, they're self-healing. Same with the Shellys I've become so dependent on:
And just to perfectly illustrate the problem, I snapped that screen cap the day before posting this part of the series. Just over a day later, it's a different story and I only knew there was an update pending because I fired up the app and looked at the device:
I checked just one of the couple of dozen connected lights running in the Tuya app:
This looks good, but it wasn't the default state! I had to manually enabled automatic updates and I had to do it on a per-device basis. People just aren't going to do this themselves.
The next thing I checked was my Thermomix and the firmware situation is directly accessible via the device itself:
I'm not sure whether this auto-updates itself or not (it's still fairly new in the house), but with a big TFT screen and the ability to prompt the user whilst in front of the device, I'd be ok if it required human interaction.
Finally, I checked my TP-Link smart plugs via the Kasa app:
Uh... is that good? Bad? Does it need an update? Turns out you can't tell by looking at the device itself, you need to jump back out to the main menu, go down to settings, into firmware update then you see everything pending for all devices:
I don't know how to auto-update these nor do I have any desire to continue returning to the app and checking what's pending. I hit the update button and assumed all would be fine... (it wasn't, but I'll come back to shortly)
Here's what I'm getting at with all this and I'll hark back to the title of part 1: it's a mess. There's no consistency across manufacturers or devices either in terms of defaulting to auto-updates or even where to find updates. And before anyone starts jumping up and down suggesting that devices shouldn't auto-update because you should carefully test any patches before rolling out to production and ensuring you have a robust rollback strategy, these are consumer devices made for people like my mum and dad! It needs to be easy. It's not.
When Patching Goes Wrong
Now that I've finished talking about how patching should be autonomous, let's talk about the problems with that starting with an issue I raised in this tweet from yesterday:
In the first of my IoT blog series yesterday, I lamented how one of my smart plugs was unexplainably inaccessible. Looks like @tplinkuk broke it with a firmware update which will now break a bunch of stuff around the house. Check out the angry responses to their tweet, wow 😯 https://t.co/RKFxNF7v9a— Troy Hunt (@troyhunt) November 23, 2020
What appears to have happened is that in order to address "security vulnerabilities on the plug", TP-Link issued a firmware update that killed the HA integration. More specifically, they closed off the port that allowed HA to talk directly to the smart plug which broke the integration, but didn't break the native Kasa app. As at the time of writing, the fix is to raise a support ticket with TP-Link, send them your MAC address then they'll respond with a firmware downgrade you can use to restore the device to its previous state. Ugh. (Sidenote: regarding this particular issue, it looks like work has been done to make HA play nice with the newer version of the firmware.)
Let's start by looking at this from a philosophical standpoint:
But here’s the bigger philosophical question: the device still worked fine with the native app, should @TPLINKUK be held accountable for supporting non-documented use cases? Probably “no”, but in a perfect world they’d document local connections by other apps and not break that.— Troy Hunt (@troyhunt) November 23, 2020
Clearly it was never TP-Link's intention for people to use their plugs in the fashion HA presently is and I'll talk more about why HA does this in the next section of this post. But rightly or wrongly, the risk you take when using devices in a fashion they weren't designed for is that the manufacturer may break that functionality at some time. One way of dealing with that is to simply block the devices from receiving any updates:
Troy, Firewall Rule number 1 for HA and Home IoT subnets (although breaks Wiz Bulb connectivity even though they have a “local” access API) pic.twitter.com/RGOhsGaq7F— GerryD ©️ (@Bayview252) November 23, 2020
But what if that device was the LIFX light bulb from earlier on and the patch was designed to fix a serious security vulnerability? Now you've introduced another risk because you're not taking patches and you have to trade that off against the risk you run when you do take patches! As @GerryD says further down that thread, it's a calculated risk and ultimately, you're trading one problem off against another one.
Speaking of trading problems, another approach is just to flash the devices with custom firmware like Tasmota:
Moral of story, avoid anything requiring proprietary access. They can always screw you. Use devices you can drop Tasmota onto. If only a company would sell devices that need no specific cloud service.— Brian Orpin (@borpin) November 23, 2020
Tasmota is designed for precisely this sort of use case and I have a high degree of confidence that they wouldn't break functionality in the same way as TP-Link did. However, I also have a high degree of confidence that Tasmota is software, all software has bugs (open source or not), and you still need a patching mechanism. To my point about @GerryD's tweet earlier, firewalling off devices still remains a problem even when running open source custom firmware.
So, what's the right approach? For your average consumer (and remember, that's probably 99%+ of people buying TP-Link smart plugs), automatically updating firmware is key. For the rest of us, we need to recognise that we take on risks when using IoT devices in ways they weren't designed for. In a perfect world, companies would approach this in the same way Shelly has:
One company that we have partnered with is Shelly. They supplied the people working on the integration with the products, access to pre-release firmware and a dedicated QA group to talk to the CEO + engineers. The integration is maturing fast and next release will be really 👌— Paulus Schoutsen (@balloob) November 24, 2020
Paulus is the founder of HA and I've had a few chats with him during my IoT journey. This tweet is exemplary behaviour by Shelly and if I'm honest, my opinion of them raised a few bars after reading this. In that perfect world, TP-Link wouldn't necessarily need to go as far as devoting resources to building HA integrations (although that would be nice!), but they would make a commitment to ensure their devices are "open" and accessible to other platforms in a documented, supported fashion that won't be broken by future patches. Perhaps that's just a matter of time and as demand grows, who knows, we might even see HA on the TP-Link box alongside the tech behemoths.
This whole discussion about devices updating their firmware raised another philosophical debate which I want to delve into now, and that's the one about how self-contained the IoT ecosystem should be within the LAN versus having cloud dependencies.
Cloud Versus Local Only Access
In part 1 of the series I quoted from the HA website about how the project "puts local control and privacy first". What this means in practical terms is that HA can operate in a self-contained fashion within the local network. For example, before the aforementioned TP-Link firmware update, HA could reach out from its home in my server cabinet directly to the smart plug in Ari's room and communicate with it over port 9999. It would still work if there was no internet connectivity (local control) and TP-Link were none the wiser that I'd just toggled a switch (privacy first). There's also the added upside of the resiliency this brings with it should an IoT manufacturer have an outage on their cloud:
for my gear that is Tuya based, Tasmota has been flawless for me. I know Troy isn't fond of the firmware replacement approach, but I don't want to wake up one day (or not wake up!) to find that all my HA has broken because of an outage with the Tuya cloud servers.— Alan (@Alan_1) November 23, 2020
That resiliency extends beyond just a cloud outage too; what if Tuya shuts down the service? Still want to be able to turn your lights on? There's a lot to be said about local control. That said, there's also a lot to be said about cloud integration and a perfect example of that is weather stations. I'm looking around at devices (the Davis Vantage Pro2 is the frontrunner at present, but I'm open to suggestions), and that then raises the question: which ones have an integration with HA? But also (and based on the TP-Link experience above), which ones have an integration that won't break in the future? A weather station is a sizable outlay compared to a smart plug and I don't want to go into it with an expectation of it working a certain way and then one day having that broken.
One approach is that rather than trying to integrate directly between the weather station and HA, you find a weather station that can integrate with Weather Underground (which Davis can do with WeatherLink Live) then use the Weather Underground integration. Now you're dependent on the cloud, but you've also dramatically widened your scope of compatible devices (WU integration is very common) and done so in a way that's a lot less hacky than custom integrations connecting to non-standard services. I don't have a problem with this, and I think that being too religious about "though shalt not have any cloud dependencies" robs you of a lot of choices.
That said, from a simple security and privacy perspective (and often a performance perspective too), I always prioritise local communication. For example, each Shelly device in the house has cloud integration disabled:
That doesn't stop me controlling the device remotely because I can use HA's Nabu Casa to do that, but it does stop my being dependent on yet another IoT vendor to remotely manage my home. It also grants me more privacy as the devices aren't perpetually polling someone else's cloud... almost. For some reason, the Shelly on my garage door is making a DNS request for api.shelly.cloud once every second!
That data is from my Pi-hole and the Shelly is configured precisely per the earlier image. I've even pulled the JSON from the /settings API on the Shelly (you can hit that path on the IP of any Shelly on the network and retrieve all the config data), diffed it with other Shellys not displaying this behaviour and I still can't work out why it's so chatty. The point I'm making here is that devices can do a lot of communicating back to the mothership and where possible, this should be disabled.
IoT SSIDs and VLANs
If we recognise this whole thing is a mess and that at least as of today, we don't have a good strategy for keeping things patched, what should we do? One popular approach is to isolate the network the IoT things are on from the network the non-IoT things are on. This mindset is akin to putting all the potentially bad eggs in the one basket and the good eggs (such as your PC) in another basket.
The requirement for doing this is to have networking gear in the home that supports it. In part 2 I talked about the importance of good networking gear and indeed I've written many pieces before about Ubiquiti before, both their AmpliFi consumer line and UniFi prosumer line, the latter having run in my house for the last 4 years. Running UniFi, I can easily create multiple Wi-Fi networks:
And yes, I name my SSIDs "HTTP403" 😊
As we then look at which clients have connected to which SSIDs, we can see them spread across the primary (HTTP403) and IoT (HTTP403 IoT) networks:
I've also got a heap of access points across my house so different devices are connected to different APs depending on where they're located and what signal strength they have. I've chosen to place all my highly trusted devices such as my iPhone, iPad and PCs on the primary network and all the IoT things on the IoT network. I've also placed the Ubiquiti cameras (including their doorbell) on the primary network figuring they're all essentially part of the UniFi ecosystem anyway.
But this is just segmentation by SSID; every device is on the same subnet and the same logical VLAN and there's not presently any segmentation of clients such that the Shelly controlling the lights on my fireplace can't see my iPhone. Ubiquiti has a good writeup of how to do this and in the first version of my UniFi network, that's precisely how things were configured. (Also check out how to configure interVLAN routing.) But there were problems...
The main problem is that you end up with all sorts of scenarios where a particular IoT device needs to see the app that controls it but because the very purpose of the VLAN is to lock the IoT things away, things would fail. So, you end up tracking down devices, ports and protocols and creating ever more complex firewall rules between networks. Troubleshooting was painful; every time I had an IoT device not behaving as expected, I'd look suspiciously at the firewall rules between the VLANs. I ended up constantly debugging network traffic and searching across endless threads just like this one trying to work out why Sonos wasn't playing nice across VLANs.
When I set up version 2 of my UniFi network (complete tweet thread here), I kept the IoT SSID but never bothered with the VLAN. It made it easy for all the existing devices to jump onto the new network (I used the same password from the v1 network) and it gives me the option to segment traffic later on. It also gives me the option to easily put it all on a different subnet later on, for example if I genuinely get to the point of IPV4 exhaustion on the 192.168.1.0/24 subnet. (Sidenote: even this can be painful as the native apps for many IoT devices want to join them to the same SSID the phone running the app is on so I found myself continually joining my iPhone to the IoT SSID before pairing... then forgetting I'd done that and later wondering why my phone was on the IoT network! It's painful.)
Getting back to network compatibility, whilst Ubiquiti's UniFi range will happily support this approach, AmpliFi won't. To the best of my knowledge, most consumer-focused network products won't and why would they? Can you imagine your parents VLAN'ing their IoT things? It's painful enough for me! We need to think differently.
Let's just take a slice out of out of the Wikipedia definition:
The main concept behind zero trust, is that networked devices, such as laptops, should not be trusted by default, even if they are connected to a managed corporate network such as the corporate LAN and even if they were previously verified.
It's become a bit of a buzzword of late but the principle is important: instead of assuming everything on the network is safe because you only put good things on the network, assume instead that everything is bad and that each client must protect itself from other clients. It's akin to moving away from the old thinking that all the bad stuff was outside the network perimeter and all the good stuff was inside. That logic started eroding as soon as we had floppy disks, went quickly downhill with USB sticks and is all but gone in the era of cloud. We've been heading in this direction with enterprise security for years, now we also need to adopt that same thinking in the home.
A good example of the importance of this brings me back to the TP-Link plugs I mentioned earlier. Remember, the one with the security flaw which was patched and then broke the HA integration? Just last month, Which? did a review on smart plugs and found the following:
A critical flaw we found in testing meant that an attacker could seize total control of the plug, and of the power going to the connected device. The vulnerability is the result of weak encryption used by TP-Link. The attacker would have to be on your wi-fi network to do the hack.
The whole premise of an attacker already being on your network is precisely why zero trust is important. Somewhat ironically though, I suspect that whilst on the one hand the TP-Link situation is viewed as a vulnerability, the ability to connect directly to it on the local network is probably what made the HA integration feasible in the first place! In other words, one person's vulnerability is another person's integration 😎
When we put this into the context of your average consumer, it means that stuff just needs to work out of the box. The Windows machine should be resilient to a connected IoT vacuum cleaner gone bad. The personal NAS shouldn't be wide open to a connected sous vide turned rogue. Consumers can't configure this stuff nor should they, rather we need to do a better job as an industry of making IoT devices resilient to each other.
I appreciate this isn't concise "do this and you'll be fine" advice, but it's where we need to head in the future, and I'd be remiss not to push that view here. Let's look at one more related topic - TLS.
Transport Layer Security
Our view of SSL or HTTPS or TLS (and all those terms get used a bit interchangeably), has really changed over the years. Once upon a time, it was the sole domain of banks and e-commerce sites and it meant you were "secure" (Chrome literally used to use that word). The good guys had it, the bad guys didn't. In fact, most websites didn't have it but these days, it's quite the opposite; most websites do serve their traffic securely regardless of the type of business they are. The growth has been driven by the free and easy availability of certificates, largely due to the emergence of Let's Encrypt in 2016.
As it relates to IoT, let's look at it in 2 different ways:
- Devices talking to hosted services over HTTPS
- Devices hosting services that could support HTTPS
The first point is a bit of a no brainer because all the certificate management is done centrally by, say, Amazon for their Echo devices. Every time one of the kids asks Alexa a question, a TLS connection is established to Amazon's services and they get the benefit of confidentiality, integrity and authenticity.
The second point is trickier because we're talking about a whole bunch of devices in the house running web servers and talking HTTP. For example, my UniFi network centres around their Dream Machine Pro device and Scott has written in the past about how to set up HTTPS on the UDM. He's also done the same thing with his Pi-hole. HA has a Let's Encrypt add-on. Increasingly, we're seeing IoT things support HTTPS which is great, and it goes a step further in taking us towards that zero trust principle, but it's not all that simple...
Every Shelly I have in the house has its own little web server and I connect to it locally via IP address... over HTTP. An adversary sitting at the network routing level (i.e. on one of my switches) would be able to observe the traffic (no confidentiality), modify it (no integrity) or redirect it (no authenticity). Beyond a cursory Google search that returned no results, I haven't even begun to think about the logistics of installing a cert on a Shelly let alone the dozen other Shelly devices I have in the house.
Out of curiosity, I asked this question earlier today and got a response from Paulus just before publishing this blog post:
For Shelly we use a mix of HTTP (settings, control) and CoAP (state). Neither is encrypted.— Paulus Schoutsen (@balloob) November 25, 2020
I think the way IKEA does CoAP is neat. Bottom of gateway is a key / QR that can be used to generate an access key. Then use DTLs for encryption.
Reading through the responses to my original question, the resounding feedback was that when it comes to IoT communicating inside home networks, people weren't too concerned about a lack of transport layer encryption. I can understand that conclusion insofar as the LAN is a much lower risk part of the whole IoT ecosystem. I'd like everything to be sent over a secure transport layer (perhaps per Paulus' IKEA suggestion), and certainly any devices acting as clients communicating with external servers should be doing this already, but inevitably, there will be gaps.
There are, however, some very practical, very common-sense things we can do right now to improve the security posture of our IoT things so let's finish up by talking about those.
Security goes well beyond just digital controls, indeed there are many ways we can influence our IoT security posture simply by adjusting the way we think about the devices. I want to break this down into 3, common-sense approaches:
1. You cannot lose what you do not have: This is an old adage often used in a digital privacy context and it's never been truer than with IoT. Headlines such as Stranger hacks into baby monitor, tells child, 'I love you' are a near daily occurrence and there's a sure way to ensure a hacker doesn't end up watching and talking to your child: don't put a camera with a mic and speaker in their bedroom! Right about now, a small subset of my readership is getting ready to leave angry comments about "victim blaming" and I'll ask them to start with a blog post from almost 5 years ago titled Suggesting you shouldn’t digitise your sexual exploits isn’t “victim blaming”, it’s common-sense. The point in all these cases isn't to say someone is "wrong" for using a connected baby monitor or making kinky home movies, rather that doing so increases the chances of an otherwise private event being seen by others. Do your own assessment on whether you're willing to take that risk or not.
As it relates to my own approach to IoT, all cameras I have point at places that are publicly observable. (The only exceptions are inside my garage and my boatshed, both places where nothing happens I wouldn't be comfortable with the public seeing.) My worst-case scenario if my cameras are pwned isn't the exposure of my kids to strangers or an intimate moment with my partner, it's only publicly observable activity.
Using features such as Ubiquiti's privacy zones on their Protect cameras also helps:
Those black boxes are recorded onto all video the camera captures and shield both the master bedroom and the pool from view should someone obtain the video. If an adversary gained full control to the UniFi Protect server then yes, they could remove the privacy zones, but that would only apply to future videos and only until I cottoned on to something being wrong.
2. Be selective with what you connect: This whole journey began with me trying to automate my garage door, which I eventually did. But I actually have 2 garage doors with one leading to what could more appropriately be called a carport (a covered area inside the property boundary) and the other then leading inside the house. It looks like this:
I've divided this into risk zones and the reason the upper area is low risk is that it's easily accessible. There's a wall around the house behind those green palms, but it can be jumped. That door is internet connected and it allows me to remotely open it so couriers can drop off packages or I can easily ride my bike back inside the property boundary (I just ask Siri on my watch to open it up). The higher risk zone contains things like bikes, wakeboards and life vests (not to mention my beer fridge!) I've not connected that door as it presents a greater risk and provides less upside if connected than the external door thus is harder to justify being IoT enabled.
The point here is that I'm effectively doing my own little risk assessment on each IoT device, and you can too. What upside does it bring you? What downside does it present? How likely is that to happen? And finally, what's the impact if it does? Easy 🙂
3. Choose who to trust: I'll give you a real-world example here, starting with this tweet:
Helping some friends out who are looking for a connected doorbell, what's the best option these days? Main thing is support for a chime box inside the house (also required) plus the usual video and audio to mobile devices.— Troy Hunt (@troyhunt) October 19, 2020
The back story to this was that I'd just installed Ubiquiti's AmpliFi ALIEN unit at this friend's house and in doing so, set up a brand new network with new SSID and subsequently set about migrating all the connected things to the new one. Everything came over just fine... except the doorbell. I have absolutely no idea who made that doorbell; it seemed to be a cheap Chinese model with very little documentation and no clear way to join a new network. I was stumped and the doorbell was kinda crap anyway thus the tweet above.
Now, if I had to choose between trusting that old doorbell with the ones suggested in that thread (namely Ring, Nest and Ubiquiti), it's an easy decision. These companies invest serious dollars in their security things in just the same way Amazon does with their Echo devices. Why mention Echo? Because people often ask if I trust them given I have one in each kids' room. Now that's a binary question with a non-binary response because trust is not as simple as "completely" or "not at all", it's much more nuanced. What I know about each of the multi-billion dollar tech companies mentioned here is that they have huge budgets for this stuff and are the most likely not just to get it right in the first place, but to deal with it responsibly if they get it wrong.
But a caveat: Nissan is also a huge company with massive budgets and they made an absolute mess of the security around their car. It doesn't surprise me that CloudPets and TicTocTrack made the mistakes they did because they're precisely the sorts of small organisations shipping cheap products that I expect to get this wrong, but clearly organisation size alone is not a measure of security posture.
There will be those who respond to this blog post with responses along the lines of "well, you really don't need any of these things connected anyway, why take the risk?" There's an easy answer: because it improves my life. In the final part of this series I'm going to do video walkthroughs of a whole bunch of different ways in which I benefit from my connected environment, showing how each connected thing operates. I like my IoT devices and in order to reap the benefits they provide, I'm willing to wear some risk.
Coming back to a recurring theme from this series, the security situation as it relates to normal everyday people using IoT devices isn't great and I've given plenty of examples of why that's the case. I also don't believe the approaches taken by enthusiasts solves the problem in any meaningful way, namely custom firmware, blocking device updates and creating VLANs. It's fiddly, time consuming, fraught with problems and most importantly, completely out of reach for the huge majority of people using IoT devices. We need to do better as an industry; better self-healing devices, better zero trust networks and better interoperability.
Finally, and per the last couple of blogs in the series, Scott and I will be talking live about all things IoT (and definitely drilling much deeper into the security piece given the way both of us make a living), later this week via this scheduled broadcast 👇
In part 1, I deliberately kept everything really high level because frankly, I didn't want to scare people off. I'm not ashamed to say that the process of getting even the basics working absolutely did my head in as I waded through a sea of unfamiliar technologies, protocols and acronyms. I wish I'd had just the fundamentals down pat before going deeper and that was my intention with the first part of the series.
So, peeling back that next layer, the whole IoT space isn't just about devices that get their own IP address on your network and talk over TCP (or UDP). Many of them do (such as the Shelly switch in part 1), but then there's the whole Zigbee space as well. Let's drill into all that and then go deeper into custom firmware and soldering too.
IoT and IP Addresses
So, what happens when you start filling your home with IoT things? You end up assigning a lot of IP addresses; here's what it looks like in Ubiquiti's UniFi dashboard:
Clearly, I have a long way to go before exhausting available IPV4 addresses on this subnet so that's not something that worries me right now. Plus, all my IoT devices are on their own Wi-Fi network and it'd be dead simple just to start assigning those devices IPs from a different subnet (more on that in part 3 about security). IPV6? It's rare to see in IoT devices today, but there are many compelling reasons that make a lot of sense to see broader support in the future.
For the most part, the IoT devices in my home simply take their IP address from the DHCP server and I never think about it again. There are, however, occasions where you end up getting tied to specific IP addresses. For example, here's how the downlights in my office are configured in HA courtesy of the Wiz integration:
Then, one day, the lights stopped working. Why? They worked fine in the native Wiz app, why were they dead in HA? Back into the UniFi dashboard, down to the Wiz lights and... ah:
Because they're dynamically assigned an IP address, at some stage the lights had restarted and got themselves new ones. The fix, however, was easy:
I got to thinking more about IP address reservation (which is what you see above where the same IP is always assigned by the DHCP server) versus static IP address (where the IP is set in the client itself), after having to totally rebuild my network. (If you're interested in what happened, I covered it in detail in weekly update video 216.) There's a good overview of the two approaches here but in a nutshell, central management is always preferable. It means it's very easy to jump into the UniFi dashboard and get a quick list of all the fixed IP addresses in the network (it's under "Insights"):
The kids' Nanoleaves also use reserved IPs because like the Wiz lights, the HA integration needs a hard-coded IP address for the device. Having easy access to configurability such as this at the network layer is really essential, so let's delve into that network layer and talk about good gear.
Good Network Gear is Essential
As you're probably starting to gather from this series (and you'll see more of this as it progresses), you find yourself spending a lot of time troubleshooting problems. Why can't I see a device? Why can only some clients see a device? Why is the device slow to respond? Why have I started drinking so much since beginning my IoT journey? Having good visibility into my network configuration has been absolutely essential in helping answer those questions.
I've been a vocal proponent of Ubiquiti's gear for many years now and it's an absolutely essential part of my IoT world. (Disclosure: I bought every piece of equipment in that original blog post. Since then, they've sent me a bunch of gear.) For example, when I look at my network topology today, I can easily see everything that's connected to everything else:
I've named each and every device I've added to the network and given it a descriptive icon so that at a glance, I can get a really good idea of how everything is tied together. I can easily block a device from talking to the internet, throttle its connection, see which online services it's communicating with and access a whole host of other information about it. For example, just today I was trying to identify one pesky device I hadn't named earlier on and now had no idea what it was:
Trying to figure out what a client I'd previously connected to my network is. I put it on my IoT network, it's connected to my Office AP and it's running Linux and downloading data from Amazon and Spotify, ideas? pic.twitter.com/PE3eVLseFY— Troy Hunt (@troyhunt) November 24, 2020
Turns out it was my daughter Elle's Amazon Echo Dot.
The Wi-Fi network is the foundation on which the IoT network is built. Investing in that was the best thing I could have done in advance of joining all the things to my network. But not all IoT is IP-based, far from it. Let's jump into Zigbee.
Alrighty, first things first: It's Zigbee, not ZigBee. I'm a stickler for details like this and it was driving me nuts seeing both stylisations all over the place but as of 2017, the "b" is lowercase (because I'm a stickler I kept scrolling back through zigbee.com on archive.org until I worked out when it changed). The Zigbee standard is maintained by the Zigbee Alliance, a group of companies responsible for shepherding it in the right direction. Zigbee uses the IEEE 802.15.4 standard and it's worthwhile understanding why, especially as compared to having devices just communicating directly over Wi-Fi:
IEEE standard 802.15.4 intends to offer the fundamental lower network layers of a type of wireless personal area network (WPAN) which focuses on low-cost, low-speed ubiquitous communication between devices. It can be contrasted with other approaches, such as Wi-Fi, which offer more bandwidth and require more power. The emphasis is on very low cost communication of nearby devices with little to no underlying infrastructure, intending to exploit this to lower power consumption even more.IEEE 802.15. 4 is a low-data rate wireless personal area network and is the PHY and MAC layer used by many IoT protocols, such as ZigBee, and WirelessHART.
In other words, the value proposition is low power consumption and low cost at the expense of bandwidth. But that's just fine for devices like this:
Just had a Mi temp and humidity sensor arrive for the IoT stuff I’m doing. Really neat size, it’d be easy to place a bunch of these around the house, yet to see it actually work though... pic.twitter.com/yjgtR87DUo— Troy Hunt (@troyhunt) June 7, 2020
In fact, it's perfect for devices like this because they can be battery powered (they run on a standard CR2032) and get a couple of years of life and they only need to transmit a few simple values at a relatively low frequency.
Let me divert on a quick tangent for a moment: Zigbee isn't the only low-power, low-bandwidth standard out there and as I went through my travels, many people also suggested various Z-wave devices. I went all in on Zigbee primarily because the Aqara devices are great (more on them soon) and I already had Philips Hue units I could use as range extenders (more on that soon too). I may well end up with Z-wave devices in the future as well and I'd be remiss not to mention them here, but at present I haven't needed to diversify beyond Zigbee.
But Zigbee ain't Wi-Fi so you can't just buy a little device like the one above and connect it to an existing network, it needs a hub that can talk 802.15.4 to do that and suddenly, we're back into proprietary land again. For example, both the little temp sensor above and the motion sensors I discussed in part 1 are made by Xiaomi and I could always buy the Aqara Hub and connect them up:
But then what about other Zigbee devices from other manufacturers? For example, I've got a bunch of Philips Hue lights in the house and they run over Zigbee, do I really want to end up with a Philips Hue hub (which I actually already had and has an HA integration) plus an Aqara hub (which also has an HA integration) plus whatever other devices I end up with and their own hubs as well? Not really, which brings me to the ConBee II Zigbee sniffer.
ConBee II, The Universal Zigbee USB Gateway
HA alone can't read from Zigbee devices and as already discussed, they also can't drop directly onto your Wi-Fi hence the need for a hub. What folks tend to do is go for a "CC2531 stick" which can "sniff" Zigbee traffic. CC2531 is a chipset made by Texas Instruments (check the date on that resources, this goes back over a decade) that appears in a whole heap of cheap units sold as "Zigbee sniffers". But there was one particular model that came up time and time again after I posted that earlier tweet with the temp sensor; without prompting, many people directed me to the ConBee II, a little USB stick with a CC2531 chip that can talk IEEE 802.15.4 and implements the Zigbee protocol. See how that ties all these new things together? 😊
Here's the unit:
The ConBee II is produced under the Phoscon brand, a name I mentioned back in part 1 in relation to the deCONZ integration. I picked one up off Amazon for A$78, plugged it into the USB port of the Raspberry Pi running HA then configured it all by following this great guide which takes you through the entire journey. When I went through that process only 6 months after that post was written, there were quite a few bits that were out of date (namely where things are located within the UI), but it was still easy to follow. Once done, all the mechanics are now there to join up all the respective bits of the Zigbee network:
The next problem is that in my case, I ended up with a single USB sniffer stuck into a Raspberry Pi inside a server rack inside a large walk-in cupboard inside a garage at the bottom of a large 3-story solid brick construction house. You can guess what comes next...
Extending Zigbee Range with Repeaters
In fairness to the ConBee II, it did an admirable job under the circumstances and indeed its range is a big selling point:
Thanks to its power-amplifier, the ConBee II has an outstanding range. This lets the signal pass through 2–3 rooms or floors, depending on the construction type.
But it wasn't enough. I continually found temp sensors (which I now had in every single room) not being available so clearly something had to give. Fortunately, one of the joys of Zigbee is that - and I'm going to quote here - "all mains powered Zigbee devices, such as lights and sockets, act as repeaters and can route the signal". This is again from the Phoscon page on the ConBee II which they illustrate as follows:
This creates a mesh network enabling you to expand the Zigbee range as more (mains powered) devices are added. That's all good in theory but in practice, well, let me just drop a discussion I had with my good mate Scott Helme in right here as he was going through his own HA build:
I wanted to include this discussion in its original candid state because it perfectly illustrates the frustrations I raised in part 1: this is still a "maker" world where even people who live and breathe tech day in and day out continue to hit hurdles. I found multiple references around the web about the IKEA repeaters not playing nice with Xiaomi devices, yet when I looked at my own Zigbee network, I saw this:
I can see plenty of devices connected to "Range Extender 1" in the garage! But no devices connected to "Range Extender 2" in the master bedroom. There are too many devices spread out over too large an area for this to be a mere coincidence, is it simply that one range extender doesn't want to connect and one does? I've ordered another couple just to see what happens, but I continually get the feeling that this whole effort raises more questions than it answers...
A quick sidenote on those Philips Hue devices in the Zigbee map above: per my discussion with Scott, I had to unpair them from the Hue Bridge and then pair them in deCONZ just like all the other Zigbee devices. Consequently, I can no longer use the Philips Hue app to manage, say, the two Hue Go units on my desk. As I said in part 1, the native apps are often richer in functionality than what HA provides and that's the case here too. I have several Hue light strips around my fireplace, one behind my TV and one behind the perimeter of a massive mirror in my entertainment room. I want the family to be able to manage these directly via an easy to use app hence I haven't moved them over to deCONZ. That means they don't form part of the Zigbee mesh network in the image above, but they're also in locations where there's plenty of coverage already. My office really needed more coverage (it's several floors above where the ConBee II is located) and it's only me who manages them hence their presence on the deCONZ network.
One final thing on the whole Zigbee piece: I'm seeing a lot of feedback about people having problems with deCONZ and switching over to ZHA instead:
Hi Troy just read your post.— Dementor 🇮🇱 (@the_mentor) November 23, 2020
Really cool stuff.
You should know that you can switch from deCONZ to native ZHA integration imo it works much better and makes the integration much better.
I did the switch a few months ago and it's been great only downside is you need to pair again.
The Zigbee Home Automation ("ZHA") integration seems to be quite highly regarded and if I'm honest, I've had a lot of problems with deCONZ. When I look at it within HA now, there's a bunch of devices that have lost the carefully crafted names I provided them with when originally pairing them:
This happens over and over again and to be honest, I just need to bite the bullet, kill deCONZ, set up ZHA and manually re-pair every single Zigbee device in the house 😭 To be clear, this isn't breaking the HA references to the devices in any way, it just screws up their representation within deCONZ and subsequently, the earlier network map as well.
But for the most part the Zigbee stuff has been great, especially those Xiaomi Aqara devices. Let's drill into them now.
I want to devote a section of this post specifically to Xiaomi Aqara as these are great little devices that I now have all over the house. Before I get to the devices themselves, a bit of disambiguation around the names you'll see used here:
- Xiaomi is the Chinese company that makes the gear
- Mi is an abbreviation of their name (their website is literally just mi.com)
- Mijia is a brand name owned by Xiaomi (you would have seen it on the Aqara hub image earlier on)
- Aqara is a brand name owned by Xiaomi
Bottom line: Aqara is the name you'll see me using here as that's what's on the devices I've been buying (plus I can spell it more reliably than Xiaomi!) They're cheap, reliable and in my view, pretty slick looking little units. Earlier in this post I showed one of the temp sensors (pro tip: the round ones are an earlier generation, the square ones are newer and also do air pressure as well as temp and humidity), and in part 1 I showed the motion sensors which trigger lights when it's dark. Beyond those, I've used a number of proximity sensors so I know when doors are open or shut:
In part 1 when I showed my Apple Watch opening the garage door, this is achieved by defining a cover in HA. A cover, uh, "covers" stuff so blinds, shutters and garage doors, for example. When you think about a cover like a garage door, there's really 2 things you want visibility or control over:
- Is it open or shut
- Open or shut it
The proximity sensor answers the first point and the Shelly from part 1 answers the second point. Combined, they enable me to glance at my watch, see the state of the garage door and then change that state.
I also picked up a few Aqara buttons to do, well, anything:
IoT button. What does it do? Absolutely anything I want 🙂 pic.twitter.com/wXxsdPsXFo— Troy Hunt (@troyhunt) October 27, 2020
These are simple triggers that can be used in automations. For example, I have one at the bottom of my stairs that can turn off a bunch of lights with just a single click. Those lights normally come on just before sunset but if I want to manually turn them on, that's just a double-click on the same button. Neat!
And inspired by others, I even attached a vibration sensor to my letterbox:
Get mailbox notifications in 4 easy steps: 1) Get a @AQaraSmarthouse vibration/movement sensor 2) add it to your local #ZigBee network 3) attach it to the mailbox 4) add some automation to @home_assistant so you get a notification every time there's movement! #homeautomation pic.twitter.com/tP9pg7lzu1— Pedro Lamas (@pedrolamas) July 7, 2019
There are plenty of Zigbee devices out there, but I wanted to call out Aqara in particular as they've just been so damn reliable. Only once have I had an issue with any of the couple of dozen devices I have in the house, and that was just the letterbox vibration sensor shipping with a near-flat battery.
I put a temp sensor in each room right at the beginning of my HA journey. It was simple, cheap and immediately gave me useful data I could start doing stuff with:
So pro tip: if you want to get into HA and IoT in a meaningful way, start here and work up. Those temp sensors are cheap, useful and give you a means of dipping your toe into the IoT water in a pretty low-friction way. Chuck in some motion and proximity sensors and there's a bunch of stuff you can do right away without spending much.
Let's now move onto something completely the opposite of low-friction and get our hands much, much dirtier.
Flashing Custom Firmware and Soldering
I propose that we all need to find our own paths in terms of just how dirty we want to get our hands when playing with IoT. For many, the whole idea of running a Raspberry Pi with community driven software you configure with YAML is a step too far. For others, it's just the beginning with many people going down the path of, per the heading above, flashing custom firmware onto devices and soldering wires. In fact, this is the path I was originally going to head down for my garage door by following this video:
I bought all the bits, downloaded the firmware flasher, wired it all up per the instructions yet still, found myself lost:
Need some debug help with Sonoff SV and Tasmotizer: boards seem to be wired up properly, serial converter LED comes on, Sonoff is powered on with reflash button held, COM port is correct yet Tasmotizer can't see the Sonoff. Anything obvious wrong? pic.twitter.com/DByJqCEKDQ— Troy Hunt (@troyhunt) August 24, 2020
I then discovered that contrary to the instructions, RX shouldn't go to TX, it should go to RX and right there at that moment, I'll be honest: I lost my shit. Why is this so hard?! Why do I need to modify the firmware of such a simple little device?! And why do I then find myself holding a burning soldering iron just to open my freakin' garage door?!
To be fair to the folks that enjoy living in this world, I can see the attraction and I have great respect for those with the skill and patience to take this path. Tasmota is enormously popular open source firmware designed for ESP8266 devices which is the chipset many IoT products run (including a bunch of the lights in my house). But for me, it's a step too far and an unnecessary one at that given how easy it eventually was to achieve the same result with a Shelly that requires no custom firmware, no soldering and has no exposed circuitry:
Slick 😎 pic.twitter.com/QT0hM9XPYp— Troy Hunt (@troyhunt) August 26, 2020
The most complex part of this entire approach was reading the garage door opener manual and referring to the terminal block on the back of the unit:
And per the manual:
O/S/C INPUT is used for the connection of a wired switch (momentary contact). This switch can then be used to open, stop or close the door.
All the garage door automation needed to do was close the circuit between the COM and OSC terminals via the Shelly which is then powered via the 24V terminal. The point I'm trying to make is that there's a heap that can be done without going down to the custom firmware and soldering layers and I wish I'd known that before I got started. This, to my mind, is the "happy path" I referred to in part 1.
This post mostly boils down to "have a decent network, get Aqara Zigbee devices and avoid custom firmware and soldering unless you really want to go in that direction". It feels obvious now to summarise it so succinctly, but it took a lot of trial and error to reach those conclusions. Tomorrow in part 3, it's time to talk about security and oh boy, there's a can of worms right there!
Lastly, and as I mentioned in the conclusion to part 1, Scott and I will be doing a live stream on Friday where we discuss how we've both approached the whole IoT piece. It'll be candid, direct and we'll definitely be taking questions too so come join in then via the video below 👇
With the benefit of hindsight, this was a naïve question:
Alright clever IoT folks, I've got two of these garage door openers, what do you reckon the best way of connecting them with Apple HomeKit is? https://t.co/i0RmjSMkkD— Troy Hunt (@troyhunt) April 25, 2020
In my mind, the answer would be simple: "Just buy X, plug it in and you're good to go". Instead, I found myself heading down the rabbit hole into a world of soldering, custom firmware and community-driven home automation kits. Finally, a full 123 days later, I managed to open my garage door with an app:
Smashing it today! So impressed with the Shelly 1, it made this so simple 😊 pic.twitter.com/miD8WdfUvM— Troy Hunt (@troyhunt) August 26, 2020
What follows is my journey down that very deep, very dark rabbit hole from which I thought I'd never emerge. Every time I thought I had an answer, it raised 2 more questions. I had to buy new gear, learn new acronyms and work with things I'd never heard of before. I waded through endless online discussions with strong opinions expressed in frequently conflicting directions about things I thought would be simple. Never before have I headed down a technology path that, frankly, is such a fragmented mess.
I added to this blog post as I progressed with a view to ultimately having a "happy path" for others to follow in the future. Instead of a single post, I ended up with a 5-part epic which I'll post piece by piece over the course of this week with the hope that others can follow along and eventually, with enough time and patience, be able to open their garage doors too.
Everybody Wants to be "The IoT Solution"
This is where the whole mess starts: what is the hub of your IoT world? In my original tweet above, I thought it would be Apple's HomeKit which seemed like a reasonable assumption given my family's dependencies on iPhones, iPads, Apple Watches and with an Apple TV in the house. Those in an Android world might reasonably assume that Google Home would be their hub. Others might assume it'd be something Alexa related. But no, every one of those answers is wrong because every single one is a proprietary ecosystem with fragmented support by different devices and a kludge of vendor lock-in. Take this as an example:
Stuck inside and not allowed out? Nerf gun wall!— Troy Hunt (@troyhunt) April 9, 2020
LED strip lights are Arlec from Bunnings at A$60 for 5m. Controller app plus Alexa integration so next step is full voice control 😎 pic.twitter.com/8mP2G3CM3t
Now firstly, the Nerf gun wall is freakin' epic! But secondly, that Arlec LED strip Ari is attaching to the back of the wall runs on the Grid Connect ecosystem which includes support for:
Google and Amazon. That is all. No HomeKit. In fact, HomeKit was often the odd one out when I looked at IoT products and I can imagine someone explaining it away as Apple demanding things be done the Apple way or the highway hence the lack of compatible devices. And this wasn't a typo on the Grid Connect website:
It's not just the big players either; you'll find all sorts of lesser-known brands wanting to be the hub of your IoT world. During this whole exercise, I decided I needed to replace the receiver in my home entertainment setup as it wasn't powerful enough to drive the speakers I have. So, I'm in at the home theatre shop and I see this beautifully made universal remote control:
This lovely, brushed aluminium unit is made by Control4 and guess what? They can be the hub of your smart home! Oh - but it's not self-configurable and you need a licensed installer to set it all up for you 🤦♂️
Which brings us to Home Assistant or for the sake of brevity, HA.
This feels like a fair place to start:
But it's also slightly disingenuous because whilst on the surface it may look like yet another solution to the same problem, it's philosophically different in several key ways:
Open source home automation that puts local control and privacy first. Powered by a worldwide community of tinkerers and DIY enthusiasts. Perfect to run on a Raspberry Pi or a local server.
The Apple / Google / Amazon solutions are all proprietary and tied very closely to the respective tech behemoths' commercial offerings. They want people on their platforms, using their clouds and buying their products. HA, on the other hand, doesn't care who made what or which devices you have or whose clouds you're on, it just wants to tie it all together in a meaningful way. It's an extremely active open source project typically (but not exclusively) run on a Raspberry Pi with a goal of integrating all of your things and keeping them self-contained within your own home rather than being dependent on public cloud services. It has amazing community support and a very devoted fan base which has helped catapult it into one of the top open source projects on GitHub. However...
The learning curve is steep, it has a bunch of rough edges (it's still not reached a v1 as of the time of writing), you end up living in YAML and by any reasonable measure, it's only usable by geeks who are happy living in a world unfamiliar to most mere mortals. Fortunately, that includes me and despite the "maker" nature of the whole thing, I'm massively impressed with HA and nothing else I've seen along my IoT journey comes even close to comparing. If you're going to do IoT in any meaningful way, you start with HA.
The thing is though, you need to be ready to get your hands really dirty:
Is phoscon running in a docker container? If so you'll likely need to use vnc to connect to the container to get to the phoscon UI to remove the device from there.— Phil Ermiya (@PhilErmiya) June 18, 2020
Then remove the integration from HA, then readd it. It might need a tidy up in HA config files if it gets orphaned.
I captured this tweet and dropped it into the draft blog post as I was lamenting just how damn hard it was to make simple things work the way I wanted them to. But I don't want to get anywhere near that level of detail in this blog series as it'll just scare people off, let me instead focus on the basics and provide enough background to get people heading in the right direction, starting with the fundamental principles of what makes HA great.
Integrations, Devices, Entities, Automations and Scenes
When I'm explaining this to people, I put it like this:
HA integrates with other devices and services which it can both use as triggers and perform actions on.
For example, just to jump straight to the conclusion for a moment, I now have a bunch of little motion sensors around the house that can turn lights on:
Now entering the next phase of my IoT buildout with Xiaomi Aqara motion sensors spread around the house to trigger lights on or off based on movement. These are Zigbee based with a 2 year battery life and include light sensors as well. Cool 😎 pic.twitter.com/XLIPyNz5Ej— Troy Hunt (@troyhunt) October 6, 2020
This is achieved firstly, by using an integration that can communicate with the sensors and in this case, it's deCONZ which is a product under the Phoscon brand made by Dresden Elektronik (hence the "de" in deCONZ):
I've left other integrations in the screen cap above to give you a sense of some of the other things HA can communicate with: Alexa, WeMo switches, Elgato key lights and many other connected devices in my house. At the time of writing, there are 1,713 different integrations including... a Have I Been Pwned Integration!
The deCONZ integration enables communication with Zigbee devices (more on that in part 2) and per the screen cap above, I presently have 35 of those in my house. One of them is the first motion sensor in the earlier tweet which, in HA, looks like this:
The motion sensor is a device I placed at the bottom of the stairs in my house which spans 3 floors. I have another motion sensor halfway along near the kids' room and another again at the top near our master bedroom. These motion sensor devices each have 3 different entities:
- The amount of light they can currently see
- A battery level
- Whether or not there's currently motion detected
This nomenclature threw me a bit at first but it makes sense: one physical device you can hold in your hand may measure many different things and each one of those things is considered to be an entity (entities aren't just about measurement but let's use that as a simplistic example for the moment). I have little temperature sensors in each room and each one of those devices can measure humidity, pressure, temperature and has a battery state:
Yet another device I now have all over the house is an IoT relay called a Shelly, two of which you can see in the tweet below (they're the little blue units amongst all the wires):
This is fine... pic.twitter.com/6Q6AxLfyVv— Troy Hunt (@troyhunt) September 3, 2020
Yes, this is pretty normal Aussie wall socket wiring. No, we don't use gang boxes. Yes, I'm conscious you do things differently in other parts of the world. Moving on, each Shelly has a single entity which is simply a power switch:
So, now we have all the mechanics required to tie together automations and as you can see in the screen cap above (and in the earlier one that shows the stairs motion sensor), I have 2 automations using these devices. I'm not going to go anywhere near the YAML involved in this blog series, let's instead focus on the logic:
- If motion is detected at the bottom, middle or top of the stairs and the light level down the bottom is beneath 200 lumens, turn the Shelly on the light switch on
- If all 3 motion sensors haven't detected any motion for the last 5 minutes, turn the Shelly on the light switch off
And that's it 🙂
But that automation just turns on a single light, what if I wanted to turn on more lights? Or play music? Or set other device statuses, all at the same time? This is where we get to "scenes" which allow you to define multiple pre-set states that can all be switched on in one go. For example, Ari wanted a fast way to get all his lights back to the same state he referred to as "cool", so we made a scene that turned on a bunch of lights and set the nerf gun wall to red:
That scene can be trigged by various events, including automations. We'll come back and look at that again shortly but for now, let's talk about how all those lights work in the first place.
Interfacing with Devices: Different Brands, Same Stuff
Ever get an odd sense of déjà vu when you see a product under a certain brand and you could swear you'd seen it somewhere before, but just different? I had that recently when I drove a friend's Tesla Model X and the indicator stalk felt just like the one in my Mercedes. Turns out that because it is just like the one in my Mercedes with the US brand using a bunch of parts from the Germans.
And so it is with IoT bits too:
Anyone know what's involved in making Grid Connect lights play nice with @home_assistant? These are the units, got a heap of them in the kids' rooms and they already integrate with Alexa and Google Assistant: https://t.co/xJKdtzJKED— Troy Hunt (@troyhunt) July 19, 2020
Earlier on I mentioned I'd bought the Grid Connect lights (which are manufactured by Arlec) to put behind Ari's Nerf Gun wall. They were cheap (at least compared to something like Philips Hue), RGB (not just different shades of white) and could talk over Wi-Fi (not just controllable via a remote). The Grid Connect app worked fine but as I also mentioned earlier, there's no way it'd work with Apple's HomeKit and based on feedback to the tweet above, nor were there any integrations with HA. But there was another option:
These are based on an off the shelf Tuya ESP8266 module. Either use the Smart Life or Tuya apps instead of the Grid Connect one - HA has an integration to their cloud based web service. Or flash them with different firmware - Tasmota and ESPHome are the main options— Chris Ford (@chrisfordoz) July 19, 2020
Ok, that's actually several different options but let's just focus on Tuya first because that's the easiest path. Tuya is "the World's Leading IoT platform" (yay, another platform 🤦♂️) and per the above tweet, they ship products that run a ESP8266 chip which is a pretty common piece of kit. Consequently, I could pair that Grid Connect light strip with the Tuya app which... then says Arlec!
Later on, I bought a heap of RGB downlights from Oz Smart Things:
MORE IPS!!! pic.twitter.com/whQUziITtr— Troy Hunt (@troyhunt) September 3, 2020
Turns out these are also Tuya compatible so now, without directly buying a single Tuya product, I have a lot of products running in the Tuya app:
What that means is that it's dead easy to control things such as the colour and the brightness:
Now, let's bring it back to HA for a moment and the value proposition here is that per Chris' earlier tweet, there's an integration that can bring these devices right into the same environment all my other IoT things are now in:
Ok, so far so good, now let's get to the twists in all this starting with how the same device looks in HA:
That looks fine now, but when I first added the downlights, I had no colour control. Power and brightness, yes, but no colour. It took some researching to realise that Tuya had killed colour control for a whole bunch of other people too and that the answer was to edit the customize.yaml file and for each Tuya entity, change the supported features to indicate colour control. I'm not even going to get into the mechanics of that here because that's not really the point of this series, rather I want to highlight how I kept running into "compatible but not completely compatible" scenarios like this.
So, now should I change the colour via the Tuya app or the HA website or app? In one way, it doesn't matter because the state is reflected the same in both (i.e. make it red in HA and the Tuya app shows it as red). In another way, I'm now in this vicious cycle of having more and more apps for specific IoT devices that whilst integrated with HA, still require the OEM app to do a heap of stuff. For example, the Nanoleaf app has a very specific set of controls:
These allow predefined scenes to be played on the light panels (something that can also be triggered by HA), but also very specific configuration such as what colour to make individual panels. AFAIK, that capability isn't built into the HA integration and even if it was, it's unlikely the experience in setting it up would rival that of the dedicated app.
The bottom line is that you inevitably end up with multiple different interfaces into the same device be they native interfaces provided by the device manufacturer or those exposed via the HA integration. But it doesn't end there either, because you still need to get those devices back into the other IoT hubs. Here's why:
Integration with Other IoT Hubs
Earlier on, I lamented that everyone wants to be the hub of your IoT world and that fortunately, HA can play that role in the place of one of the large incumbent tech companies. Mostly. The gap comes when you start using products from one of those companies that expect to communicate with IoT devices via their own proprietary product. For example, both my kids have an Amazon Echo Dot in their room. I put these in there in part because they're fun learning devices they can easily ask questions of (they can also ask "Alexa, who's Troy Hunt" and get an answer or, as I learned last night with my daughter, they can ask "Alexa, is Troy Hunt handsome" and get a resounding "He is handsome" 🤣), and in part to control their IoT-enabled devices. The latter can be done without even needing HA as Tuya natively integrates with Alexa and exposes all the devices:
But there are other things in HA which we might still want to access via Alexa, for example the "cool" scene I set up for Ari earlier on. To do that we need to surface data from HA into Alexa which can be done with the Amazon Alexa integration. Once configured, the scene appears and he can talk to the Echo Dot and ask Alexa to "turn on cool in Ari's room":
Just as there are reasons to surface HA into Alexa, there are also reasons to surface HA into Apple's HomeKit, a feat that can be achieved with the HomeKit Bridge integration. (Note: there is also Homebridge which is a different beast altogether.) We can now surface all the same devices into Apple's ecosystem:
Remember, that Nerf gun wall is running the Arlec LED strips that use Grid Connect surfaced through the Tuya app which all has no support for HomeKit yet here we are with control in HomeKit 😎
That extends all the way to Apple Watches too:
One of the primary reasons for doing this is that once you're in the Apple ecosystem you have Siri so now I can just raise my wrist and say "Hey Siri, open the garage door". Or if I'm in my car with Apple CarPlay I can issue the same command without even taking my hands off the wheel.
This does, however, create other problems especially when it comes to troubleshooting. Take a look at the hero image at the top of this blog post. Nice Nerf gun wall representing Ari's room as HomeKit sees it on my iPad, except... his desk power is showing "No Response". Huh, wonder if he accidentally unplugged it this morning? So I go into his room and no, he hasn't unplugged it because his neon-backlit keyboard is glowing and it's plugged into the USB hub connected to the TP-Link HS100 smart plug that's presently unresponsive. It's surfaced in HomeKit via the HomeKit Bridge integration in HA so I go into that device and the entity is disabled. If HA can't see it then HomeKit won't be able to see it. Ok, let's go further up the stack and now I'm in the native iOS Kasa app where the plug is both present and responsive to power on / power off commands which means it's on the network just fine. I stopped there because frankly, I got a bit pissed with the whole thing and just want to finish this blog post right now, but I've included this here to demonstrate just how many moving parts are required to make all this work. Just one of those moving parts stops and not only does it kill a part of your internet of things, but there's a good chance you'll be in for a lengthy troubleshooting session.
This all took me a while to wrap my head around, namely the fact that you can't escape the necessity to have multiple "hubs of all your things" and that they can all work together harmoniously... most of the time. It's not difficult, but it is fiddly especially when you end up with the same devices in HA as Alexa can natively talk to then you see dupes or you get to HomeKit and there's a zillion devices in there when you really only want a couple of lights. There are solutions to these problems, however, it just requires a little patience and a lot of tweaking.
I want to wrap up part 1 here because it's a nice finish before peeling back more layers of complexity. Get yourself a Raspberry Pi, install HA and add integrations for your existing devices, surface through your platforms of choice and you're off and running. But that's only the first step, in part 2 I want to start delving into the implications of all those IP addresses, the role of Zigbee, custom firmware and soldering and ultimately, finding my own happy path to how complex I wanted to make the whole thing.
Lastly, I'm going to devote my regular weekly update live stream to this blog series and do it in conjunction with my good mate Scott Helme whose been going through his own IoT journey. It'll be broadcast at 17:00 Gold Coast time for me this Friday which is 08:00 the same day in London and 23:00 Thursday evening on the US west coast. If you can't make the live stream, it'll still be available here afterwards:
5G and the IoT: A Look Ahead at What’s Next for Your Home and Community
October is Cybersecurity Awareness Month, which is led by the U.S. government’s Cybersecurity and Infrastructure Security Agency (CISA) in conjunction with the National Cyber Security Alliance (NCSA)—a national non-profit focused on cybersecurity education & awareness. McAfee is pleased to announce that we’re a proud participant.
Imagine it’s 20 years ago and someone at a dinner party predicts that one day you could pop down to the appliance store and buy an internet-connected fridge. Your year 2000 self might have shook that off and then then asked, “Why would someone ever do that?”
Yet here we are.
Today, so much is getting connected. Our appliances, security systems, and even our coffeemakers too. So far this month, we’ve talked about protecting these connected things and securing these new digital frontiers as Internet of Things (IoT) devices transform not only our homes, but businesses and communities as well.
To wrap up Cybersecurity Awareness Month, let’s take a look ahead at how the next wave of connected devices could take shape by taking a look at the network that billions of them will find themselves on: 5G networks.
5G is the key
You’ve no doubt seen plenty of commercials from the big mobile carriers as they tout the rollout of their new, more powerful 5G networks. And more powerful they are. For starters, 5G is expected to operate roughly 10 times faster than the 4G LTE networks many of us enjoy now—with the potential to get yet faster than that over time.
While mention of faster speeds continues to be the top selling point in ads and the like, 5G offers another pair of big benefits: greater bandwidth and lower latency. Taken together, that means 5G networks can host more devices than before and with a near-instantaneous response time.
The implication of these advances is that billions and billions of new devices will connect to mobile networks directly, at terrific speeds, rather than to Wi-Fi networks. Of those, many billions will be IoT devices. And that means more than just phones.
What will those devices look like?
One answer is plenty more of what we’re already starting to see today—such as commercial and industrial devices that track fleet vehicles, open locks on tractor trailer deliveries based on location, monitor heating and air conditioning systems, oversee supply chains. We’ll also see more devices that manage traffic, meter utilities, and connect devices used in healthcare, energy, and agriculture. That’s in addition to the ones we’ll own ourselves, like wearables and even IoT tech in our cars.
All together, we’ll add about 15 billion new IoT devices to the 26 billion IoT devices already in play today for a total of an expected 41 billion IoT devices in 2025.
Securing 5G and the IoT
Citing those examples of IoT applications underscores the critical need for safety and security in the new 5G networks. This is a network we will count on in numerous ways. Businesses will trust their operations to the IoT devices that operate on it. Cities will run their infrastructure on 5G IoT devices. And we, as people, will use 5G networks for everything from entertainment to healthcare. Not only will IoT devices themselves need protection, yet the networks will need to be hardened for protection as well. And you can be certain that increased network security, and security in general, is a part of our future forecast.
The GSMA, an industry group representing more than 750 operators in the mobile space, calls out the inherent need for security for 5G networks in their 5G Reference Guide for Operators. In their words, “New threats will be developed as attackers are provided live service environment to develop their techniques. 5G is the first generation that recognizes this threat and has security at its foundation.” When you consider the multitude of devices and the multitude of applications that will find their way onto 5G, a “square one” emphasis on security makes absolute sense. It’s a must.
While standards and architectures are taking shape and in their first stages of implementation, we can expect operators to put even more stringent defenses in place, like improved encryption, ways of authenticating devices to ensure they’re not malicious, creating secure “slices” of the network, and more, which can all improve security.
Another consideration for security beyond the oncoming flood of emerging devices and services that’ll find their way onto 5G networks is the sheer volume of traffic and data they’ll generate. One estimate puts that figure of 5G traffic at 79.4 zettabytes (ZB) of data in 2025. (What’s a zettabyte? Imagine a 10 followed by 21 zeroes.) This will call for an evolution in security that makes further use of machine learning and AI to curb a similarly increased volume of threats—with technologies much like you see in our McAfee security products today.
The newest IoT devices making their way into your home
“Siri/Alexa/Cortana/Google, play Neko Case I Wish I Was the Moon.”
We’ve all gotten increasingly comfy with the idea of connected devices in our homes, like our smart assistants. Just in 2018, Juniper Research estimated that there’d be some 8 billion digital voice assistants globally by 2023, thanks in large part to things like smart TVs and other devices for the home. Expect to see more IoT devices like those available for use in and around your house.
What shape and form might they take? Aside from the voice-activated variety, plenty of IoT devices will help us automate our homes more and more. For example, you might have smart sensors in your garden that can tell when your tomatoes are thirsty and activate your soaker hoses for a drink—or other smart sensors placed near your water heater that will text you when they detect a leak.
Beyond that, we’re already purchasing connected lights and smart thermostats, yet how about connecting these things all together to create presets for your home? Imagine a setting called “Movie Night,” where just a simple voice command draws the shades, lowers the lights, turns on the gas fireplace, and fires up the popcorn maker. All you need to do is get your slippers.
Next, add in a degree of household AI, which can learn your preferences and habits. Aspects of your home may run themselves and predict things for you, like the fact that you like your coffee piping hot at 5:30am on Tuesdays. Your connected coffeemaker will have it ready for you.
These scenarios were once purely of the George Jetson variety (remember him?), yet more and more people will get to indulge in these comforts and conveniences as the technology becomes more pervasive and affordable.
Technology for All
One point of consideration with any emerging technology like the IoT on 5G is access.
This year drove home a hard reality: access to high-speed internet, whether via mobile device or a home network is no longer a luxury. It’s a utility. Like running water. We need it to work. We need it to study. We need it to bank, shop, and simply get things done.
Yet people in underserved and rural communities in the U.S. still have no access to broadband internet in their homes. Nearly 6 in 10 of U.S. parents with lower incomes say their child may face digital obstacles in schoolwork because of reduced access to devices and quality internet service. And I’ve heard anecdotes from educators about kids taking classes online who have to pull into their school’s parking lot to get proper Wi-Fi, simply because they don’t have a quality connection at home.
The point is this: as these IoT innovations continue to knit their way into our lives and the way the world works, we can’t forget that there’s still a digital divide that will take years of effort, investment, and development before that gap gets closed. And I see us closing that gap in partnership, as people and communities, businesses and governments, all stand to benefit when access to technology increases.
So as we look to the future, my hope is that we all come to see high-speed internet connections for what they are—an absolute essential—and take the steps needed to deliver on it. That’s an advance I’d truly embrace.
The post 5G and the IoT: A Look Ahead at What’s Next for Your Home and Community appeared first on McAfee Blogs.
Seven Tips for Protecting Your Internet-Connected Healthcare Devices: Cybersecurity Awareness Month
October is Cybersecurity Awareness Month, which is led by the U.S. government’s Cybersecurity and Infrastructure Security Agency (CISA) in conjunction with the National Cyber Security Alliance (NCSA)—a national non-profit focused on cybersecurity education & awareness. McAfee is pleased to announce that we’re a proud participant.
Fitness trackers worn on the wrist, glucose monitors that test blood sugar without a prick, and connected toothbrushes that let you know when you’ve missed a spot—welcome to internet-connected healthcare. It’s new realm of care with breakthroughs big and small. Some you’ll find in your home, some you’ll find inside your doctor’s office, yet all of them are connected. Which means they all need to be protected. After all, they’re not tracking any old data. They’re tracking our health data, one of the most precious things we own.
What is internet-connected healthcare?
Internet-connected healthcare, also known as connected medicine, is a broad topic. On the consumer side, it covers everything from smart watches that track health data to wireless blood pressure monitors that you can use at home. On the practitioner side, it accounts for technologies ranging from electronic patient records, network-enabled diagnostic devices, remote patient monitoring in the form of wearable devices, apps for therapy, and even small cameras that can be swallowed in the form of a pill to get a view of a patient’s digestive system.
Additionally, it also includes telemedicine visits, where you can get a medical issue diagnosed and treated remotely via your smartphone or computer by way of a video conference or a healthcare provider’s portal—which you can read about more in one of my blogs from earlier this year. In all, big digital changes are taking place in healthcare—a transformation that’s rapidly taking shape to the tune of a global market expected to top USD 534.3 billion by 2025.
Privacy and security in internet-connected healthcare
Advances in digital healthcare have come more slowly compared to other aspects of our lives, such as consumer devices like phones and tablets. Security is a top reason why. Not only must a healthcare device go through a rigorous design and approval process to ensure it’s safe, sound, and effective, it also held to similar rigorous degrees of regulation when it comes to medical data privacy. For example, in the U.S., we have the Health Insurance Portability and Accountability Act of 1996 (HIPAA), which sets privacy and security standards for certain health information.
Taken together, this requires additional development time for any connected medical device or solution, in addition to the time it takes to develop one with the proper efficacy. Healthcare device manufacturers cannot simply move as quickly as, say, a smartphone manufacturer can. And rightfully so.
Seven tips for protecting your internet-connected healthcare devices
However, for this blog, we’ll focus on the home and personal side of the equation, with devices like fitness trackers, glucose monitors, smart watches, and wearable devices in general—connected healthcare devices that more and more of us are purchasing on our own. To be clear, while these devices may not always be categorized as healthcare devices in the strictest (and regulatory) sense, they are gathering your health data, which you should absolutely protect. Here are some straightforward steps you can take:
1) First up, protect your phone
Many medical IoT devices use a smartphone as an interface, and as a means of gathering, storing, and sharing health data. So whether you’re an Android owner or iOS owner, get security software installed on your phone so you can protect all the things it accesses and controls. Additionally, installing it will protect you and your phone in general as well.
2) Set strong, unique passwords for your medical IoT devices
Some IoT devices have found themselves open to attack because they come with a default username and password—which are often published on the internet. When you purchase any IoT device, set a fresh password using a strong method of password creation. And keep those passwords safe. Instead of keeping them on a notebook or on sticky notes, consider using a password manager.
3) Use two-factor authentication
You’ve probably come across two-factor authentication while banking, shopping, or logging into any other number of accounts. Using a combination of your username, password, and a security code sent to another device you own (typically a mobile phone) makes it tougher for hackers to crack your device. If your IoT device supports two-factor authentication, use it for extra security.
4) Update your devices regularly
This is vital. Make sure you have the latest updates so that you get the latest functionality from your device. Equally important is that updates often contain security upgrades. If you can set your device to receive automatic updates, do so.
5) Secure your internet router
Your medical IoT device will invariably use your home Wi-Fi network to connect to the internet, just like your other devices. All the data that travels on there is personal and private use already, and that goes double for any health data that passes along it. Make sure you use a strong and unique password. Also change the name of your router so it doesn’t give away your address or identity. One more step is to check that your router is using an encryption method, like WPA2, which will keep your signal secure. You may also want to consider investing in an advanced internet router that has built-in protection, which can secure and monitor any device that connects to your network.
6) Use a VPN and a comprehensive security solution
Similar to the above, another way you can further protect the health data you send over the internet is to use a virtual private network, or VPN. A VPN uses an encrypted connection to send and receive data, which shields it from prying eyes. A hacker attempting to eavesdrop on your session will effectively see a mish-mash of garbage data, which helps keep your health data secure.
7) When purchasing, do your research
One recent study found that 25% of U.S. homeowners with broadband internet expect to purchase a new connected consumer health or fitness device within the next year. Just be sure yours is secure. Read up on reviews and comments about the devices you’re interested in, along with news articles about their manufacturers. See what their track record is on security, such as if they’ve exposed data or otherwise left their users open to attack.
Take care of your health, and your health data
Bottom line, when we speak of connected healthcare, we’re ultimately speaking about one of the most personal things you own: your health data. That’s what’s being collected. And that’s what’s being transmitted by your home network. Take these extra measures to protect your devices, data, and yourself as you enjoy the benefits of the connected care you bring into your life and home.
The post Seven Tips for Protecting Your Internet-Connected Healthcare Devices appeared first on McAfee Blogs.