Preface

I've long loved the idea of home automation. From X10 and LightwaveRF through to modern Bluetooth and Wifi connected devices, I have played with dozens of technologies in search of home automation nirvana. But recently I have watched with growing bewilderment at the incredible number of "cloud-connected" home automation devices being released and the eagerness with which they're snapped up by naive consumers hungry to control everything from the carefree comfort of their iPhone.

You see, while you can buy a myriad of IoT devices off the shelf nowadays, they nearly all come with some form of "cloud-service" that is necessary in order for the device to work as sold. As the more wily of reader will no doubt be aware, this exposes your home network to innumerable security concerns, potential abuses and an external point of failure that cannot be closed/fixed without sacrificing some or all of the functionality of the new fangled device.

While I understand the ostensible benefits of this approach (ease of setup, remote use without manually opening firewall ports, centralised patching and upgrading, etc), sacrificing control of (potentially hazardous or invasive) devices within my home is not a value proposition I am comfortable with. I would very much like to see a new (or is that old?) breed of device that:

• does not require an internet connection to operate with all features intact,
• with which the owner can proactively decide what control and data is available to servers outside of the home network and,
• which surface simple, open interfaces to the owner allowing them to completely control all aspects of the device.

In short, I'd like to drop the 'Inter' from IoT and expand the 'net' to become a 'Network of Things', or NoT.

In terms of the consumer market, I am undoubtedly swimming against the tide here. Fortunately with the rise of hobbyist devices such as Arduino and RaspberryPi, IoT technologies have been democratised to the extent that anyone with just the smallest ability with a soldering iron and faculty with an IDE can create such devices for themselves.

Ladies and gentlemen, I present my first (finished) NoT device, the...

MonsterPi

Years ago, while setting up my (living room) home cinema, I came across the Monster Power HTS 1600 on Scan's website. It seems Monster Products were end-of-lining their power products in the UK (the above link was literally the only one I could find that still works!) and Scan were selling them off at £30 a piece. It was exactly what I was looking for at the time and, not being one to pass up a bargain, I bought two.

Both devices found homes powering and protected my front room and study AV equipment and, to this day, I am still very happy with them. However, I always felt that Monster had missed a trick with this product: the ability to individually and - ideally - remotely turn each of the sockets on the unit on and off as desired.

When Microsoft announced that Windows IoT Core would run on a RaspberryPi the learning curve ahead of making this happen evaporated and I knew it was something I wanted to do. Unfortunately both Monster Power devices were in full time use and I didn't want to potentially sacrifice one on a project that might not work and could consign the device to the scrap yard. Given that you couldn't purchase the UK version of these devices any more and that, when they occasionally appeared on eBay, they'd invariably be priced at £100+ the project was indefinitely parked.

Finally, a couple of months ago, a 'used' one appeared on eBay without a reserve and with bidding at thirty odd quid having just a few hours to go. I placed a bid without really hoping it would be successful and, to my surprise, ended up winning the auction for £40'ish including delivery. When it arrived I was delighted to find that it seemed to be brand new and unused (twisty wire on all the cables, supplementary cables still in sealed bags, etc). Plugging it in proved that everything worked as it should so everything was in place to build the MonsterPi.

Software

While waiting for the time and space required to start hacking up the hardware, I took a look into what was required to write a headless UWP app, self-hosting a HTTP REST endpoint that could be deployed to the RaspberryPi and set values on the GPIO pins necessary to control the Waveshare RaspberryPi Relay Board.

It didn't take long to find Restup, a beautifully simple if somewhat minimal 'Webserver for Universal Windows Apps'. The github repository provided ample samples for writing various types of 'controller' and in less than an hour, I had a working solution.

Given the Waveshare relay board just required GPIO pins to be set in order to control the relay (low to close, high to open) this was achieved very simply using the classes available in the Windows.Devices.Gpio namespace.

Deployment was taken care of by Visual Studio and configuration performed using the Windows IoT Core Device Portal. The Device Portal allows you to configure deployed apps to run at start up thereby creating a "service-like" experience for headless apps.

Full source code is available on my Github account.

Hardware

The hardware side of things proved to be both easier and more tricky than I expected.

Initially I thought fitting the Pi was going to be child's-play when, upon opening the Monster Power chasis I found that the configuration of sockets providing isolation for RJ11 and RJ45 devices (phone and ethernet respectively) matched the layout of the ethernet and USB connectors of the Pi almost perfectly. Furthermore, these sockets were mounted on an easily removable daughter-board providing an obvious way to fix the pi in place.

While alignment wasn't perfect, filing the holes in the chasis to provide access to all ports would be easy.

Complexity came when I realised that, although the Monster Power included a micro-controller driven digital display, it was unlikely that the DC subsystem in place to power this would be adequate for the RaspberryPi. So here I had to get creative.

I bought a small 12v 80W switching power supply which would fit down one side of the Moster Power chasis and wired it to the 240v input of using the conveniently provided ring terminals. I used a custom printed bracket to secure the PSU in place while providing a platform to mount the Waveshare RaspberryPi Relay Board above, in close proximity to the sockets I wanted to control with the relays.

The live wire to the three sockets to be controlled by relays were daisy-chained together so one side of this wire was cut from each socket and connected to the normally-closed output of the relay (extending where necessary using crimp connectors).

This is shown below:

While the perspective in the picture makes it look like it hangs over the edge of the chasis, it does actually fit. It's tight, but it fits.

I used a 12V To 5V 3A 15W Power Converter Regulator with Micro USB Cable to power the RaspberryPi and - given I now had plenty of power to spare, decided to also fit the 4-port USB power module I had bought, but not used, for our travels earlier in the year. Again, this aligned almost perfectly in the remaining holes in the Monster Power chasis.

Both these were mounted - upside down - on a custom printed bracket using the screw holes for the original daughter board to secure it in place. Terminal connectors were used to provide connection to the power supply just in case I needed to remove the components at a later date for some reason.

Finally, boards were fixed in place and a ribbon cable connected between the GPIO socket on the RaspberryPi and the relay board to allow control of the relays.

After a thorough check to make sure there were no shorts on any of the connections and that I had connected polarity correctly, I plugged it in and turned it on....

Testing

... and everything worked.

The RaspberryPi booted but didn't switch the sockets on as - I think - not having a network connection meant it couldn't get an IP address which meant the software hadn't enabled to relays due to being configured to fail safe (leave the sockets off). The power indicator on the USB power module suggested it was working fine too.

Next I relocated to another room where a network connection was available. I plugged it in, turned it on and saw the network connection LED's start blinking. After 15-20 seconds or so while the RaspberryPi booted, the relays tickets on and I was able to hit the REST endpoint from Postman. I'd even managed to get the names of the sockets on the rest service to match the sockets the relays were controlling, although I admit this was more luck than judgement (I had completely expected to have to re-configure the software to match after the hardware was complete).

I plugged in a small table lamp and recorded this:

Boom! (Figuratively speaking of course... the MonsterPi didn't literally go boom... yet :0)