ase2024-docs
ASE2024 Project Description
Overview
In teams of 4 students, you will develop a RESTful API to consult environmental data captured by multi-sensor Internet of Things devices. Moreover, you will build upon your API to create a complete Internet of Things (IoT) scenario. Examples of such scenarios from recent projects include activity tracker (fitness coach), monitoring and control of wash machines or fridges, parcel tracking, terrarium monitoring, predictive analysis for clothing, and voice assistant. This scenario should integrate some sort of dataflow programming (i.e., workflow engine, business rules…) as well as a mobile, web, or desktop client. The application should also use and consume data from other services (service mashup).
Thingy:91
The project is based on the Thingy:91 cellular IoT device from Nordic Semiconductor. According to Nordic; “The Nordic Thingy:91 is an easy-to-use battery-operated prototyping platform for cellular IoT using LTE-M, NB-IoT, and GPS. It is ideal for creating Proof-of-Concept (PoC), demos, and initial prototypes in your cIoT development phase.” The device can probe temperature, humidity, air pressure, air quality (IAQ and CO2 equivalent), color, and light intensity. It has a GPS for positioning, an accelerometer, a push button, an RGB LED, and a buzzer. We will provide some Thingy:91 devices to each group.
Thingy:91
The Thingy:91 directly connects to the Internet using LTE-M. It sends and receives data using the MQTT protocol. The device publishes its sensor data (temperature…) at a regular interval (i.e., 30s by default). When there is an event (e.g., the button is pressed), the device publishes a notification. The device also subscribes to a specific topic(s) for interaction with actuators (i.e., LED and buzzer).
You can explore published sensor data by subscribing to things/+/shadow/update.
MQTT messages
MQTT messages are subscribed from/published to the MQTT broker with the following scheme:
| appId | messageType | topic |
|---|---|---|
| GPS | DATA | things/{device_uuid}/shadow/update |
| FLIP | DATA | things/{device_uuid}/shadow/update |
| BUTTON | DATA | things/{device_uuid}/shadow/update |
| TEMP | DATA | things/{device_uuid}/shadow/update |
| HUMID | DATA | things/{device_uuid}/shadow/update |
| AIR_PRESS | DATA | things/{device_uuid}/shadow/update |
| AIR_QUAL | DATA | things/{device_uuid}/shadow/update |
| CO2_EQUIV | DATA | things/{device_uuid}/shadow/update |
| LIGHT | DATA | things/{device_uuid}/shadow/update |
| LED | CFG_SET | things/{device_uuid}/shadow/update/accepted |
| BUZZER | CFG_SET | things/{device_uuid}/shadow/update/accepted |
Here are examples pub/sub using Mosquitto client:
- Subscribe to sensor notifications
mosquitto_sub -t 'things/{device_uuid}/shadow/update'
- Enable buzzer at 2 kHz :
mosquitto_pub -t 'things/{device_uuid}/shadow/update/accepted' -m '{"appId":"BUZZER","data":{"frequency":2000},"messageType":"CFG_SET"}'
- Set LED color to red (R,G,B = 255,0,0)
mosquitto_pub -t 'things/{device_uuid}/shadow/update/accepted' -m '{"appId":"LED","data":{"color":"ff0000"},"messageType":"CFG_SET"}'
Architecture
Your application should have a similar architecture:
Thingy API
You should create a RESTful API (thingy-api) using Koa.js or Python async framework aiohttp.
The thingy-api should (at a bare minimum) provide the following features:
- Expose Thingy shadows through a Web Thing REST API
- Retrieve time series data based on time ranges
- Retrieve extra data required by your scenario
- Make decisions based on dataflow programming rules (e.g., using an external tool like Node-RED) or your logic
- User authorization and authentication (OAuth2+JSON Web Token)
- Documentation (generated using Open API (Swagger) or RAML)
Thingy Client (thingy-client)
You should also create a web, mobile, or desktop client (thingy-client) consuming the resources of thingy-api. You can use any programming language/technology you want as long as you are able to demonstrate your prototype at the end of the sprints and during the final presentation. Also, make sure that each of your team members has a compatible device if you make a mobile application.
The thingy-client should (at a bare minimum) provide the following features:
- User authentication
- List devices of the resource owner
- Display data required by your scenario
- Display current state
- Plot some time series data
There are many possible features that fit your scenario and creativity.
Evaluation criteria and deliverables
You will mostly be evaluated on the following criteria:
- Originality of your project
- Fulfillment of the basic requirements as detailed in this document
- Code quality (structure, design, robustness, consistency, etc.)
- Compliance with your project planning, respect of scrum practices
- Up-to-date project planning documentation
- Working API delivery on GitHub at the end of each sprint
- You should produce a fully working revision of your API in your project repository (v1, v2, v3)
- Working client demo at the end of each sprint
- API deployed in production on a real server at the end of sprint 3
Of course, your contribution to the group will also be an important aspect of our evaluation. Note that we allow ourselves to check your Github repository and scrum planning document on a regular basis to ensure the respect of good practices (regular work, updating the planning document, etc.).
Timeline
| Date | Task |
|---|---|
| 03.10.2024 | Group Formation |
| 06.10.2024 | Deadline for submission: Todo backend with database persistence |
| 10.10.2024 | Project plan presentation |
| 24.10.2024 | thingy-api v1 on GitHub (end of sprint #1) |
| 31.10.2024 | thingy-client v1 demo (during the course) |
| 27.11.2023 | thingy-api v2 on GitHub (end of sprint #2) |
| 28.11.2024 | thingy-client v2 + workflow v1 demo (during the course) |
| 18.12.2024 | thingy-api v3 (final) on GitHub and deployed on server (end of sprint #3) |
| 19.12.2024 | Final presentation |