Problem

V-Zug smart cooking devices are digitally advanced and energy efficient, but only work for a limited V-Zug provided recipes. Open Food Data + Smart Kitchen Chanllenge No. 7: Unified Food Platform

Solution

Find, filter and Integrate desired recipes from other databases and make them available in V-Zug end user App and usable within the logic of the V-Zug smart kitchen machines.

Achieved

Enriched Babel ZUG platform was created:

• contain 188 original V-Zug recipes + 231 recipes of Nestlé (+120% in 2 days)
• each recipe could connect to V-Zug device according to cooking instructions

Created a convincing case study for more open food data:

• enable cooking experience for end users more enjoyable
• enable high quality kitchen device manufacturers sell more products
• ensure food providers who care about quality have larger market share
• overall positive impact, win-win for all parties involved
• it is technically feasible

How could the future look like

• A unified food platform for the end users when they think about food and cooking.
• Adapt recipes for end users specific food needs, like allergies, vegetarian, food co2 footprint awareness, etc.
• Automated import and conversion of any recipe to use with V-Zug Machines
• Automated online shopping
• Food Profiling
• Food Journals
• Nutritional Information and tracking

Presentation

https://1drv.ms/p/s!Aj_hYoIcf3UThgmtSWMgcb6w2SsA

DEMO / SLIDES

Forgetting food in the fridge is a common cause of foodwaste.

‘Beat’ reminds you before your food expires and provides you with recipe-recommendations based on your inventory.

Beat the Foodwaste !

EatInDer is an app for all the Eaters tired of searching for the right meal, fed up with looking for the vegetarian option through random websites. For Eaters who think individual meals should be rated, and not just the restaurant. For Eaters who care about having data at hand, like whether the ingredients are sourced locally. EatInDer is for Feeders: get a search boost if you specialise in a certain category, understand demand - and get to the right place and time without the costs of market research. EatInDer is for food that clicks with you!

WIREFRAME / DEMO

Food Matters

---

Why

Food waste is a problem we can all relate to. To tackle this on a personal level, we needed to do research first and take a look on a global scale.

We came to the conclusion that food waste is a much bigger problem to begin with. To name a few:

• Economic: Yearly loss of between 780 billion – 1 trillion dollar.

• Climate: If food loss and waste were a country, it’d be the 3th largest greenhouse gas emitter after China and the US.

• Natural resources: Loss of water, oil and land.

• Biodiversity: Land conversion to agriculture is one of the greatest threats to global biodiversity

The perfect example to identify our problem with was given to us by Lander (but we can all relate): You lookup a recipe, it tells you 20+ different ingredients, you go to the shop, buy everything and cook it. That’s when you end up using 1 tablespoon of maple sirup. That bottle of maple sirup is still in your fridge and you have no idea what to do with it. Everyone has this problem on different levels but we hate throwing away food.

We believe that every piece of food in your kitchen has some serious potential.

That’s why we came up with FoodMatters!

Key features

FOODMatters generates a meal plan for a specific period of time with bulk-bought ingredients that will be completely used.

• Efficient meal planning with ingredient memory.

• Personalized meal suggestions for specific amount of days.

• Grocery shopping listbased on your selection.

• Easy step-by-step recipeswith smart kitchen timer .

What

• Frederic (Design) wrote out the concept flow followed by low fidelity wireframes (Paper). Decided the scope of the project together with the team. Made 3-4 visual concepts in sketch ( High fidelity) chose one and turned this into a clickable prototype

• Roberto (Mobile) checked out some possible data that could be used for future implementations and integrated the kickass AI/ML backend that Lander provided together with the fancy designs of Fred into a working iOS prototype.

• Lander (Backend) looked at the different APIs that were provided and wrote an algorithm to match ingredients between recipes. He also provided all the data that was needed to be displayed in the app.

• Ancy (Business) made sure we had a professionally structures powerpoint presentation. She took over the business side of the project.

Challenges

• Defining the scope of the project. We had so many good ideas that it was a bit hard to focus.

• Matching recipes with meaningful others. We needed to exclude salt, pepper and others

• We only had a limited amount of recipes to work with

Status

• Backend of the working algorithm matching the recipes is up and running.

• We have a working iOS prototype you can play around in.

Future

