1. Title and name (1 point)
- Alarm System of Doom, action and explosions.
- Lucas Fryhl (lf223cc) & Lukas Söderlund (ls224ec)

2. Short project description (2 points)
- Short and brief project description?
An alarm system with different sensors, and with codes to deactivate the alarm system. It triggers when a door opens.

3. Objective (3 points)
Describe why you have chosen to build this specific device. What purpose does it serve? What do you want to do with the data, and what new insights do you think it will give?
- Why you chose the project
We were planning on making a Pong game with controllers but due to one of our raspberry pi picos getting fried due to accidentally switching the wires for ground and power, we outed to instead make something with an LCD display we had laying around, as well as a few buttons. We looked into some of the sensors we had and found an obstacle detector sensor. That sensor combined with a few buttons and an LCD display we got the idea of an alarm system that detects if a door is open with personal passcodes. This was the idea that we switched to and were determined to do.

- What purpose does it serve
Even though it’s not a “super secure” alarm system it still serves as a decent low cost alarm system that we could build ourselves. The system allows people entering to be identified if they use their codes in our system, as well as alerting when users enter without entering a valid passcode within a certain timeframe. This makes the alarm system a good tool to identify break ins and allows the user to not have to be keeping an eye open all the time and instead leaving the system to watch for them, if the door cannot be locked for example. It’s a time, stress and money saving idea that we brought to life using simple IoT components! The system also serves as a temperature and humidity device recording and displaying trends in both.

- What insights you think it will give
It will show the user trends in humidity and temperatures during day and night time, as well as when people are in the room or outside. It can give insights to if the room needs additional ventilation or humidifiers to help with the rooms ambiance and comfort. It will also give insights on how many people come and go during the weeks and when the room is most populated which can be helpful to identify when ventilation might need to be lowered or increased due to population inside. It will also give insights to if people enter without permission or authority and give insights to the security of the room or premise.

4. List of material (3 points)
- List of material
1x obstacle detector sensor, 1x breadboards, 44x cords, 5x buttons, 1x raspberry pi pico w, 1x DHT11 Temperature and Humidity sensor, 1x 1000 ohm resistor, 1x active buzzer module, 1x LCD display, 1x potentiometer, Ducttape, Cardboard and scissors.

- What the different things (sensors, wires, controllers) do - short specifications
- Where you bought them and how much they cost (if applicable)
One of us had already bought everything we needed for this project a couple of months beforehand, so we had things laying around that we could use, an approximation for the entire build cost we’ll put a high guess at 450 SEK. The obstacle detector detects whether something is in front of it at all times, and can be calibrated to the wanted sensitivity. The active buzzer makes the alarm sound as well as the little jingle when you enter the correct codes. The buttons detect when they’re pressed or not, and the LCD display shows the data we want to display such as “success”, “temp: humidity:” and “wrong code”. The pico holds the code for all of this to function. The potentiometer is used to change the brightness of the LCD display to match well whatever lighting we have in the room. The DHT11 sensor gives us data of the temperature and humidity in the room.

5. Computer setup (3 points)
How is the device programmed. Which IDE are you using. Describe all steps from flashing the firmware, installing plugins in your favorite editor. How are you uploading (flashing) your code, describe the workflow.
- Chosen IDE
Thonny
- How the code is uploaded (workflow)
We connect the device via USB to edit and upload updated files written in Thonny.

- Steps that you needed to do for your computer. Installation of Node.js, extra drivers, etc.
We clicked the BOOTSEL button and plugged the pico into the laptop to enter BOOTSEL mode, where we dropped a MicroPython firmware file in to flash the pico. Then we used Thonny to flash python files into the pico.

6. Putting everything together (2 points)
How is all the electronics connected? Describe all the wiring, good if you can show a circuit diagram. Be specific on how to connect everything, and what to think of in terms of resistors, current and voltage. Is this only for a development setup or could it be used in production?

- Circuit diagram (can be hand drawn)
- *Electrical calculations (advanced level)
(Please excuse the data lines intersecting, photoshop was lagging my laptop SO much and therefore took a shortcut even though it’s not accurate. Thanks <3)

