UK smart light switches

Obviously I have tinkered with smart light switches, and the like, for a long time.

You only have to look on Amazon to see a lot of different options now, but there was one simple combination that has been lacking. I have been looking for this for ages, and finally they now exists - the Shelly 1. But more on that at the end of this blog post. First a bit of background.

UK lighting circuits

One of the problems is UK lighting circuits have a live and switched live to the light switch from the light fitting. This means that, at the light switch, there is no neutral. The only way to power a "smart switch" is through the light bulb, which is not ideal. Indeed, it is not that reliable as it also depends a lot on the type of light bulb in use. This means that almost all smart light switches need the wiring changed to allow live and neutral to the light switch. In simple partition walls that is not too hard for an electrician to pull through a new cable, but it is not always so easy. The other big issue is that you almost always have to change the back box from a shallow back box to a deep one, and that can mean chiselling out some brick, etc.

Basically, fitting a smart light switch in the UK is a pain, needs an electrician to do properly (and I am not even trying to address the regulatory issues here), and costs a lot more than just the switch itself.

There are now, finally, some UK variety smart switches, e.g. DS-102L. It has a bypass capacitor to fit across the light bulb so as to allow enough in-line power for the switch. This again is fiddly for a non technical person, but saves running new wiring. I am making the huge assumption that this is valid wiring in the UK as well.

Some options

There are a few approaches to smart lights though...

• A smart switch. But as mentioned, in the UK, this is not always easy.
• A smart bulb. Simple, but tends to cost more (I'll not go in to these here, but Shelly do one!).
• A smart in-line power relay in the lighting circuit.

Yet more problems

The other problem is how you control your smart light switch. Obviously some sort of app on your phone, or integration with Alexa or Siri or something. But then what?

We tried - we really did. I got a simple smart light switch, and we decided to try and get it working as intended. I have used these for years, but always re-flashed with new firmware, so trying it as sold was new for me. A (non technical) relative wanted to simply be able to work some lights, from her phone, remotely, so this seemed like a good idea. I also asked my son to try, as a new pair of eyes. No joy!

We even set up a bog standard router with NAT and WiFi (yes, NAT is evil), and still could not get the damn thing to work as intended. They come with an app, which was easy to download, but then we could not get anything to actually work. This did surprise me, to be honest.

We ended up putting a raspberry pi running MQTT (mosquitto) and a tasmota flashed in-line power plug for a lamp.

Using the Internet

The other concern I have is that these things normally use servers somewhere in the Cloud, i.e.on the Internet. No idea where. No contract in place with whoever runs the servers. No recourse if they stop working. No idea if usage patterns are logged or sold somehow. And all this relying on working Internet.

Call me old fashioned, but I like a light switch that does not rely on working Internet and someone else's server in China!

Of course this means having my own "hub" of some sort - in my case a raspberry pi and MQTT server, but this could be some "home hub" or some such.

Tasmota

If you have not encountered Tasmota before, do take a look. It is free open source software that runs on most of these smart switches and devices. It means re-flashing the device, and they vary in complexity from "having a header you can just plug in to with a serial lead", to "soldering bits of wire inside the switch". But once re-flashed they can be re-configured and re-programmed over the air (WiFi). As for actually flashing the code - you just need a simple serial lead and the tasmotizer app, and it is very easy.

The key thing about Tasmota is that it works using a simple standard called MQTT. Having an MQTT server in your home is cheap and easy, and can integrate with various home automation systems. It does not, then, rely on any Internet connection or third party servers. It can work with various home hub / automation systems as well.

Some options

The main three options I would consider are these. All can be flashed with Tasmota.

• Sonoff basic: This is a neat, very cheap, in-line, 10A switch. It has live/neutral one end, and switched live / neutral the other. It has a tiny button and LED as well, which are not that useful. The main downside I have found is they have a tendency to die after a while.
  
  
  
• DS-102 light switch: There are a lot of these type of smart light switches. The key thing with this particular model is that it has actual tactile micro switches behind the buttons. There are many that are capacitive, so harder to work in the dark when not looking. Some also have LEDs you cannot control. But the DS-102 seems about the best I have found so far. They come in one, two, and three gang, and as mentioned they have an option for live only, supplied with a capacitor to fit across the light fitting. One big down side is you have to solder wires to re-flash them (though people have made rigs with pogo-pins to do this).
  
  
  
• Shelly 1 relay: This is what I have been waiting for! It is a relay, like the sonoff basic. It costs more than the sonoff basic, but typically less than one of the smart light switches. See below.
  
  
  

The Shelly 1

I have been after this for a long time - I even considered making one myself - something simple like the Sonoff Basic, but with a proper switch input. The Shelly 1 seems to be ideal for light controls in the UK.

It can go behind the light fitting in the ceiling where the live and neutral are already present, so solving the fact we don't have neutral at our light switches. But it can take the switched live as an input. Obviously it can have a default mode of operation where the switch works the light, so even no Internet or WiFi does not stop it working in the obvious way.

It has a simple header for re-flashing (please do take note of the warnings about these being at live voltages when connected to power!). So loading Tasmota is a doddle.

This means that with no extra wiring, and no changing to a deep back box, and no change of light switch to something cheap and tacky white plastic. It is easy to make a normal light fitting WiFi connected.

It is also 16A not 10A, so much more useful than the Sonoff basic (obviously for things other than lights, which get nowhere near that rating).

I have one coming today :-)

