Paddy's Cakes

The world of Cakes is a fickle one, and as unpredictable as the rain...

My housemate (Paddy) makes cakes, absolutely fantastically delicious cakes. He has a couple of regular customers (cafes), but struggles with confidence, motivation and planning. I want to see him succeed and my local city-centre cafe to always have a slice on hand for my delectation...

To help out a friend in need, in the past I setup a simple spreadsheet to help with planning ingredients, but there was still the problem of the busy cafe not relaying their stock-level on a regular basis, made worse by group meetings at the cafe where whole cakes would disappear. As a result Paddy has missed some potential opportunities to up-sell to his existing customers, due to not having a stock-sensitive system for re-ordering.

He has also expressed a desire to simplify from his free-style offering into a set menu of 10-cakes with the occasional seasonal (or whenever he feels like creating something different) special. This could be configured in a web-based interface for Paddy, and also an End-User (-think cafe-) portal for re-ordering and potentially billing. Automatically declares Cake past Best-Before date, emails Cafe at end of day and Paddy.

The Solution:

It seems a multi-part solution would be best...

1) An online stock ordering and ingredient management portal. Potentially for Paddy, and a separate area for his clients.  This portal could be reused for other businesses as opposed to cake, or even franchisees with no IT skills.
 
2) a) A physical product that will estimate cake consumption and support TARE.
   b) Report back to cloud / Paddy based on predefined range, trigger alert.
 This could be a single master controller for multiple (2a)

So ignoring the potentially endless task of designing a flexible web-portal for stock management and ingredients planning, with attached End-user portal for re-ordering of products, we will instead mock this with the simplest implementation until we have identified if it is a viable solution.

// Leave ourselves a to-do about portal:
//TODO: Find existing portal solution (of which there are many)

I will setup an IOT trigger, which will eventually be linked to an email / telephony (twilio etc) alert system, for each cakestand reaching 75% cake consumption. Paddy will receive a communique at 4pm each day, in time to shop for the nighttime's cake production.

By weighing the cakes after production, the system can "know" which cake has been placed on which cake display stand.

Build Plannig Time:

A Cake Display-stand: Consisting of load-sensor, optional re-settable slice counter, Tare-button, Battery-powered, Doily re-ordering support, easy setup for end-user or Paddy.

Potentially one cake stand would be the master controller, with WAN access (internet) either through wifi and ideally mobile-data connection. There would then be an unlimited amount of slave cake display-stands which sync to master with Bluetooth or Wifi, or during initial trial wired connection.

Ideally the microprocessor would be an ESP32 for each slave cakestand, Preconfigured by Paddy using the portal to create a local group of End-user cakestands called a DisplayGroup (collection of cakestands in one area at least with 1 master all on same wifi network).

Future version will include detection of removing one half cake from a cakestand onto another half empty cakestand. This will require pressure areas rather than one area, possibly achieved with custom scale pans (eights of a circle) and button load cells configured to notice the large addition in weight across the load areas.

Theory:

Load cells are strain gauges or equivalent to potential divider circuits with one resistor changing according to force (strain in this case ;) ). They are super sensitive and cause millivolt changes. There is plenty of information on them and the relevant topic of Wheatstone bridges. I've got mine from an old Swan 5Kg kitchen scale, it's a single 4-wire load-cell bar with base and plate through-hole threads at each end and the figure-of-8/double-circle hole in the middle. I've managed to keep the base and top-plate from my scales.

4-Wire Load Cell Wiring Colour Guide: http://www.controlweigh.com/loadcell_colors.htm

If you have multiple sensors like from a bathroom set of scales, they'll probably be 3wire and you can use the load cell combinator as I have diagrammed in Fritzing.

3-Wire Load Cell Guidance: http://electronics.stackexchange.com/questions/199487/connect-hx711-to-a-three-wire-load-cell

Now onto reading them... The prototype wifi-enabled board I have available is either a Raspberry Pi3, or the Dragonboard 410C, both of which follow the 96boards open hardware consumer board specification allowing complete interchangeability. Sadly neither have a suitable way of reading the strain gauge due to lacking an ADC, and really we shouldn't use them for the HX711 mentioned later due to the timing required in communication and them not running a real-time-operating-system in my setup. Most cheap System-on-chips ADC's (analog to digital converter) like my alternative ADC on the arduino nano have a poor sensitivity, the arduino nano has a resolution of 10bits (2^10=1024 steps) so instead we use the HX711 24bit ADC designed for load cells. They are cheap as chips, and come with shielding if you're lucky. I got 2 for less than €5.

Now we simply hook the load cell to the hx711, and either straight to GPIO or via a logic level converter to the raspberry pi3's low speed connector ( or another 96boards device) where we can also get to GND, 5V and GPIO. When using the low speed connector we need the logic-level-converter because the 96boards.org Consumer Edition spec dictates we should assume all logic levels at 1.8V unless otherwise stated by Manufacturer. Now I think they vary much like arduinos(between 3.3v/5v) but the converter solves the problem. Just make sure to pickup one that is bidirectional, supports SPI and is fast enough for your other future needs. My needs are basic, 1 sample per few minutes is probably too many, I'd be better sampling as infrequently as possible for battery life, and possibly using a vibration sensor as well as timer interrupt.

I'm going to calibrate my scale with jugs of water because super accuracy is not a major concern in this prototype. Depending on the code library to access the hx711 you will find it calibrates to zero on initialisation or pumps out an average and this should be saved as the offset, but the scale factor will be unknown so we should also test with known weights and amend the library's defined default values for scale and offset. Follow an appropriate guide written for your library.

Remaining Components:

Now we hookup some buttons for increasing and decreasing the slices of cake for when the cafe adds a fresh one. Also the new cake button, and a 2digit display for slice count (or cupcake count if mini cakes).

A load of batteries in parallel will solve most issues about current requirements, especially in the prototyping stage, and based on timing or a battery voltage sensing component we can set an appropriate re-ordering frequency on Amazon Dash Replacement Service.

Final Thoughts:

Lets be honest, no-one likes to maintain things properly anymore, software is no exception, and when it possibly involves networked communications we should take it very seriously. For this reason I will be committing software and firmware updates remotely via a 3rd party managed service so I can let someone else automatically patch my systems as new exploits are discovered and avoid being responsible for a million machine cake-based-botnet...

-- To be updated...