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

[crycode]

@raspiuser Da hat der Build nicht geklappt.
Den Infos nach ist das wohl ein Bug in gcc-12/g++-12 (dem Compiler).

Mit gcc-11/g++-11 sollte es funktionieren (im cannelloni-Verzeichnis):

sudo apt install gcc-11 g++-11
export CC=gcc-11
export CXX=g++-11
rm -f CMakeCache.txt
cmake -DCMAKE_BUILD_TYPE=Release
make
sudo make install

Bei der Ausgabe vom cmake [...] Befehl, sollte u.a. folgendes enthalten sein, was dir zeigt, dass gcc-11/g++-11 verwendet werden:

-- The C compiler identification is GNU 11.3.0
-- The CXX compiler identification is GNU 11.3.0

[RaspiUser]

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

Da hat der Build nicht geklappt.

... aber jetzt ... die Werte kommen (wieder) an ... Vielen Dank für deine Hilfe !!!

Und ich bin ein wenig beruhigt, dass nicht ich unmittelbar das Problem war (oder ?!)

Muss / sollte ich die Anleitung (s. erster Beitrag) anpassen ?

EDIT:
... und sollte man (ich) etwas im Dateisystem o.ä. aufräumen ?

[crycode]

@raspiuser Immer gerne Nein, du warst (diesmal) nicht das Problem
Im Dateisystem brauchst du da eigentlich nichts aufräumen.
Die Anleitung könnte man um einen entsprechenden Hinweis ergänzen.

[ViennaTom]

@crycode Erstmal alle Daumen hoch !!!

Ich habe jetzt auch versucht meine Altherma Echo-2 (Baujahr 2022/23) über CAN-Bus zu steuern (Die UART-Schnittstelle an X-10A erlaubt leider/vermutlich nur das Auslesen von Betriebsdaten).
An meiner Altherma ist am X3 des MMI eine Mischstation (EKMIKPOAF) für einen 2.ten Heizkreis angeschlossen.
Ich verwende einen ESP32 und bin zunächst an der 20kBit Baudrate gescheitert.
Wie sich herausgestellt hat, arbeitet dieser CAN-Bus aber mit 50kBit und auch die Frames sehen ganz anders aus als die von euch dokumentierten.

Es werden hier die folgenden Can-IDs verwendet:
Can-ID,Daten, Frequenz

• 0000 , 0101, 1x

• 0081, 810001FFFFFFFFFF, 1x

• 058A, 4F17250064000000, ~2/Sekunde
  4B2225002A010000
  606D250000000000

• 060A, 4017250000000000, ~2/Sekunde
  4022250000000000
  2B6D2500C2010000

• 06CA, 8000200000000405, alle 5 Sekunden
  4000200000000000

• 070A, 7F, alle 3 Sekunden

• 0701, 05, alle 3 Sekunden

058A 4F17 könnte die Stellung des 3-Wege Ventils sein (100%)
058A 4B22 dürfte der little endian Temperaturwert des Sensors sein (28-32°C)
060A 2B6D sieht auch noch einem Temperaturwert aus 45.0°C
Nur scheinen leider alle Register im Zusammenhang mit der Mischergruppe zu stehen *

Laut Installationshandbuch EHS157034 (RO-CON) verwendet diese auch den CAN-Bus gemeinsam mit der Mischergruppe ....

Die Mischstation steuert ein Dreiwegeventil, bis zu zwei PWM-Pumpen und kann einen Temperaturfühler auslesen.
Bis jetzt werden aber immer nur die gezeigten Werte gesendet. Ich werde noch einen Aktuatortest machen um zu sehen ob sich die Werte wenigstens dann ändern.

Kannst du mit den gezeigten Frames was anfangen ? Gibt es vielleicht eine zweite CAN-Schnittstelle für die von euch gezeigte Implementierung ? Muß ich die Altherma vielleicht umkonfigurieren, daß sie eine Steuerung erlaubt ? Auf Abfrageframes 0680 31 00 XX reagiert die Schnittstelle mit Ignoranz

Danke für deine bisherige Arbeit und vielleicht kannst du mir ja weiterhelfen, denn die ONECTA App ist wohl nur ein schlechter Scherz ...

LG, Tom

[cb187]

@viennatom

Hi ich glaube das ist keine CAN Verbindung.Du misst mal gucken da gibts nen extra Projekt für den Anschluss x10.

[ViennaTom]