P.S. For those that have not used tasmota, you can have an input as a button or a switch. A button works toggling an output on pressing the button. A switch toggles the output on change of input. So a normal light switch would be connected in switch mode, and turn on/off when changed. If you override via MQTT you simply swap the way it works, much like a normal two-way light switch arrangement, so the switch now works in reverse until you next override.

P.P.S. Smaller than I expected - this is really neat, and can even run off 12V or 24V-60V if you need. This is exactly what I wanted!

P.P.P.S. I had not heard of Shelly before, but they have loads of cool stuff, all looks quite sane, including the simple to re-flash header, and the fact they will do MQTT anyway. Very cool. shellystore.co.uk

(Do always follow local electrical safety regulations, please)

Tasmota / Sonoff - two way light switch controls

One small thing I wanted to do is make one Sonoff light switch work another - a simple two may light switch arrangement, such as top and bottom of stairs, etc.

Obviously, one can use a home automation server like home-assistant, but I am trying to keep it a bit simpler at the moment. I have an MQTT broker (actually on a Pi) and that allows any of the MQTT devices I have to talk to each other. Some devices, like my door entry, and alarm system have a means to send a series of MQTT messages on various events already.

It seems Tasmota / Sonoff can do what I want, but there were a couple of challenges, and reading some blogs I see I am not alone. So here is what I found and what is a gotcha or two.

The set up

What I was trying to do was have a light switch that controlled another - a simple two-way light switch arrangement (which is what it used to be). Either light switch ("button") when pressed would toggle the light, simple. I had another case where I wanted one button to control 4 lights, but we'll come to that later.

ButtonTopic

The simple answer is to set the ButtonTopic on the extra switch and tell it that the topic to use is the first switches. This should just work. But...

• You cannot set the ButtonTopic if you are sending a group message, which it thinks you are if the name of the GroupTopic is a substring of the Topic of the device, which is just silly. The result is a status saying ButtonTopic is still "0". No error, just confusing. I had to read the code to find this. I had Bed1LS as a GroupTopic and Bed1LS3 as the device Topic. As a result I could not set the ButtonTopic to anything!
• I don't think you can use the ButtonTopic if it is set to the same as the device GroupTopic (from looking at the code). So even changing GroupTopic and changing back to set ButtonTopic would not work in the above case. I am not totally sure why, unless it creates some sort of loop, but I cannot see why it would and it would be better to fix that than to silently ignore it.
• You can only set a system wide ButtonTopic, not a topic for each button if you have several buttons. This is OK on a simple button switch, obviously.
• You set the ButtonTopic just to the name, without the cmnd/ prefix or /Power suffix. It adds those - which was not obvious.
• Note, ButtonTopic replaces the normal relay operation unless MQTT is not available.

Request: Please can we have a ButtonTopic1/2/etc for each button?

Request: Can we please avoid the loop or whatever stops use of the GroupTopic as ButtonTopic?

Request: Why is grpflg set using strstr hence meaning it is set when talking to a device where group is subset of device topic. I can see group being subset of device as quite common?

Rules

Rules are another good way to do things and are mode flexible. You can make a rule so that pressing the button publishes on MQTT. You can have more than one sequence on a rule.

You simply send something like :-

 cmnd/Bed1LS3/Rule1 on Button1#state do publish cmnd/Bed1LS/Power1 TOGGLE endon

And you can add a second part to the rule, e.g.

 cmnd/Bed1LS3/Rule1 +on Button1#state do publish cmnd/Bed1LS/Power2 TOGGLE endon

I had to add two parts because the lights switches where double, and so needs Power1 and Power2 set.

• It looks like the Rule and ButtonTopic do not work together which is odd.
• I could not publish a command with spaces in it, such as Backlog (to change both Power1 and Power2 together). Maybe there is a trick to that. Hence I had two parts to the rule.
• Note, a rule on ButtonX replaces normal relay operation. A rule on PowerX happens when power changes which could be because of normal button control of power. You can test Power1#state=0 and Power1#state=1 if you don't want to use TOGGLE.

