Wer sich regelmäßig mit Arduino, ESP32, Raspberry Pi oder anderen Mikrocontrollern beschäftigt, kennt vermutlich das Problem: Mit der Zeit sammeln sich immer mehr Sensoren, Displays, Entwicklungsboards, LEDs, Widerstände und andere elektronische Bauteile an. Irgendwann weiß man zwar noch ungefähr, was sich in den Sortierkästen befindet, aber nicht mehr unbedingt, wie viele Bauteile vorhanden sind, wo sie liegen oder ob für ein neues Projekt bereits alles vorhanden ist.
Natürlich gibt es bereits fertige Systeme, mit denen sich elektronische Bauteile katalogisieren und verwalten lassen. Meine Idee für dieses Projekt geht jedoch einen Schritt weiter: Die erfassten Daten sollen später auch Claude über einen eigenen MCP-Server zur Verfügung stehen.
Damit möchte ich beispielsweise Fragen stellen können wie:
„Ich möchte mit einem ESP32 Temperatur und Luftfeuchtigkeit messen und die Werte auf einem Display anzeigen. Welche passenden Bauteile habe ich dafür bereits auf Lager?“
Claude soll dann nicht einfach allgemeine Komponenten vorschlagen, sondern meinen tatsächlichen Bestand berücksichtigen und daraus eine passende Zusammenstellung für das Projekt erzeugen.
Genauso soll sich überprüfen lassen:
„Habe ich eigentlich alles da, was ich für dieses Projekt benötige?“
Damit wird aus einer klassischen Bauteilverwaltung nach und nach eine intelligente Elektronik-Werkstatt, die mich nicht nur beim Finden von Komponenten unterstützt, sondern auch bei der Planung neuer Projekte.
Was hebt meine Lösung von anderen ab?
Eine klassische Bauteilverwaltung endet meist bei Bestand und Lagerort. In meiner Lösung sollen diese Informationen zusätzlich direkt in die Projektplanung einfließen.
Wenn ich mir beispielsweise ein neues ESP32-Projekt erstellen lasse, soll Claude berücksichtigen, welche Mikrocontroller, Sensoren, Displays oder Module tatsächlich in meinem Bestand vorhanden sind.
So muss ich nach einem Projektvorschlag nicht erst prüfen, ob die benötigten Komponenten überhaupt vorhanden sind. Fehlt ein Bauteil, kann gleichzeitig nach einer passenden Alternative aus meinem Bestand gesucht werden.
Der eigentliche Mehrwert liegt für mich deshalb nicht nur im Katalogisieren der Bauteile, sondern darin, den eigenen Bestand direkt in den Entwicklungsprozess einzubeziehen. Aus einer einfachen Inventarliste wird damit nach und nach eine praktische Grundlage für die Planung neuer Elektronikprojekte.
Projekt auf GitHub
Den aktuellen Stand der Bauteilverwaltung stelle ich auf GitHub zur Verfügung. Dort findest du den Quellcode des Python-Tools sowie die zugehörige SQLite-Struktur und kannst das Projekt selbst ausprobieren oder für die eigene Werkstatt anpassen.
GitHub-Repository:
https://github.com/StefanDraeger/bauteilverwaltung-mit-ki/tree/main/bauteilverwaltung
Das Repository wird im Verlauf dieser Serie Schritt für Schritt erweitert. So kannst du die einzelnen Ausbaustufen nachvollziehen und die Entwicklung der smarten Elektronik-Werkstatt direkt mitverfolgen.
Die erste Ausbaustufe: Den eigenen Bestand erfassen
Bevor Claude später auf meinen tatsächlichen Bauteilbestand zugreifen und daraus passende Komponenten für ein Projekt auswählen kann, benötigen wir zunächst eine verlässliche Datengrundlage.
Der erste Schritt besteht daher darin, die vorhandenen Elektronikbauteile zu katalogisieren. Dafür werden die Komponenten in einer SQLite-Datenbank gespeichert. Neben dem Namen eines Bauteils können dabei unter anderem Kategorie, Hersteller, Schnittstellen, unterstützte Funkstandards, Stückzahl sowie die Position im Sortierkasten hinterlegt werden.
Damit die Datenbank nicht mühsam über SQL-Befehle gepflegt werden muss, kommt ein kleines Python-Tool zum Einsatz. Über eine grafische Oberfläche lassen sich die vorhandenen Bauteile komfortabel hinzufügen, bearbeiten, suchen und wieder löschen.
Für jedes Bauteil können beispielsweise folgende Informationen erfasst werden:
- Name
- Kategorie
- Hersteller
- Schnittstellen
- WiFi, BLE, Matter, Zigbee und Thread
- vorhandene Stückzahl
- Reihe und Spalte im Sortierkasten
- zusätzliche Beschreibung
Diese Angaben ermöglichen später gezielte Abfragen, beispielsweise nach bestimmten Schnittstellen, Herstellern oder Funkstandards. Aus einem einfachen Eintrag wie „ESP32“ wird so ein Datensatz, den wir gezielt durchsuchen und später auch von einer KI auswerten lassen können.
Die Katalogisierung kostet zunächst etwas Zeit, dafür steht anschließend eine strukturierte Datenbasis für die weiteren Ausbaustufen zur Verfügung.
Im ersten Schritt können wir damit bereits unseren eigenen Bestand durchsuchen und herausfinden, welche Bauteile vorhanden sind und wo sie liegen.
In meinem Fall bedeutet dieser erste Schritt allerdings einiges an Arbeit: Aktuell müssen 18 Sortimentskästen digitalisiert und die darin enthaltenen Bauteile erfasst werden.
Gleichzeitig nutze ich das Projekt, um meine bisherige Lagerstruktur zu überarbeiten. Viele Komponenten befinden sich derzeit noch in klassischen Sortimentkästen mit Deckel. Diese möchte ich nach und nach durch übersichtlichere Kleinteilemagazine ersetzen.
Dadurch verbinde ich die digitale Katalogisierung direkt mit einer Neuorganisation meiner Elektronik-Werkstatt. Jedes Bauteil erhält nicht nur einen Eintrag in der Datenbank, sondern gleichzeitig einen eindeutig definierten Lagerplatz über Reihe und Spalte.
Der Aufwand ist zunächst größer, dafür entsteht eine eindeutige Lagerstruktur, die sowohl für mich als auch für die spätere Software leicht nachvollziehbar ist.
Aufbau der SQLite-Datenbank
Für die erste Version verwenden wir eine kleine, normalisierte SQLite-Datenbank. Statt alle Informationen in einer einzigen Tabelle zu speichern, werden wiederkehrende Daten wie Kategorie, Hersteller und Schnittstellen ausgelagert. Das verhindert unterschiedliche Schreibweisen und erleichtert spätere Abfragen.
Das folgende UML-Diagramm zeigt den Aufbau der Datenbank und die Beziehungen zwischen den einzelnen Tabellen.
Das verhindert unterschiedliche Schreibweisen und erleichtert spätere Abfragen.
Unsere Datenbank besteht zunächst aus fünf Tabellen:
| Tabelle | Aufgabe |
|---|---|
components | Bauteile, Bestand, Lagerposition und Eigenschaften |
categories | Kategorien wie Sensor, Display oder Mikrocontroller |
manufacturers | Hersteller der Komponenten |
interfaces | Schnittstellen wie I2C, SPI, UART oder GPIO |
component_interfaces | Zuordnung mehrerer Schnittstellen zu einem Bauteil |
Die zentrale Tabelle components enthält unter anderem:
- Name,
- Hersteller
- Kategorie
- WiFi / BLE / Matter / Zigbee / Thread
- Bestand
- Reihe
- Spalte
- Beschreibung
Kategorie und Hersteller werden dabei nur über ihre jeweilige ID referenziert. Bei den Schnittstellen benötigen wir zusätzlich die Tabelle component_interfaces, da ein Bauteil beispielsweise gleichzeitig I2C, SPI und UART unterstützen kann.
Auch die Lagerposition wird bewusst getrennt als Reihe und Spalte gespeichert. So müssen wir später keinen Text wie Reihe 3 / Spalte 7 zerlegen und können die Position einfacher mit unserem geplanten LED-System verbinden.
Für den Einstieg reicht dieser Aufbau vollkommen aus. Gleichzeitig bleiben die Daten sauber strukturiert und können später sowohl mit Python als auch über den geplanten MCP-Server gezielt abgefragt werden.
Bauteile mit Python durchsuchen
Nachdem die Komponenten in der SQLite-Datenbank erfasst wurden, können wir unseren Bestand bereits komfortabel durchsuchen. Dafür kommt ein kleines Python-Tool zum Einsatz, das ausschließlich lesend auf die Datenbank zugreift.
Gestartet wird die Suche mit:
python suche.py
Die Suche arbeitet bewusst sehr einfach: Der eingegebene Suchbegriff wird gleichzeitig über mehrere Felder der Datenbank geprüft. Dazu gehören unter anderem:
- Name
- Kategorie
- Hersteller
- Schnittstellen
- Beschreibung
- Reihe
- Spalte
Eine separate Auswahl einzelner Filter ist in dieser ersten Version nicht vorgesehen. Suche ich beispielsweise nach I2C, werden alle Bauteile angezeigt, bei denen dieser Begriff in einem der berücksichtigten Felder vorkommt.
Die Treffer erscheinen anschließend in einer Tabelle mit Name, Kategorie, Hersteller, Schnittstellen, Bestand sowie Reihe und Spalte. Wird ein Bauteil ausgewählt, zeigt das Tool zusätzlich weitere Informationen wie Funkstandards und Beschreibung an.
Damit haben wir bereits einen ersten praktischen Nutzen aus unserer Datenbank: Statt die Sortimentskästen manuell zu durchsuchen, reicht eine kurze Suche nach einem Bauteil, Hersteller oder einer bestimmten Eigenschaft.
Diese einfache Volltextsuche bildet gleichzeitig die Grundlage für die späteren Ausbaustufen, in denen Claude die vorhandenen Daten direkt über einen MCP-Server abfragen soll.
Fazit
Mit der Katalogisierung ist der wahrscheinlich lästigste Teil der smarten Elektronik-Werkstatt zunächst geschafft. Die vorhandenen Komponenten sind strukturiert in einer SQLite-Datenbank abgelegt und können über das Python-Tool bereits durchsucht werden.
Damit steht jetzt die Grundlage für die nächsten Schritte: Wir wissen, welche Bauteile vorhanden sind, welche Eigenschaften sie besitzen und wo sie liegen.
Der Aufwand beim Erfassen der Komponenten ist zwar nicht ganz unerheblich, muss aber im Idealfall nur einmal sauber durchgeführt werden. Danach lässt sich der Bestand deutlich einfacher pflegen und durchsuchen.
Ausblick auf Teil 2
Im nächsten Teil kommt nun Claude ins Spiel. Dafür werden wir die SQLite-Datenbank so anbinden, dass Claude auf unseren tatsächlichen Bauteilbestand zugreifen kann.
Das Ziel ist, die Informationen aus der Datenbank gezielt in den Kontext eines Prompts einzubinden. Claude soll dadurch bei der Planung eines Projekts nicht nur allgemeine Bauteile vorschlagen, sondern berücksichtigen, was tatsächlich vorhanden ist.
Aus einer Anfrage wie:
„Erstelle mir ein kleines Projekt zur Messung von Temperatur und Luftfeuchtigkeit mit Display.“
soll später eine Lösung entstehen, die direkt prüft, welche passenden Mikrocontroller, Sensoren und Displays in der eigenen Werkstatt vorhanden sind.
Damit verlassen wir im nächsten Teil die reine Bauteilverwaltung und beginnen mit dem eigentlichen Kern der Serie: Die eigene Elektronik-Werkstatt wird Teil des Kontexts von Claude.
Letzte Aktualisierung am: 17. August 2026
