[Session 2026-06-22] Prüfstand DS18B20 angelegt; Flash durch verpolten Sensor blockiert #124

New issue

Open

opened 2026-06-22 20:57:24 +00:00 by orbitalo · 0 comments

orbitalo commented

2026-06-22 20:57:24 +00:00

Owner

Was wurde gemacht

DS18B20-Werkbank-Prüfstand konzipiert (Architektur-Entscheidung: Split ESP8266-Testknecht + Waveshare ESP32-S3 HMI über MQTT, eigener Namespace pruefstand/...).
Neues Repo orbitalo/pruefstand (Cline) mit Phase-0/1-Firmware: DS18B20-Scan, CRC8, Klon-Heuristik, Parasitär-Erkennung, MQTT-Publish + Bench-I/O.
Code-Review + Verifikation durchgeführt; firmware.bin nach pve-mu-3 übertragen (sha256 verifiziert).
Flash-Workflow-Wirrwarr aufgeklärt: ESP8266-Satelliten/Prüfstand werden über pve-mu-3 (/dev/ttyUSB0, CH340) per esptool geflasht — NICHT über den Windows/COM-Weg des ESP32-Heizraum-Knotens. In OpenMemory festgehalten.
Kurze Architektur-Beratung zum CT116-Deploy (Forgejo Actions vs. Ist-Zustand) — Ergebnis: vorerst so lassen, optionale Verbesserungen in OpenMemory notiert.

Aenderungen an Infrastruktur

Neues Forgejo-Repo orbitalo/pruefstand (privat) + Issue #1 (Status/Next Steps).
Mehrere OpenMemory-Einträge: Flash-Setups (ESP32-Windows vs. ESP8266-pve-mu-3), Pin D3=GPIO0, Prüfstand-Optionen, CT116-Deploy-Restpunkte.
Keine Änderungen an produktiven Diensten (Bot, Broker, Heizraum-FW unangetastet).

Erkannte Probleme

DS18B20 am Prüfstand-ESP verpolt angelötet (VDD/GND) → Überstrom, USB-Brownouts, Flash-Connect scheitert, GPIO0/Chip mutmaßlich beschädigt. Reine HW-Ursache, Software ist ok.

Naechste Schritte

Siehe orbitalo/pruefstand#1: neuen Sensor korrekt anlöten (DQ→D3/GPIO0, 4,7k Pull-up), ESP allein auf Flashbarkeit testen, sonst frischen D1 Mini; dann Flash von Pulse + Broker-Verifikation; danach Phase 2 (Waveshare LVGL-HMI, braucht 5V/2A-Netzteil).

Betroffene Systeme

orbitalo/pruefstand (neu), pve-mu-3 (Flash-Host /dev/ttyUSB0), CT143 (MQTT-Broker, Ziel), CT122 (OpenMemory), CT116 (nur Beratung, keine Änderung).

## Was wurde gemacht - **DS18B20-Werkbank-Prüfstand** konzipiert (Architektur-Entscheidung: Split ESP8266-Testknecht + Waveshare ESP32-S3 HMI über MQTT, eigener Namespace `pruefstand/...`). - Neues Repo **`orbitalo/pruefstand`** (Cline) mit Phase-0/1-Firmware: DS18B20-Scan, CRC8, Klon-Heuristik, Parasitär-Erkennung, MQTT-Publish + Bench-I/O. - Code-Review + Verifikation durchgeführt; `firmware.bin` nach pve-mu-3 übertragen (sha256 verifiziert). - **Flash-Workflow-Wirrwarr aufgeklärt**: ESP8266-Satelliten/Prüfstand werden über pve-mu-3 (/dev/ttyUSB0, CH340) per esptool geflasht — NICHT über den Windows/COM-Weg des ESP32-Heizraum-Knotens. In OpenMemory festgehalten. - Kurze Architektur-Beratung zum CT116-Deploy (Forgejo Actions vs. Ist-Zustand) — Ergebnis: vorerst so lassen, optionale Verbesserungen in OpenMemory notiert. ## Aenderungen an Infrastruktur - Neues Forgejo-Repo `orbitalo/pruefstand` (privat) + Issue #1 (Status/Next Steps). - Mehrere OpenMemory-Einträge: Flash-Setups (ESP32-Windows vs. ESP8266-pve-mu-3), Pin D3=GPIO0, Prüfstand-Optionen, CT116-Deploy-Restpunkte. - Keine Änderungen an produktiven Diensten (Bot, Broker, Heizraum-FW unangetastet). ## Erkannte Probleme - **DS18B20 am Prüfstand-ESP verpolt angelötet (VDD/GND)** → Überstrom, USB-Brownouts, Flash-Connect scheitert, GPIO0/Chip mutmaßlich beschädigt. Reine HW-Ursache, Software ist ok. ## Naechste Schritte - Siehe **orbitalo/pruefstand#1**: neuen Sensor korrekt anlöten (DQ→D3/GPIO0, 4,7k Pull-up), ESP allein auf Flashbarkeit testen, sonst frischen D1 Mini; dann Flash von Pulse + Broker-Verifikation; danach Phase 2 (Waveshare LVGL-HMI, braucht 5V/2A-Netzteil). ## Betroffene Systeme orbitalo/pruefstand (neu), pve-mu-3 (Flash-Host /dev/ttyUSB0), CT143 (MQTT-Broker, Ziel), CT122 (OpenMemory), CT116 (nur Beratung, keine Änderung).