@cb187 Ja am X10-A habe ich einen zweiten ESP32 der die UART Schnittstelle ausliest und die Daten per MQTT verschickt. Da sehe ich ziemlich alle Betriebsdaten, kann aber keine Werte schreiben.

Ich würde aber gerne Sollwerte witterungsbedingt bzw. zur Optimierung bei PV-Ertrag verändern.
Also habe ich mich voller Euphorie auf dieses Projekt gefreut nur "tut" meine CAN-Schnittstelle anders und reagiert nicht oder mit Störung auf Abfragen.

Meine CAN-Schnittstelle arbeitet auch mit 50kBit/s und nicht mit 20kBit/s und dürfte nur für Mischstation und Raumbedienmodul verwendet werden ?!
0701 05 zeigt Mischstation online 0701 7F Mischstation offline
070A dürfte der entsprechende Status für das Raumbedienmodul sein (das ich nicht habe).

Schicke ich "abstruse" Abfragen geht die WP auf Störung "Kommunikationsfehler Mischstation".

Auf der Suche nach einem zweiten CAN-Bus habe ich leider auf keiner der Platinen in der WP einen CAN-Transceiver Chip gefunden.

Ich denke ich leiste mir so ein Raumbedienmodul und sehe mir die Kommunikation dann nochmals an. Ohne Untersuchung am lebenden Patienten dürfte das sonst schwer werden
Gesagt - getan, wenn ich das Bedienmodul angeschlossen habe werde ich weiter berichten ....

[crycode]

@viennatom Das scheint wieder ein ganz anderes Protokoll zu sein.
Mir ist zumindest bislang keine Gemeinsamkeit mit den bisher bekannten Daten aufgefallen.
Zudem scheinen es bei dir meistens 8 Datenbytes zu sein, wobei es bei den aktuell funktionierenden Modellen immer 7 Bytes sind.

[ViennaTom]

@crycode Danke für deine Antwort. Ja die Datenpakete sehen ganz anders aus. Die Werte scheinbar in little endian und ich habe auch keine "polling frames" sehen können. Wird scheinbar unaufgefordert gesendet ....
Mitte Feb. bekomme ich die Bedienstation über die man fast alle Einstellungen ändern kann (Sollwerte, Heizkurve, etc.) - ich werde dann berichten.

Bei dem 20kBit Protokoll und deinen Abfragen hat mich gewundert, warum manchmal 20 0A XX, 30 00 XX oder 60 00 XX verwendet wird ? Ist hier das Modul und nicht die Can-ID ausschlaggebend ?
Funktionieren mehrere Varianten oder ist das vom Register abhängig (oder hab ich mich vertan) ?
e.g:
300 / 20 0A 04 T-HK Soll setzen, lesen aber mit 61 00 04
300 / 30 00 05 T-Raum Soll setzen, lesen aber mit 61 00 05
300 / 60 00 28 T-Vorlauf Max setzen, lesen mit 61 00 28

180 / 20 0A 0E
180 / 30 00 13

Ich wollte das Protokoll auf ESP32 implementieren und mir was ersparen

[crycode]

@viennatom Das hängt damit zusammen, dass die Entwickler hier die Funktionsweise des CAN Bus etwas anders interpretiert haben...
Die eigentliche Nachrichten-ID ist hier die ID von der Absender-Baugruppe. In den ersten beiden Nachrichten-Bytes steckt dann die ID von der Empfänger-Baugruppe und was es für eine Nachrichtenart sein soll. Dann folgt die ID des Wertes und dann die Daten...
Ich habe das versucht hier einigermaßen zu dokumentieren.

[ViennaTom]

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

die Entwickler

Jaja und bei mir waren wieder andere am Werk
Die haben wohl auch vergessen, daß es eine 32 Bit CAN-ID gibt um Nachrichten vernünftig Baugruppen oder Funktionen zuordnen und entsprechend filtern zu können. Naja die ganze WP scheint ein wenig zusammengestoppelt zu sein ...

[Hurricane55557]

@cb187 Wo finde ich denn die json config zum runter laden?

[cb187]

@hurricane55557

Du kannst übe Import/Export die Keon von Github abrufen.

[Hurricane55557]

@cb187 Sorry, ich stehe heute auf dem Schlauch. Import/Export aber wo? Hier im Forum? Gibt es ein link?

[cb187]

@hurricane55557

Im Adapter

[Hurricane55557]

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?

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