Works

Tea Pot or Not?

The code for this project is published on Github

Background

I have recently admittedly been thinking about projects to work on. I knew I wanted to make something, but an idea “worthy of a portfolio piece” just hadn’t came to my mind. And then I saw a LinkedIn post (one of those cringey inspirational ones) that spoke about caring less about making grand things, and just focussing on basic concepts that you actually enjoy creating.

At that moment it hit me, I want to make a project that uses the Hyper Text Coffee Pot Control Protocol! 418 is an easter egg HTCPCP/1.0 status code, that indicates that the server is unable to brew a coffee, as it is indeed a teapot. I started to ponder what I actually wanted to make, and then came across two Github issues (Go, NodeJS) where some boring developers wanted to actually…get rid of the easter egg HTTP code…to make space for extra ones in the future…what?!

I then stumbled across the Save 418 Movement and realised that heck, even Google implements the 418 status code… I HAD to join in and make a “useful” application of the 418 HTCPCP/1.0 protocol…

Tea Pot Or Not?

So what actually is this application? Well put simply, it’s a basic Flask API that you provide an image to, and then it will return one of three messages:

• 418 I’m a teapot
• 200 Here’s your coffee
• 200 I’m not a teapot

The messages will be driven by the provided photo, by using machine learning to detect if the image contains a photo of a teapot, a coffee machine or neither.

Implementation

Honestly, I could’ve used this project as a grand plan to learn how to create, train and validate machine learning models in Python, but I wanted to create the project in a few hours…There’s plenty of time to learn about Machine Learning models in the future, but in my hungover state at the time, I just wanted to quickly slap up an API to determine if something is a teapot or not! 

With the above in mind, I started to research a bit about pretrained Machine Learning models. I first found an image dataset called Open Images V7, which has generously been placed in the public domain and contains literally millions of pre-annotated images ready to be used for training machine learning models.

At this point, I wanted to try and download a subset of the data (specifically just teapot images and coffee machines). I searched tons and tons of guides on doing this, but eventually I got bored of all the console errors I was getting.

Scrap that plan… On to doing what a developer does best, and just copying someone else’s work. I discovered a Github repo for Ultralytics which provides it’s owned YOLO state-of-the-art model that has been trained on the Open Images V7 dataset. Following a few examples, I started to play around with it in a new Python file.

Now all I needed to do was build an API that can accept a file via a BREW/POST API request, and then classify the objects in the image, and return a response based on the result.

The End

And that’s it really, the resulting code is published on my Github. I don’t actually think there is anything to show off here, just under a hundred lines of code that “borrows” someone else’s model and returns a response on it. The only real learning from this project was some extra context on the basics of machine learning models, the desire to learn more about machine learning, and most importantly…The history of the Hyper Text Coffee Pot Control Protocol. 

Rest assured, I’m diligently looking for any opportunity to implement a HTCPCP/1.0 418 response in my current companies codebase, probably an internal tool or something… Thanks for reading!

Gaze Detection

The code for this project is published on Github

Project Summary

 The idea for this project was born from an issue I regularly see in video calls, whereby when a person has multiple monitors and isn’t looking at the one with their webcam attached, the rest of the people in the call are stuck looking at the side of their face, which gives the impression of them being disinterested and it also reduces the immersion for everyone else on the call.

 I had a couple of webcams laying around so I decided to put two of them on different monitors, and attempt to make a program that automatically switches between them based on the monitor a person is looking at.

Implementation

 The full details can be seen on the Github repository for this project (linked above), however as a brief overview the project uses something called Gaze Detection, which is an area of machine learning research focussed on trying to detect where a persons eyes are looking.

 Using a pre-existing Python module called Gaze Tracking, I have been able to make a program that passes in frames from different camera sources and then gets back an estimated value of where the eyes are looking (relative to the camera). Using these returned values, my program simply selects the camera which a person is most likely to be looking at based on the gaze tracking estimates.

 The bulk of my own code simply just interfaces with the gaze tracking module, and compares readings to then try and select a webcam feed to pipe through a virtual camera – that can then be selected in video conferencing apps. My program also does a variety of things to try and improve the reliability of switching – so that cameras do not flicker between each other really fast – these measures include adding a timeout before switching, and gathering the average of readings over a set measurement period to have more data to be compared when considering which camera should be selected and piped through the virtual camera.

More details can be seen on the Github, and I am continuing to explore different ways to improve the reliability of the program.

Demonstration

https://youtu.be/kMjx8XlOlno

WiFi Bottle Opener

Project Summary

In December 2022 it was fast approaching Christmas, and I realised I hadn’t got my Dad a present yet. I wanted to get him something memorable, not just a boring pair of socks. I remembered we used to have an Elvis Presley bottle opener, that would sing “Viva Las Vegas” when opening a bottle…We all found this hilarious, but one day it broke.