Request: Can we have it so Power (rather than Power1 or Power2) applies to all power controls so that one message could toggle or control all lights on a multiple button light switch?

Request: Can we publish something with spaces in somehow?

However, end result is good :-)

P.S. You cannot turn off the relay/button LEDs on the T1 (light switches) sadly.

Update: You can use Backlog in the command, which works well. E.g.
cmnd/GardenLS0/Rule1 on Button1#state do Backlog Publish cmnd/GardenLS1/Power 2;Delay 2;Publish cmnd/GardenLS2/Power 2;Delay 2;Publish cmnd/GardenLS3/Power 2;Delay 2;Publish cmnd/GardenLS4/Power 2;Delay 2;Publish cmnd/GardenLS5/Power 2;Delay 2;Publish cmnd/GardenLS6/Power 2; endon

Update: Be careful with now code and settings. I turned on Home Assistant Discovery and it changed the topics. I turned on WiFi signal scanning and somehow managed to put most of the sonoffs in a mode where they could not connect to the WiFi so went in to an AP mode for 3 minutes and tried again. It meant all my devices vanished and did not come back for quite a while. Several devices even somehow went in to a mode where they acted like the original SonOff code. I had to actually unscrew 4 of them and refresh, and two of those I had to erase the flash with a separate binary. The other two I had to sent a command over serial to Reset the config. So top tip: Always have one separate unit on which to test any changes first.

Reprogramming a light switch

I started in computers in the late '70s when my high school got an RML 380Z. I never imagined I would ever be re-programming a light switch. Yes, a light switch, and one that is only £14.99 from amazon.

But yes, that is what I am doing. I was very impressed with this youtube video with step by step instructions on loading the Tasmota code using a Mac. It worked exactly as expected. That never happens!

I purchased a serial adapter from Amazon (here) which came with leads, and a simple molex header. The good news is you don't actually have to solder a header in the holes, you can just hold it there whilst programming. You only ever have to do this once (per device).

I now have a web page I can use to control it and configure it and so on. I had to do very little tweaking to the config, but was able to set up so it connected to the right SSID by default. I can even upgrade the s/w over the air (web interface). Impressive.

The only complication was the T1 (light switches) which needed more messing to get in to flash mode (see here). But you only need to flash once like this obviously and it is pretty simple.

Note: one other issue - edit the my_user_config.h and turn off some things you don't need (add // to start of the #define line). Test compiling Sketch->Verify/Compile to confirm under 500k size. This means you can have two copies in memory and hence upgrade the firmware over the air via its web page. If not, you have to take apart and re-flash to change code.

Next step MQTT... This is the messaging broker used to control and report button pushes...

It seems a simple apt install mosquitto moquitto-clients is a good start. And just like that I have an MQTT broker just working. Wow. Running in debug shows the events and everything, but it just works.

By setting the MQTT topic on a device, in this case to pixar, I can do commands like mosquitto_pub -t cmnd/pixar/Power -m 1 to turn the lamp on!

It allows me to send commands to the sonoff devices, and allows me to collect messages from them - cool. Next step I expect is to set up some scripts to do what I want.

That, or play with something like home-assistant.



P.S. I did tidy the wiring - the cover now clamps on the sleeving as it should.

De-clouding IoT

There is a lot of IoT (Internet of Things) stuff these days, and it is impressive what you can do with home automation - linking sensors and devices and command speakers and phones and all sorts. It is even impressive that third party linking services like If This Then That even exist now!

A lot of these devices make use of The Cloud in one way or another, but not all, and not all to the same extent. This is both good and bad, and represents something of the age old compromise of security and convenience in a way.

Today I am playing with three devices: A Daikin air-conditioning unit (as per my blog), a Withings Sleep monitor (as per my blog), and some new SONOFF switches. All have different approaches. All work with IFTTT, so if I was happy to just use the cloud, this would all be simple.

What's wrong with the cloud?

Convenience

The first thing that is right with the cloud is the convenience - simply connect a device, load a phone app, set up and it is working. Devices that live on your home WiFi and talk to servers on The Internet do tend to just work and be easy to use. But this convenience comes at a cost...

Privacy

One of the issues is privacy - the data from these devices is going to third parties - companies you don't know, or may not even know which country they are in. Often the "service" they provide is not something you even knew was needed when buying the product and is some separate "agreement". GDPR should make your data safe, but it is a law not a technical means. They may not understand GDPR (Withings clearly don't, and have been reported to the ICO). Even if they do understand GDPR you have no real way to know if they are following it properly, or if they will ever get hacked.

