Wilo Stratos PICO plus Pumpe Schnittstelle

[Moritz M. (moritz2)]

Guten Abend zusammen,

ich habe eine Heizungspumpe Wilo Stratos pico plus (WILO-4244375) und 
habe gesehen, dass es dort ein (relativ nutzloses) Bluetooth-Modul zu 
gibt namens Wilo Smart Connect (WILO-4239241).

Ich habe da mal ein paar Drähte zwischengebastelt um das Protokoll 
mitzuhören, mit dem Ziel, die Pumpe per ESP32 oder RS485 oder ähnlichem 
vernünftig anzusprechen.

Verbunden ist das Modul über einen 2x5 poligen card edge connector mit 
1mm pitch.

Wichtig: Die Pumpe ist nicht galvanisch getrennt, hier liegen also 
230VAC an! Genau wie bei vielen Homematic oder Shelly Produkten.

Benutzt werden von den 5 pins an der oberseite nur 4. Dabei sind GND und 
VCC etwas länger und auch auf die gegenüberliegende Seite verbunden.

1 Pump-TX (3v3, 115200 8N1)
2 GND
3 Pump-RX (3v3, 115200 8N1)
4 nicht verbunden
5 VCC (15v DC)

Ohne verbundenes Bluetooth-Modul empfängt man dann von der Pumpe (also 
auf Pin 1) so etwas wie ein heartbeat-Signal, in hex:
7E 02 nn 7E

7E scheint hier frame start / end marker zu sein, 02 der code für ein 
heartbeat, und nn ist zufällig, aber immer ein gleicher Wert in Folge.

Zudem gibt es noch 7E 04 nn mm .. .. 7E, dies scheint die eigentliche 
Kommunikation zu sein, die erst entsteht, wenn das Bluetooth Smart 
Connect mit angeschlossen ist.

Hier mal ein Auszug aus der Kommunikation, 1> ist, was das Smart Connect 
Modul an die Pumpe sendet, und 2> was die Pumpe sendet. Die 7E 
Start/Endmarker sind weggelassen:

1> 0275
2> 0275
1> 0275
2> 0275
1> 0275
2> 0275
1> 0275
2> 0275
1> 0275
2> 0275
1> 0275
2> 0275
1> 0275
2> 0275
1> 0275
1> 04193013134201016e0f02b430663032113ce106e71121035823
2> 0275
2> 02f6
1> 029a
1> 043e3013134201016f0b3ab430623361113ce106e71121037661
2> 049a30210c6245016e0f02c13ce106e7182111ff7153747261746f73205049434f2030303637e00d
1> 043e3013134201016f0b3ab430623361113ce106e71121037661
1> 043e3013134201016f0b3ab430623361113ce106e71121037661
1> 043e3013134201016f0b3ab430623361113ce106e71121037661
2> 027b
2> 04df3013116284016f0b3ab430623361113ce106e70521110690
2> 02df
1> 02df
1> 04b3301313420101700c8bb430633862113ce106e71121035f3a
1> 04b3301313420101700c8bb430633862113ce106e71121035f3a
1> 04b3301313420101700c8bb430633862113ce106e71121035f3a
1> 04b3301313420101700c8bb430633862113ce106e71121035f3a
2> 025c
1> 0230
1> 049430131342010171067db430363764113ce106e7112103a640
1> 049430131342010171067db430363764113ce106e7112103a640
1> 049430131342010171067db430363764113ce106e7112103a640
2> 043030100c624501700c8bc13ce106e7072111ff80b511
2> 0230
2> 02d1
1> 0275
1> 041930300642030172f00db466303030113ce106e7112120ff8a1908c51908fd1908fe1909d918791903a219067f1906810119067d81af
2> 047530100c62450171067dc13ce106e7072111ff02923b
2> 0275
1> 041930300642030172f00db466303030113ce106e7112120ff8a1908c51908fd1908fe1909d918791903a219067f1906810119067d81af
1> 029a
2> 049a30420662440172f006c13ce106e7142111ffaa1908c5011908fd1908cb1908fe1a801c02a61909d919935a18791917771903a2195b2019067f18fc19068109010819067d02e911
2> 029a
1> 029a
2> 029a
1> 029a

Hat hierzu jemand eine Idee, welche Art Protokoll dies sein könnte? 
Womöglich ist in den 04- Datensätzen ein anderes Protokoll gekapselt?