I set out on my quest to find this bottle opener, but found nothing. It was a really old product, not being sold anymore. Time to make one!

Investigation Phase

Initially, a bought a bog standard singing bottle opener from Amazon, with the hope that I could figure out how it actually works. I tore it apart and found a basic sound module, that I had zero idea how to program. I did find some useful information though, in that the part of the bottle opener that touched the bottle cap was split into two metal sections, and essentially the metal bottle cap would complete a circuit that triggered the musical sound.

Initial Concept

I couldn’t reprogram the bottle opener I had purchased, so I decided to tear all of the electronics out of it, and purchase something called a “Programmable Sound Module” on Amazon. These modules can be programmed with a button and a microphone, and then once you have programmed them, you can just disconnect the microphone and button assembly so that it fits into your ideal card / case or whatever you are using it for…Unfortunately this didn’t fit the bottle opener.

So, I can’t fit a normal sound module speaker in this thing…Project doomed.

Second Concept

At this point I stepped back and had a think. I can’t fit a speaker inside the case, so what can I do? I tried to think out of the box, and then it literally hit me…Have the speaker outside of the bottle opener.

A bit of extra thinking later, and I settled on using my kitchens Sonos sound system to play the music. But how would this work?

Design / Implementation

I first started to figure out how to tell that a bottle was being opened, so that the “Viva Las Vegas” song could be played on the Sonos system. I realised I could use an RF transmitter, that would easily fit inside the bottle opener, and then receive this signal with a Raspberry PI and use some magic to get sound playing.

After deciding the above flow, I next purchased an RF receiver and transmitter from Amazon. I then started to do some research into the GPIO pins that my Raspberry Pi 3 had, as I had only limited practice of using them before this project. I knew that I would need to use them to detect when the receiver was detecting an RF signal.

Following on from this research, I produced the following basic electrical diagrams for my interpretation of how the components would interact on both the bottle opener side, and the Raspberry Pi side.

At this point it was time to start thinking about programming. To be honest, I started with a nice clean Github repository, and then I gave up pulling/fetching it to the Raspberry Pi and just started locally developing and debugging on the device. I’ve since lost the SD card that the OS was on and I also cleverly deleted the repository…

Essentially the code used the RPi.GPIO library to detect inputs from the 5v GPIO port connected to the receivers VCC output. I used SoCo to connect to the Sonos speakers, and the device would spin up a media server with the song to playback, and then on each receiver input, SoCo would tell the local Sonos API the location of the selected song to play.

During programming, I of-course had to set up the hardware as-well. Debugging usually takes a while, and if I had opened a can of beer each time I tried to test the thing, I probably wouldn’t be alive to tell this story. Instead, whilst locally testing I just hooked up the transmitter module to a button. Once I had finished debugging, I then put the transmitter module inside the bottle opener and soldered it to the existing contacts.

I don’t actually have any pictures of the Raspberry Pi and receiver, but I have managed to find a video of myself showcasing the prototype. You’re going to have to ignore the fact that I’m using my finger to test the unit, I wasn’t really thinking about publishing this video when I made it…

You will notice that the status LED is constantly flickering due to the RF noise being picked up – more on this later – but the LED completely turns off when the bottle opener contacts are connected.

Challenges

There where many challenges with this project. The first major challenge was the time pressure I placed on myself, having committed to this being the sole present for my Dad, I couldn’t just accept tons of his gifts on Christmas and then present him with a pile of electrical junk…

The first technical challenge was clearly not being able to find a small enough sound module to fit inside the bottle opener, leading to the thought of using an RF transmitter instead – and thus a vastly larger and more complex project scope.

The second challenge was learning how to solder…I had a tiny amount of soldering experience before this project, but the bottle opener casing I had, used tiny wires to connect to the contacts, and every mistake would just make them shorter. I didn’t have a second case to play around with, so I was facing quite some pressure to get solders right the first time around. I practiced soldering by just connecting small wires I had from a Raspberry Pi kit, before attempting the real thing.

The third and final challenge was unfortunately not solved before Christmas day. I had not anticipated the amount of RF interference in a typical house. When thinking back, it is clear that this would be an issue given my home uses lots of smart devices. Whilst you can physically see the LED flickering in the above video and then turning off completely on the bottle openers contacts being connected, this was extremely hard to determine in the code as I could not figure out how to determine the voltage being detected from the GPIO pin, instead it seems that the library I was using only supported telling me whether the contact was powered or not…I may have got this wrong, but at the time that was my conclusion.

Essentially, when the device was powered on, it would seem to work as normal, but every now and then the Kitchen speakers would randomly erupt with “VIVA LAS VEGAS”, not exactly great! I am now aware that there is a mechanism to set specific values in the RF signals, so that the transmitter and receiver can be more accurately “tuned” if that is the correct word.

Closing Notes

Overall the project was a slight success, but it could definitely be turned into a success if I where to approach it again.

