As the weather is still terrible around here, I spent the weekend working on my home automation. A load of general maintenance such as replacing batteries and fixing broken things like the integration with the burglar alarm.

I also added a few new integrations:

• DVLA Link – This lets me query details about our cars, and more specifically the due dates for MOT and insurance.
• Waste Management – Link into the local government to know when and what type of refuse collection is coming up.

But, the most fun one was finally getting the 10 inch display and Raspberry Pi mounted on the wall as a custom control panel!

I’ve had it sat on my desk for about six months and decided it was actually time to get it done. I had to CAD up a box for wall mounting and hiding the electronics. Not the best design, and lots of things to improve, but its functional.

A quick couple of holes in the wall, and it was mounted.

Once I have the local voice assistant details finished, this will get that installed too. That will need a redesign of the case to support some speakers and volume controls. The actual dashboard needs a bit more work, and possibly an LCARS theme as an option.

But at least its off my desk and working now. Very handy for a quick glance at the calendar, weather, alarm status, and also to view the front door camera.

Over the years I’ve messed with various home automation systems. From X10 in the early 2000’s, through Mi Casa Verde and z-wave going into the 2010’s, a few years using OpenHAB, up to the current day where I’m using Home Assistant.

Home Assistant has been around for a while, but I was loathe to move from OpenHAB as I already had a lot set up. However, as OpenHAB fell behind I finally bit the bullet and installed HAOS on a spare Raspberry Pi. This turned out to be a good thing.

I’ve been using it now for a couple of years, and it works really well as a central hub for all the different technologies in the house. This post is a quick overview of what I have set up.

Technologies

The beauty of Home Assistant is that it acts as a hub for many different home automation protocols, devices, and other information. A quick list of technologies I have integrated:

• Zigbee
• Z-wave
• ESPHome
• Matter
• Thread
• MQTT
• WLED

But not only does it talk to these home automation systems, it can also tie into other things such as:

• 3d Printers (Octoprint, Klipper, Bambu Labs)
• Google Assistant (Ties your home automation into google voice commands)
• Jellyfin/Plex
• Fitbit
• Raspberry Pi
• Roomba
• Smart Meters
• Printers (you know, the none 3d kind)
• Frigate (CCTV)
• Solar Production

And lastly, you can pull in information from web APIs to help with automations:

• Weather
• Sunrise/Sunset
• Moon phases
• Astronomy Weather (More detailed weather more geared to astronomers)
• Github (Monitor commits, issues, etc.)
• Whois (Keep an eye on domains expiring)
• DVLA (MOT and insurance due dates)
• Waste Management (get dates and types of refuse collection)

This is a lot of tech, and this isn’t a complete list of everything I have tied in, just the majority.

My Setup

So, enough of what it can talk to. How is my house set up?

Core

The main core of the system is a Raspberry Pi 4 running Home Assistant OS. This is a simple install onto a Pi and is fully managed by Home Assistant. Everything runs in containers and gives you everything you need to get started.

The Pi is run from PoE in a rack, to keep things simple, and also has everything installed onto an SSD drive as it is a lot more reliable that using an SD Card (My old OpenHAB system was on SD Card and I had to rebuild it every now and again as the SD card wore out). Plugged into the Pi are two USB dongles, one for z-wave and one for Zigbee/Matter. This direct connection lets me control the majority of the devices I have.

Also, installed as part of HA OS I have a few other addons. These are:

• InfluxDB – This keeps a historical record of all the stats in the house, which can then be pulled out into a Grafana Dashboard
• Mosquitto MQTT Broker – Some devices talk directly to an MQTT server, so this is running to fill that role
• ESPHome – A system designed to convert simple ESP32 or ESP8266 boards into home automation devices using a simple yaml language. Some commercial devices can also be flashed with ESPHome for extra functionality.
• HA Google Backup – Backups!!
• Lets Encrypt – Automatically renews my SSL cert
• VaultWarden – A locally run version of Bitwarden password manager.

These are all running on the same Pi quite happily.

CCTV (Frigate)

I have a second Pi 4 running a system called Frigate. This is an open source CCTV system that integrates really nicely with Home Assistant. It also has functionality for not only motion detection but facial detection too so that it will only trigger if it detects a human (not a cat or squirrel) which definitely helps cut down on false positives. I have had to block out certain areas for detection tho, as in high winds it sometimes thought some of Joy’s flowers were a human!

