Rotex HPSU / Daikin Altherma Wärmepumpe über ioBroker.canbus
-
Hallo,
sorry für meine vielleichten komischen Fragen.
JASON config wo finde ich diese genau?
Ich meine ich suche im Prinzip den Nachrichtenkatalog um die Signale richtig deuten zu können.
Oder verstehe ich das was falsch? -
-
@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
-
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 -
Hallo zusammen,
ich habe folgenden Fehler im ioBroker:
canbus.0 *timestamp* debug read parser 61 for 680 returned undefinedwo 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
-
@f-miller Hi, also die Debug-Meldungen mit
read parser ... for ... returned undefinedsind 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 ebenundefinedzurü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.
-
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?
