From Sensor to Dashboard: A 7-Day IoT Course with Unihiker K10 & MicroPython
Class 1: What is IoT? & Your First Connected Device 🌐
Objective: Understand the fundamental components of an IoT system (Device, Network, Cloud, Application) and get the Unihiker K10 connected to the internet to fetch data.
Key Concepts:
IoT System Architecture (The 4 Pillars).
IP Networking Basics (IP Address, Wi-Fi).
Client-Server Model.
Application Programming Interfaces (APIs).
HTTP GET Requests.
JSON data format.
Teaching Materials:
Hardware: Unihiker K10, USB-C cable, computer with Thonny IDE, reliable Wi-Fi access.
Software/Services: Thonny IDE, a web browser.
Slides/Whiteboard: Diagram of the 4 Pillars of IoT. Example of an API request URL and a JSON response.
Lecture Outline (Suggested Flow):
Engage (5 min): Start with a relatable example: "How does a smartwatch send your heart rate to your phone and the cloud?" Use this to introduce the 4 pillars.
Explain (15 min): Draw the 4-pillar diagram.
Device: The "Thing" with sensors (our Unihiker).
Network: How it connects (Wi-Fi).
Cloud: Where data is sent for processing/storage.
Application: How the user interacts with the data (phone app, dashboard).
Demonstrate (15 min):
Explain that our first step is making the "Device" talk to the "Cloud".
Introduce APIs as a "menu" for web services. Show the WorldTimeAPI website and its simple URL structure.
Introduce JSON as the simple text-based language APIs use to respond.
Live code the Wi-Fi connection using the Wifi example.
Introduce the urequests library and write a line to get data from the API. Print the raw text response.
Lab Intro (5 min): Explain the goal: connect, fetch the time, pull out just the datetime string from the JSON, and display it.
In-Class Lab Activity (45 min):
Students use the Wifi example to connect their Unihiker to the network.
They import urequests and import json.
They make a GET request to http://worldtimeapi.org/api/ip.
They parse the response using response.json() and access the specific datetime key (e.g., data['datetime']).
They display the retrieved time on the Unihiker's screen.
Discussion & Homework (5 min):
Question: "Besides time, what other data from a public API could be useful for an IoT device?" (e.g., weather forecast, air quality index, stock prices).
Homework: Find another simple, key-less public API and modify the code to pull and display one piece of data from it.
Class 2: Sensing the World & Pushing Data to the Cloud 📤
Objective: Learn to collect data from the physical world (telemetry) and send it to an IoT platform for storage and visualization.
Key Concepts:
Telemetry & Data Logging.
Sensors (Input) vs. Actuators (Output).
Cloud IoT Platforms.
HTTP POST Requests.
Data Visualization (Graphs, Gauges).
Teaching Materials:
Hardware: Unihiker K10.
Software/Services: Thonny IDE, a free account on ThingSpeak or Adafruit IO.
Slides/Whiteboard: Comparison of HTTP GET vs. POST. Diagram showing the Unihiker sending data to a cloud platform which is then viewed in a browser.
Lecture Outline (Suggested Flow):
Recap (5 min): Briefly review fetching data from the cloud. Announce that today's goal is to send data to the cloud.
Explain (20 min):
Define Telemetry. Explain why we log data (to see trends, historical analysis, etc.).
Walk through the Unihiker's onboard sensors (Temperature & Humidity sensor, Ambient Light Sensor).
Screen-share the process of signing up for ThingSpeak or Adafruit IO. Create a new "Channel" (ThingSpeak) or "Feed" (Adafruit IO). Emphasize creating fields/feeds for temperature, humidity, and light.
Crucially, show where to find the "API Write Key". Explain that this key authorizes their device to send data.
Explain that an HTTP POST request is used to send data, unlike the GET request which retrieves it.
Demonstrate (10 min): Show the structure of the ThingSpeak update URL, which includes the API key and field data. Live code how to build this URL string in MicroPython with the latest sensor values.
In-Class Lab Activity (50 min):
Students set up their own IoT platform account and channel.
They write a script that reads all three onboard sensors.
They construct the URL for the HTTP POST request, embedding their unique API key and the sensor values.
They put this logic inside a while True: loop with a time.sleep(30) to send data every 30 seconds.
The final step is to watch their dashboard online and see the graphs update in real time.
Discussion & Homework (5 min):
Question: "What are the pros and cons of sending data every 5 seconds vs. every 5 minutes?" (Discuss battery life, data costs, data resolution).
Homework: Add error handling. What if the Wi-Fi disconnects? Use a try...except block to catch errors during the request and print a message instead of crashing.
Class 3: Mastering MQTT - The Language of IoT 💬
Objective: Understand and implement MQTT, the standard messaging protocol for IoT, for efficient, real-time communication.
Key Concepts:
Publish/Subscribe (Pub/Sub) architecture.
MQTT Broker, Client, and Topics.
Lightweight protocol benefits (vs. HTTP).
Quality of Service (QoS) at a high level.
Teaching Materials:
Hardware: Unihiker K10.
Software/Services: Thonny IDE, a web browser for a web-based MQTT client (like the HiveMQ Web Client).
Slides/Whiteboard: A diagram comparing the HTTP request/response model with the MQTT Pub/Sub model.
Lecture Outline (Suggested Flow):
Engage (5 min): Use an analogy for Pub/Sub. "HTTP is like ordering from a restaurant menu—you ask for something specific and get a response. MQTT is like subscribing to a magazine—you tell the publisher (Broker) you're interested in a topic, and they send you new issues whenever they're published."
Explain (20 min):
Draw the Pub/Sub architecture: multiple Clients (Publishers and Subscribers) all connecting to a central Broker.
Explain that clients don't know about each other; they only know the Broker. This decoupling is powerful.
Detail the concept of Topics, which are like addresses for messages (e.g., class/student_name/sensors). Emphasize the use of a hierarchical structure.
Explain why MQTT is the standard for IoT: it's lightweight, uses less data, and works better on unreliable networks than HTTP.
Demonstrate (10 min):
Open the HiveMQ Web Client. Show how to connect to the public broker.
Subscribe to a sample topic.
In another browser tab, use the client to publish a message to that topic and watch it appear instantly.
In-Class Lab Activity (50 min):
Students will use the MQTT example code as a base.
They will configure the code to connect to the public HiveMQ broker.
They will modify their script from Class 2. Instead of making an HTTP POST request, they will now publish a JSON string of their sensor data to a unique topic (e.g., iot_class/jane_doe/environment).
They will use the web client to subscribe to their own topic and watch their Unihiker's data stream in real-time.
Discussion & Homework (5 min):
Question: "Why is it critical to use a unique topic name on a public broker? What would happen if two people published to the same topic?"
Homework: Think about and design the MQTT topic structure for a smart home with devices in a living room and a kitchen.
Class 4: Two-Way Communication - Controlling Devices Remotely 🎮
Objective: Learn to send commands from the cloud back to the device to control hardware remotely.
Key Concepts:
Bidirectional communication.
Command and Control patterns.
Callback functions for event handling.
Parsing command payloads (JSON).
Teaching Materials:
Hardware: Unihiker K10, optional servo motor and jumper wires.
Software/Services: Thonny IDE, HiveMQ Web Client.
Slides/Whiteboard: Flowchart showing a command path: User -> MQTT Client -> Broker -> Unihiker -> Actuator.
Lecture Outline (Suggested Flow):
Recap (5 min): "So far, our device has only been a publisher (talking). Today, we'll teach it how to be a subscriber (listening)."
Explain (20 min):
Introduce the concept of a callback function. "It's a function you write that you don't call yourself. Instead, the MQTT library calls it for you automatically whenever a new message arrives on a topic you're subscribed to."
Discuss the importance of a well-defined command structure. It's better to send structured data like JSON ({"component": "led", "color": "red"}) than simple strings like "turn on". This makes your code scalable.
Draw the command flowchart on the board.
Demonstrate (10 min): Walk through the key parts of the MicroPython MQTT code for subscribing: client.set_callback(my_function), client.subscribe("my_topic"), and the client.check_msg() call inside the main loop that allows the callback to be triggered.
In-Class Lab Activity (50 min):
Students will write a callback function that receives topic and msg arguments.
Inside the callback, they will parse the msg (which will be a JSON string).
Their Unihiker will subscribe to a control topic (e.g., iot_class/jane_doe/control).
Using the web client, they will publish JSON commands to that topic to control the onboard RGB LED (e.g., {"led_color": "#00FF00"}) and, if they have one, a servo motor (e.g., {"servo_angle": 90}).
Discussion & Homework (5 min):
Question: "What are the security risks of this system? How could you prevent a stranger from controlling your device?" (Leads to discussion of authentication, private brokers).
Homework: Enhance the code to handle bad commands. What should happen if it receives a JSON message it doesn't understand? (e.g., {"toaster": "on"}).
Class 5: Building an Interactive IoT Dashboard 📊
Objective: Design and create a functional web dashboard to both visualize data and control the device, closing the loop of a full IoT application.
Key Concepts:
Data Visualization.
User Interface (UI) / User Experience (UX).
Dashboarding tools and widgets.
Integrating MQTT with a front-end service.
Teaching Materials:
Hardware: Unihiker K10.
Software/Services: Thonny IDE, a free account on Adafruit IO (recommended for its easy-to-use, integrated dashboard and MQTT broker).
Slides/Whiteboard: Screenshots of a well-designed dashboard vs. a poorly designed one.
Lecture Outline (Suggested Flow):
Engage (5 min): Show a polished, professional IoT dashboard (e.g., for a smart factory or smart farm). Explain that this is the "Application" layer where raw data becomes useful information.
Explain (20 min):
Introduce Adafruit IO as an all-in-one platform that provides both the MQTT Broker and the Dashboard builder.
Walk through the key concepts of Adafruit IO:
Feeds: These are the "Topics" where your data lives (e.g., a feed for temperature, a feed for humidity).
Dashboards: The visual canvas where you place your widgets.
Widgets: The visual elements themselves (graphs, gauges, buttons, sliders).
Demonstrate (15 min): Live screen-share the entire process:
Create a new Adafruit IO account.
Create two feeds: temperature and led-control.
Create a new dashboard.
Add a line chart widget and link it to the temperature feed.
Add a toggle switch widget and link it to the led-control feed.
Show where to find the Adafruit IO username and AIO Key needed for the code.
In-Class Lab Activity (45 min):
Students create their own Adafruit IO account and a dashboard with feeds for their sensor data and a control element.
They update their MicroPython code with the new Adafruit IO server, username, AIO key, and feed names.
The goal is to have their Unihiker publishing sensor data that appears on the dashboard's graph, while also listening for commands from the dashboard's toggle switch to turn the onboard LED on and off.
Discussion & Homework (5 min):
Question: "How would you design a dashboard differently for an engineer monitoring a machine versus a homeowner checking their thermostat?" (Discuss information density, simplicity, user goals).
Homework: Explore and add a different type of widget to your dashboard (e.g., a gauge for humidity or a color picker for the RGB LED).
Class 6: Edge Computing & Event-Driven IoT 🧠
Objective: Introduce the concept of processing data on the device (at the edge) to make intelligent decisions locally and send alerts only when necessary.
Key Concepts:
Edge Computing vs. Cloud Computing.
Benefits: Reduced latency, bandwidth savings, improved reliability.
State Machines (simple implementation).
Event-Driven architecture.
Teaching Materials:
Hardware: Unihiker K10, Ultrasonic Sensor (HC-SR04).
Software/Services: Thonny IDE, Adafruit IO account.
Slides/Whiteboard: Diagram comparing a "dumb" sensor streaming all data vs. a "smart" edge device sending only important events.
Lecture Outline (Suggested Flow):
Engage (5 min): Pose a scenario: "Imagine a security camera. Should it stream video 24/7 to the cloud, using tons of data? Or should it be smart enough to only send a clip when it detects motion?" This is the core idea of edge computing.
Explain (15 min):
Define Edge Computing: Performing computation on the device itself before data is sent to the cloud.
List the benefits: It's faster (no round-trip to the cloud), cheaper (uses less data), and more reliable (can still function if the internet goes down).
Introduce the concept of a simple State Machine. "Our device will only have two states: object_is_near or object_is_far. We only care about the moment it changes from one state to the other."
Demonstrate (15 min):
Show how to connect the ultrasonic sensor using the TRIG-ECHO Ultrasonic sensor example.
Whiteboard the logic for the lab:
In-Class Lab Activity (50 min):
Students will build a "Smart Proximity Alert System."
They connect the ultrasonic sensor to their Unihiker.
They will implement the state machine logic described above.
The device will send an MQTT message to an Adafruit IO dashboard only when an object enters or leaves a predefined range (e.g., 10 cm). The dashboard can have an indicator light that shows the current status.
Discussion & Homework (5 min):
Question: "What other decisions could be made at the edge for a smart home?" (e.g., turning on a light locally when motion is detected, without waiting for the cloud).
Homework: Add another layer of edge intelligence: modify the code to only send an alert if the object has been "near" for more than 5 seconds.
current_state = "far" loop: distance = read_sensor() if distance < 10 and current_state == "far": // State change! send_mqtt_alert("Object detected!") current_state = "near" elif distance >= 10 and current_state == "near": // State change! send_mqtt_alert("Object is gone.") current_state = "far"
Class 7: Final Project Workshop - Build Your Own IoT Solution 🏆
Objective: Integrate all learned concepts to design, build, and demonstrate a complete, functional IoT project.
Key Concepts:
System Integration.
Project Planning & Management.
Debugging complex systems.
Documentation and Presentation.
Teaching Materials:
Hardware: All previous hardware, plus a "maker buffet" of optional sensors and actuators (soil moisture sensors, relays, small pumps, PIR motion sensors, etc.).
Software/Services: Thonny IDE, Adafruit IO.
Lecture Outline (Suggested Flow):
Explain (15 min): This class is primarily a workshop.
Clearly state the final project requirements:
Must sense something from the physical world.
Must connect to the Adafruit IO platform using MQTT.
Must visualize at least one piece of data on a dashboard.
Must allow for remote control of at least one actuator from the dashboard.
Should incorporate some form of edge logic (i.e., not just streaming raw data).
Brainstorm project ideas as a class and present some prepared options.
Project Ideas:
Smart Plant Monitor: Uses a soil moisture sensor. Publishes moisture levels and can remotely trigger a relay connected to a small water pump.
Smart Desk Environment Monitor: Monitors light, temperature, and humidity. Sends an alert only if conditions go outside a "healthy" range.
Remote Pet Feeder: Uses a servo to dispense food, controlled by a button on the dashboard. A weight sensor could be used to publish how much food is left.
In-Class Lab Activity (Workshop - 65 min):
Students choose a project and begin building.
The instructor's role is to be a facilitator and consultant, moving between students to help them with:
Hardware wiring.
Code integration (combining sensor, MQTT, and control logic).
Debugging why something isn't working as expected.
Presentations & Wrap-up (10 min):
If time allows, have a few students briefly demonstrate their working projects.
Review the journey of the course, from a simple connected device to a full, intelligent IoT system.
Homework: Finish building the project and prepare a short documentation page including a system diagram, a link to the dashboard, and the final MicroPython code.