I’m hoping to upgrade this to a Pi 5 when the PoE hat comes out, as I currently have 4 cameras going into it and it does struggle a bit. I do have a USB Coral AI stick from Google that I can offload some of the more AI related tasks too.

NAS (TrueNAS Scale)

I do have a NAS box set up that has a simplified Kubernetes system installed. On this I run a few other services, including Grafana for viewing stats of my home, Spoolman which keeps track of my 3d printer filament usage, and Trilium Notes for keeping track of the random things in my brain.

Other Hardware

So what have I actually got set up?

Most of the main lighting in the house are Phillips Hue lights, with their dimmer controllers. However, since realising just how much data the Hue hub was sending back, I removed that and now everything is directly controller via Zigbee. The only main exception to this is the garage which initially had fluorescent tubes and I use a z-wave in wall module to control that.

I’ve a lot of smart sockets around the house too, from plugin units to actual in wall faceplates. The vast majority of these allow for energy usage collection too so I can not only turn things on and off remotely, but I can also monitor the energy usage of various items such as 3d printers, server cabinets, desktops, TVs, etc.

The burglar alarm is also connected in, which turns all the various door and motion sensors into sensors that Home Assistant can use for automations.

WLED is a system to install onto an ESP8266 or ESP32 to control a string of RGB LEDs. I’m starting to incorporate more of these into the setup and they tie very nicely into Home Assistant

Control

What does all this gain me? The main benefit is a single app on my phone to control everything. I don’t need a Hue app, a Roomba app, to access a webpage to control my WLED lights, etc. I can create a dashboard on Home Assistant to give me a nice overview of the controls in the house. For instance, my setup main dashboard consists of an overview page (simple controls such as lights, along with main thermostat control and some other status) with the ability to click a room and get more detailed controls and information. That covers about 90% of everything.

Along with this, as I have Google Assistant integrated, I can also just ask google to turn lights on, set the thermostat, etc.

Automations

So far, most of the stuff is just allowing for remote control, but the real beauty is making things automatic. I’ve only really got some basic automations done at the moment and want to expand on this in the future.

• Automatic outside lights. I have the lights set to come on at sunset, and turn off at midnight. They’ll also come on in the morning if Joy is going to work and its still dark out.
• Turn the thermostat down at night. The thermostat will drop a couple of degrees at midnight whilst we’re asleep to save some energy. I have got the alternative set to turn it back up in the morning, but thats disabled for now as its just as easy to turn it up manually depending on what time we get up.
• Send an alert if someone comes to the front door, and turn the light on. This is one of the reasons I want to upgrade the Frigate Pi. The Pi 4 is just a little slow on this, and hoping the extra processing power will speed things up.
• Show video feed on my google home displays when someone is detected on the front door camera.
• Automatic office lights. I’m terrible at remembering to turn my light off in the office, so I have a simple motion detector to automatically turn the lights on and off. They do turn off occasionally if I’m in the office concentrating on something and not moving much (such as writing a blog post about my home automation system) so I’ve just ordered some mm wave detectors to try which should be more sensitive.
• Notifications when prints have finished or theres an issue.
• Daily notification if a battery is low in a device. All my Phillips Hue Dimmers were bought at the same time, and I’ve just had to replace all the batteries at once!

Theres room to do a lot more of course, but these will do for now.

Monitoring

So, I’m a nerd and I like stats. One of my favourite things that Home Assistant does is store historical data so that I can pull information out and graph it in Grafana. I’ve no idea if this will have future uses, but it does produce some pretty pictures such as the one on the left that shows temperature and humidity over time.

Also, Home Assistant has an inbuilt energy dashboard. You can select the various entities you monitor for energy usage from smart meters or solar panels, and it will generate a nice dashboard to show your energy usage.

Water consumption is on there because it seems UK water meters broadcast their readings unencrypted on a band that can be read with a cheap USB dongle. I wrote some python to read the meter and push the stats into Home Assistant. I also wrote some software to run on a Pi connected to my two solar systems to read the meter information there and push it into Home Assistant.

I’m hoping once I’ve collected data for a full year, I can work out if I can get a decent ROI on a house battery.

Future Plans

One of the big things at the moment is LLMs (I won’t call them AI!) and Home Assistant can actually make use of them right now. This means I can replace all my spyware Google Homes with a fully local solution running on some low powered Raspberry Pi zeros, using a local LLM for more natural language communication. Plus you get the ability to add custom wake words, which will be fun.

I’ve also got a Pi with a 10 inch display on my desk that I want to turn into a control panel to put somewhere in the house, possibly in the entrance way.

