Hi, bin ich so auf dem richtigen Weg?

{0x53,9,105,2,-1,"Flow sensor (l/min)"},
{0x53,1,105,2,-1,"Test2"},
{0x54,9,105,2,-1,"Test1"},
{0x54, 1, 103, 2, -1, "?1"},
{0x54, 3, 153, 2, -1, "?2"},
{0x54, 7, 153, 2, -1, "?3"},
{0x54, 14, 153, 1, -1, "?4"},
{0x54, 15, 153, 1, -1, "?5"},
{0x54, 16, 153, 1, -1, "?6"},
{0x54, 16, 151, 1, -1, "?7"},
{0x54, 16, 109, 1, -1, "?8"},
{0x54, 19, 153, 1, -1, "?9"},
{0x54, 20, 153, 1, -1, "?10"},
{0x54, 21, 153, 1, -1, "?11"},
{0x54, 22, 153, 1, -1, "?12"},
{0x55, 5, 151, 1, -1, "?13"},
{0x55, 6, 204, 1, -1, "?14"},
{0x55, 7, 204, 1, -1, "?15"},
{0x55, 8, 204, 1, -1, "?16"},
{0x55, 9, 204, 1, -1, "?17"},
{0x56, 0, 103, 2, -1, "?18"},
{0x56, 1, 103, 2, -1, "?19"},
{0x56, 2, 103, 2, -1, "?20"},
{0x56, 3, 103, 2, -1, "?21"},
{0x56, 4, 103, 2, -1, "?22"},
{0x56, 5, 103, 2, -1, "?23"},
{0x56, 6, 103, 2, -1, "?24"},
{0x56, 7, 103, 2, -1, "?25"},
{0x56, 8, 103, 2, -1, "?26"},

das wird dann in HA angezeigt:

Flow sensor (l/min)
0
Test2
0
?1
-67,91
?2
48,09
?3
176,09
?4
0
?5
0
?6
0,63
?7
162
?8
1,27
?9
0
?10
0
?11
0
?12
0
?13
30
?14
0
?15
0
?16
0
?17
0
?18
45,75
?19
-68,82
?20
0,73
?21
0
?22
0
?23
0
?24
0
?25
0
?26
0

Wie kann ich am einfachsten ein Screenshot einfügen?
Glg Alex

Ja, so funktioniert es!
Bilder muss man erst irgendwo hochladen (z.B picr.de) und dann als Link hier einfügen.

Ok, aber woher weiß ich ob der Code richtig ist,
Die Umwälzpumpe läuft gerade, aber Durchfluss ist immer noch 0

Wenn kein plausibler Wert angezeigt wird, ist die Adresse falsch. Plausibel ist ein Wert, wenn er mit der Anzeige an Deiner ECH2O übereinstimmt.

Ok, aber ich sehe an meiner Daikin keinen Volumenstrom