• Additional dietary preferences(e.g. vegan, vegetarian, low-carb) and allergies.

• Refrigerator feature to manually add food for recipe suggestions

• Integration with home delivery services (e.g. Coop@home)

Who

Lander Van Breda (lvbreda@gmail.com)

Roberto Dries (robertodries92@gmail.com)

Ancy Mechelmans (ancymechelmans@gmail.com)

Frederic Berghmans (fre.berghmans@gmail.com)

DESIGNS / SLIDES (PPTX)

The DigiMeals Open Recipe API provides access to a set of structured recipes. In the current state, the API only provides two endpoints where one returns a very limited info about a list of recipes and the other sends a lot of data about a single recipe in one request. To get relevant data for a list of recipes a client has to send a separate request for each recipe in the list. Then, additional data from other data sources needs to be collected to show a short info about the recipe in the list. This causes the client to make multiple requests to the API and other sources just to show the list with a few details.

The goal of the project is to suggest and design a different structure of the recipe data each API endpoint returns and to make the API calls much easier.

Source code

Background

The DigiMeals Open Recipe API provides access to a continously expanding set of fully structured recipes. These recipes include not only the directions and ingredients as a text but also detailed parameters for each recipe step. The parameters provide easily accessible data to show users additional information, create new features or conduct analyses. The structured recipe data is particularly useful for connecting with smart kitchen devices or integrating into an ecosystem of applications or devices.

Impact

The Open Recipe API has already been used as basis for several projects at the hackathon, e.g.:
Food Matters
BEAT the food waste
Standardized Meal System
With the here suggested improvements, more projects will be able to use the API in an easier manner.

Further development

The API will be continously expanded and improved. Initial feedback was collected during the hackathon and any kind of feedback or issues can be raised on the GitHub repository.

Just looking around:

1) Come to venue, see Wi-Fi password

2) $ ifconfig => my IP, e.g. 192.168.0.23

3) $ nmap 192.168.0.0-255 -p 80 => e.g. 192.168.0.42 looks like an oven

4) Access 192.168.0.42/Network.html => Sicherheitseinstellungen => set user "admin", password "hacked"

Let's add SSL/TLS and remote access:

5) https://yaler.net/ => RELAY_DOMAIN

6) https://yaler.net/macos => ./yalertunnel installed (would run right on the oven MCU in a real deployment)

7) $ ./yalertunnel server 192.168.0.42:80 ssl:try.yaler.io:443 RELAY_DOMAIN -min-listeners 8

8) Access (from everywhere) https://RELAY_DOMAIN.try.yaler.io/

9) E.g. on your phone https://chart.googleapis.com/chart?cht=qr&chs=150x150&choe=UTF-8&chld=H&chl=https://RELAY_DOMAIN.try.yaler.io/

