Test Adapter canbus v1.1.x Latest

[cb187]

@crycode Mein script für das ausführen von dem aktualisieren der Daten funktioniert mit umschalten nicht mehr.Was muss ich jetzt da angeben?

Den Betriebsmodus umschalten und min max Pumpe verstellen geht ich nicht mehr.
BOH Warte Zeit ist auch falsch da zeigt er nen Datum an sollte aber min anzeigen.
Hab meine Liste wieder eingeladen und es funktioniert.

[crycode]

@cb187 Eigentlich hätte das auch ohne Update vom Adapter funktionieren sollen aber ok.

@cb187 sagte in Test Adapter canbus v1.1.x Latest:

Mein script für das ausführen von dem aktualisieren der Daten funktioniert mit umschalten nicht mehr.Was muss ich jetzt da angeben?

Du meinst die "abfragen" States? Per Skript kannst du die wie folgt triggern:

setState(id, true);

Ansonsten zeig mal dein aktuelles Skript.

@cb187 sagte in Test Adapter canbus v1.1.x Latest:

Den Betriebsmodus umschalten und min max Pumpe verstellen geht ich nicht mehr.

Welche IDs genau? Gibt es Fehlermeldungen, oder passiert einfach nichts?

@cb187 sagte in Test Adapter canbus v1.1.x Latest:

BOH Warte Zeit ist auch falsch da zeigt er nen Datum an sollte aber min anzeigen.

Hab ich grad angepasst und sollte mit v1.0.1 der Config jetzt richtig angezeigt werden.

[cb187]

@crycode
Ich hab das blockly script von umschalten auf steuere geändert da gings.
Zb Mode hat nicht aktualisiert und die betriebsart konnte nicht geändert werden.
Min max werte für Umwälzpumpe wurden auchbnicht aktualisiert.

Gibt keine Fehlermeldungen

[crycode]

@cb187 Kannst du das mit der aktuellen Version noch mal testen und dabei einen candump mitlaufen lassen und das dann hier posten?

[cb187]

@crycode
Wie führe ich das candump aus das es in einer txt gespeichert wird?

[crycode]

@cb187 candump -tA -x can0 | tee -a candump.txt

-tA -x fügt dem ganzen noch ein paar zusätzliche Infos hinzu.

| tee -a candump.txt speichert die Ausgabe zusätzlich in die angegebene Datei candump.txt

[cb187]

@crycode

ok mache das dann jetzt mal

[cb187]

Das kommt schonmal alles in io

[cb187]

@crycode candump.txt

Hier die candump.Habe jede id einmal aktualisieren lassen und id680 auch alle gesetzt.

[cb187]

und das kommt gerade mit meiner alten Liste

[crycode]

@cb187 Welche Version vom Adapter hast du aktuell installiert? Das sieht mir nach einer älteren aus.
Besonders das "Parser xxx returned wrong data type undefined" dürfte mit der aktuellen v1.1.3 oder v1.1.4 nicht kommen.

Danke für den candump, das schau ich mir morgen mal in Ruhe genau an.

[cb187]

@crycode 1.1.4 also die neuste.

[crycode]

@cb187 Dann installiere die mal bitte neu und starte danach auch die Adapterinstanz neu. Irgendwas passt da nicht

[cb187]

@crycode

Für den candump test hab ich extra nen zweiten neu installierten can adapter genommen.

[crycode]

@cb187 Hab mir jetzt mal deinen candump angeschaut und damit noch einige Logikfehler finden können.
Ich denke nun habe ich die Kommunikation der HPSU tatsächlich größtenteils verstanden.

Ein paar Infos zur Kommunikation habe ich hier festgehalten: https://github.com/crycode-de/ioBroker.canbus/blob/master/well-known-messages/configs/rotex-hpsu.md

---

Über den Adapter kannst du jetzt die 1.1.0 der Konfiguration für die HPSU importieren. Vorher möglichst die alte Konfiguration komplett löschen.

Hier sollten jetzt alle Daten richtig erfasst werden, da die Parser nun die IDs etc. richtig auslesen sollten.

Achtung: Alle Parser-IDs haben sich geändert. (jeweils die ersten 4 Zeichen der ID sind weggefallen)
Zudem sind die "setzen"-Parser von 0x680 jetzt alle bei 0x190 mit untergebracht.

---

