Moin zusammen,
ich bin aktuell dabei die Bluetooth Kommunikation des DSC und des BB zu reverse-engineeren um daraus eine VanPi Anwendung und Integration zu bauen.
Für die SC Module wird es vermutlich nur ein Testen sein, aber bei den SBB müssen wir dann die Kommunikation noch analysieren.
Daher suche ich gezielt Personen, die mich dabei unterstützen können und wollen.
Zurzeit bin ich noch in Hamburg, fahre aber demnächst durch den Harz und an Frankfurt vorbei in den Süden Deutschland, sodass man die SBB Analyse ggfs. auch bei einem persönlichen Treffens machen kann.
Den Hersteller habe ich auch schon kontaktiert, ob er mir alle Infos zu der Schnittstelle zur Verfügung stellt, jedoch bisher noch keine Antwort eines Technikers bekommen.
Viele Grüße
WeiserMoench
Grüß dich @WeiserMoench ,
ich sehe dein Post ist nun schon 12 Tage her (sind erst jetzt vom Balkan zurück), von daher bin ich mir nicht sicher wo du dich auf deiner Reise vom Norden in den Süen oder andersrum befindest aber ich könnte dir in der Karlsruher Ecke eine Accubox S200 anbieten…
Ansonsten hier ein paar u.a. neue Erkentnisse:
erstmal Respekt — große Teile des Protokolls entschlüsselt, ohne dass du eine Ectivehattest. Das ist richtig gute Arbeit. Ich nutze die AccuBox 200S seit über einem Jahr in meinem eigenen System (Raspberry 4B, eigenes Cockpit, das BT-Protokoll hab ich über die Monate durch Reverse Engineering plus Abgleich mit der Ective-App verifiziert). Meine Box ist zwar die 200S (~200 Ah); aber ich denke die Vorgehensweise ist auf die 300S oder 120S übertragbar. Ich packe Dir meine Erkenntnisse mal hier rein (ausführlicher Link unten), damit Du sie mit Deinen abgleichen kannst:
-
Service/Charakteristik: 0000ffe1-…9b34fb, BMS antwortet mit exakt 21 Byte little-endian als Notification. Das BMS ist Request-Response: Status-Request ist 1c 03 04 00 00 08 46 b1, und mit aktivem Request-Loop (5 s) streamt es kontinuierlich ca. 3 Frames/s — ohne Requests kommt nach dem ersten Frame Stille (erste Anfrage nach Connect wird gern verschluckt, 0,5 s warten, nochmal).
-
Byte-Map: [4:6] Restkapazität Ah, [6:8] SOC %, [8:10]/[10:12] Restzeit h/min, [12:14] signed int16 Lade-Strom-Raw (das High-Byte data ist KEIN Multiplexer — der klassische Fehlgriff), [14:16] Temp-Raw, [16:18] Voltage-Raw, [18:20] signed int16 Entlade-Strom-Raw, Reserve.
-
Modus-abhängige Skalen (empirisch): voltage_raw > 200 → V = raw/47,3 und I = abs(raw)/94; sonst V = raw/10,0 und I = −abs(raw)/7965. Sekundär-Korrektur für Float-Phase: dekodierte V ≥ 14,0 trotz raw ≤ 200 = trotzdem „charging".
-
Zwei Decode-Fallen haben wir jetzt RAW-belegt (2612 Frames an unserer 200S über einen kompletten Ladezyklus, Bulk→Absorption→Voll-Cutoff):
- Im Starklade-Bulk meldet das BMS voltage_raw 397–400 statt ~651–653 (High-Byte-Klasse, Δ≈256) — der Decoder zeigt dann 8,4 V, real sind es ~13,8 V. Bei 783 von 784 Bulk-Frames. Ein +256-Check mit Physik-Fenster (11–15,5 V) fängt das zuverlässig.
- Der Temperatur-Kanal kippt an Moduswechseln auf 0,0–8 °C (temp_raw < 100) — teils für die GESAMTE Ladephase, auch im Entladen gesehen. Und: Ladestrom-Rohwerte sind 256er-quantisiert, 256 = Standby-Pegel („Voll") — der echte Kleinstrom (1,2–1,5 A) steht dann im Entlade-Kanal. Checksumme (Byte 20) folgt keiner Standard-Formel (Sum/XOR/ CRC8-Sweep ohne Treffer) — Glitch-Schutz läuft bei uns deshalb über ein Plausibilitäts-Gate, nicht über die Prüfsumme.
-
Unser Decoder v4.2 mit genau diesen Gates (Selftest + Replay über die 2612 echten Frames: 0 Frames < 11 V nach Gate, alle Glitches geflaggt) und ein RAW-Capture-Skript (JSONL mit Hex + Byte-Map) sind als Gist verlinkt — Accubox 300S Peakaway · GitHub (inkl. 2612-Frame-Fixtures + Methodik-Beschreibung) — falls Du echte Daten (sofern Hardware vorhanden) zum Abgleich brauchst, liefert das Capture-Skript genau das Format. Der Voll-Treiber läuft heute als Drop-in (gleiche CLI wie der alte Reader) produktiv in unserem System am Pi — der Service schreibt das gewohnte JSON-Format, ergänzt um ein „flags"-Feld für die Gates.
Liebe Grüße,
Erik
Moin Erik,
sehr interessant.
Wir sollten uns ggfs. mal austauschen.
Ich bin noch nicht so weit im Süden, da ich in HH noch einiges zu tun hatte und mittlerweile bin in in der Region Hannover.
Ich werde ca. Ende 2 Anfang 3. Oktoberwoche bei Karlsruhe. Dann könnten wir uns gerne Treffen.
Ich habe entdeckt, das es 40 Bytes sind. Und zuvor eine Kommunikation als “Handschlag” stattfindet, bei dem das Gerät mitgibt, welches es ist.
Ich habe zwei Geräte und zurzeit die Hälfte der Bytes der Momentandaten davon entschlüsselt, jedoch wird es auf diesen Bytes auch noch Status geben, die ich noch nicht entschlüsselt habe.
Ich habe dafür die Kommunikation zwischen dem BT Modul des DSC35 bzw. des BB60 und der beiden Handyapps mittels Wireshark abgefangen und diese Aufzeichnungen mit den Screenshots der KI gegeben.
Da ich keine schreibenden Befehle habe, sind diese bisher komplett nicht betroffen.
Von den 20 fehlenden Bytes sind vermutlich nur noch 4 relevant, denn diese haben die Fehlermeldungen und davon habe ich halt bisher keine erzeugt.
Neben den Momentanwerten habe ich die Historie, die aus 20 Byte besteht, vollständig entschlüsselt.
Dabei leider auch Schwachstellen in der Historienaufzeichnung der Geräte selber offengelegt.
Ich habe meine Werte noch nicht veröffentlicht, denn ich versuche vorher noch einige Punkte zu entschlüsseln.
Liebe Grüße
WeiserMoench