Wow, its been so long since I’ve done a post on this blog! So, here is a list of projects I am currently using a Raspberry Pi for. Occasionally this comes up in conversation, so I thought I’d compile the list here.

• Octopi
• Klipper
• PiHole
• Home Assistant
• Frigate (CCTV)
• FlightRadar24 Plane Tracking
• 2 x Astromechs
• EmonPi Hub
• Telescope Control
• CNC control
• RetroPi
• Astropixels Demo control
• Reflow oven (wIp)
• LoRaWAN gateway
• ROS robot
• Allsky camera (wip)
• K8s cluster (4 Raspberry Pi)
• 2 x Solar PV Monitors

Then I also use one for the Droid Driving Course, with a couple of Pi Zero for monitors to display results.

The list is ever changing. I would love to run a K8s cluster at some point, but it looks like the shortage of RPi isn’t going to let up any time soon.

SDR Radios

One of the things I’ve been getting into recently is using Software Defined Radios (SDR) with cheap USB digital TV tuners that are available all over ebay, etc. These have been taking the radio community by storm as the chipset in them from RealTek can tune into a really wide band of frequencies. Usually from down around 20MHz, all the way up to nearly 2GHz.

Tracking the skies

One of the fun and cheap projects you can do is track all the aircraft that are flying around you. All commercial and some light aircraft are required to have an ADS-B transponder that sends out a radio signal on 1090MHz that contains their location, speed, etc. These signals can be received with one of these SDR dongles and decoded to display this information on your computer.

There is even a ready made piece of software called dump1090 (and many, many forks of it) that will also display this information on top of a google map.

Antenna

The first thing you will need is a decent antenna for receiving these signals. The easiest to make is a quarter wave ground plane. In the simplest terms, this means that the main part of the antenna is a quarter of the wave length of the signal. The equation for this is:

f = c / λ

where f is the frequency, c is the speed of light in m/s, and λ is the wavelength. So to get the wavelength of 1090MHz, you rearrange the equation to:

λ = c / f

Putting the correct numbers into this means that a quarter of a wavelength is just 68.8mm. This makes for a pretty small antenna.

The ground plane is just four more wires at 90 degrees to each other, and bent down at a 45 degree angle.

All these wires are then soldered into a standard SO239 panel socket.

There are many sites that will give a much better walk through of how to make one and the details behind it.

Software

Next, we need to look at the software. At this stage, if all you want to do is have a quick look for some fun, all you need is the antenna, usb stick, and the dump1090 software from one of the many forks (If found the dump1090-mutability one to be best). Download or clone this repo, and follow the compile instructions to give it a try. You should then be able to view the results either on screen or via a web browser.

The other option if you are going to go for a more permanent solution is to maybe use the data to improve a commercial sight such as FlightRadar24. This is what I chose to do, so I signed up for an account with them and followed the instructions to build a dedicated Raspberry Pi receiver that will automatically upload any information I receive to their systems, hence improving their reliability. This also gets you a full business account on there worth $500/year!

Enclosure

Lastly, if you’re doing a permanent solution, you need somewhere to put it. To save space and cost, I just used a Raspberry Pi with an decent sealed enclosure box.

I used some epoxy to glue the antenna on the end of some 20mm conduit that I had, with the cable passing down through it. Then drilled two holes in the box. One that I put a rubber grommet in to pass the power feed through, and the other to put an external antenna connector through.

Lastly, I used epoxy again to fasten some 20mm brackets to the box lid for the antenna to attach to. This was better than screwing, as fewer holes for moisture/bugs to get in through. Then I just mounted the whole thing on the side of my garage and passed a cable for power to it.

Ideally it would be placed higher, or at least the antenna would be, but that started to make things complicated. As it is, I can still get signals from planes nearly 200 nautical miles away.

Summary

Now I can access the Pi whilst I’m on my network and view all the planes around me. I also have a full business level account with FlightRadar24. Is there much point? Nope, not really apart from helping crowd source data for a company. Why’d I do it? Because I can and its fun!

This year has been a bit busy so far, and in February I realised I only had something like three free weekends to get R2 ready for his first outing, Morecambe Comic Con, a deadline I was determined to keep. Between conventions, work trips, and more conventions (including two on back to back weekends), I knew I had a lot of work to do in a short time. Thankfully, with a bit of organisation and a few late nights I finally managed to get him to a showable state. Not quite to the level I wanted, but close enough.

