Notidry

Introduction

Esslingen, January of 2019

This project is created in context of the lecture “Internet of Things Ecosystems” at the University of Applied Science Esslingen. It covers the invention of an own IoT Idea and Application from the scratch solving a real-world problem. In the design sprints the students learn about design, implementation (full-stack) and business aspects of Internet of Things applications.

Description

As already mentioned, the goal of the lecture is to solve a mundane real-world issue, which can be solved with the use of IoT.

One of those issues has affected us already several times in our own lives is the process of drying clothes.

Even after hanging up the clothes on a clotheshorse (which is already a tedious chore), you can’t relax and focus on more relevant things since bad weather might thwart your plans.

As a result, you have to constantly pay attention to the weather in order to avoid being caught off-guard by bad weather and hence having wet clothes.

Also, for more convenience we’d like to be informed when the clothes are ready to be taken off from the clotheshorse, so we can avoid manual checking.

Thus, our goal was to develop an IoT clotheshorse, which “eases the pain” and makes the process of drying our clothes more convenient.

Initial ideas

First idea

Our first idea was to detect the state of the clothes based on conductivity by using a peg-like design.

Since wet clothes are still soaked with water, we can simply determine how much current is still flowing. As soon as a current of zero has been reached, we know our clothes are dried and ready to be taken off.

The primary benefit of this approach would be a high accuracy, but on the downside, we could monitor only one garment at a time.

Second idea

The second idea was based on weight by using a clotheshorse-like design.

Due to the fact that wet clothes are heavier than dry clothes, we could simply monitor the weight of the clothes, calculate the derivation over time and predict thereby the state of the clothes.

This approach would sacrifice accuracy for more garments, which could be monitored at once.

Solution

Proof of concept prototype

After we’ve finished drafting our approaches, we started prototyping, which involved the development of an app (described in detail in section App), the implementation of the required APIs and services (described in detail in section Losant).

The idea was as mentioned (in section Initial ideas) to create a clothes horse equipped with load cells. But after our first presentation we got the feedback to think more about the cost structure and maybe the solution of just the IoT devices without the clothes horse, so you could upgrade your own clothes horse at home.

The problem with creating a clothes horse with IoT is that it is expensive because you need to manufacture a whole clothes horse. The idea of just an upgrade kit was logical because it would be less expensive and everyone could just stick the upgrade to his own clotheshorse without buying a whole new one.

Finally we started with the creation of our first proof of concept upgrade-kit called“Notidry”.

In conclusion Notidry consists of the Application and the Notidry skids which you can apply on to your clothes horse’s legs.

Usage

Prototype

Weight of clothes

Technical

Overall architecture

• Notidry-skid monitors the current state of clothes
• Updates will be pushed to particle-cloud and published via REST-API (powered by Losant)
• App aggregates data (weather service & Notidry-updates) and informs user based on current state

Board & Sensors

For prototyping we used a standard Particle Photon Wi-Fi board in conjunction with four load cells (up to 50 kg) and a load cell amplifier (HX711 - 24-bit resolution) giving us a total measurable weight of 200kg, which should be sufficient.

The firmware implements a state machine, which has the states Initializing, Measuring, Sending and Waiting. When thedevice is powered trough an external power source, the device goes inInitializing state.

In the Initializing state the deviceinitiates the load cell amplifier by setting the calibration factor for theamplifier. The calibration depends on the used load cells (especially on theweight range) and how they are connected with each other at the load cellamplifier. After the Initializing state the state machine goes into theMeasuring state.

In the Measuring state, as the name alreadysuggests, the device communicates with the load cell amplifier to get thecurrent weight in lbs. It then converts the weight to kilograms and stores thevalue.

In the Sending state the value will be ‘written’into a JSON message which will be published by the help of the Particle cloudfunctions for further processing by the Losant workflows.

After sending the measured value as JSON, the system will wait for a specific amount of time before measuring the nextvalue.

Losant

Losantis used to process the data of the particle board and prepare it for thecustomer. Obviously, Losant is located between the board and the userinterfaces (very much like the app and the language assistant Alexa). Duringoperation, the board publishes in regular intervals the current weight loadedon the skids to Losant and simply by looking at the weight curve, you can make thefollowing statements about the laundry:

1. If the weight does not change after setting up, the clothes horse is empty.

2. If the weight increases, clothes are hung on the clothes horse.

3. If the weight decreases, the laundry dries.

4. If the weight does not decrease for a certain period of time, the laundry is dry.

The workflow in Losant looks as follows:

Depending on the change in weight, the workflow is divided into different branches. At the end of the calculations, when the status of the laundry has been determined, it is stored in a table.

Losant provides the option of offering a REST interface. Via the created REST-API, the app and any other user interface can access the stored status of the laundry. In addition to the status, status-related information can also be obtained via the REST API. In the following code example, we see the JSON response as it would look for the status "dry". It contains information about the duration of the drying process, the weight lost during drying and the start and end times.

App

The app represents the frontend for the user and is rather simplistic for easier ease of use.

The app is comprised of two basic elements:

• Push-notifications:

=> Based on weather-data (polled from OpenWeatherMap), alerts (in form of push-notifications) will be dispatched.

=> Also, when the laundry has dried, a notification will be dispatched.

• The main (and only) activity of the app:

=> Displays all relevant information at a glance (weather-data & state of clothes).

Conclusion

Within the scope of the lecture ‘IoT Ecosystems’ we had the opportunity to get further insights into the process of developing products and the resulting responsibilities of product owners.

The theme of the lecture was very much hands-on and interactive. Therefore, the lecture was comprised of weekly sprints, giving us the chance to present our progress (and get valuable feedback) and a dedicated WhatsApp-group for further conversations/exchange.

We even had the opportunity to visit the Festo headquarters in Esslingen, which included a tour and the chance to get additional input from experts while working on our prototype.

All in all, it has been very practical lecture, grounded in the real-world as close as possible, which was very exciting and refreshing.

Hence, we can recommend this lecture to all students who seek to become entrepreneurs/product owners and who are willing to invest the required time and effort in the project.

Team C: Samuel Maier, Gerrit Klein, Janfabian Fabriczek, Emrehan Cagatay