The main way to ensure privacy is to keep control of your data. A cloud based service inherently takes that control away.

Reliability

If a device needs the cloud to work, that is also a problem. Even the Withings Sleep monitor, which is totally cloud might seem like it is not an issue if your WiFi or Internet is down or they are doing maintenance on their servers, etc, but when you use the real-time triggers for getting up or going to bed to work the lights and heating and so on, suddenly it matters.

With locally connected and controlled devices in your home you can remove that reliance on the Internet and The Cloud, but at the cost of a single point of failure and equipment you have to maintain.

You also have to allow for the fact that this is most likely a free service, and something they can stop by choice, or because they go bust, or even politics between countries, and suddenly your devices are useless.

Adding extra parties like IFTTT just adds to the issues.

Security

Finally security - this is a huge issue with IoT. "The S in IoT stands for Security".

The Daikin air-con have no security - simple http requests. Even if there was a password it would be easy to snoop. It means anyone on your home network / WiFi can access the air-con.

Does it matter? After all anyone with a remote can do the same in the house or even from outside through the window (stories of someone turning on neighbours air-con through the letter box whilst they are away so heat rises to their flat and saves them money). But is it a big deal? Well, remember, this is not just about you - if someone could control all air-con in a country they could make them all turn on at the same second and cause a major power blip? They could monitor when you are in and not and break in when not. It is not so simple.

But they need to be one local network / WiFI? Well, no, they just need a compromised broadband router or compromised device (a lot of IoT is very hackable) on your LAN, or even some background secret function in some popular phone app. It is not as hard as it sounds.

So security of IoT really needs to improve.

What do I mean by de-clouding?

Basically I want to have devices I control, and home automation I manage using my computers in my home without using The Cloud. I can set up any remote access I want with a secure VPN. I then control my systems, and control my data. It means I have to maintain a machine, but I do that anyway, and it is not that hard - could even be a Raspberry Pi or some such.

Daikin

As per my blog, this was simple - no authentication just local http - it has no security.

The good news is that it makes it simple for me to lock down on separate WiFi SSID and VLAN and easy for me to write my own controls.

Apart from a lack of security, the other failing is a lack of documentation. I'd prefer if the API was actually documented - why not, Daikin?

Withings Sleep

The Withings Sleep monitor was more of a challenge - the security is trying with this one.

The device does an HTTP request to fetch the public key used for HTTPS, but includes its MAC and a random challenge in the request and gets a digest in the response. Any change to the response key, or even the request MAC causes it to abort and start again (DHCP, DNS, HTTP, etc). So it seems there is likely to be a per-device key check on the response and as such I cannot simply replace the public key returned. It then checks the public key on the HTTPS.

So yes, I am stuck. The good news is that it does do IFTTT and that can be linked by creating an applet to a webhook to poke my own server for triggers. Sadly this is not direct from the device, but via Withings, so no chance to intercept / hack that either. It has all the disadvantages of cloud and local servers combined, but does mean I can then control the actions I take directly - such as changing air-con settings, turning lights on/off, etc.

SONOFF

I was inspired by a blog post (here). It seems SONOFF are very cheap and very popular, even with alternative code that people flash in to the units. However, the security is poor in the first place meaning one can control them off-the-shelf. This is bad for security but good for de-clouding them.

First off, the simple in-line power switch (e.g. for lighting circuits) - which I have connected to a table lamp (purchases especially for this test, and obviously pixar style).

It was incredibly difficult to see the AP mode SSID pop up and connect to it, and I wonder if you just have to try several times. You long hold the button and it shows up if you are lucky (ITEAD-1000xxxxxx with password 12345678) But then the /device and /ap http commands work as explained in that blog. It seems serverName can be a host name.

As expected it then connects https. Unfortunately, even where the server has proper https and the name matches, it is just closing the connection after getting server certificate details. Arrrg.

Reading some of the comments, it seems I am not alone - even with a valid (LE) cert, the sonoff is not happy with the https negotiation. Grrr.

This sort of leaves me either using IFTTT and cloud, again, or re-flashing the code. Not amused.

What I think would help...

Firstly I think all IoT needs better security - maybe there needs to be a testing standard as part of compliance for CE marking (scary).

But also I really think the APIs should be published. This would allow devices to work directly with IFTTT or competing home automation systems or local controllers.

At the end of the day the closed approach, and forcing all data via the cloud maybe made commercial sense when companies could collect and use all that lovely personal data. GDPR kills that business model, and even makes having that data a potential liability! So please, let's open the APIs (securely) to allow more competition in the home automation market.

Oh, and don't forget support of the current IP protocol (IPv6).

Update: Current plan is to re-flash SONOFF. I'll blog more on that soon.