I utilised Github’s issue and project management tools to help organise myself, putting issues in as todo items, as well as logging things that I found were wrong as I went along. This actually helped quite a bit, and I’m going to endeavour to keep using it. I slowly managed to close off some of the items, and R2 was getting more and more complete. I managed to get the electronics and code to a level where it was stable and he wasn’t too fast to react. Had a few dicey moments when direction changes at high speed made him teeter on the edge of doing a faceplant.

And more bits were added, I got his skirt installed finally, after having bought it nearly a year ago. This however involved some fairly major dismantling of R2, which in turn meant I had to finally get the sled finished for him. Overall, I’m quite pleased with the sled, and it allowed me to lay him down gently and take his legs off to get into the base of the frame.

With the skirt all painted and in place, it was time to test the electronics with his new battery. Up to this point I’d been using a couple of SLA batteries, but these were heavy and didn’t fit in properly. Not to mention they were very low capacity. Over the last year I had been collecting old laptop batteries from various sources, and stripping them down to get the 18650 cells out of them. Once I’d tested the cells and selected the decent ones, I made a new battery pack (6s11p) which should provide 24V, with about 22Ah of capacity. A bit of metal folding and riveting, and R2 also had a battery box.

A quick reassembly, and he was back on all three wheels, ready for the final touches. However, time was getting very short indeed by this point. I had one weekend and a few evenings to get the panels on the doors, and to sort out a few other annoying little details. I’d had the idea of using sheet steel for the doors, but had trouble putting the correct curve into the metal to make it sit nicely in the door areas. If I can get this right, then the doors can be attached easily with magnets to the hinge areas, letting me remove them so I can still get the skin off if needs be. Without the right curve tho, this just didn’t work and looked rather poor. Unfortunately, with no time left I simple hot glued them in place, so that at least there was something there. There wasn’t even enough time to paint one of the panels, so was left bare. 

On my last evening to work on him, I made the decision to change the dome drive mechanism. I’d got a new, more powerful motor, but this gave me troubles with the friction drive in that the rubber ring was coming off. I did have a dome gear set, and decided to try that out (once I’d found it. The garage is a bit untidy). Turned out this was a bad idea. The motor gear is only a thin piece of aluminium, and you have to get it exactly in line with the equally thin main gear. With more time (and the correct cad file) I’ll laser cut a much thicker motor gear out of acrylic. This will make it both easier to mesh the two gears, and also a little quieter hopefully.

So, at about 1am I called him finished and went to bed. I was due to set off to a convention the next day in London. To make it even more complicated, there was another convention the weekend after in the same hotel. Rather than drive home, just to drive back again a couple of days later, I opted to stay down in London. I would’ve got another couple of evenings to do more work, but in the end I decided it was the better option.

All I had left to do was get to the convention…

Hi, my name is Darren and I’m a serial hobbiest.

Well maybe not that bad, most of my hobbies are pretty much related (electronics, computers, science), and a lot are things I’ve been interested in since I was a kid. Most recently, I’ve invested in a fairly decent telescope and mount to do some visual astronomy, but more for astrophotography. I want to take pretty pictures of things very far away! So after a lot of reading of various blogs and websites (Star Gazers Lounge forum is fantastic), and watching numerous youtube videos, I got a tripod for my camera and a couple of cheap lenses off eBay. That is all that is needed and you can get some half decent shots.

My astrophotography album

But it wasn’t enough. So I dove back into the forums and did even more research, and learnt a few important things.

• Telescope – Numerous different types, mainly split into reflectors, refractors, and catadioptric. All have their benefits and downsides, but for doing astrophotography the telescope isn’t the most important item surprisingly.
• Mount – This, for astrophotography, is the most important thing to get right.You need to have a solid mount for doing anything more than a few seconds exposure, and one with tracking in Right Ascension at least, to track the stars. And it really needs to be an equatorial mount to avoid rotation of the starfield as it rotates.
• Eyepieces – You need eye pieces to view through a telescope, and the shorter the focal length, the greater the magnification. These are generally only used for visual astronomy, as cameras bypass the need.
• Camera – Most DSLR cameras block out a large part of the infra red by design, but you can get them modified to remove this filter and get much more vibrant images. Its not a necessity, but definitely a nice to have.

Whilst learning all this, I had a thought in my head about some form of computer control (Linux based, of course) and actually stumbled upon a few projects to help with this. The first was AstroEQ which was an opensource ‘Goto’ system (select a star, and the telescope will automatically move to center on it) designed around an arduino. That was a perfect start for me, and I was pretty sure I could get it working from Linux. Thats when I discovered indilib!

