I can take care of the security myself with separate IoT VLAN and hidden SSID and firewalling and so on, and I would rather not hand both my personal data, and control of my home, to third party "cloud" services if I can avoid it. I appreciate security of WiFI is always an issue, but at least it is mostly a physically constrained issue (i.e. in range of my WiFi) which is a lot tighter than cloud services in China, etc.
The SONOFF switches were interesting. I was a bit against re-flashing them initially, but in fact I think this is working really well. I have refreshed a few with Tasmota and it just works. The Tasmota provides a simple (optional) web interface and talks MQTT. It seems there are a few common open source projects for these, and Tasmota was recommended - thank you.
I had not quite appreciated how MQTT works, and actually it is quite fun. A simple messaging protocol via a hub (MQTT broker. The Tasmota stuff has loads of commands allowing you to configured everything via MQTT. You can even have one switch send MQTT commands to other switches (via the broker) so easy to create two way pairs of light switches, etc, with no control application.
It took me maybe half an hour to add MQTT support to my door entry and alarm system (SolarSystem) using the mosquitto library. This means I can add config to do things like turn on the lights when I open the door to my office, etc.
But MQTT is an odd beast in some ways - it is designed to be really simple for the small simple code of embedded devices, but you can use it with TLS and usernames and passwords as well. This is almost at odds as TLS is a big bit of code for an embedded device (it can be done). Also, the management of certificates is a complication for managing simple IoT. In some ways a simpler approach of a local firewalled VLAN is a lot easier, but then the comms within that LAN are all plain text and not secure. This is an area where an actual local area LAN, locked down, makes some sense.
Of course, I am not new to any sort of home automation - I had a door entry system back in the late 80's using a home made mag card reader connected to a wire wrapped 6502 board I made. But I have not really got on the bandwagon for some of this cheap modern kit like the SONOFFs. My approach, as usual, is to understand the nuts and bolts of these things, so at present a simple MQTT broker (mosquitto) is all I need, but I may go for something like home assistant some time.
However, I do like MQTT, so I will probably make an MQTT client for my Daikin air-con at some point (and put on GitHub). It may be that I add MQTT to some other code and systems as well.
The hardest part of MQTT for me is coming up with a consistent and pleasing naming scheme for topics.
ReplyDeleteGlad you said that - I thought it was just me. Currently battling with various embedded devices throwing out their information using wildly different (and unchangeable) naming schemes.
DeleteIndeed!
DeleteI ended up using node-red to re-publish mqtt messages on my own preferred topic hierarchy. (As I am already using it to schedule lights and log temperature data for grafana)
ReplyDeleteThe trouble with MQTT is that it's a single point of failure. If you're relying on your VLAN for security, why not opt for a multicast based protocol, and get distributed services and redundancy for free?
ReplyDeleteStill depends on network, Wi-Fi, maybe switches. The actual MQTT Broker could almost certainly be set up with a back up.
DeletePS. The Shelly modules have MQTT built in IIRC, and are 'good enough' to avoid the need for reflashing. I had a scare (and I am not alone) with Sonoff 16A switches on an immersion - they could not cope with the load, melted and almost caught fire. PCB tracks too thin, acknowledged issue. No idea if the insurance would have paid out if they had actually caught (fortunately they were on a metal plate).
ReplyDeleteThats would be quite bad practice anyway. Ideally you should use the Sonoff relay to switch a contactor (with a snubber network across the contacts) or a SSR and let them switch the immersion. Using the on board relay directly is asking for trouble.
DeleteWhat a load of twaddle. A relay rated for 16A should have no issues at all switching a 10A resistive load.
DeleteRe-read the previous post, you'll see that the manufacturer acknowledged a design fault - the PCB tracks were undersized for the load. What they should have done, but did not, is issue a recall for the affected devices.
More interesting to me is the liability issue: if I flash my own firmware in a device, am I then responsible for damage arising from the failure of that device?
Source: I'm a qualified EE.
It is an interesting question - given the mains voltage part is clearly separate and is a relay, the only thing the s/w can do is switch the relay, so how can faulty s/w ever cause a problem that could not be caused by a normal switch?
DeletePondering more - maybe switching really on/off quickly or something - but given the supplied system and s/w can be integrated with other systems - what if those systems cause it to do the same?
DeleteDuty cycle, as you've pointed out, is one obvious potential issue. Another might be taking the average power consumption out of spec.? Suppose "my" firmware enters some failure state where it is watchdogging continuously, and I exceed the duty cycle for which the device was designed leading to thermal failure/fire (perhaps using a device as a fermentation controller? Or modded 3D printer firmware overheats the bed/bed supply? (I'm sure there are better examples...). Would a typical household insurance policy cover it (assuming they found out)? I guess it's a similar scenario to any DIY/self built device - but I don't know how insurance companies deal with that - and the 'use at your own risk' disclaimers cover open source liability.
DeleteThat's an awful lot of devices you have there polluting the spectrum... What strikes me most is that replacing all your light switches isn't something you tend to do very often, if at all - so will you when the next in a long line of wifi vulnerabilities comes along and renders these a liability? Low end CPU may mean a software upgrade can't help you either if it lacks the h/w offload for whatever new crypto thing has been chosen.
ReplyDeleteYou then have to start wondering if the cost to produce and then dispose of these devices is actually worth it?
In a world where incandescent bulbs have been banned and the replacement supposedly energy efficient CFLs are now being replaced by LEDs due to CFLs being too energy inefficient, how long before these IoTat switches get banned due to their excessive and unnecessary energy use as well?
Hope you kept the old-fashioned manual switches :)
They do not talk much, so not really a spectrum issue, and anyway they are only 2.4GHz which we don't use for normal Internet access. As for vulnerabilities, they are talking unencrypted MQTT but on a local firewalled VLAN - so really only issue for WiFi side which is obviously lower risk as needing local access. All good questions, but I do not think we have an issue, honest.
DeleteI am finding that LED bulbs only last about two years, whereas the CFLs they replaced lasted about 10 years on average. The LEDs consume between half and two thirds the electricity, but need to be manufactured 5 times as often. It is not at all clear which is better overall for the environment.
ReplyDeleteThe problem with poor life of LED bulbs appears to the power supplies. If I knew anything about electronics I could repair them I suspect. I have gone back to CFLs in a couple of locations, I got sick of replacing LEDs. At least many of the LEDs have been replaced under warranty, but the environmental cost still applies. And it really annoys me that bulbs advertised as having a 10+ years life die after 1 to 2 years.
I'd love to replace our light switches with those ones you've pictured. Unfortunately our house is wired in the traditional British way with no neutral at the wall switch. The best I've done in a few places is to slot one of the in-line Sonoff devices above the ceiling rose on the lights I want to control, wire the light permanently on and replace the switch with a LightwaveRF unit. It works, but has the massive downside that it's impossible to manually control in the event that any part of the HA system goes down. Seriously thinking of having the house re-wired.
ReplyDeleteThere are some options that work with no neutral in the UK. I have some of these : http://www.wifi-smart-home.co.uk/smart-wi-fi-light-switches.html
ReplyDeleteI have a couple of similar units and they work fine with tungsten lamps, mustn't be used with CFLs and LEDs must be dimmable (but even then I've had mixed success). Which bulbs to use needs to be completely irrelevant to my better half and needing to know wipes out this option :-(
ReplyDelete