Rotex HPSU / Daikin Altherma Wärmepumpe über ioBroker.canbus

[RaspiUser]

@hurricane55557

[crycode]

@hurricane55557 Alternativ direkt die json auf GitHub: https://github.com/crycode-de/ioBroker.canbus/blob/master/well-known-messages/configs/rotex-hpsu-1.7.0.json

[Hurricane55557]

Vielen Dank an euch beide.

Werde gleich mal schauen ob ich damit weiter komme. Bin meinem Ziel schon wieder ein Schritt näher gekommen!!!
Danke euch

[F.Miller]

Hallo zusammen,

ich habe folgenden Fehler im ioBroker:
canbus.0 *timestamp* debug read parser 61 for 680 returned undefined

wo fang ich an zu suchen...

EDIT:
Sorr habs gefunden... meine can0 läuft nicht korrekt.

ich versuche nämlich mit einem USB-CAN-A (Waveshare) und SLCAND die Schnittstelle zum laufen zu bekommen..
jemand schon mal damit erfolgreich gewesen???
Geht um die ROTEX HPSU Wärmepumpe.

Grüße

[crycode]

@f-miller Hi, also die Debug-Meldungen mit read parser ... for ... returned undefined sind an der Stelle normal. Da verschiedene Daten unter der gleichen Nachrichten-ID gesendet werden, prüfen hier viele Parser die Nachricht und für den jeweiligen Parser nicht der passende Inhalt dabei war, dann gibt der Parser eben undefined zurück. Dies bedeutet wiederum, dass sich der Wert, den der Parser lesen wollte, nicht verändert hat.

Wenn diese Meldung kommt, dann heißt das aber auch, dass Daten für die Nachrichten-ID 0x680 empfangen wurden. Dein can0-Interface scheint also zu laufen.

[KalaNagHTD]

Hallo @crycode
Nachdem ich jahrelang pyHPSU verwendet habe, möchte ich als ioBroker-Nutzer auf ioBroker.canbus umstellen.
Der ioBroker läuft auf einem Pi3B mit Pican2 Schnittstelle.
Dank Deiner perfekten Tutorials hat die Installation gut funktioniert, und die Kommunikation mit meiner HPSU läuft ohne jegliche Fehlermeldungen.

Problem:
Der Adapter empfängt nur die von der HPSU automatisch im Abstand von ca. 10 Sekunden gesendeten Werte, z.B. die Sprache, die Software-Nr. und die Außentemperatur (fa0a0c). Das Anfordern von Werten über die Buttons führt zu keinerlei CAN-Nachricht an die HPSU. Ein CAN-Dump zeigt nur Empfangsaktivitäten, aber keinerlei TX-Vorgänge.

pi@raspberrypi2:~ $ candump -tA -x can0
 (2024-06-04 22:34:33.621284)  can0  RX - -  10A   [7]  31 00 FA 06 95 00 00
 (2024-06-04 22:34:33.626945)  can0  RX - -  180   [7]  22 0A FA 06 95 00 00
 (2024-06-04 22:34:33.641367)  can0  RX - -  10A   [7]  61 00 FA 01 1A 00 00
 (2024-06-04 22:34:33.647441)  can0  RX - -  300   [7]  22 0A FA 01 1A 00 00
 (2024-06-04 22:34:33.661229)  can0  RX - -  10A   [7]  61 00 FA 13 58 00 00
 (2024-06-04 22:34:33.667152)  can0  RX - -  300   [7]  22 0A FA 13 58 00 00
 (2024-06-04 22:34:33.681352)  can0  RX - -  10A   [7]  61 00 FA 01 EC 00 00
 (2024-06-04 22:34:33.687251)  can0  RX - -  300   [7]  22 0A FA 01 EC 00 00
 (2024-06-04 22:34:33.701322)  can0  RX - -  10A   [7]  61 00 FA 01 1E 00 00
 (2024-06-04 22:34:33.707204)  can0  RX - -  300   [7]  22 0A FA 01 1E 00 00
 (2024-06-04 22:34:33.721254)  can0  RX - -  10A   [7]  61 00 FA 13 53 00 00
 (2024-06-04 22:34:33.727217)  can0  RX - -  300   [7]  22 0A FA 13 53 00 00
 (2024-06-04 22:34:33.741306)  can0  RX - -  10A   [7]  31 00 FA C0 C4 00 00
 (2024-06-04 22:34:33.747219)  can0  RX - -  180   [7]  22 0A FA C0 C4 00 01
 (2024-06-04 22:34:33.761419)  can0  RX - -  10A   [7]  61 00 FA 0A 0C 00 00
 (2024-06-04 22:34:33.767239)  can0  RX - -  300   [7]  22 0A FA 0A 0C 00 9B
 (2024-06-04 22:34:33.781391)  can0  RX - -  10A   [7]  31 00 0C 00 00 00 00
 (2024-06-04 22:34:33.787160)  can0  RX - -  180   [7]  22 0A 0C 00 9B 00 00

