retr0
391e615893
Flask-App + mobile Web UI für Diagnose vor Ort ohne HAOS/MQTT. Pi 3B: eth0 → ShineLAN-X (DHCP), wlan0 → Hotspot "ShineDiag". Browser auf http://10.0.1.1: Modell wählen, alle Sensoren auslesen, Rohdaten-Register-Dump, Export als JSON. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
3.1 KiB
3.1 KiB
ShineBridge — Roadmap
In Arbeit / Bekannte Bugs
- SDM-630 Gesamtwirkleistung zeigt falschen Wert → Fix in v1.2.1 (aus Phasensumme berechnet)
Phase 2 (ShineBridge Add-on)
- Flash-Wizard — NuttX-Firmware via USB DFU direkt aus dem HA Web UI flashen (kein ST-Link)
- Persistente History — SQLite in /data/history.db, 7 Tage Retention (v1.3.0)
- Weitere Growatt-Modelle — MOD 10000, SPH 10000 etc.
ShineDiag — Portabler Vor-Ort-Diagnose-Gateway (Pi 3B)
Hardware: Raspberry Pi 3B (eth0 → ShineLAN-X, wlan0 → WiFi-Hotspot „ShineDiag")
Pi-Netzwerk-Setup
- eth0: statische IP 10.0.0.1/24, dnsmasq DHCP → ShineLAN-X bekommt 10.0.0.100
- wlan0: hostapd Hotspot „ShineDiag", WPA2
- Autostart ShineDiag beim Boot (systemd)
ShineDiag Web App (tools/shinediag/)
- Flask-App: verbindet sich mit ShineLAN-X, liest alle Register
- Mobile-freundliche UI: Modell wählen, alle Sensorwerte anzeigen
- Rohdaten-Ansicht: Register-Adresse, Hex, Dezimal
- Fault-Codes decodiert (Growatt Status-Register)
- Export als JSON für Kundendokumentation
- Pi-Setup-Script (install.sh)
Phase 3 — Multi-Brand / Multi-Hardware
Goodwe WiFi Stick (ESP32 + LAN)
- Hardware analysieren: LAN-Chip identifizieren (W5500? LAN8720?)
- Firmware: NuttX auf ESP32 + mbusd → Modbus TCP Gateway (wie ShineLAN-X)
- Goodwe Register-Maps in
inverters.pyergänzen (SEMS-Protokoll, gut dokumentiert) - Goodwe-Modelle im Web UI auswählbar
ShineWifi-X als ShineBridge-Gateway
- Schlankes ESP8266-Projekt: RS485 → Modbus TCP Bridge (Arduino/ESP-IDF)
- Dann: ShineWifi-X ebenfalls in ShineBridge Web UI verwaltbar (statt separater ESPHome-YAMLs)
Langfristig
- ShineBridge als universelle Multi-Brand-Plattform (Growatt, Goodwe, weitere)
- Hardware-Erkennung automatisch im Web UI
Phase 4 — Messkonzept
Ziel: korrekte, widerspruchsfreie Energiebilanz im HA Energie-Dashboard.
Messkonzept definieren
- Messstellenplan: welcher Sensor misst was (SDM-630 = Netz, SPH = Batterie+AC, MIC = PV)
- Hausverbrauch berechnen:
Hausverbrauch = PV_gesamt + Netzbezug - Einspeisung - Bat_Ladung + Bat_Entladung - Vorzeichen-Konvention einheitlich festlegen (SDM-630 negativ = Einspeisung ✓)
- Sensorüberschneidungen klären: SPH meldet AC-Leistung UND Netzleistung — was ist was?
HA Energie-Dashboard
- Alle Dashboard-Slots mit den richtigen Aggregat-Sensoren belegen
- Virtuelle Sensoren für berechnete Größen (Hausverbrauch) als MQTT-Sensor anlegen
- Prüfen ob
total_increasingauf allen Energie-Sensoren korrekt gesetzt ist
Erledigt
- v1.0.0 — Grundfunktion: ShineLAN-X + Growatt MIC via Modbus TCP + MQTT
- v1.1.3 — Security: XSS-Fix, Flask-Binding, API-Validierung
- v1.1.4 — Fix: Flask zurück auf 0.0.0.0 (HA Ingress)
- v1.1.5 — Feature: Eastron SDM-630 Support + Float32 Decode
- v1.2.0 — Feature: Aggregat-Gerät + Energie-Dashboard Sensoren
- v1.2.1 — Fix: SDM-630 Gesamtwirkleistung aus Phasensumme berechnet