Rotex HPSU / Daikin Altherma Wärmepumpe über ioBroker.canbus
-
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 00pi@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!
-
@kalanaghtd du musst die aktive Abfrage erst anschalten.
-
@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.“ -
Automatisch einen bestimmten Wert setzen anschalten und dann kannst den Abfrage Intervall einstellen.
-
@cb187 Da tut sich leider auch nichts…
-
@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. -
-
@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.
-
@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.jsonaktualisiert, wenn du versuchst eine Abfrage zu starten? Eigentlich sollte der dann die Datenbytes enthalten, die gesendet werden. -
@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.jsonaktualisiert, wenn du versuchst eine Abfrage zu starten? Eigentlich sollte der dann die Datenbytes enthalten, die gesendet werden.2 x ja!
-
@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 can0nach 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 mcp2551in einem Terminal auf dem Raspi? -
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:~ $ -
@crycode
„dmesg -T | grep mcp2551“ ergibt keine Ausgabepi@raspberrypi2:~ $ dmesg -T | grep mcp2551 pi@raspberrypi2:~ $ -
Ist ein Hardwaredefekt am Pican2 denkbar, der solche Auswirkungen hat? Empfangen ja, Senden nein?
-
@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#ffetwas 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. -
@crycode Zweimal gesendet: Da tut sich was!
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 1356390 193770 0 111 0 0 TX: bytes packets errors dropped carrier collsns 2 2 0 0 0 0 pi@raspberrypi2:~ $ -
Evtl. von Interesse:
Wenn ich den Befehl „cansend can0 001#ff“ statt in der Konsole mittels eines Java-Scripts in ioBroker auslöse, wird er ebenfalls erfolgreich gesendet. -
@kalanaghtd Ok, dann ist zumindest deine Hardware in Ordnung und das System kann auch richtig damit kommunizieren.
Bleibt nur die Frage, warum es vom Adapter aus nicht klappt.
Den "Senden" Haken bei Nachricht 680 hast du drin, oder?
-
@crycode said in Rotex HPSU / Daikin Altherma Wärmepumpe über ioBroker.canbus:
Den "Senden" Haken bei Nachricht 680 hast du drin, oder?
Ja, klar!
-
Good news!
Nachdem offenbar irgendwas zwischen dem CAN-Adapter und meiner ioBroker-Installation nicht stimmte, habe ich den CAN-Adapter gelöscht und neu installiert. Was soll ich sagen: Jetzt funktioniert alles perfekt, als wäre nichts gewesen!
Ganz herzlichen Dank an @cb187 und insbesondere an @crycode für die überaus geduldige und kompetente Hilfestellung!