All components except the LCD are powered using 3.3V from the pico, and the LCD through VBUS which is 5V. This was the development setup which we ended up using in the end, with the exception of adding a 4x battery holder connected to VSYS and GND to make it wireless. We used a 1000 ohm resistor between the 5V VBUS and the LCD anode to not burn out the LCD. We did not use the EN pin on the obstacle detector sensor because we do not have a need for being able to turn the sensor on and off.

7. Platform (2 points)
Describe your choice of platform. If you have tried different platforms it can be good to provide a comparison. Is your platform based on a local installation or a cloud? Do you plan to use a paid subscription or a free? Describe the different alternatives on going forward if you want to scale your idea.
- Describe platform in terms of functionality
- *Explain and elaborate what made you choose this platform (advanced)
Our platform is a TIG stack (Telegraf InfluxDB and Grafana) which handles everything we need, visualizing data, processing data and storing data. We chose it due to having some experience with TIG stacks, and we did not go for a simpler approach with like Adafruit so we can have a more customizable platform. Our platform also works offline and gives us full control over the data which is perfect for a security device. In the future this stack is scalable and can be changed into a cloud-hosted InfluxDB instance if we want to make an app or something from it where you can view the data from anywhere, but for now we’re using a free local hosted server for this small scale project.

8. The code (1 point)
Is the code attached in a proper and readable format? It can either be code snippets in the document (if not too much) or links to a Github repository.
snippet 1:

snippet 2:

snippet 3:

These are some code snippets from Main.py, we also used gpio_lcd.py and lcd_api.py with code from https://github.com/dhylands/python_lcd/tree/master for the LCD display.

9. Transmitting the data / connectivity (4 points)
- How often is the data sent?
Every 5 seconds for the temperature and humidity data, but the door events are sent immediately upon recognition.

- Which wireless protocols did you use (WiFi, LoRa, etc …)?
WiFi.

- Which transport protocols were used (MQTT, webhook, etc …)
We're using HTTP POST as a transport protocol, with the “urequests” library. We used influxDB on a local instance as the server.

- *Elaborate on the design choices regarding data transmission and wireless
protocols. That is how your choices affect the device range and battery consumption as well as the security perspective.
We chose WiFi because it's already built into the pico w and is easy to set up here in school (we're working on linnaeus university). So the range is not far but good enough for the alarm system since it's stationary. We used InfluxDB because we've had some experience using it in the past. WiFi does use quite a bit of power but since we're using 4x batteries that's not a concern. HTTP POST with urequests is simple and easy to use and is compatible with influxDB which is why we used it. Since we're only using a local server the security is pretty tight even though the actual physical alarm probably has some security concerns.

10. Presenting the data (4 points)
- Provide visual examples on how the dashboard looks. Pictures needed.

- How often is data saved in the database.
Every 5 seconds for the temperature and humidity data, but the door events are sent immediately upon recognition.

- *Explain your choice of database.
We used InfluxDB because we've had some experience using it in the past.

- *Automation/triggers of the data.
Break in alert is triggered after 60 seconds of the alarm not being stopped with a correct code input, and as soon as a correct code is entered it triggers sending the data of the door event immediately. But for the temp and humidity sensor data, those are automated every 5 seconds.

11. Finalizing the design (2 points)
Show the final results of your project. Give your final thoughts on how you think the project went. What could have been done in an other way, or even better? Pictures are nice!
- Show final results of the project
We could’ve tried to make it more clean and simplistic without a temp and humidity sensor since it’s not really needed in an alarm system, but the data you can use from that information together with knowing the amount of people entering could be useful. We would have not used a breadboard and instead tried to incorporate the components into a box more suitable and less of a fire hazard than a cardboard box with duct tape, another problem with using a breadboard is that wires put into it sometimes get loose and can fail the entire system. We could also have used 10 buttons with numbers from 0-9 instead of just 1-5 which is a security risk. Someone could easily break this contraption by opening the door just slightly and then pushing a little paper to cover the obstacle detector to bypass it, which is one of many ways to break this system. We could’ve definitely made it more robust and put more thinking into how the design can be exploited. We also would’ve used color coordinated wires since we ended up with 44 wires which was hard to keep track of sometimes. Overall we’re quite happy with the result, as we’re still learning and were not really expecting a top of the shelf kind of device in the end. Our effort was rewarded in the end with a pretty cool IoT alarm system. Pretty sick :)
- Pictures


(the first image didn’t have the battery attached but the second image does have it inside)