Im letzten Beitrag habe ich dir gezeigt, wie du dich per SSH mit dem Arduino UNO Q verbindest, das Debian-System aktualisierst und Python installierst. Damit haben wir die Linux-Seite des Boards kennengelernt und den UNO Q wie einen kleinen Server im Arduino-Format eingerichtet.
In diesem Teil wechseln wir die Perspektive:
Wir arbeiten nun im Arduino App Lab und programmieren das Board direkt über die Entwicklungsumgebung.
Dabei schließen wir einen Modulino-Sensor über die Qwiic/I²C-Schnittstelle an und bringen ihn zum Laufen. Doch genau hier zeigt sich die eigentliche Besonderheit des Arduino UNO Q:
👉 Wir haben es nicht nur mit einem Mikrocontroller zu tun.
👉 Wir haben ein Board mit zwei Welten.
Auf der einen Seite steht die MCU, die klassisch mit Arduino-Style C/C++ (oder je nach Setup auch Python) programmiert wird und direkt mit der Hardware kommuniziert.
Auf der anderen Seite läuft ein vollständiges Linux-System, auf dem wir Python, Dienste und später sogar Monitoring einsetzen können.
Der große Vorteil:
Wir können beide Systeme relativ einfach miteinander verbinden und so das Beste aus beiden Ansätzen kombinieren – schnelle Hardware-Ansteuerung auf der MCU und flexible Weiterverarbeitung unter Linux.
In diesem Beitrag zeige ich dir:
- wie das Arduino App Lab aufgebaut ist
- wie du Code auf der MCU ausführst
- wie du einen Modulino anschließt und ausliest
- und warum die Verbindung zwischen MCU und Linux so spannend ist
Rückblick
Wie du den Arduino UNO Q einrichtest und ein erstes kleines Programm ausführst, habe ich dir bereits im Beitrag
„Arduino UNO Q – Wenn dein Mikrocontroller plötzlich ein Mini-PC wird“ ausführlich gezeigt.
Dort ging es vor allem um die Hardware, das Konzept hinter dem Board und warum der UNO Q eben kein klassischer Mikrocontroller ist, sondern eher ein kleiner Linux-Rechner im Arduino-Formfaktor.
Im zweiten Beitrag
„Arduino UNO Q – Linux, Python & Monitoring in der Praxis“
haben wir uns dann mit der Linux-Seite beschäftigt und gelernt, wie du per SSH auf die Shell zugreifst und Python installierst.
Genau hier knüpfen wir nun an.
In diesem Beitrag zeige ich dir, wie du den Arduino UNO Q im Arduino App Lab programmierst – sowohl im klassischen Arduino-Style mit C/C++ auf der MCU als auch mit Python im Linux-System.
Das Arduino App Lab verstehen
Statt erneut jede Oberfläche im Detail zu erklären, schauen wir uns den tatsächlichen Workflow im Arduino App Lab an – denn genau hier unterscheidet sich der UNO Q deutlich von einem klassischen Arduino-Board.
Der typische Ablauf im Arduino App Lab
Die Arbeit mit dem Arduino UNO Q folgt einem klaren Schema:
- Board auswählen
Verbindung über USB oder Netzwerk herstellen. - Projekt anlegen
Neue App erstellen und Entwicklungsumgebung vorbereiten. - In C/C++ und/oder Python programmieren
Je nach Anwendungsfall wird Code für die MCU oder für das Linux-System geschrieben – oder für beide. - Projekt auf den Arduino übertragen und starten
Die App wird deployed und direkt auf dem UNO Q ausgeführt.
Dieser Ablauf ist zunächst vertraut – zumindest für alle, die schon einmal mit der klassischen Arduino IDE oder der Arduino IDE 2.x gearbeitet haben. Der Unterschied liegt jedoch nicht im Workflow selbst, sondern in der Architektur dahinter.
Der entscheidende Unterschied zur klassischen Arduino IDE
Bei einem klassischen Arduino-Board gibt es nur eine Zielplattform: den Mikrocontroller.
Beim Arduino UNO Q hingegen arbeiten wir mit zwei Systemen gleichzeitig:
- MCU – für hardware-nahe, zeitkritische Aufgaben
- MPU (Linux) – für komplexere Logik, Netzwerk und
Python-Anwendungen
Im Arduino App Lab können beide Seiten aus einem einzigen Projekt heraus programmiert und miteinander verbunden werden.
Das ist zunächst ungewohnt, aber genau hier liegt die Stärke des UNO Q.
Warum das so spannend ist
Wir können Aufgaben sinnvoll aufteilen:
- Sensoren und Hardware direkt auf der MCU ansteuern
- Daten auf dem Linux-System weiterverarbeiten
- Funktionen systemübergreifend ausführen
Damit entsteht ein hybrides System, das deutlich leistungsfähiger ist als ein klassischer Mikrocontroller – ohne den typischen Bastel-Charakter zu verlieren.
Vergleich mit dem Raspberry Pi
An dieser Stelle lohnt sich ein kurzer Vergleich mit dem Raspberry Pi – insbesondere mit dem aktuellen Raspberry Pi 5.
Ein Raspberry Pi 5 in der 16-GB-Variante liegt derzeit bei rund 210 €, während der Arduino UNO Q in der 4-GB-Version bei etwa 65 € liegt. Preislich bewegt sich der UNO Q also in einem deutlich niedrigeren Bereich.
Beide Geräte basieren auf einem Linux-System – doch der Ansatz ist unterschiedlich.
Raspberry Pi
Beim Raspberry Pi arbeiten wir ausschließlich auf einem Linux-System.
Das bedeutet:
- Projekte werden direkt unter Linux umgesetzt
- Typische Sprachen sind Python, C/C++, Rust, Go oder Node.js
- Es gibt keinen separaten Mikrocontroller für hardware-nahe Echtzeitaufgaben
Für viele Anwendungsfälle ist das vollkommen ausreichend.
Gerade bei komplexeren Anwendungen oder Desktop-ähnlichen Projekten spielt der Raspberry Pi seine Stärken aus.
Allerdings bedeutet das auch, dass selbst einfache Hardware-Aufgaben vollständig im Linux-Kontext umgesetzt werden müssen.
Arduino UNO Q
Der Arduino UNO Q verfolgt einen hybriden Ansatz:
- Eine MCU für hardware-nahe, zeitkritische Aufgaben
- Eine MPU mit Linux für Logik, Netzwerk, Dateisystem und Python
Dadurch entsteht ein System, das die Stärken beider Welten kombiniert.
Einfache Hardware-Logik kann klassisch im Arduino-Style umgesetzt werden, ohne sich sofort mit komplexen Linux- oder Multithreading-Konzepten beschäftigen zu müssen.
Gleichzeitig steht bei Bedarf ein vollständiges Linux-System zur Verfügung.
Modulino anschließen – bewusst einfach gehalten
Über die bekannten Buchsenleisten des Arduino UNO Q können wir – ganz klassisch – Sensoren und Aktoren anschließen. LEDs, Buzzer, Taster oder Relais lassen sich wie gewohnt über die digitalen und analogen Pins verbinden.
Für diesen Beitrag möchte ich es jedoch bewusst einfacher halten.
Arduino bietet mit den sogenannten Modulinos kleine, kompakte Sensor- und Aktor-Boards an, die sich über die integrierte Qwiic-Schnittstelle (I²C) anschließen lassen. Der große Vorteil:
Kein aufwendiges Verdrahten, keine zusätzlichen Widerstände – einfach anstecken und loslegen.
Da der Fokus in diesem Beitrag nicht auf Schaltungsdesign oder Elektronik liegt, sondern auf der Programmierung und Architektur des UNO Q, nutze ich hier genau diesen Weg.
Da die Modulinos via I²C angeschlossen werden, können hier mehrere unterschiedliche Sensoren und auch Aktoren hintereinander verbunden werden!
Erstes MCU-Programm – Modulino Thermo auslesen
Damit wir das Modulino Thermo über die MCU ansprechen können, benötigen wir die passende Bibliothek. Arduino stellt hierfür die Bibliothek Arduino_Modulino bereit.
Diese Bibliothek enthält die Implementierungen für alle Modulinos – also nicht nur für das Thermo-Modul, sondern auch für weitere Sensor- und Aktor-Boards aus der Serie.
Zusätzlich installieren wir:
- Arduino_RouterBridge – für die Kommunikation zwischen MCU und Linux-System
- MsgPack – zur strukturierten Datenübertragung über die Bridge
Auch wenn wir die Bridge in diesem Abschnitt noch nicht vollständig einsetzen, ist es sinnvoll, diese Bibliotheken direkt mit zu installieren. So ist das Projekt später problemlos erweiterbar.
Wie du das Modulino Thermo am Arduino UNO R4 ausließt und die Daten in die Cloud sendest habe ich dir im Beitrag Smarte Wetterstation mit dem Arduino Plug and Make Kit und Cloud-Dashboard ausführlich erläutert.
Der Code für die MCU wird unter sketch > sketch.ino abgelegt. Dort können wir wie in der Arduino IDE die Sketche programmieren.
#include <Modulino.h>
#include "Arduino_RouterBridge.h"
ModulinoThermo thermo;
void setup(){
Monitor.begin();
Modulino.begin();
thermo.begin();
}
void loop(){
float temp = thermo.getTemperature();
float hum = thermo.getHumidity();
char msg[64];
formatEnvironment(temp, hum, msg, sizeof(msg));
Monitor.println(msg);
delay(2000);
}
void formatEnvironment(float temperature, float humidity, char* buffer, size_t size) {
snprintf(buffer, size, "T: %.2fC H: %.2f%%", temperature, humidity);
}
Die Daten des Sensors (Temperatur und rel. Luftfeuchtigkeit) lassen wir im Seriellen Monitor ausgeben.
Das manche Werte hintereinander geschrieben werden lassen wir erstmal so denn später werden wir die Daten an die MPU senden und dort weiterverarbeiten.
Damit haben wir den ersten Meilenstein erreicht, die Daten vom Sensor wurden erfolgreich ausgelesen. Wenn wir die Daten jedoch noch visualisieren möchten, dann benötigen wir sowas wie den seriellen Plotter in der Arduino IDE.
Im Arduino App Lab gibt es sowas jedoch nicht, jedoch kann man die Arduino IDE parallel dazu öffnen und somit die Daten abgreifen und anzeigen.
Wir müssen dazu nur die Daten in einem bestimmten format absenden, jeder Sensorwert muss ein Label gefolgt von einem Doppelpunkt haben, anschließend wird der Sensorwert ausgegeben.
Quellcode – formatierte Ausgabe von Sensordaten für den seriellen Plotter der Arduino IDE
#include <Modulino.h>
#include "Arduino_RouterBridge.h"
ModulinoThermo thermo;
void setup(){
Monitor.begin();
Modulino.begin();
thermo.begin();
}
void loop(){
float temp = thermo.getTemperature();
float hum = thermo.getHumidity();
char msg[64];
formatEnvironment(temp, hum, msg, sizeof(msg));
Monitor.print(msg);
delay(2000);
}
void formatEnvironment(float temperature, float humidity, char* buffer, size_t size) {
snprintf(buffer, size, "T:%.2f\r\nH:%.2f\r\n", temperature, humidity);
}
Damit können wir die Daten nun im seriellen Plotter der Arduino IDE anzeigen lassen.
Übergeben von Daten aus dem Mikrocontroller an das Linux-System
Bis hierhin haben wir den Modulino Thermo erfolgreich über die MCU ausgelesen und die Werte im Monitor ausgegeben.
Doch jetzt kommt der spannende Teil.
👉 Die Daten sollen das MCU-System verlassen.
👉 Sie sollen im Linux-System weiterverarbeitet werden.
Und genau dafür gibt es beim Arduino UNO Q eine integrierte Lösung:
Die RouterBridge
Die Bibliothek Arduino_RouterBridge ermöglicht die direkte Kommunikation zwischen der MCU und dem Linux-System.
Im einfachsten Fall bedeutet das: Die MCU sendet Daten – Linux empfängt sie.
Man kann sich das wie eine interne serielle Verbindung vorstellen, nur deutlich strukturierter und leistungsfähiger.
Minimalbeispiel: Daten von der MCU nach Linux senden
Erweitern wir unseren Sketch um eine einfache Übertragung:
#include <Modulino.h>
#include <Arduino_RouterBridge.h>
ModulinoThermo thermo;
void setup(){
Bridge.begin();
Monitor.begin();
Modulino.begin();
thermo.begin();
}
void loop(){
float temp = thermo.getTemperature();
float hum = thermo.getHumidity();
char msg[64];
formatEnvironment(temp, hum, msg, sizeof(msg));
Monitor.print(msg);
Bridge.notify("measurement", temp, hum);
delay(2000);
}
void formatEnvironment(float temperature, float humidity, char* buffer, size_t size) {
snprintf(buffer, size, "T:%.2f\r\nH:%.2f\r\n", temperature, humidity);
}
Hier passiert Folgendes:
notify()sendet ein Ereignis an das Linux-System- Es wird kein Rückgabewert erwartet
- Die Ausführung ist sofort abgeschlossen (non-blocking)
Damit verlassen unsere Sensordaten erstmals die MCU-Welt.
Linux-Seite: Messwerte in main.py empfangen
Im Arduino App Lab existiert die Datei main.py bereits automatisch.
Sie ist der Einstiegspunkt für den Linux-Teil deiner Anwendung.
Wir ergänzen dort nun den Code, um die von der MCU gesendeten Messwerte zu empfangen.
import time
from arduino.app_utils import *
print("Arduino UNO Q - Temperatur & rel. Luftfeuchtigkeit vom Modulino Thermo")
def loop():
# Der user_loop läuft dauerhaft,
# die Bridge verarbeitet eingehende Events im Hintergrund.
time.sleep(10)
def on_measurement_received(temp: float, hum: float):
print("Temperatur:", round(temp, 2), "°C")
print("rel. Luftfeuchtigkeit:", round(hum, 2), "%")
# Event "measurement" mit unserer Callback-Funktion verknüpfen
Bridge.provide("measurement", on_measurement_received)
# App starten
App.run(user_loop=loop)
Was passiert hier genau?
- Die MCU sendet: Bridge.notify(„measurement“, temperature, humidity);
- Der Linux-Router empfängt das Event.
- Die Bridge ruft automatisch: on_measurement_received(temp, hum) auf.
- Die Werte werden in der Linux-Konsole ausgegeben.
Wichtig:
main.pyläuft auf dem Linux-System des Arduino UNO Q- Die Bridge verarbeitet eingehende Nachrichten im Hintergrund
- Der
user_loopist nur dein optionaler Anwendungs-Loop
Sensordaten speichern und mit Matplotlib visualisieren
Bis hierhin werden die Sensordaten von der MCU zuverlässig an das Linux-System des Arduino UNO Q übergeben.
Jetzt gehen wir einen Schritt weiter:
- Die Daten werden dauerhaft gespeichert
- Ein Diagramm wird automatisch neu erzeugt
- Die Visualisierung läuft vollständig auf dem Linux-System
Damit nutzen wir genau die Stärke des UNO Q:
Hardware-Logik auf der MCU – Datenverarbeitung unter Linux.
Quellcode – visualisieren von Sensordaten im Arduino App Lab
from datetime import datetime
from zoneinfo import ZoneInfo
import time
from arduino.app_utils import *
import json
from pathlib import Path
import matplotlib
matplotlib.use("Agg") # wichtig auf Server ohne GUI
import matplotlib.pyplot as plt
DATA_FILE = "data.json"
PNG_FILE = "chart.png"
current_data = { "temperatur": None, "luftfeuchte": None }
print("Arduino UNO Q - Temperatur & rel. Luftfeuchtigkeit")
def loop():
time.sleep(10)
def on_measurement_received(temp: float, hum: float):
global current_data
current_data["temperatur"] = round(temp, 2)
current_data["luftfeuchte"] = round(hum, 2)
tryStoreData()
Bridge.provide("measurement", on_measurement_received)
def tryStoreData():
global current_data
if current_data["temperatur"] is not None and current_data["luftfeuchte"] is not None:
ts = int(time.time())
dt = datetime.fromtimestamp(ts, tz=ZoneInfo("Europe/Berlin")).strftime("%d.%m.%Y %H:%M:%S")
entry = {
"unixtimestamp": ts,
"zeitstempel": dt,
"temperatur": current_data["temperatur"],
"luftfeuchte": current_data["luftfeuchte"]
}
with open(DATA_FILE, "a") as f:
f.write(json.dumps(entry) + "\n")
print("Gespeichert:", entry)
# Reset für nächsten Zyklus
current_data = { "temperatur": None, "luftfeuchte": None }
#das Diagram erstellen / neuzeichnen
render_chart_from_ndjson()
def render_chart_from_ndjson(max_points: int = 200) -> str:
ndjson_file = Path(DATA_FILE)
output_file = Path(PNG_FILE)
output_file.parent.mkdir(parents=True, exist_ok=True)
if not ndjson_file.exists():
raise FileNotFoundError(f"Datei nicht gefunden: {ndjson_file}")
zeit_labels = []
temperaturen = []
luftfeuchte = []
with ndjson_file.open("r", encoding="utf-8") as f:
lines = [line.strip() for line in f if line.strip()]
# Nur letzte X Punkte anzeigen
lines = lines[-max_points:]
for line in lines:
obj = json.loads(line)
zeit_labels.append(obj["zeitstempel"])
temperaturen.append(float(obj["temperatur"]))
luftfeuchte.append(float(obj["luftfeuchte"]))
if not temperaturen:
raise ValueError("Keine gültigen Datenpunkte gefunden.")
plt.figure(figsize=(12, 5))
plt.plot(temperaturen, label="Temperatur (°C)")
plt.plot(luftfeuchte, label="Luftfeuchte (%)")
plt.title("Arduino UNO Q – Sensordaten")
plt.ylabel("Wert")
plt.grid(True, alpha=0.3)
plt.legend()
# X-Achse nicht überfrachten
step = max(1, len(zeit_labels) // 8)
x_ticks = list(range(0, len(zeit_labels), step))
plt.xticks(x_ticks,
[zeit_labels[i] for i in x_ticks],
rotation=30,
ha="right")
plt.tight_layout()
plt.savefig(output_file, dpi=150)
plt.close()
return str(output_file)
App.run(user_loop=loop)
Daten als NDJSON speichern
Anstatt eine klassische CSV-Datei zu verwenden, speichere ich die Messwerte als NDJSON (Newline Delimited JSON).
Das bedeutet:
- Jede Zeile ist ein eigenständiges JSON-Objekt
- Die Datei wächst kontinuierlich
- Sie lässt sich später einfach weiterverarbeiten (z. B. per Python, jq oder Import in Tools)
Ein gespeicherter Eintrag sieht beispielsweise so aus:
{"unixtimestamp": 1772224800, "zeitstempel": "27.02.2026 18:52:25", "temperatur": 21.54, "luftfeuchte": 45.12}
Der Zeitstempel wird dabei explizit in der Zeitzone Europe/Berlin erzeugt, sodass Sommer- und Winterzeit automatisch korrekt berücksichtigt werden.
Automatisches Speichern nach jedem Messwert
Sobald die MCU neue Werte sendet, wird das Callback on_measurement_received() ausgelöst:
def on_measurement_received(temp: float, hum: float): global current_data current_data["temperatur"] = round(temp, 2) current_data["luftfeuchte"] = round(hum, 2) tryStoreData()
Sobald beide Werte vorhanden sind, werden sie gespeichert:
dt = datetime.fromtimestamp(ts, tz=ZoneInfo("Europe/Berlin")).strftime("%d.%m.%Y %H:%M:%S")
Danach wird automatisch das Diagramm neu erzeugt.
Diagramm automatisch neu rendern
Die Funktion render_chart_from_ndjson() übernimmt:
- Einlesen der letzten Messwerte
- Begrenzung auf die letzten 200 Datenpunkte
- Erstellung eines PNG-Diagramms mit Matplotlib
- Speichern als
chart.png
Wichtig ist dabei:
matplotlib.use("Agg")
Da das Linux-System des UNO Q keine grafische Oberfläche besitzt, wird Matplotlib im Headless-Modus betrieben.
Das Diagramm wird direkt als Bilddatei gespeichert.
Die X-Achse wird bewusst nicht mit allen Zeitpunkten beschriftet, sondern nur in sinnvollen Abständen, damit das Diagramm lesbar bleibt.
Ergebnis
Nach wenigen Messzyklen entstehen zwei Dateien:
data.json→ fortlaufendes Sensordaten-Loggingchart.png→ aktuelles Diagramm
Das Diagramm wird bei jedem neuen Messwert aktualisiert.
Damit haben wir nun:
✔ Sensor auslesen (MCU)
✔ Daten übertragen (Bridge)
✔ Daten speichern (Linux)
✔ Daten visualisieren (Matplotlib)
Und das alles auf einem einzigen Board.
Warum das ein echter Unterschied ist
Auf einem klassischen Mikrocontroller wäre:
- Dateisystem eingeschränkt
- Matplotlib nicht nutzbar
- Datenanalyse nur mit externem PC möglich
Auf einem reinen Raspberry Pi gäbe es keine saubere Trennung zwischen Hardware- und Linux-Logik.
Der Arduino UNO Q kombiniert beides in einem sauberen, modularen Ansatz.
Fazit: Zwei Welten, ein System
Mit diesem Beispiel haben wir nicht einfach nur einen Sensor ausgelesen.
Wir haben ein vollständiges, hybrides System aufgebaut:
- Die MCU übernimmt die hardware-nahe Sensorabfrage
- Das Linux-System speichert, verarbeitet und visualisiert die Daten
- Beide Welten kommunizieren sauber über die RouterBridge
Und genau hier liegt der eigentliche Unterschied.
Der Arduino UNO Q ist kein „Arduino mit mehr Power“.
Und er ist auch kein „Raspberry Pi im Arduino-Format“.
Er ist eine Kombination aus beidem.
Während klassische Mikrocontroller bei Dateisystem, Visualisierung oder komplexer Logik schnell an ihre Grenzen stoßen, und ein reines Linux-System keine echte Trennung zwischen Echtzeit-Hardware und Applikationslogik bietet, kombiniert der UNO Q beide Ansätze auf einem Board.
Letzte Aktualisierung am: 01. März 2026