Hier habe ich eine Spezifikation von Wilo gefunden, die aber ein anderes 
Protokoll zu beschreiben scheint:
https://github.com/christoph2/wiloPLR/blob/master/doc/WILO_PLR(RS485)spec_deutsch_v1.04.pdf


Besten Dank

Moritz

[Matthias Q. (zaphod_beeblebrox)]

Hallo, bist du da weiter gekommen? Es gibt ja offiziell auch das 
"Schnittstellenmodul Connect module Modbus RTU". Grundsätzlich kann man 
also über die Schnittstelle bidirektional kommunizieren. Das "Wilo-Smart 
Gateway" hat auch eine RS485-Schnittstelle.
Gibt es irgendwo weitere Informationen über die Schnittstelle an den 
neuen Pumpen?

Danke und viele Grüße
Matthias

[Moritz M. (moritz2)]

Hi,

ja, bin (etwas) weiter gekokmmen.

BLE: GATT-UUID 0000xxxx-0000-1000-8000-0023f5000001. Service 0001 hat 
0002 für write, 0003 für lesen, und 0005 schreiben verschlüsselt.

Ablauf zum Lesen:

1. Als BLE-Central verbinden, ATT-MTU auf 185 hochsetzen, Notifications 
auf char-03 aktivieren.
2. Handshake auf char-02 (Request -> Antwort): 
`0103010001`->`0103030002b400`, `0103010003`->`01030300040000`, 
`0103010005`->`010302000613`, `0503010001`->`050302000205`.
3. PIN: die Pumpe zeigt pro Verbindung eine frische 4-stellige Zahl im 
LCD. Diese als `05 03 03 00 03 <code:2B LE>` schicken -> Ack 
`0503010004`. Ohne Auth wird sofort getrennt.
4. Read-Request auf char-02 (nach dem Transport-Header `1f 03 <len16 
LE>`):
   `42 01 <seq> <pid:2B> b4 "<PID-ASCII>" 11 3c e1 06 e7 13 21 00 ff 19 
<pid:2B>`
   Antwort auf char-03: `... 62 45 00 <seq> <pid> c1 3c e1 06 e7 00 21 
13 ff <tag><wert>`.
   Wichtig: `<seq>` ist ein Transaktionszähler (01, 02, 03 ..., wird in 
der Antwort gespiegelt), und es darf immer nur ein Request gleichzeitig 
offen sein, sonst trennt das Modul. Werte-Tags: `18`=u8, `19`=u16, 
`1a`=u32.

Zu den PIDs: auf dem Draht wird ein Parameter über eine 16-Bit-PID 
adressiert.
Bisher decodierte PIDs (Service PV, sid 4):

- `08fd` (u16) — Drehzahl in U/min
- `08fe` (u32) — Förderstrom Q, /1000 → m3/h (die oberen Bits sind 
Flags)
- `03a2` (u16) — Förderhöhe, /10000 → m
- `09ee` (u8) — Leistung, *0,5 W
- `09dc` (u32) — Betriebssekunden (+1/s, monoton)
- `0bc9` (u16) — Sollwert-Multiplikator: `round(Prozent * 40.96)`, Q12 
(100 % = `0x1000`) — schreibbar
- `0669` — Motor AN/AUS: `ff01` = an, `ff00` = aus — schreibbar

Schreiben (Sollwert, Motor an/aus) geht mit demselben Frame-Format über 
char-02, nur mit Opcode `42 03 ...` statt `42 01`.


UART -> im ist 115200 8E1, nicht 8N1. Das Wire-Protokoll ist ähnlich, 
hat aber zusätzlich eine 16-Bit-Prüfsumme, die ich nicht herausgefunden 
habe. Aktuell nutze ich BLE, und UART sniffing um die PIN zu bekommen.

[Martin D. (mdewendt)]

Hallo,

Kannst du noch etwas weiter erklären wie du via BLE mit der Pumpe 
kommunizierst? Ich würde da gerne einen Rpi mit USB BLE Modul für 
verwenden.
Nutzt du das gatttool?

Martin

[Thomas (kosmos)]

ich habs mal durch die KI gejagt