Oha! Gibt es das? Kein Strömungssensor? Unglaublich!
EDIT: Könnte sein, weil die Pumpe nicht geregelt ist! Dann findest Du auch mit ESPAltherma nichts :-(

Die Pumpe hat nur zwei fixe Einstellungen, ist also nicht geregelt:

Das heißt, ich muss gar nicht mehr weiter suchen?

Ja, genau! Auch kannst Du die thermische Leistung leider nicht berechnen.

Ok schade
Danke für deine Hilfe und deine Zeit
Vg Alex

Hallo zusammen,

ich nutz den Adapter von CB187 (Daikin-Rotex-HPSU-CAN) und bin super zufrieden, wegen des sehr guten Supports und der ausführlichen Installationsanleitung.

Leider hat CB187 ein leicht anderes Modell als ich -->Altherma 3 R ECH2O (EHSX08P50DA3)

Darum die Frage hier:
Bei mir wird der Kompressorstatus nicht ausgelesen über Canbus, weil die Adressen wohl unterschiedlich sind. Hat jemand vielleicht die Info, wie die Can-Adresse heißt, dass bei meinem Modell dieser Status auch ausgelesen werden kann?

Da die WP ja leider nicht die Takte selbst mitzählt, würde ich diese gerne über Homeassistant und den Kompressorstatus selbst mitloggen.

Vielen Dank im Voraus für eure Hilfe!

Bei der EHSXB04P50DA3 ist's Adresse 0x500, Register 0x61, falls das hilft.

Ich habe allerdings keine Ahnung, in welchem Format dieses Projekt die Adressen erwartet, das PyHPSU-Zeug zum Beispiel ist da ziemlich wirr. Diese Angaben hier entsprechen dem Format, das ich in https://www.haustechnikdialog.de/Forum/p/3714616 beschrieben habe. Nur, dass es natürlich ((p[0] >> 5) << 8) | (p[1]) heißen muss, nicht (p[0] >> 5) | (p[1]).

Can id 500 register 61 ist zuwenig. Da kommen ja noch einige stellen mehr.

Ich hätte vielleicht ne Idee wie wir die Adresse rausfinden können.
Komm mal in die Telegrammgruppe.

Kannst Du genauer erklären, was für Stellen Du hier meinst bzw. was Du meinst, was hier zu wenig sein soll?

Ich meine, ich lese faktisch den Kompressor-Status aus Register 0x61 von Adresse 0x500 aus, von daher kann das ja kaum falsch sein.

Wenn Du in Deinem Projekt da möglicherweise eine andere Konvention für die Spezifikation von Registern benutzt, müsstest Du vielleicht konkret die Bits der Bus-Nachrichten angeben, von denen Du sprichst?! Für meine Konvention habe ich das ja in dem verlinkten Post getan.

Was bringt dir denn nur 500 und die 61?
Da gibts wie du sagst noch ein paar bits mehr. Zb fa 02 usw.
Ich benutze wie alle die can nachrichten abfragen die kompletten Adressen nicht nur 500 und 61

Mir ist unklar, was Du wissen willst? Also, ich habe ja nicht nur "0x500 und 0x61" angegeben, sondern auch, an welche Stelle sie in die Busnachricht gehören, und wie die sonst so aussieht. Wenn man das zusammennimmt, dann kann man mit diesem Wissen eine Busnachricht konstruieren, die dazu führt, dass die Heizung einem verrät, ob der Kompressor an ist. Mein Verständnis war, dass das hier das Ziel war?!



0x500 und 0x61 sind die kompletten Adressen. Die CAN-Nachricht enthält mehr Felder als die Zieladresse und Registernummer. Aber warum sollte man diese anderen Felder, deren Inhalt mit dem adressierten Register nichts zu tun haben, mit den Adressen vermischen?!

Also, beispielsweise ist das Register für "Raumtemperatur Soll 1" das Register mit der Nummer 5 von Adresse 0x180. Natürlich muss man in der Nachricht auch angeben, ob man das Register lesen oder schreiben will (die 4 LSB vom ersten Payload-Byte, wie in dem verlinkten Post spezifiziert). Was wäre jetzt der Vorteil, wenn man stattdessen irgendeine "komplette Adresse" angeben würde, die diesen Opcode mit enthält ... was dann dazu führen würde, dass man fürs Lesen und Schreiben des Registers zwei verschiedene "Adressen" benutzen muss?!

Jetzt mal ganz ehrlich was soll ein Anfänger mit deiner Aussage anfangen?
Aber egal.

Abfrage 680 [ 0xA1, 0x00, 0x61, 0x00, 0x00, 0x00, 0x00 ] und 500 empfang
so einfach hätte es doch sein können.

Naja, im Zweifel kann er sie zu Dir tragen, wenn er selber nicht draus schlau wird? Oder ggf. hier genauer erklären, was Deine Software da erwartet?

Ich habe in Dein Repo geguckt und da auf Anhieb nichts gesehen, was nach Quellcode aussieht. Von daher: Woher sollte ich bitte wissen, in welchem Format Deine Software Registeradressen erwartet? Ich habe halt das angegeben, was sinnvoll konstruierte Software als Input erwarten würde, plus Spezifikation, wie genau die Werte zu verstehen sind, sodass ein etwaiger Entwickler, der was anderes erwartet, daraus schlau werden kann, um die Werte zu übersetzen. Mehr kann ich ja wohl nicht tun, wenn ich mir jetzt nicht erst nen passenden ESP32 kaufen und Deine Software darauf flashen will.



Kann es sein, dass Du einfach selber verwirrt bist, was den Aufbau der Busnachrichten angeht?

Also, die 0x61 als Registernummer hatte ich angegeben, und findet sich offensichtlich in der Nachricht wieder. Die Zieladresse 0x500 findet sich offensichtlich auch in der Nachricht wieder, wenn man halt weiß, in welchen Bits sie steht - in welchen Bits sie steht, hatte ich aber ja angegeben. Dass das sonst nicht offensichtlich ist, ergibt sich halt einfach daraus, dass ein Teil der Adresse und der Opcode (hier 1 für "read") in einem Byte kombiniert sind ... deswegen so zu tun, als sei der Opcode Teil der Adresse, wäre aber ja offensichtlich Unfug.

Naja, und dann bleiben einmal die Null-Padding-Bytes. Da ist es wohl auch kaum sinnvoll, die explizit zu spezifizieren, wenn die Nachrichten eh immer die gleiche Länge haben.

Und dann bleibt, dass Du allem Anschein nach als Adresse für Deinen Adapter die 0x680 ausgewählt hast. Was ich zum einen wohl auch wieder nicht wissen kann, ohne den Quellcode gelesen zu haben, und zum anderen ist es halt auch ziemlich unsinnig, bei der Spezifikation eines Registers die Busadresse Deines Adapters mit anzugeben, da die Registernummern sich ja kaum unterscheiden, wenn man einen Request von einer anderen Adresse schickt.

Von daher: Ich habe nach wie vor keine Ahnung, was ich da hätte klarer machen können. Die zwei Felder, die man braucht, um ein Register anzusprechen, sind die Busadresse und die Registernummer. Beide habe ich angegeben.

(Die eine Ausnahme ist die Emulation des Raumeinflusses durch den Raumthermostaten, da muss man von der well-known-Adresse des Raumthermostaten senden.)

Und wie fragst du den status ab?
Geht ja nicht über 500 wenn die Wp selber nichts sendet.
Also der code ist aber ziemlich einfach zuverstehn.Wenn pyhpsu usw kennst solltest da aber ziemlich leicht durchsteigen.
Und zu mir tragen brauch er auch nicht man kann ja auch schnüffeln🤣

Reden da zwei Leute aneinander vorbei bzw. über zwei unterschiedliche Tools?

Trunks1982/Daikin-Rotex-HPSU-CAN

crycode-de/ioBroker.canbus (config für Rotex HPSU)

Nein im Prinzip beides das selbe. Bei mir hat man aber den Vorteil das ich keinen Server brauche und standalone laufen kann.

Hu? Du hast doch selber geschrieben, wie es geht!?

destaddr = 0x500, reg = 0x61, op = 1 (read), und du sendest [(destaddr >> 8) << 5) | op, destaddr & 0xff, reg], aufgefüllt mit Nullen, genau wie in Deinem Beispiel zu sehen!?