Indilib is an open source system for controlling all sorts of astronomical instrumentation, not just goto mounts, but also things like auto focusers, digital camera, filter wheels, and other custom devices you may want. Even better, all this can be run from a Raspberry Pi as the control server and a laptop using the actual astronomy software. This would mean I could set it all up, and retreat to somewhere a little warmer to actually do my observations and photography. I’m sure this is against the amateur astronomers code or something, but damn it gets cold out there.

Along with indilib, there is kstars. This is a planetarium program written for the K Desktop Environment, and with EKOS plugin can control any indilib hardware. Not only that, it can schedule work and sequences, and help you plan your observations.

I’m going to (try to) write more blog posts chronicling my progress on getting all this set up, and some HowTo posts on using indilib on a raspberry pi, with kstars, and any custom hardware I make.

Its been a long time since an update, but we moved house at the start of the year and things have been hectic. At least, thats my excuse and I’m sticking to it! I have been making progress with R2 in the last couple of months, doing a lot of work on his brain for starters, and painting various parts.

Code wise, there has been a couple of fairly drastic rewrites since my last update. The interface is a REST API, which sends commands to various modules as before. I’ve added a scripting module now, so that scripts or loops can be initiated such as random sounds, or a dance routine. The servo module had to have a major rewrite too as I discovered that I could only control one servo at once and had to wait for that to finish before another command could be sent. That wasn’t much good! I’ve also written the first of the actual controller interfaces (not counting a simple web one for testing), R2 can now be controlled from a PS3 controller. Button combos are read in from a csv file to trigger certain effects or scripts. Lastly, R2 now has a voice, and can play any mp3 stored in a directory, including selecting random ones from a list of types. Next step is to get either the Pi or the A la mode Arduino to control the speed controllers. I don’t want to run them off the Adafruit i2c servo controller for safety, I’d rather drive them directly and have some form of watchdog to make sure R2 doesn’t go on a rampage. All the code is still available on GitHub under my user, dpoulson

The PDU also needed a rethink, not least of all because of the amount of current it needed. The setup now has feeds directly to the speed controllers, with relays on the output from them to the motors so I can break the circuit if needs be. These relays will automatically turn off if the battery is disconnected so that any pushing of R2 will not feedback into the speed controllers and fry them. The relays will also be controlled from GPIO pins on the Raspberry Pi so I can disconnect them via an API call. I’ll also have an input for a kill switch that will have to be permanently on if any of the motors are to be powered, possibly using a transmitter in a replica droid caller or hilt of a light saber. I’ve a base idea for the new relay controls:

 The relays I’ve found are Omron G4A-1EA, which have the benefit of the switched load being on spade connectors on the top, rather than through PCB traces, which when I did the calculations would need to be massive to support the potential current running through them. This allows me to make a simple PCB with the controller circuit, and hook the 24V battery up to it to power the coils. If the battery is removed, the coils turn off and the circuits are broken. No fried speed controllers.

The 24V connection will probably go through the fuse box I’ve installed, with a hefty fuse. The makers of the speed controllers don’t actually recommend a fuse but I’ve seen a few comments saying a 60+A fuse can’t be a bad idea, just in case!

The battery will connect directly to the center contacts of a DPDT switch, with the fuse box on one side, and the charger connection on the other. This will allow charging the batteries without taking them out of the droid. Not sure if this is best practice or not, needs more research. Currently they are just a pair of 12V SLA batteries that I had, connected in series to give the full 24V.

I’m hoping to get some time either this weekend or next, to hook up the motors, speed controllers, and battery, to test them out and get an idea of potential current draw. They’ll be controlled with a standard RC transmitter/receiver for now. If I can get the legs onto R2 he may even be drivable by xmas.

Fingers crossed!

So, I seem to be building R2 in the reverse of how most people build their versions. Whilst I started with the dome due to finding a good deal, I’ve spent most of my time working on his internals and very little on the actual physical droid. Since my last post back in August regarding R2’s brain, I’ve done a lot of work on how everything will tie together to do the control. My current working idea is to have an i2c bus running throughout as R2’s central nervous system both sending out commands, and receiving feedback.

The main control is still going to be a Raspberry Pi as this gives me much more range to do some interesting things later such as voice recognition, as well as letting me experiment with lots of different ways to actually control R2. I’m still thinking of using a PS3 controller as input, but also thinking of using a wii nunchuck is possible as a much smaller one to control simple operations.

