Context
With the return to the office post-covid, the workplace has changed into a hybrid of old expectations and new habits formed during the mandatory Work From Home requirement of the pandemic. This has created some interesting changes to the communal environment at work.
Within the new normal of a loud, internet-connected office buzzing with the chatter of many co-located conversations and the old habits of cross-desk conversations encourages the use of headphones to cancel these noises or to drown them out with the sounds of a calm waterfall or racing game soundtracks from the early 2000s.
It is no mystery then why instant messaging platforms have become the default foundation of workplace communication, both in the office and out. Here is where I wanted to begin exploring this new interaction. Given my existing interesting Tangible Interfaces and Ubiquitous Technologies, it became an interesting design space to explore.
One such activity that is particularly important in a design and research studio like Spotless is sharing the fresh brew and conversation of the communal coffee pot. Problems take on new perspectives and trading stories act as a healthy balancer to restore your equilibrium, refreshing you for whatever is next on your ever growing list of tasks.
Based on a conversation about the joy of useless slack bots, the kernel of an idea had formed. A device that could detect a fresh pot of coffee, and send an alert through the workplace platform of choice to encourage these impromptu conversations.
Planning
I knew that I wanted to make a physical device that would be able to take up counter space and provide some form of immediate response to encourage the coffee maker to use the device. I decided early that I wanted the housing for the device to be made from 'found' materials. In keeping with the coffee theme, I decided to make use of some instant coffee containers I'd been using for storage.
The basic task flow was as follows:
- Person makes coffee in coffee pot
- Person puts now hot coffee pot on device
- Device detects temperature change
- Device sends an alert to a communal Slack channel making everyone aware that there is a fresh pot of coffee
- People come and get the fresh coffee
Simple right? So that’s where I’d start……but what if someone is at their desk and misses the initial alert and wants to know if the coffee is still fresh?
Well, that would look something like:
- Person A makes coffee in coffee pot
- Person A puts now hot coffee pot on device
- Device detects temperature change
- Device sends an alert to a communal Slack channel making everyone aware that there is a fresh pot of coffee
- People come and get the fresh coffee
- Time passes
- Person B was in a meeting, but now sees the Fresh Pot alert and wants to know how fresh the coffee is.
- Person B asks the device if the pot is still fresh.
- The device returns information on the temperature and brew age of the coffeePerson B decides if it’s palatable or if they should make a new coffee.
Approach + Doing
Tech Stack
Fresh Pots Bot
- Raspberry Pi 3B+
- Python3
- Hardware interface libraries for the temperature sensor and display
Backend
- Firebase Realtime Database (NoSQL)
- GCP Cloud Functions with a Node.js runtime
####Slack App
- Configured to accept slash commands and post to a request url that's set to the GCP Cloud function trigger.
- Webhook to receive posts from the Fresh Pots Bot for the initial alert.
Technical Detail
As the main face of the project, I decided to explore the physical device of the Fresh Pots Bot first. I had a Raspberry Pi 3B+ with WiFi capability that was crying out for a purpose. Loading Raspbian onto it and configuring it for remote access from VS Code was the first step. From there I began to construct my circuit diagram and pseudocode for the read loop.
Using the GPIO interface on the Raspberry Pi, I connected a Waterproof DS18B20 temperature sensor, and a 128x128 RGB OLED display module. This would be the basis of the overall sensing and in-person output for the individual making the coffee. Setting up the hardware was relatively straightforward and required minimal configuration between the python script and the GPIO mappings to get everything in working order.
I did deviate to do some fun rendering on the OLED display module inspired by having just watched both bladerunner movies and Alien back to back. There’s nothing quite like 20th Century Sci-Fi interface design.
After this, I was quickly able to get the components reading temperatures from the room, and then began to implement the on-board logic.
The Slack App for receiving and posting the temperature data in slack was again straightforward to put together on the internal Slack workspace. There is a useful tutorial on their website that walks through the basic formatting and settings for apps configured with message webhooks. The time consuming part of this was deciding on the correct messaging format but that came later.
The basic mode of operation for sensing and logging from the temperature sensor is:
- Every 30 seconds, scan the temperature
- Add the temperature to a rolling window of the previous 10 readings
- If the new temperature deviates by a set amount from the previous 10 readings, then
- Every 10 seconds, scan the temperature
- If the temperature continues to rise, then
- Post a JSON payload to the Slack App webhook to put a formatted slack message into the desired Slack channel.
- Render a joyful gif on the display module, then write the current temperature of the coffee pot and the time elapsed since the alert of fresh coffee (brew age).
- Return the read rate to 30 seconds
- If after a set period of time, or if the temperature drastically dips then
- Set the pot to Not Fresh in any queries and on the display module.
- Return to line 1.
I was able to begin real-world testing with my filter brewing carafe which worked exactly as I had expected, although I did have to spend some time setting the trigger temperatures for the thermal properties of the glass carafe.
Querying
Bolstered by this initial success, I moved on to implementing the querying capabilities. I knew upfront that I wanted to eventually introduce new functionality once I had an initial set of usage data to analyse. Therefore, I needed a data store that I could rapidly write to for every sensor read and that could grow and extend as new features were introduced (more on this in the Next Steps).
To do this, I decided to go with the Firebase Realtime Database and the GCP Cloud Functions as I wanted to try Google Cloud Platforms and it provided many options for analytics and machine learning once I gathered a large enough dataset. The Carbon Neutral options for hosting were also a factor, if the option is there then I’ll take it!
The on-device logic didn’t require drastic change, only the introduction of a WRITE step to log the temperature data into the Firebase Realtime Database with some additional configuration to handle the initial authentication and token refresh during operation.
The new mode of operation for sensing and logging from the temperature sensor is:
- Every 30 seconds, scan the temperature
- Add the temperature to a rolling window of the previous 10 readings
- If the new temperature deviates by a set amount from the previous 10 readings, then
- Every 10 seconds, scan the temperature
- If the temperature continues to rise, then
- Post a JSON payload to the Slack App webhook to put a formatted slack message into the desired Slack channel.
- Write the current temperature to the Firebase Realtime Database to allow slack command queries from the Cloud Functions.
- Render a joyful gif on the display module, then write the current temperature of the coffee pot and the time elapsed since the alert of fresh coffee (brew age).
- Return the read rate to 30 seconds
- If after a set period of time, or if the temperature drastically dips then
- Set the pot to Not Fresh in any queries and on the display module.
- Return to line 1.
Now that I was capturing the data in a centralised location, I could begin to build out the backend to allow queries from Slack. This is where the GCP Cloud Functions come in; by setting up the cloud function to receive incoming requests, I could trigger it with a Slack slash command to run and query the most recent entry in the database and return a JSON payload with the data in a formatted slack message.
This was really rewarding to work on. The satisfaction of closing the loop on the Fresh Pot Bot’s physical component felt like I’d setup the project for whatever additions I wanted to make in the future. With this complete, the prototype was ready for the office.
Feedback + Iterating
Throughout development, I tested the device using a glass carafe that I use for filter coffee. This worked well as a test device as I could get readings very quickly. However, when the Fresh Pots Bot made it’s office debut, I quickly discovered that the cafetieres we use were extremely well-insulated on the base. This makes sense. The cafetieres were designed to hold a lot of hot liquid and be placed on various tables and surfaces. The insulated base therefore protects the tables from burning. Side tables everywhere rejoiced meanwhile the Fresh Pots Bot couldn’t sense a thing.
Iterating quickly, I fabricated an addition to the housing out of a second coffee container that I had previously experimented on. Using this I fashioned a fan-like aluminium bracket that would ‘hug’ the cafetiere and conduct heat through it’s much less insulated sides. I then attached the temperature sensor to the back of this bracket for a better reading.
With this initial problem solved, I quickly discovered that the thermal transfer of the cafetieres was much better than the glass carafe and so I had to adjust my moving window and temperature increase triggers to accommodate this.
Learnings + Next Steps
Overall I was pleased with my strange little device. It could alert people to fresh coffee using a basic temperature sensor and allow them to check the status of the coffee at any given time. There was of course room for improvement and I learnt a lot from both my development experience and the research of watching people interact with the bot. I’ll now go through some of my thoughts and plans for next steps here.
Interactions
When I watched people interact with the Fresh Pots Bot, there was an ambiguity in when the should place the freshly hot cafetiere onto the sensing area:
- When the water was first poured, but before the strainer was plunged;
- Or once the cafetiere was strained and the coffee was ready to drink.
Either way the detail is that of a few minutes but it was still interesting to me. I have designs on my next immediate feature is to integrate a weight sensing capability that can sense the weight of the cafetiere and trigger a brew timer that will alert the individual of when to plunge before then sending the message to the Slack channels. This is of course a cafetiere specific problem so perhaps I will set it to detect different weights of containers and make a judgement on the protocol to run.
Note: the above could be achieved with Machine Vision but as this is a communal space for conversation, I have no desire to create what may be perceived as a surveillance device.
#### Data I want to integrate my coffee data with other sources of data from the office such as calendar data for in-office meetings. I think this might be interesting to begin creating trends and integrating a gentle ‘nudge’ into the overall interaction when the bot thinks that the office could do with a fresh pot of coffee.
I would also like to implement some form of report at the end of a month or week with details like ‘this many cups drank’ or ‘There’s more coffee drunk during days with this client.
’’Natural Language Descriptions
Finally, this project is all about joy and delight. I was trying to find creative ways of building interactions that can provide a bridge between the various modes of interaction that exist in the modern office space. With the expanding usage of AI’s like ChatGPT in the workplace I scoped a feature that would use ChatGPT to describe the status of the coffee pot instead of a message I had constructed. This was a lot of fun to do but I found in my testing that it would give strange descriptors for temperatures or brew age that didn’t correlate with what a human might say. Still, with the recent research form Marti A. Hearst featured in ACM Communications on the potential for NLP in describing graphs and data visualisations, I can see potential to integrate ChatGPT in the future for the end of month reports.