ElektronikDB — komponentlager med et kamera og en kritisk sans

Jeg har en skuffe. Faktisk har jeg flere, og i dem ligger der modstande, kondensatorer, ESP32-moduler, sensorer jeg købte til et projekt jeg aldrig kom i gang med, og et ukendt antal LED’er. Problemet er ikke at finde plads. Det er at huske hvad der ligger der.

Så jeg byggede ElektronikDB: et komponentlager der kører på min egen server, som jeg kan fodre med et billede fra telefonen, og som ikke lyver for mig om hvad den ved.

Hvad den gør

• Katalogiserer elektronikkomponenter ud fra et eller flere billeder taget med telefonen
• Foreslår kategori, navn og specifikationer med en AI-model — men gemmer aldrig noget uden godkendelse
• Beskærer billedet automatisk til selve komponenten, uden ekstra API-kald
• Holder styr på antal, dubletter og manglende data på tværs af samlingen
• Fungerer som en PWA med offline-fallback

Lige nu ligger der 334 komponenter, 4.643 stykker i alt, fordelt på 18 kategorier med 459 billeder.

Sådan virker det

Arbejdsgangen er tre trin.

Du vælger kategori — ikke fordi systemet ikke kan gætte, men fordi et gæt koster kvalitet. Med kategorien på forhånd ved sprogmodellen præcis hvilke felter den skal udfylde, i stedet for at finde på sit eget skema.

Du tager op til fire billeder af samme komponent. Typenummer og driver-IC står ofte på bagsiden, pin-labels på forsiden — ingen af siderne kan identificere komponenten alene.

Du godkender. Modellens svar er et forslag: en sikkerhedsscore, en begrundelse der siger hvilket billede hvad kom fra, og en knap ved hvert felt. Er forslaget forkert, skriver man hvad det faktisk er, og de samme billeder køres igennem igen — ingen ny upload nødvendig.

I samme kald, hvor modellen identificerer komponenten, returnerer den også en bounding box, så billedet beskæres automatisk. Det koster hverken et ekstra API-kald eller ekstra ventetid.

Det, der var svært

Farvekoder kan ikke aflæses pålideligt fra et foto. To modeller på samme billede af en farvekodet modstand gav forskellige svar — én læste fire bånd, en anden fem. Løsningen blev ikke at stole på tolkningen, men altid at gemme de rå bånd-farver som en selvstændig specifikation, så jeg selv kan kontrollere aflæsningen med et blik.

En sprogmodel skrev sin tankestrøm direkte ind i et felt — 661 tegn i et felt der skulle indeholde “4,7 kΩ”. Prompten forbyder det stadig eksplicit, men som sikkerhedsnet afviser serveren nu svar der er for lange til at kunne være en ægte værdi. Prompten er den optimistiske del af systemet. Serveren er den pessimistiske.

Beskæringen krævede tre lag detaljer, jeg ikke havde forventet: EXIF-rotation skal bages ind i pixlerne før beskæring, marginen omkring komponenten skal have et gulv (ellers bliver et aflangt billede beskåret for stramt), og miniaturen i previewet må ikke bruge object-fit: cover — det fik korrekte beskæringer til at se forkerte ud.

Teknikken, kort

• Backend: FastAPI, Jinja2-templates, HTMX — server-renderet, ingen frontend-build
• Database: SQLite i én fil
• Drift: Én Docker-container bag nginx-proxy-manager med Let’s Encrypt
• Sprogregel: Backend (kode, URL’er, prompt) er engelsk. Brugerflade og indhold er dansk
• Adgang: Åben læseadgang, PIN-krav på alt der skriver — håndhævet i middleware ud fra HTTP-metoden, ikke en liste af ruter

Hvad jeg tager med

Et forslag er ikke et svar — hele systemet er bygget om den skelnen mellem hvad AI’en foreslår, og hvad et menneske godkender. Og næsten hver eneste designbeslutning kom af at tælle noget i de rigtige data, ikke af at gætte: skal et felt være obligatorisk? Tæl hvor mange komponenter der faktisk har det udfyldt, og lad tallet bestemme.