Die meisten Anfänger raten, wo ihre Firmware hängt. Dabei sagt es das Programm selbst – über die Verbindung, die es beim Flashen ohnehin nutzt.

Wer ein erstes IoT-Programm auf einen Mikrocontroller lädt, trifft schnell auf Serial.println(). Wer nicht weiß, was dahinterläuft, sieht nur wirre Zeichen im Monitor und hält die Platine für kaputt.

Der serielle Monitor der Arduino-IDE zeigt Textausgaben der Firmware über die USB-Verbindung an, etwa mit Serial.println(). Dahinter steckt dieselbe UART-Verbindung, also die serielle Schnittstelle mit einer TX- und einer RX-Leitung, über die auch die Firmware in den Flash-Speicher geschrieben wird. UART überträgt Daten ohne gemeinsamen Takt, deshalb müssen Firmware und Monitor dieselbe Baudrate verwenden, also dieselbe Übertragungsgeschwindigkeit in Bits pro Sekunde.

In der Praxis sieht das so aus: In setup(), dem Vorbereitungsteil, der genau einmal läuft, startet Serial.begin() die Schnittstelle und legt die Baudrate fest. Danach gibt die Firmware mit Serial.print() Text aus dem laufenden loop(), der Endlosschleife nach dem Start, an den PC. Serial.println() fügt am Ende einen Zeilenumbruch an, sodass jede Ausgabe eine eigene Zeile erhält. Vor dem WLAN-Verbinden etwa eine Zeile „WLAN verbinde…“, danach die Antwort der Firmware.

Verwechselt wird der Monitor gern mit einem Messgerät. Er ist keins: Er zeigt nur, was die Firmware selbst ausgibt, etwa den gelesenen Pin-Zustand, nicht was ein Multimeter messen würde. Auch Serial.begin() gehört in setup(), nicht in loop(), sonst wiederholt die Firmware die Startarbeit bei jedem Durchlauf und kann Abläufe stören, die nur beim Start gehören.

Der serielle Monitor ist kein separates Werkzeug, sondern dasselbe UART-Kabel, nur in Gegenrichtung. Er ersetzt kein Messgerät – aber er ersetzt das Raten.

📌 Serieller Monitor · Serial.println() · Baudrate

📚 IoT von Grund auf · Tag 3 von 30
#Arduino #esp32 #Mikrocontroller

Ein Quantencomputer prüft angeblich alle Lösungen gleichzeitig. Das klingt faszinierend – und ist grundsätzlich falsch verstanden.

Viele Einsteiger denken, ein Qubit speichere „0 und 1 zugleich“ wie einen Parallelspeicher. Plausibel, weil klassische Rechner mit Bits arbeiten und mehr Bits einfach mehr Werte bedeuten.

Tatsächlich ist ein Qubit das Gegenstück zum Bit, trägt aber keine fertigen Werte. Es hält eine Überlagerung (Superposition) der Zustände 0 und 1; erst bei der Messung geht genau ein klassisches Ergebnis hervor. Die Messung zerstört die Superposition, danach liegt ein eindeutiges Bit vor.

Der Irrtum entsteht, weil Wahrscheinlichkeiten wie „viele Werte auf einmal“ klingen. Aus einem Qubit liest man immer nur ein einziges Bit aus.

Er nutzt Superposition, Verschränkung (unteilbare Verbindung mehrerer Qubits mit gemeinsamem Zustand) und eine Fourier-Transformation auf Qubits, um große Zahlen zu faktorisieren. Der Trick ist nicht paralleles Ausprobieren, sondern Interferenz: die Rechnung verstärkt die Wahrscheinlichkeit der richtigen Lösung und unterdrückt die falschen.

Quantenprogramme bestehen aus Gattern (Operationen auf Qubits, analog zu UND und NICHT) und Messungen. Ergebnisse sind statistisch und werden über viele Wiederholungen, sogenannte Shots, ermittelt. Ein Quantencomputer ist keine schnellere Allzweckmaschine; Vorteile gibt es nur für bestimmte Problemklassen.

Woran man es erkennt: Wer von „alle Lösungen gleichzeitig testen“ spricht, verwechselt Messung mit Rechnung. Korrekt ist: Nutzen entsteht durch gezielte Wahrscheinlichkeitssteuerung, nicht durch Parallelspeicherung.

Superposition heißt nicht „viele Werte auf einmal ablesen“, sondern eine Überlagerung, die erst durch Gatter, Interferenz und die abschließende Messung ihren Wert entfaltet.

📌 Qubit · Superposition · Interferenz

📚 Zukunftstechnologien verstehen · Tag 3 von 30
#Quantencomputing #Innovation

Die Antwort erscheint Wort für Wort – und trotzdem entsteht sie Stück für Stück. Ein Sprachmodell plant keinen Satz, es wählt immer nur den nächsten Baustein.