If you’ve read this far, thanks for sticking with my writing! I feel I’ve rambled a lot here, and would really love some feedback to help improve my writing style as I continue to publish more of my old projects. Send over any feedback to: contact@jackdevonshire.co.uk

C# Savings Calculator

The code for this project is published on Github

Project Summary

Having recently re-joining my placement company as a graduate developer, I realised I needed to plan how to save my money – after-all I had spent the past 4 years living in my overdraft like a typical student. Cobbling together some Google sheets formulas, I managed to find an ideal allocation of savings accounts for me. With my savings strategy sorted, I realised that banks of-course change their rates, and also most introductory AER rates only last for the first year, so I would need to change my strategy yearly – or potentially more often. 

I could of-course have just cobbled together new formulas yearly, but as a developer I had gained an interest in how I could model how various savings accounts work over time…

The Solution

Every Friday, my company designates the afternoon as Kaizen time, a Japanese phrase that translates to continuous improvement – in a way this perfectly fits in with the companies Agile approach to project planning and development. I decided to use this Kaizen time one afternoon to develop the framework of a C# application that can model the rates of various types of savings accounts.

The solution isn’t some fancy web app, or even something with a user interface – although it could progress to this if I decide – but instead it is a collection of classes that model the basics of how various different savings accounts work. These classes can be created, interacted with via deposits, withdrawals and setting up monthly deposits, and then each class has it’s own calculation logic that will calculate the expected earnings by a set period of time, given the above deposits and withdrawals.

At the time of writing, the project has served it’s purpose for me, and resolved my curiosity of how savings accounts may be modelled in C#, however I may very well choose to expand it. Follow the projects progress on Github.

McFlurry Finder

The Problem

McDonalds are always out of McFlurry’s! Now it sounds funny, but it’s a genuine problem that every McDonalds branch across the globe struggles with.

McDonalds has a contract with an ice cream machine manufacturer (Taylor), where they are legally bound to purchasing Taylor ice cream machines, specifically the Taylor C602 model of ice cream machines, in this contract, they are also legally required to ONLY use Taylor certified technicians when these machines break – a kick in the teeth for right to repair, but lets not get in to that.

In and of itself, a contract described above would only cause issues if machines regularly broke. Well, that’s exactly what happens! The Taylor C602 requires a 4 hour cleaning cycle every night, and often times, ambiguous error messages pop up, requiring McDonalds to call in a Taylor certified technician to diagnose and resolve the problem.

Anyway, unfair contracts are McDonalds problem. I just want to know where I can drive to get my ice-cream, and where I can drive to get it NOW!

The Solution

Now, this project was inspired by mcbroken.com but I will be the first to admit, I am not as smart as its maker. McBroken works by misusing the official McDonalds API that powers its smartphone apps (the maker reverse engineered the android version of the McDonalds app).

Unfortunately this site only works for US McDonalds branches, so I needed to get creative. How about the UberEats API?

Step One

Explore how Uber Eats gets it’s information on what products are available. To find this out, I simply went to the Uber Eats website and selected a random McDonalds branch in Liverpool (where I was at the time), for this case McDonald’s Kensington.

In Chrome developer tools, I loaded up the Network monitor and filtered by Fetch/XHR requests. I found a request that seemed to return all information for a particular store, specifically:

• POST https://www.ubereats.com/api/getStoreV1?localeCode=gb with a body consisting of two parameters (storeUuid and sfNuggetCount)

Now I have no idea what sfNuggetCount is, but I now have a way to obtain a stores unique identifier, and retrieve it’s information, including products.

Step Two

Analyse the response. I copied the response from the above request in to a JSON pretifier. The request is rammed full of data, but I found that navigating to data -> sectionEntitiesMap there are a bunch of sections (used to separate categories of food), and if you loop through these sections and the items in them, you will eventually find McFlurry products.

Step Three

Process the data. I made a Python Program that loops through a list of curated store Uuids, and sends requests to the endpoint identified above. This program then loops through all of the products, until it finds a product with a title containing the word ‘McFlurry’. Each product object returned from the Uber Eats API has a field ‘suspendUntil’, now if this field is set to 0, the product is available, however if it is set to a date in the future, the product is not available.

The program then stores the results from all the API calls for each separate McDoanalds I have specified, and then uploads this data to a .json file via FTP to a webserver.

Step Four

Display the data. Now I am no UI designer, or front ender for that matter (apart from the few tasks my placement supervisor occasionally made me do, AngularJS gives me the chills to this day).  With this in mind, I found a simple HTML template online, and displayed the data from the JSON file specified above.

The End Product

The end product is shown below. Unfortunately at the time of rewriting  this portfolio, Uber has updated their API endpoints rendering the previous code broken. I’m not quite as desperate for McFlurry’s anymore, but at-least we know that on the 5th January 2022 all but one of Liverpools major McDonalds branches had working ice-cream machines!