(Full disclosure: I'm a founder of Yaler)

The Problem

Many of the platforms for recipes have the approach to be like an online cookbook or search engine for recipes. They are mostly not structured around the idea to be part of your life or support you technically with your daily decisions.

The Vision

Lucia is eagerly looking for platforms which support her needs to plan her meals and nutrition for a long period of time. A platform which not only considers a single decision, like what is the next meal for today, but help with the questions like

• what are the meals for the week
• what is the impact on my diet
• what are the ingredients I have to shop

and already anticipating some constraints by knowing which cooking tools she has, or ingredients she likes or dislikes.

The Challenge

For that reason we teamed up for challenge #1 from DigiMeals.

We wanted to show in a prototype how to

• filter the avaibale DigiMeals data
• to select the meals for a week
• combine it with nutritional data (from the Siwss Food Composition Database)

and as result be able to get the grocery shopping list and the weekly plan.

In the end we had to compromise with the nutritional data and the simplicity of the prototype but it was workable.

The Participants

Lucia Caiata and Michael Werlitz met at Friday for the first time to tackle this challenge. And we did.

Link to Presentation (via GitHub)

Challenge #1

An attempt to enable hands-free operation of a V-ZUG Combi-Steam XSL.

Why

In the kitchen, you always lack a hand or two: pots, kids, ingredients, and a phone call.. it's often a juggling act. So voice-controlled devices are a valuable little helpers. Works in my kitchen today, for lights, timers, the family's shopping list, etc. If it also worked for some of the appliances.. that would be nice! Also: I hear from more and more elderly people for which voice user interfaces are unbelievably valuable - and modern devices, like a smart phone, are super hard to work with: too hard to read, too many options, too complicated. A smart kitchen could make things actually worse for them, if an oven becomes as hard to use like a phone. So let's see what we can do..

 What

• Amazon Alexa Skill: configured a model to accept the different ways to talk to our device, like "tell my steamer to {mode} for {duration} at {temperature}
• Amazon Lambda Functions: accept Alexa input, build and enqueue messages on the correct "device shadow"
• Amazons IOT: our secured message queue, basically
  
• Local Node.js gateway: authenticates to Amazon IOT and translates the message payloads into API calls to the V-ZUG-Home API

 Challenges

• Security: handling X.509 issues at night, after a hard week of work, while also helping to run the hackathon and coach teams..
• Security: the device requires manual confirmation for any action that does actual work, like heating. That's 2FA! How could we design a system that is secure (safe!) enough to overcome that? Can we use other sensors of the device to detect the presence of a person? Could we craft an API that is secured enough to allow heating commands? Or will this all lead inevitably to hackers saying "Alexa, burn the house down"?
• Voice UI design: what does an oven need to understand? Just degrees, or hotter/colder? What extreme values would we have to catch before they take effect? What would most common misunderstandings be that we'd have to catch in daily use? What personality, what tone of voice should such a device have? What special voice control features do the different programs need? The wet towel program probably should not say "Bon appétit" when done?

 Status

Components above ready, test with Alexa test environment work.

Next steps:

• Try out in real life
• Come up with a realistic threat model (denial of service, energy waste, fire hazard, privacy breaches, ..)
• On the API, but also the oven level: see what we can do to create a more secure setup
• On the UX level, test, test and test

Who

Hannes Gassert hannes@liip.ch

We got an interesting database of recipes to play with from V-Zug Home at the Open Food Data Hackathon, used in a mobile application to program smart kitchen devices. We took a closer look and investigated ways of combining it with other data sources and tools responding to makeopendata challenge #12. See also the Beat project for an exploration of this data.

In the project repository there is a Jupyter notebook written in Python which explores the data, along with a script to convert the ~150 XML files we received according to a schema defined in recipe.py. We made a very quick visualization to demonstrate the use of data analysis libraries.

We created an example Data Package containing a summary of the dataset in CSV format, as well as a JSON formatted recipe schema proposal in recipe.json. These are proposed as a potential starting point for future discussions about developing an open standard, the advantages of which may include participation of the wider development community, better interaction with other manufacturers, and consumer trust. Here is a preview of our summary DataFrame:

	name	ingredients	instructions	skill	duration
0	Mozzarella, green bean and onion mash	8	2	easy	fast
1	Apple puff pastry horseshoes	6	5	easy	medium
2	Tarte Tatin	4	2	moderate	medium
3	Mashed potato with lime	4	3	easy	fast
4	Duck breast with a honey and soy glaze and plu...	16	3	moderate	medium

And JSON schema:

{
  "uuid": "vzug.internet.05.erdbeersirup",
  "supported-languages": [
    "de",
    "en",
    "fr",
    "it"
  ],
  "name": {
    "de": "Erdbeersirup",
    "en": "Strawberry syrup",
    "fr": "Sirop de fraise",
    "it": "Sciroppo di fragole"
}, 
...

Preparation

No special libraries are required to use the parsing script. The conversion script convert.py references the Python Data Analysis library for CSV file generation. The Jupyter notebook includes some data analysis using the Pandas, Numpy and Matplotlib libraries. You can find some setup instructions here. The schema of this Data Package was inferred using Frictionless Data CLI tools.

Research

In this project we conducted some background research of schemas used in other recipe application, particularly of interest are these cloud providers:

• Yummly API
• Spoonacular API

And these open source initiatives:

• OpenRecipeFormat (Walkthrough)
• hRecipe Microformat

License

The licensing terms of this dataset have not yet been established. If you intend to use these data in a public or commercial product, check with each of the data sources for any specific restrictions.

This Data Package is made available by its maintainers under the Public Domain Dedication and License v1.0, a copy of the full text of which is in LICENSE.md.