Erklärt wird die schrittweise Erzeugung von Text: der autoregressive Ablauf, bei dem aus Wahrscheinlichkeiten Token für Token die Antwort aufgebaut wird. Er steckt hinter jeder Chat-Antwort, ob kurzer Hinweis oder langer Brief.

Zuerst zerlegt ein Tokenizer, also das Zerlegungsprogramm, die Eingabe in Tokens. Diese Reihenfolge verarbeitet das Modell – es denkt nicht in Wörtern.

Dann berechnet das Modell für jedes mögliche Folge-Token eine Wahrscheinlichkeit über das gesamte Vokabular. Ein Sprachmodell ist darauf trainiert, genau dieses nächste Token vorherzusagen. Nach „Die Sonne scheint am“ erhalten „Himmel“ und „Morgen“ hohe Werte, „Kartoffel“ sehr niedrige.

Danach wird ein Token ausgewählt, und die Temperatur (eine Einstellung, die die Verteilung skaliert) bestimmt, wie: Unter 1 bevorzugt wahrscheinliche Tokens, über 1 mischt der Zufall stärker mit. Temperatur 0 wählt gierig das wahrscheinlichste Token und liefert bei gleicher Eingabe stets dieselbe Fortsetzung. Top-p begrenzt die Auswahl auf die kleinste Menge, deren Wahrscheinlichkeiten zusammen mindestens p ergeben.

Zuletzt wird das gewählte Token angehängt und das erweiterte Stück zur neuen Eingabe. Der Vorgang wiederholt sich, bis ein Stopp-Token oder eine gesetzte Höchstlänge die Ausgabe beendet. Weil jeder Schritt ein voller Durchlauf ist, wächst die Zeit mit der Tokenzahl; auch das Kontextfenster, die maximale berücksichtigte Tokenzahl, begrenzt den Blick.

Ein Sprachmodell plant also nicht, sondern würfelt gezielt weiter. Geschwindigkeit, Länge und Abwechslung der Antwort folgen direkt aus dieser Mechanik.

📌 Autoregressive Erzeugung · Temperatur · Token für Token

📚 KI von Grund auf · Tag 3 von 30
#llm #machinelearning #Inferenz

Viele reden von Containern, meinen aber das Image – und umgekehrt. Dabei ist der Unterschied so klar wie der zwischen Backrezept und Kuchen.

Die Verwechslung liegt an der Sprache: Docker nennt beides fast gleich, und die Begriffe treten immer paarweise auf. Ein Fehler im laufenden Container zeigt sich erst später als verlorene Arbeit.

Ein Image ist eine unveränderliche Vorlage: eine Datei-Sammlung, in der Anwendung, Laufzeit-Umgebung, Bibliotheken und Konfiguration fest eingefroren sind. Nach dem Bau wird es nicht mehr geändert, sondern nur durch ein neues ersetzt – das Prinzip heißt Immutable Infrastructure. Beschrieben wird der Bau in einem Dockerfile, einer Schritt-für-Schritt-Anleitung. Beispiel: Ein Image enthält Python in einer festen Version plus den eigenen Anwendungscode.

Ein Container ist die laufende Instanz, die aus genau diesem Image gestartet wird. Er verpackt die Anwendung mit ihren Abhängigkeiten und teilt sich den Kernel (den Kern) des Host-Betriebssystems, startet dadurch schneller als eine virtuelle Maschine. Aus ein und demselben Image lassen sich beliebig viele Container starten, die alle identisch beginnen. Beispiel: Drei Container aus demselben Python-Image laufen gleichzeitig auf drei Rechnern.

Das Image bleibt unverändert, der Container ist vergänglich. Jede Änderung am laufenden Container verliert mit dessen Löschung ihre Spur.

Faustregel: Änderungen gehören immer in ein neues Image, das man über das Dockerfile baut – niemals in den laufenden Container.

Ein Image ist die Vorlage, ein Container deren laufende Kopie. Wer am Container schraubt, arbeitet im Sandkasten; wer am Image baut, arbeitet für jeden künftigen Start.

📌 Image = Vorlage · Container = Instanz · Änderungen ins Dockerfile

📚 Cloud von Grund auf · Tag 3 von 30
#docker #devops #kubernetes

Eine Webhook-URL funktioniert wie ein Türspalt ohne Schloss: Wer die Adresse kennt, kommt herein. Niemand meldet sich an, niemand fragt nach dem Ausweis.

Vorstellen lässt sich eine Hinterwerkstattür, die ein zustellender Bote regelmäßig nutzt. Der Bote kennt die Tür, schiebt Pakete durch und geht wieder. Ein Fremder, der die Adresse der Tür einmal gesehen hat, kann dieselbe Tür genauso benutzen. Er wirft dann keine echten Pakete hinein, sondern ausgedachte.