Sollten die von dir oben beschriebenen Fehler weiterhin auftreten, dann bitte ein mal den Adapter neu von GitHub installieren.

[cb187]

@crycode

Bei dem ersten kurzen Test hat er schonmal alle abfragen gemacht das einzige was glaub noch nicht funktioniert hat waren die werte setzen.
Ah und warn meldungen wieder im log.

[Mic208]

Hallo @crycode,

da muss jetzt mal ein wirklicher CAN Bus Versteher ran:
Ich hatte ja vor 5 Jahren über candump's mit Vergleich der Display-Eingaben die Befehlssequenzen "abgeschrieben". Bei Eingabe der gleichen Display Befehle mittels ELM von der gleichen 'Nachrichten-ID' aus, stürzt die Rotex-Wärmepumpe hart ab. Irgendwann hatte ich für die Fragen die Nachrichten-ID um 0x10 erhöht und bekam dann auch die richtigen Antworten. Beim Setzen von Werten hat das dann aber wieder nicht funktioniert. Deswegen sind so wenig 'Setz'-Befehle (im Gegensatz zu den fast 150 Frage und Antwort Befehlen) herausgekommen, weil auch dann die Rotex gerne mal wieder abstürzt. Man kann die Setz Befehle nicht von irgendwoher aus senden, die Maschine reagiert dann nicht entsprechend, sprich der Wert wird nicht übernommen oder stürzt ganz ab. Ist mir in den letzten Wochen viele Male passiert (nachdem ich Jahre Ruhe davor hatte), das Wiederherstellen der Maschine dauert dann auch wieder einige Minuten, ist mir aber manchmal erst nach Stunden aufgefallen, wenn das Warmwasser oder Räume kalt wurden.
Nur so als Info.

Übrigens: Da ich immer noch mein 2-minütliches Script mit der Frage nach 20 Befehlen laufen habe, habe auch ich täglich ein Log mit 500 MByte. Das hat sich die letzten 3 Versionen nicht wirklich geändert.

LG
Mic

[cb187]

@michael-wind so ne grosse log hab ich aber mit meiner liste aber nicht da läuft alles normal.Komischerweise nur mit der neuen liste con cry

[Mic208]

Hallo @cb187 & @crycode,

wollte hier mein Log von gestern (ungepackt 510 MB, gepackt 22 KB) anhängen, ließ das Forum-System nicht zu, will es wohl auf Viren scannen.

Deswegen nur die ersten 5 Minuten.
iobroker.2021-04-19.log.die-ersten-5-Minuten.zip

Mic

[crycode]

@michael-wind / @cb187 Danke für die Infos. In der aktuellen Version auf GitHub ist das Problem mit der Warnung "Parser xxx returned wrong data type undefined" jetzt behoben. Wenn ihr den Adapter ein mal von GitHub neu installiert, dann sollte das Log deutlich besser aussehen.

@cb187 Falls bei dir noch immer die Warnungen mit "You are assigning a boolean to the state..." auftauchen, bitte die config noch mal neu mit gesetztem Haken bei Vorhandene Nachrichten beim Import überschreiben importieren.

---

Zum Setzen der Werte habe ich jetzt noch ein paar Infos gefunden, die sich aber teils widersprechen.
Kann das einer von euch mal über die folgenden cansend Befehle testen und mir eine kurze Rückmeldung geben, was davon geklappt hat? Das sollte T-WW Soll1 auf 21,5°C setzen.

Variante a
CAN-ID 0x680 und die ersten beiden Bytes entsprechend dem Zielgerät gesetzt. Die zweite Stelle könnte 0 oder 2 sein. Eventuell müssen auch immer 7 Bytes gesendet werden.
cansend 680#30001300D7
cansend 680#30001300D70000
cansend 680#32001300D7
cansend 680#32001300D70000

Variante b
CAN-ID 0x480 und die ersten beiden Bytes 92 00.
cansend 480#92001300D7
cansend 480#92001300D70000

---

Das Senden der Anfragen mit der ID um 0x10 erhöht ist in diesem Fall ok, wobei die ID hier evtl. sogar egal ist, solange sie nicht mit einer vorhandenen kollidiert. Wenn das Setzen nach einem oben genannten Muster klappt, dann könnte man die Anfragen auch mal mit der gleichen Nachrichten-ID testen.