The one with NodeRED

Dear fellow Lhamas,

Before you dive deeper into this blog post we strongly advice you to kick your legs up and open a cold one, because this is gonna be a long one..

Like a true influencer, we have had something cooking for you since last week - stay tuned, but not so much any longer, because now the wait is over! May we present to you, our UI interface created in NodeRED.

The first spade sticks and overview

When we started looking at this, last week, we first had two tracks in our approach to the UI flow, which eventually would be united from today and throughout the week. You might have guessed it, but if not, I am talking about our FRONTEND and BACKEND coding.

But first, a brief introduction to our User Interface. The purpose of the UI is to enable the user to track how far they are in the process of brewing their homemade wine. We expect the target user to be someone who is attracted to "Do It Yourself" projects, but at the same time doesn't have too much time on their hands to immerse themselves totally in the art of brewing homemade wine. The UI therefore needs to be very self-explanatory and will enable the user to give their batch a name and color customize the UI as well as monitor the fermentation process. It will take the stress of the user, and hold them in their hands throughout the whole process.

We started out by making a flowchart of the desired Frontend and Backend connections, mainly based on the wire framing we did in the first sprint (check this blogpost out: https://mekadtu.wixsite.com/doslhamas/post/sprint-one-has-now-begun) This flowchart has been refined as latest as today, and we can now say that this flowchart more or less resembles our final UI flow. It was made in order for us to keep an overview of how the different main functions would communicate with each other. One function might of course contain more than what is seen in the chart.

Color coding:

User screen, NodeRED, Arduino

As you can see, we are planning to put as much as the heavy lifting on the NodeRED backend as possible. We want to collect the data into one place, as well as most of the data logging, in order to spare the ESP's, as we ran into some challenges with them the last time. Consequently we don't want to rely on the ESP's too much and risk having the same issues.

Frontend

We wanted the UI to have a user friendly approach, which means as few layers as possible. We are developing a form of card index with different recipes, which are stored in NodeRED, that the user can choose from. After choosing a recipe the user can start brewing their wine. For now, the recipes will not determine the fermentation process and how long this has to take, but for future work we expect that the monitoring process will be altered to each batch, depending on the recipe and kind of fruit.

Backend

For the Backend part, the only data that NodeRED will obtain from the ESP's is the temperature, humidity level and number of bubbles passing through the airlock. The data is converted through the following; at first appears as integers at the ESP, through the cloud MQTT it appears as strings, then NodeRED where it appears as integers again and at last it is stored in arrays. We need to store quite a big amount of data, and this is the solution, as one batch and fermentation process will run over at least 4-6 weeks. By storing the data online, the data will still be saved if the ESP should restart at some point.

In addition, by having NodeRED to do the data processing, we can set up some limitations for too low/high temperature, too high humidity level, and a monitoring system for the bubble counting. We can then send out notifications to the user, if one of these is off, so that the user would still have the opportunity to save his/hers batch of home-brewed wine. The stirring and racking of the wine will also be controlled through NodeRED, as it will be connected to timers that sets these actions of once the batch has started fermenting. These actions are very crucial for the wine to turn out good, which is why the responsibility also is on the shoulders of the NodeRED.

As the data is important to not only store, but also to process, we have used several different nodes from the ui-dashboard library. These nodes enable us to log the data in graphs so that the user can follow and keep track of the process.

Another perk of having most of the coding in NodeRED is that it is fairly easy to advance and adjust the coding for future work, when/if the product is developed further.

Hardware/software limitations

In terms of hardware limitations, it is not possible for us to "connect/enter" the smartWINERY and tell it which network to connect to, because as the code is set up now, we define this as a part of start of the code. The OLED screen we have for now is also quite small (faulty purchase:)), which means there isn't really room to display a lot of information. This size screen would of course not be ideal for the ideal finished product, but for now it will do.

The software limitations is mostly centered around the connection between NodeRED and the smartWINERY, as they need to be connected through the cloud MQTT from the start in order to work together.

This was all we had. We expect that you have reached the bottom of you beer now, and we hope that you are as exited as us to see how the whole UI will turn out in the end! So stay tuned and be safe out there!

Lots of lhama hugs from your favorite LHAMAS