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

[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.

[KalaNagHTD]

@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:~ $ 

[KalaNagHTD]

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.

[crycode]

@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?

[KalaNagHTD]

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

Den "Senden" Haken bei Nachricht 680 hast du drin, oder?

Ja, klar!

[KalaNagHTD]

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!

[crycode]

@kalanaghtd Super! Schön dass es jetzt läuft.