Also, und dann wartest Du natürlich auf die Antwort an die von Dir angegebene Quelladresse mit op = 2 (read response).



OK ... und wo ist der zu finden? Also, vielleicht bin ich ja blind, aber ich sehe auf der oben verlinkten Github-Seite nur .bins, readmes, .yamls, und irgendwas für iobroker, das klingt mir jetzt alles nicht nach Quellcode im engeren Sinne.



Ja, PyHPSU kenne ist, das ist ziemlich wirr. Ob ich bei Dir durchsteigen würde, weiß ich nicht, weil ich nicht weiß, wo ich da überhaupt gucken müsste.

Und ja, klar, man kann schnüffeln, daher weiß ich im Zweifel die Adresse ;-)

Die yaml datei ist die config (quellcode) datei da steht alles drin. Aufgeteilt in sensoren abfragen usw.
Wenn man esphome kennt easy zuverstehn.

OK, da muss man drauf kommen! Ich hätte da bestenfalls die Registernummern drin erwartet, nicht den Code zum Zusammenbau der Nachrichten in zig Kopien.

Und ... scheint mir auch ziemlich wirr!? Also, vor allem alles so kompliziert und redundant ... und langsam?!

Also, was ist der Nutzen dabei, zum Beispiel das Register "Raumtemperatur Soll 1" dreimal zu spezifizieren, einmal zum Schreiben:

return { 0x30, 0x00, 0x05, high_byte, low_byte, 0x00, 0x00 };

einmal zum Lesen:

- canbus.send:
data: [0x31, 0x00, 0x05, 0x00, 0x00, 0x00, 0x00]

und dann nochmal bei der Lese-Antwort:

- can_id: 0x180
if(x[0]==0xd2 and x[1]==0x00 and x[2]==0x05 and x[3]==0x00 and x[5]==0x00) {

Wenn man stattdessen auch nur einmal addr = 0x180, reg = 0x0005 angeben könnte, plus Spezifikation des Datenformats, das ja identisch ist mit zig anderen Feldern.

Das gleiche Feld sieht bei mir in der kompletten Spezifikation so aus (0x180 ist impliziter Standard, weil die meisten Register da sind):

[ 0x0005, 1, 'num', 'Raumtemperatur Soll 1', 'u16/10:1°C:5:40:.5' ]

Das ganze En- und Decoding sind zentrale Funktionen, die halt einmal implementiert sind und alle Felder entsprechend der Spec abhandeln.

(Und sorry, ist leider keine Freie Software, aus Gründen.)