Author: jbaer

I presented my slides to the class this week. I displayed our updated system design and highlighted how each component integrates to meet our design requirements. I focused on the role of the database and dashboard and how our planned anomaly detection model fits into the system. The presentation went smoothly, and the feedback received will help refine both our architecture and testing approach moving forward.

Also, I began exploring Flask and Server-Sent Events (SSE). These will be used to implement real-time alerts in our user interface. Flask will handle communication between the Raspberry Pi 5 and the dashboard. SSE will allow the server to push live alerts, like anomaly detections, to the user without needing manual refreshes. I plan to set up a basic Flask environment and start researching how to structure the SSE endpoint for continuous data streaming.

Next week, I plan to continue developing the alert system prototype and test real-time communication between the backend and dashboard to ensure smooth integration with the rest of the system.

This week, I took the responsibility of developing the final design slides. We changed a lot of our previous use case requirements and mapped design requirements that matched them. We also changed our block diagram, switching out certain systems to better meet our needs.

Some examples include:

• We swapped out the Grafana software to alert users with just Flask and an HTTP protocol. We realized that Grafana is a full-fledged software that might be overkill to send a signal. Whereas we can strictly just send that alert with Flask.
• We also decided on using an autoencoder ML algorithm
  • It’s unsupervised learning (looking at unlabeled data), which is great for us since we don’t know what an anomaly looks like
  • It also excels at anomaly detection

Moreover, I extensively practiced the presentation content to ensure the presentation went smoothly.

The project is still on track, and we should be receiving a handful of parts soon. As much as I would like to get started on developing our system, we still have to write our design report, which should occupy us for a while.

For this week, I looked into the different software to actually gather data from our system.

Three components: a dashboard and UI layer, a database to hold the data, and (optionally) containers

For UI to make an optimal dashboard for all sensors, I found Grafana to be optimal. Grafana is optimized to display data from sensors with speed and temperature, and has built-in user-friendly features to help users implement dashboards. It has an easy setup and is very lightweight in terms of storage and processing power required, making it optimal for a Raspberry Pi.

Alternatives include:

• Kibana- Which is better when you need to search for things, which is a feature we don’t really need
• Redash- Which is optimized to display only SQL databases
• MetaBase- Which is very user-friendly, but meant to display business analytics rather than temperature, fan speed, etc.

InfluxDB will be the database platform we plan to use. It can easily pull and push sensor data with Python and does so very efficiently. Furthermore, all data is time-stamped and optimized for sensors. InfluxDB is also very lightweight and fast, which makes it easy to use on the Pi.

Alternatives include:

• QuestDB- high-performance, fast-speed DB, but uses SQL interface, and I don’t know SQL
• Prometheus- This requires exports to transfer data, which is heavier and bulky

Lastly, Docker is a container system used to work across different systems. The code will exist within a sandbox so that it’s not run locally. This prevents the “works on one machine but not another” problem. I’ve used Docker before in a software engineering class and have a good understanding of it, and I believe it will make our project better

Another thing to note is that there already exists a bunch of software that links Grafana to InfluxDB to Docker, so if I get stuck, I have a handful of other repositories to reference.