Uplink: Smart-home group project

The dreaded third year group project. I recently completed my CS undergrad at Heriot-Watt University, and like most CS degrees, it included a group project in the third year. This post is just a summary and some thoughts on the project.

Task

The group project in 2019-20 was to develop an automated smart-home system that could fulfil the needs of Team Esteem - Heriot-Watt’s entry into Dubai’s Solar Decathlon (SDME). SDME’s website provides the following summary of the event:

Universities from all over the world meet to design, build and operate sustainable and high energy efficiency grid‐connected solar powered houses

The “operate” bit is the smart-home computer system, which per the project specification, must:

mediate between the user (the home-dweller) and user activity, and various Internet-enabled smart devices in the home. Most importantly, the system will record data on energy use and energy generation throughout the home, and be able to present this information to users in a number of forms depending on context.

Basically: produce a system & app/interface which lets the user monitor and control smart-home devices.

Team

Teams were picked “at random” and consisted of students from Computer Science, Computer Systems and Information Systems. My group consisted of another C. Science student, a few C. Systems students (C. Science but without the maths, basically) and an Information Systems student. Our project supervisor was Dr. Rob Stewart.

I’d recently been learning about MQTT and similar technologies so I had some semblance of a plan and became Technical Manager, while the Information Systems student, more focused on the business side of things, became Organisational Manager. Despite being a mixed group, we held regular meetings, came up with a decent game-plan and for the most part, stuck to it!

We chose to name our group, fake dev house and product: Uplink. I don’t think I need to explain why.

Schedule

The group project spanned two semesters and consisted of three stages:

• Stage 1: Planning. Roles, requirements engineering, development scheduling and a vague idea of the technical side of things.
• Stage 2: Prototyping and demoing. Have roughly 50% of the implementation completed and demo the prototype to your supervisor and course facilitators.
• Stage 3: Finish the project, demo it again! There is supposed to be an expo where you demo the product to other teams and the “clients”, but COVID-19 stopped this happening.

Development

I came up with the idea of a central server (the ‘Uplink Hub’ or ‘U-Hub’) serving as an MQTT broker, database logger and web interface to interact with the system. The database logger & API were coded in Node.js and the web interface in Node.js and Vue.js. We used Mosquitto as our broker and the whole system was to be hosted on a Raspberry Pi 3.

The Hub should have integrated with a higher-level system which would give property managers access to the Hub data too, however, this became a secondary priority as time went on. The final decision was that the Hub could be linked to another server and periodically upload data via an API that was not eventually implemented.

I worked primarily on the database, logger and back-end API of the system while my colleagues developed the front-end and business reports.

Development - Database

Above is the final iteration of the Uplink Hub database schema. It is capable of storing numerous objects, such as:

• Sensor / device settings and data
• Warnings generated by the system
• Device triggers
• One-off and repeat timers
• Info for multiple users and account types
• Authentication tokens (we implemented JWT)
• Property data

It went through 7 or so major iterations, but I really enjoyed producing it. The image above was created using Umlet.

Development - API & Logger

The Hub’s database API and data logger were both the same Node.js server. Looking back, I would have done this differently - but it worked! It listened for and categorised incoming MQTT messages for logging in the database, and kept track of device timers and triggers. It also provided the Express.js API for retrieving and inserting data via the separate web interface. Some of this API was authenticated using JWT.

Development - Web interface

Truth be told: I wasn’t very involved in the front-end interface. It was produced using Vue.js and I think my student colleagues did a great job design-wise and integrating with my hacked together API, which I ended up writing on an as-needed basis. My belief is that Vue.js enabled them to quickly produce a dynamic and responsive interface for the system.

The final product

The system code is available on GitHub. The final report is available here.

It was a stressful year, but we learnt a lot about planning, task delegation and compromise. I spent years - starting when I was in high school - dreading this group project, but I was lucky enough to have a good experience with a good group of people.

Related

• Team Esteem’s Linkedin
• Euan Gordon: My CS colleague who was responsible for the other half of the technical implementation.