pi@raspberrypi2:~ $ ip -details -statistics link show can0
3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
    link/can  promiscuity 0  allmulti 0 minmtu 0 maxmtu 0 
    can state ERROR-ACTIVE restart-ms 0 
          bitrate 20000 sample-point 0.875
          tq 3125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1 brp 25
          mcp251x: tseg1 3..16 tseg2 2..8 sjw 1..4 brp 1..64 brp_inc 1
          clock 8000000 
          re-started bus-errors arbit-lost error-warn error-pass bus-off
          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 parentbus spi parentdev spi0.0 
    RX:  bytes packets errors dropped  missed   mcast           
       1113546  159078      0     111       0       0 
    TX:  bytes packets errors dropped carrier collsns           
             0       0      0       0       0       0 
pi@raspberrypi2:~ $ 

Danke für jeglichen Hinweis!

[cb187]

@kalanaghtd du musst die aktive Abfrage erst anschalten.

[KalaNagHTD]

@cb187 Wie geht das?
Ist das Drücken der Buttons nicht ausreichend?
Ich schrieb: „Das Anfordern von Werten über die Buttons führt zu keinerlei CAN-Nachricht an die HPSU.“

[cb187]

@kalanaghtd

Automatisch einen bestimmten Wert setzen anschalten und dann kannst den Abfrage Intervall einstellen.

[KalaNagHTD]

@cb187 Da tut sich leider auch nichts…

[crycode]

@kalanaghtd Tut sich irgendwas, wenn du manuell eine Abfrage über den Button einem der Abfrage-States auslöst?
Dazu wären dann auch mal zum Zeitpunkt des Auslösens das Log von ioBroker und ggf. ein candump interessant.

[cb187]

@crycode

[KalaNagHTD]

@crycode Wie oben schon geschrieben, tut sich beim Drücken der Buttons nichts. Auch im candump erscheint keine Sende-Nachricht. Im Log erscheint auch keine Info beim Sendeversuch. Der einzige (ältere) Eintrag ist, dass der Adapter erfolgreich gestartet wurde.

[crycode]

@kalanaghtd Hmm.. das ist dann seltsam.

Wird der jeweilige Abfrage-State nach deinem Auslösen auf "Bestätigt: true" gesetzt?

Wird der Wert vom State canbus.0.680.json aktualisiert, wenn du versuchst eine Abfrage zu starten? Eigentlich sollte der dann die Datenbytes enthalten, die gesendet werden.

[KalaNagHTD]

@crycode said in Rotex HPSU / Daikin Altherma Wärmepumpe über ioBroker.canbus:

@kalanaghtd Hmm.. das ist dann seltsam.

Wird der jeweilige Abfrage-State nach deinem Auslösen auf "Bestätigt: true" gesetzt?

Wird der Wert vom State canbus.0.680.json aktualisiert, wenn du versuchst eine Abfrage zu starten? Eigentlich sollte der dann die Datenbytes enthalten, die gesendet werden.

2 x ja!

[crycode]

@kalanaghtd Das ist schon mal gut und zusammen mit der Info, dass es keine Warnung o.ä. im ioBroker Log gibt, zeigt das, dass es höchstwahrscheinlich nicht am Adapter liegt.

Also gilt es den Fehler tiefer im System zu suchen...

Sieht ip -details -statistics link show can0 nach einigen Versuchen noch immer genauso aus, wie oben gepostet, oder hat sich bei den TX-Werten etwas getan?

Wie ist die Ausgabe von dmesg -T | grep mcp2551 in einem Terminal auf dem Raspi?

[KalaNagHTD]

@crycode

pi@raspberrypi2:~ $ ip -details -statistics link show can0
3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
    link/can  promiscuity 0  allmulti 0 minmtu 0 maxmtu 0 
    can state ERROR-ACTIVE restart-ms 0 
          bitrate 20000 sample-point 0.875
          tq 3125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1 brp 25
          mcp251x: tseg1 3..16 tseg2 2..8 sjw 1..4 brp 1..64 brp_inc 1
          clock 8000000 
          re-started bus-errors arbit-lost error-warn error-pass bus-off
          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 parentbus spi parentdev spi0.0 
    RX:  bytes packets errors dropped  missed   mcast           
       1305122  186446      0     111       0       0 
    TX:  bytes packets errors dropped carrier collsns           
             0       0      0       0       0       0 
pi@raspberrypi2:~ $ 

[KalaNagHTD]

@crycode
„dmesg -T | grep mcp2551“ ergibt keine Ausgabe

pi@raspberrypi2:~ $ dmesg -T | grep mcp2551
pi@raspberrypi2:~ $ 

[KalaNagHTD]

Ist ein Hardwaredefekt am Pican2 denkbar, der solche Auswirkungen hat? Empfangen ja, Senden nein?

[crycode]

@kalanaghtd Das sieht soweit eigentlich alles gut aus. Selbst bei einem Hardwaredefekt müsste eigentlich dann der Zähler bei TX errors hoch gehen.

Versuch mal mit cansend can0 001#ff etwas zu senden. Dies würde mit Nachrichten-ID 0x001 ein Byte mit Wert 0xff senden, was die Anlage nicht stören dürfte.
Danach mal prüfen, ob sich bei den TX-Zählern etwas tut.