The Pi will be linked via i2c to the various modules such as the servo controllers mentioned in my last post, with one in the dome and one in the body, and also to the lighting systems with Arduinos programmed to receive the signals to trigger various effects. I’m using BHD‘s Arduino code for the TeeCees lights in the dome at the moment, with just minor changes to accept the i2c signals. I may write something at a later date to do more dynamic light displays such as free form text messages to scroll across the RLD, but for now this is more than adequate.

Communication between the spinning dome and body will be through a 6 wire slip ring connector. 2 wires will be enough for the data signal, and then I will pair up the others to provide the power. I’ll probably have to go for two separate 5V supplies to the dome, one for electronics and one for servos as there will more than likely be a lot of noise coming over the servo power lines as they move.

Power for all the electronics will come from a simple USB battery pack, which in turn will be plugged into the power distribution board I have designed. The PDU will take in a raw input from the sealed lead acid battery (or batteries) and produce clean 5v and 12v outputs, as well as a raw output direct to the speed controllers. The PDU also incorporates a few other features such as connectors for volt/amp meters that will be behind a panel on the front of R2, a voltage divider to allow the charge bay lights to function as a crude charge display for the batteries, and also a relay cut off for recharging R2. The last means that I can safely plug R2 into the charger (via an XLR connector), which will pull power going to the rest of the circuits. Lastly, there is the main power switch to kill power from the battery. There is a diode across the switch however which should allow any charge coming from the speed controllers to go back into the battery. This is a feature of the speed controllers to allow regenerative breaking.

The clean 12v will be used to power the audio amplifier. What is R2 without a few beeps and whistles?

I’m just waiting on the PCBs to come back from OSHPark, so I can try them out. Hopefully I managed to get most of it right and I haven’t seriously miscalculated the current draw from the batteries. I don’t want any tracks melting off the board!

Code wise, I’ve done quite a drastic rewrite of the controlling software to make it much more object oriented. Each different module (servos, audio, lights, etc.) is a module with a command keyword associated with it. This means adding new modules (LCD screen, extra lighting, drinks dispenser…) should be easy and just a case of creating a config file and possibly a class file if its a new type of module. All the code is available at github, along with the schematics and board diagrams of the PDU. The PDU is also available to get direct from OSHPark.

Fingers crossed I may be getting a few parts to build the actual droid with soon, including the feet, which means I now have to figure out a drive system for him. Mechanics isn’t exactly my strong suit, so should be interesting. 🙂

Ok, so along with my R2, a side project is something that will hopefully fit inside of R2 and make him even more popular. To reprise his role in Return of the Jedi he will be serving drinks, and not just glasses from a fancy tray bolted to his shoulders. He will be able to mix a drink for you and dispense it into your glass.

The idea is, to have a bunch of reservoirs in a caddy inside R2’s main body, with pipes to an automatic arm that will open a door and raise, allowing you to put your drink under it. My design so far allows for five bottles, with peristaltic pumps from adafruit (via a UK reseller, Phenoptix), some L293D motor drivers, a TLC5940 PWM driver, and an Arduino Pro mini. I still have a long way to go on the design, but I have managed to the main module constructed and the pumps installed. I’ve also got a first revision of the circuit schematic worked out, along with a PCB layout that I’ve ordered from OSHPark.

The main unit is made from a series of laser cut acrylic sheets, with a central threaded rod as the main shaft. The bottle tops still need holes for the tubing to go into, and the lids will be glued to the acrylic. Refilling will be done by removing the bottom plate and unscrewing the bottles. I also need to figure out ideas to check for the fluid level so I get notified when a bottle is nearly empty.

The main control for selecting the drinks will be handled by a Raspberry Pi, talking over i2c to the arduino to control the motors. This will allow me to do an embedded web server for selecting the drinks, depending on what options are available. R2 will also have most of his communication done over i2c which will allow the drinks dispenser tie into that and control the door and dispensing arm. Other future ideas are also having a few spare bottles and QR codes as labels on them so that I can automatically scan them in so that the Pi knows what drinks are available rather than having to key the data in manually.

This is my first attempt at doing an actual useful PCB. Probably many errors and will need another couple of revisions, but it is a start. The Schematics and other files can be found on github here:

https://github.com/dpoulson/drinks_dispenser

And if you’re really bored and have money burning a hole in your pocket, then the latest revision of the PCB can be bought at OSHPark:

http://oshpark.com/profiles/DarrenP