Blog 5 | Final Report | George Lipceanu

May 20th, 2026.

This final blog is focusing on the everything that has been completed up to this point across the whole project and will go into lower level detail on my contribution to the project.

Overall Team Design

A diagram of the overall BinBot IoT project is shown in the figure below:

The workflow of this design is as follows

1. Available HTTP endpoints tunneled through Ngrok hosted on Node-RED to give users access to Google Classroom Invitations and notifications + Email Pub/Sub Subcriptions and emails using Resend API.

2. BinBot's Ultrasonic Sensors measure bin fullness, the Slave Microbit processes this data, encrypts it using XOR encryption, and passes it to the Master Microbit to publish to the MQTT Broker.

3. A user scans an item using their phone's Barcode Scanner, and inputs it into the IoT App to publish to the central MQTT Broker.

4. Node-RED MQTT Listeners receive the barcode and fullness data, triggering automated Google Classroom and Email notifications if specific fullness requirements are met.

5. Barcode Data is validated using OpenFoodFacts API and Google Sheets is filled in corresponding to inputted barcode + item metadata

6. Google Sheets data flows into a connected Looker Dashboard for real-time visualisation and analytics.

7. Determines the "Class Rank" based on Node-RED calculations and sends it to the MQTT Publisher, which routes it back to the MQTT Broker.

8. Master Microbit receives the rank from the broker, decrypts it, and sends it to the Slave Microbit to show on the physical display.

    A demo of the overall team design can be found here. This demo gives a high level overview of the project flow in action, with each member of the IoT team detailing their main contribution(s) to the project.

My Contribution

Regarding the total flow of my contributions, here are the nodes I have produced:

This flow can be found in the link here and can be imported into any Node-RED flow using the import feature, which is what was done for the total flow to keep all Node-RED operations to a single Node-RED instance.

    I have made a video covering this split into 2 parts, which can be found at part 1 and part 2. These videos provide explanations to each node in the flow and how they work in tandem with one another. This flow can be found here. From top to bottom, this flow covers:

• Google Classroom invitations from the teacher account to the BinBot using an external link and HTTP endpoint through an Ngrok HTTP tunnel that forwards port 1880 on the Node-RED container to HTTP and allows for it to be accessed anywhere over the Internet, and the Google Classroom API to get permissions from teachers and the BinBot accounts to allow for the application to automatically invite and accept invitations, all through an easily accessible web application.
• Another HTTP endpoint which allows for email pub/sub for specific classes.
• Fanning out BinBot messages using the Google Classroom API for Google Classroom and the Resend Email API service for publishing emails to subscribed email addresses.

1. Google Classroom Invitation:

This has been covered in greater detail in my blog 4, which I would recommend reading in order to see this in greater detail. Just to briefly touch on what happens here, a teacher looking to invite the BinBot clicks on the Google OAuth Consent link provided in blog 4, accepts the Google Classroom API permissions, gets sent to a website where they can choose which classroom to invite the BinBot to. The BinBot then receives an invitation where someone has to accept it manually to from the BinBot account (Note: there is code for auto-accepting invites however due to API restrictions in personal Google accounts, this is not possible unless the BinBot account were to be upgraded to an enterprise account).

    What should be expanded on: 

• Looking into ways of auto-accepting the invite without the use of the Google API (although I do feel like I have tried everything to no avail).
• Obscuring the secrets and tokens using some type of encryption since at the moment, they are being sent in plaintext over HTTP, which is a transport layer protocol that does not use encryption either. So if someone were to intercept that traffic, they would have full access to the BinBot account, which has access to many Google Classrooms, which has the potential for a big data breach regarding everything inside these classrooms.

2. Email Pub/Sub:

An email pub/sub system was put in place for teachers who don't use Google Classroom, BinBot administrators and (potentially) secretary or admins in a given school who wouldn't have acess to a Google Classroom for BinBot notifications but would (potentially) need to see important these alerts. For allowing for an email pub/sub system, another endpoint was added that brought users to a new HTTP website as shown below:

Users are presented with all the available options in the system and a text box to put their own email in.

Once the subscribe button is pressed, this subscribes the given email to the given class email subscription list and returns a success message.

    What should be expanded on: 

• Looking into ways of adding these subscribed emails to an MQTT topic or in a separate persistent volume as opposed to keeping them in the Node-RED containers memory. With this current setup, if the container dies and needs to be restarted for any reason (which is a certainty that it will happen), all emails get wiped since they are all in memory. These emails need to be persistent across container runs.
• Subscription verification emails to prevent users from putting in emails that are not their own, increasing the overall security of the project.

3. Notifications and Alerting through Email and Google Classroom:

The updated Google Classroom notifications used the updated MQTT setup provided by the team and, using fullness at a threshold of 0.9 in the actual flow which can be interchanged with other fields and/or added onto to suit what needs to be done. This is also covered in blog 4.