1. Das äußere Framing (Sicherungsschicht)7E (Flag): Das ist der absolute 
Standard-Marker für HDLC / PPP. Er signalisiert Frame-Start und 
Frame-Ende.Byte nach 7E (02 oder 04): Das ist der Frame-Typ 
(Control-Byte).02 = Control/Signaling (Heartbeat / Token): Ein kurzes 
Lebenszeichen. Dahinter folgt eine fortlaufende Sequenznummer/CRC 
(nn).04 = Data Frame (Information): Kapselt die eigentlichen 
Nutzdaten.Letzte Bytes vor 7E: Ein Prüfsummen-Mechanismus (meist CRC-16f 
oder CRC-8), weshalb sich bei identischem Inhalt die letzten Bytes 
ändern.2. Der "Smoking Gun"-Beweis in den Nutzdaten 
(Klartext-Analyse)Wenn wir die Hex-Werte der langen 04-Pakete in ASCII 
übersetzen, springen uns sofort Gerätenamen ins Auge. Schauen wir uns 
Zeile 16 deiner Nachricht an (Antwort von der Pumpe 2> auf ein 
04-Paket):04 9a 30210c6245016e0f02c13ce106e7182111ff71 53 74 72 61 74 6f 
73 20 50 49 43 4f 20 30 30 36 37 e00dWenn man den hinteren Teil ab 53... 
in Text umwandelt, erhält man:
53 74 72 61 74 6f 73 20 50 49 43 4f 20 \(\rightarrow \) "Stratos PICO 
"30 30 36 37 \(\rightarrow \) "0067" (vermutlich ein Teil der Firmware- 
oder Seriennummer)3. Warum es sich um BACnet MS/TP handeltDas 
Kapselungsschema (7E \(\rightarrow \) Frame-Typ \(\rightarrow \) Daten) 
und die Struktur der Datenpunkte entsprechen exakt dem BACnet-Protokoll. 
Wilo bildet damit intern BACnet-Objekte ab (Analog Inputs/Outputs für 
Durchfluss, Leistung, Förderhöhe).Schauen wir uns ein Request-Paket an 
(Zeile 27):04 19 
30300642030172f00db466303030113ce106e7112120ff8a1908c51908fd1908fe1909d9 
...30  30 06 / 42 03 01: Das sind typische ASN.1-codierte Identifier für 
BACnet-Objekttypen (z.B. Device-Objekt, Analog Value, etc.).Die sich 
wiederholenden Blöcke wie 19 08 c5, 19 08 fd, 19 08 fe am Ende sind 
BACnet-Property-Tags (Read-Property-Multiple Requests). Das 
Bluetooth-Modul fragt hier zyklisch eine ganze Liste von Registern ab.In 
Zeile 29 antwortet die Pumpe mit einer riesigen Liste:04 9a 
30420662440172f006c13ce106e7142111ffaa1908c5011908fd...Hier liefert die 
Pumpe die aktuellen Live-Werte (Leistung in Watt, Durchfluss in m³/h, 
Fehlermeldungen) zurück.4. Das Token- / Heartbeat-VerhaltenDie Sequenz 
am Anfang zeigt ein klassisches Master-Slave-Polling:1> 0275 und 2> 
0275: Das BT-Modul und die Pumpe werfen sich im Idle-Zustand extrem 
schnell (115200 Baud) den "Token" (02) mit einer Prüfsumme/ID (75) hin 
und her.Erst wenn das BT-Modul Daten will, bricht es den 02-Zyklus auf 
und sendet stattdessen einen 04-Datenframe.Praxistipp für dein 
ESP32-VorhabenSicherheit zuerst: Da du korrekterweise erkannt hast, dass 
die Pumpe das GND-Potenzial auf 230V-Phase/Nullleiter legt 
(kondensatorbasiertes Netzteil ohne Trafo), darfst du deinen ESP32 
niemals per USB an den PC anschließen, während er mit der Pumpe 
verbunden ist! Es knallt sofort.Die Lösung: Nutze einen digitalen 
Optokoppler (z.B. 6N137 oder einen fertigen UART-Isolator) für die 
TX/RX-Leitungen. Den ESP32 versorgst du über ein eigenes, galvanisch 
getrenntes 5V-Netzteil. Die Pumpe versorgt dann nur die pumpenseitige 
LED des Optokopplers über ihre 15V/GND (Spannungsregler auf 3,3V für die 
Koppler-VCC nicht vergessen).Software-Umsetzung: Du musst das Rad nicht 
neu erfinden. Da es sich um BACnet handelt, kannst du bestehende 
Open-Source-Bibliotheken nutzen. Du kannst entweder die rohen 
Hex-Pakete, die du aufgezeichnet hast, eins-zu-eins vom ESP32 
"abspielen" (Replay-Attacke), um bestimmte Werte abzufragen, oder einen 
BACnet-Stack auf dem ESP32 aufsetzen, um die Daten sauber zu parsen.

Formatierung ist leider flöten gegangen aber es sind ja schon einige 
Infos drin