Die Tür ist die Webhook-URL, die Adresse, unter der ein Workflow auf Anfragen wartet. Ein Webhook ist ein HTTP-Aufruf, meist POST mit JSON-Body, den ein System bei einem Ereignis an genau diese URL sendet. Der Riegel fehlt: Ohne weitere Prüfung genügt die Kenntnis der Adresse, um eine Anfrage abzusetzen, ganz ohne Anmeldung. HTTPS verschlüsselt zwar die Verbindung auf dem Weg, sagt aber nichts darüber, wer gesendet hat.

Konkret sieht das so aus: In n8n richtet man einen Webhook-Trigger über den Webhook Node ein, der eine URL bereitstellt. Wer diese URL kennt, kann mit einem einfachen HTTP-POST-Programm eine ausgedachte Bestellung senden und den Workflow starten, als wäre das Ereignis echt.

Das Bild hat eine Grenze: Eine Tür kann man abschließen, eine bloße URL nicht. Das Schloss ist eine Signaturprüfung mit einem gemeinsamen Geheimnis, etwa per HMAC-SHA256; nur wer das Geheimnis kennt, erzeugt eine gültige Signatur.

Deshalb: Die Webhook-URL wie ein Passwort behandeln, nur über HTTPS erreichbar machen und bei Kündigung oder Verdacht auf Bekanntwerden neu vergeben. Nicht in Repositorien, Screenshots, Dokumentationen oder Logs veröffentlichen.

Wer die Adresse kennt, kann senden. Die URL schützt niemanden, sie benennt nur die Tür.

📌 HTTPS · Vertraulichkeit · Signaturprüfung

📚 Automatisierung von Grund auf · Tag 3 von 30
#Webhooks #n8n #Automatisierung #datenschutz

Viele halten den Pfad einer URL für einen Ordner auf dem Server. Dabei ist er nur ein Bezeichner, den der Server frei interpretiert.

Einsteiger denken so, weil Adressen wie /artikel/42 wie Dateipfade aussehen. Das klingt plausibel, schließlich arbeitet man im Betriebssystem tagtäglich mit Ordnern.

Tatsächlich besteht eine URL aus mehreren Teilen: Schema, Host, optionalem Port, Pfad, optionaler Query und optionalem Fragment. Das Schema etwa https sagt dem Client, also dem Browser, welches Protokoll er für die Verbindung nutzt. Der Host nennt den Server, und der Pfad benennt die Ressource, die angefragt wird. Der Server vergleicht den Pfad mit seinen hinterlegten Routen und antwortet mit 404, wenn keine passt.

Der Irrtum entsteht, weil URLs oft so aussehen wie Dateipfade. Server dürfen den Pfad aber beliebig deuten; eine Ordnung dahinter ist reine Konvention.

Nehmen wir eine Adresse mit dem Pfad /artikel/42 und der Query ?sort=neu&page=2. Der Browser baut daraus die Anfrage an den Server des Hosts, über HTTPS verschlüsselt. Der Pfad wählt die Ressource, die Query-Parameter als Name-Wert-Paare liefern zusätzliche Angaben wie Filter oder Sortierung. Passt keine Route, antwortet der Server mit 404 statt 200.

Woran man es erkennt: Der Server antwortet auf jeden Pfad nach eigenen Regeln, nicht nach Dateisystem-Lookup. Ein Fragment nach der Raute wird gar nicht erst mitgesendet, weil es eine Stelle innerhalb der Seite bezeichnet.

Der Pfad heißt nicht Ordnerstruktur auf dem Server, sondern ein Bezeichner für die Ressource, deren Deutung beim Server liegt.

📌 Schema · Host · Pfad · Query-Parameter

📚 Webentwicklung von Grund auf · Tag 1 von 30
#webdev #HTTP #backend

„KIONOVA® ist meine Antwort auf eine Welt, in der Sicherheits-Infrastruktur, KI und Souveränität dem nächsten Cloud-Outage geopfert werden. Das Ökosystem reicht von PULSE (Compliance + Lagebild) über CORE, AI, VISION, MED bis SPACE EXIT — alles on-premise, alles aus einer Hand, alles in Deutschland entwickelt."

Amir Herco, Founder & Visionär · KIONOVA®

Lokale LLMs im Unternehmen: Open-Source-Modelle wie Mistral und Codestral auf eigener Hardware. Kein Datenschutz-Problem, keine API-Kosten, volle Kontrolle. Wir haben einen internen Playground gebaut wo jedes Team die Modelle für ihre Use Cases testen kann.

Die überraschende Erkenntnis: Für 80% unserer Anwendungsfälle reicht ein 13B-Modell. Nur für komplexe Analyse und Coding brauchen wir die großen Modelle. #localllm #opensource #datenschutz