These alerts also need to be sent to the aforementioned emails from the previous listing. To handle this, a new branch of nodes and connections in the Node-RED flow was created from the switch node for each class ID output to handle emails (this is only done for class1 in the actual flow but the logic can be easily copy and pasted and slightly tweaked for the rest of the classes). The main function node in this flow checks if the fullness is above 0.9 (90% fullness), prepares an email and uses the Resend API to send emails to the subscribed emails for that specific classroom. In case you are unaware, Resend is an API platform that allows for developers to send emails directly from their applications, which fits in perfectly with the needs of the project. 

An unfortunate drawback of Resend is that it requires to be registered to an actual domain if you want it to send to multiple email addresses that is not the email address of the actual owner of the API key. Due to time constraints, the use of Resend was kept in the project however, because to the plug-and-playability of the flow provided and Node-RED in general, this can be easily replaced with a more fitting API or system in general.

    Once the email has been sent by Node-RED, it should appear in the email inboxes like so:

What should be expanded on: 

• Other services for fanning out emails.
• More options for notifications, which can easily be done using MQTT Leaderboard outputs and weekly delays but weren't implemented due to time constraints. Some of these options include:
• Weekly updates on leaderboards and rankings
• Reaching a new milestone
• If a certain external API in this flow is down
• Ways of separating the classes/schools to only be alerted for their Google Classroom notifications and not have a global notification system. For example, have it so that St. Declan's doesn't see any notifications for BinBot alerts in St. John of God's

4. Contributions Outside Direct Project Work:

One of my first tasks in this project was to dive into Node-RED and discover it's capabilities. From my findings, it was clear to the team that there was big potential for this to become a big part of the project. Since I was the main source of knowledge for Node-RED at the time, I provided an in-person 2 hour crash course for the team with lab exercises, and I also answered any questions anyone had about Node-RED or helped those struggling with the exercises. This was covered in greater detail in my blog 3 if you want to read on it further.

    I also took part in one of the team's earliest and most critical (at the time) debugging sessions which fixed an issue regarding the MQTT broker producing invalid JSON, causing functions taking these in as inputs to error. This was quite an enjoyable experience for me since I got to set up my own challenges for everyone else just like a lecturer, which I found amusing in my own way :). This was also covered in greater detail in blog 2.

Team Reflection

Regarding my previous experience with teamwork, I found that the teams I was involved in would fall under 2 categories:

• Communication between team members is clear and work is divided up evenly
• Communication between team members is unclear and I end up doing all the work since I am the only one trying to get something done

I was glad to find that this team fell under the former category of teams as opposed to the latter. This teamwork experience was significantly different to my past experiences however. The first 9 weeks of the project (up until blog 4) was quite standard for an effectively communicating team. However, as I've alluded to in previous sections, I unfortunately fell ill for the Easter break and the last 3 weeks of the semester. Since I was advised by doctors to focus completely on recovery, this meant that I had to drop all college work for that period of time, which meant the IoT module too. 

    At this point I already had the old Google Classroom setup with the basic Resend API Email fanout setup too with no class separation. Once I was able to work again, because of how well the team had communicated on Slack previously and how each of the lads were able to explain what was going on with their part of the project, I was able to understand where the project currently was and how I could update my current work to fit these new changes to the overall MQTT system updates, which were quite easy changes to make thanks to how interchangeable Node-RED components and code can be if set up correctly. It felt like although I had been gone for so long, because of our team's effective communication, I was able to get back on the boat and into the project once I was ready to come back in, which is the main thing I liked about working in this team.

    Another thing I liked about working in this team is the amount of work we were able to get done in the end. There still are things that need to be expanded on, especially on my side of the work but as a team, I feel that we have built something beyond a strong foundation, but potentially something that may be ready for to be shipped out if we had more time. 

    I also felt that there was a good sense of trust across the team, not only codewise but also just workwise in general. My favourite examples of this was during the recording of the general high level overview of the project. There were a few team members running late who had work that the rest of us were failing to understand at the time. Even with that, there was enough trust on the team to not worry about it and to simply wait until this team member came to explain their work and clear the confusion completely, which is exactly what happened.

    Something I feel I could have communicated better is my own part of the project, specifically the Google Classroom API setup. This took a lot of trial and error to find the most secure setup for this application within the Google Cloud management console. I do feel like a lot of time was wasted on this aspect and fiddling around with the Google API, which proved to be extremely restrictive at times, the main example being the auto-accepting of invites and Google's restrictions on seeing invites for personal accounts, and I feel like I failed to communicate my struggles with this, instead choosing to go down rabbit holes which eventually lead nowhere, which wasted time that I could have spent working on something else. I did eventually point out my troubles and as a group we decided to leave auto-accepting for now and revisit it if there was any time left (which there was not :().

Regardless, this module was definitely something different compared to the rest of the modules I have had throughout the course of my degree, and a much apprecited change of pace compared to those modules. Where sitting alone with a project and theory notes which is common place in other modules, this module takes a completely open team-based approach, with everyone in the class working towards a common goal. This module has helped me with my communication and overall teamwork, but more importantly it has helped me see that being able to share the glory of a finished project within a team is a lot more satisfying than doing it alone.