Neues Modul für ComfoAir, Paul Santos und Lüftungen mit kompatibler Steuerung

[Negropo]

Hallo Michael,

konntest du schon Fotos machen? Ich bin für jede Hilfe dankbar.

Gruß

Norman

[StefanStrobel]

Hallo,

anbei eine neue Version des ComfoAir Moduls. Mir war aufgefallen, dass die Temperatur-Werte in der Nachricht 0xD2 manchmal untereinander verschoben / vertauscht waren, was vor allem in den Verlaufsgrafiken auffällig war. Offenbar stimmt die Protokollbeschreibung hier nicht ganz. Der Wert von Byte 6 in der Nachricht 0xD2 bestimmt, ob Bytes 1-5 tatsächlich so belegt sind wie in der Protokollbeschreibung bisher vermutet. Als erste Lösung habe ich einen Filter eingebaut, der die wenigen abweichenden Nachrichten ausfiltert.
Wenn die neue Version auch bei anderen Nutzern keine Probleme macht, würde ich die Änderung demnächst einchecken.

Gruss
   Stefan

Edit: die aktuelle Version des Moduls ist eingecheckt.

[paulman2]

Hallo,

ich bin recht neu und unerfahren, daher bitte ich um Entschuldigung falls ich etwas übersehen habe oder es Euch dumm vorkommt.
Ich habe eine Zehnder Comfoair 350 R Luxe mit einem aktuell abgeklemmten CC Ease und eine Konnektorplatine. An dieser habe ich per PL2303 USB - Seriell Kabel an die PC Buchse einen Raspberry angeschlossen welcher wiederum per WLAN in einem Netz mit dem Rechner hängt auf dem FHEM läuft. Die serielle Verbindung wird per socat über TCP an den FHEM Rechner weitergeleitet.

Nun kann ich die Stufen einstellen (da kann ich hören, dass sich etwas ändert), vielleicht kann ich auch die Komforttemperatur einstellen, das sehe ich aber nicht.
In den Logfiles finde ich nun:

            Lueftung: Timeout2 in ReadAnswer for Stufe
            Lueftung: timeout waiting for reply expecting 00ce Request was 07f000cd007a070f

Aus irgend einem Grund kann ich also nicht lesen, schreiben scheint aber zu gehen (Stufen ändern sich).
Daher glaube ich, das RX/TX tauschen hier nichts bringt.

Kann mir jemand helfen?

Und vielleicht auch damit, einen Schalter / Slider angezeigt zu bekommen, die, wenn möglich, auch in der Android FHEM App funktionieren?

Vielen Dank schon einmal!

[paulman2]

Hallo,

ich wollte noch ein paar Informationen geben. Vielleicht kann mir dann jemand helfen?
Um auszuschließen, dass socat Schuld an dem Problem hat, habe ich nun FHEM direkt auf dem Raspberry installiert.
In den Logfiles finde ich dann z.B.:

2014.07.10 13:10:14 5: Lueftung: handle send queue
2014.07.10 13:10:14 4: Lueftung: handle queue sends get Ventilation-Levels code: 00cd frame: 07f000cd007a070f and wait for 00ce
2014.07.10 13:10:14 5: SW: ��z
2014.07.10 13:10:14 5: Lueftung: raw buffer: 07f0d209405855590f2828a90f07f307f0ce0e0f320f3232320146000045070f
2014.07.10 13:10:14 5: Lueftung: ParseFrames got frame: 07f0d209405855590f2828a90f07f307f0ce0e0f320f3232320146000045070f data ce0e0f320f3232320146000045 Rest
2014.07.10 13:10:14 5: Lueftung: read split frame into cmd ce0e, len 15, data 320f32323201460000 chk 69
2014.07.10 13:10:14 4: Lueftung: read: wrong length: 9 (calculated) != 15 (header) cmd=ce0e, data=320f32323201460000, chk=69
2014.07.10 13:10:14 4: Lueftung: read: wrong checksum: 182 (calculated) != 69 (frame) cmd ce0e, data 320f32323201460000
2014.07.10 13:10:14 5: Lueftung: raw buffer:

Irgend etwas scheint hier nicht mit den gelesenen Daten zu stimmen, da ja die Checksumme nicht stimmt. Gibt es vielleicht ein bekanntes Problem mit einem PL2303 Kabel und eine Empfehlung zur besseren und stabileren seriellen Anbindung?

Für Rückfragen bin ich offen und möchte mich schon einmal bedanken.

Viele Grüße

[StefanStrobel]

Hallo paulman2,

Der Puffer enthält schon die richtge Antwort auf den "00cd"-Befehl, allerdings steht davor noch Unsinn, der die Parse-Routine durcheinander bringt. Das ab dem 07f0ce und bis 070f ist das richtige Frame. Nach dem Lesen wird alles bis dahin aus dem Puffer gelöscht. beim nächsten gelesenen Frame sollte das Problem daher weg sein.

Was passiert denn wenn Du den Befehl nochmal absetzt?

Gruss
   Stefan

[paulman2]

Hallo Stefan,

ich hatte gerade auch noch etwas ausprobiert, nämlich das USB - Seriell Kabel getausch auf eins mit anderem Chipsatz (diesmal FTDI). Hat aber auch nichts gebracht.
Um auf Deine Frage zurückzukommen:

Ich habe zweimal die Lüfterstufe geändert (hat nach Gehör geklappt), aber die Antwort klappte beide Male nicht.

Leider sieht mein Logfile auch irgendwie anders aus. Ich sehe die RAW Antworten nicht mehr, auch auf der Weboberfläche nicht. Verbose ist auf 5 und der RS 232 Modus auf PC Only.

Tut mir leid wenn ich mich etwas doof anstelle, bin noch am Anfang, lerne aber gerne dazu.

Vielen Dank!
Paulman

[StefanStrobel]

Hallo Paulman2,

Aus Deinem Log vom 10.7. geht hervor, dass es zumindest da nicht an den Kabeln gelegen hat. Die Daten werden korrekt übertragen. Nur die zusätzlich gelesenen Daten haben die Parse-Routine im Modul durcheinander gebracht. Ich schau mal ob ich das im Modul verbessern kann. Eigentlich sollte das Problem so nicht auftreten und vermutlich ist die Regex, die ein Frame aus dem Datenstrom extrahiert nicht optimal.

Hast Du mal statt manueller set und get Befehle einfach ein Intervall beim define angegeben, so dass das Modul z.B. alle 30 Sekunden automatisch die wichtigsten Werte abfragt? Ich vermute dass sich das Problem dann auch erledigt ...

Ich melde mich später nochmal mit einem Update für's Modul.

Gruss
   Stefan

[StefanStrobel]

Hallo paulman2,

jetzt konnte ich gerade nochmal genau hinsehen.
Die Daten, die bei Dir im Raw Buffer angekommen sind, haben zwar die gleiche Frame-Begrenzung (07F0 bis 070F) und den gleichen ACK-Code (07F3) wie bei meiner Anlage, aber das war es dann auch schon. Der Befehlscode in den Daten passt nicht und die Inhalte auch nicht. Statt dem erwarteten 00CE kommt nur ein CE und die Daten danach scheinen auch nicht zum bekannten Protokoll zu passen.
Das klingt zunächst so als ob Deine Anlage eine andere Sprache spricht. Andererseits scheinen die Befehle zum setzen der Stufe ja verstanden zu werden. Das ist Seltsam. Wenn das Kabel falsch wäre, würde auch die Frame-Begrenzungen etc. nicht ankommen.

Versuch doch mal das serielle Kabel direkt an den Anschluss für die CC Ease zu klemmen. RX, TX und GND reichen. Das Modul funktioniert bei mir auch am Anschluss, der für die CC Ease bzw. CC Luxe vorgesehen ist. PC-Modus o.ä. habe ich auch nicht gesetzt. Das Modul tut so als wäre es eine CC Luxe. So könnten wir ausschließen, dass auf der Konnektorplatine ein anderes Protokoll gesprochen wird. Würde mich zwar wundern, aber man weiss ja nie.

Wie alt bzw. neu ist Deine Anlage denn?

Ausführlichere Logs und der relevante Ausschnitt aus der Konfiguration könnten eventuell auch helfen, das Problem einzugrenzen.

Gruss
   Stefan

[paulman2]

Hallo Stefan,

finde ich echt klasse, dass Du Dich so schnell meldest. Also, die Anlage ist 2011 hier eingebaut worden, daher Baujahr Ende 2010, Anfang 2011.
In der fhem.cfg mache ich bis jetzt nur folgendes:

define Lueftung ComfoAir /home/gbr/dev/vmodem0@9600 60
attr Lueftung room Eingang
attr Lueftung webCmd Stufe
attr Lueftung poll-Betriebsstunden 1
attr Lueftung poll-Status-Bypass 1
attr Lueftung poll-Ventilation-Status 1
attr Lueftung poll-Temperaturen 1
attr Lueftung poll-Ventilation-Levels 1
attr Lueftung poll-Sensordaten 1
attr Lueftung verbose 5

Vielleicht liegt hier schon mein Fehler? Um das Kabel an den CC Ease Anschluß zu klemmen muss ich noch den Lötkolben schwingen, das dauert noch etwas. Werde ich aber probieren.

Was mir noch aufgefallen ist im Log:

014.07.12 13:53:14 5: Lueftung: Set ? not found, return list request-Status-Bypass request-Bootloader-Version request-Ventilation-Status request-Temperaturen Temp_Komfort:slider,12,1,28 request-Firmware-Version request-KonPlatine-Version request-Ventilation-Levels Stufe:auto,abwesend,niedrig,mittel,hoch request-Betriebsstunden request-Verzoegerungen request-Status-Vorheizung RS232-Modus:Ende,nur-PC,nur-CC-Ease,PC-Master,PC-Log request-Sensordaten SendRawData

2014.07.12 13:53:14 5: Lueftung: Get ? not found, return list Temp_Aussen Stufe

Das passiert, wenn ich einen Wert setzen will bzw. Abfrage mit den Set und Get Schaltern oben auf der FHEM Webseite des Lueftungsmoduls. Vielleicht habe ich ein grundsätzliches Konfigurationsproblem oder ein Hilfsmodul nicht installiert?

Vielen Dank, ich bin echt baff, wie hilfsbereit Du bist! Echt großartig!

Paulman

[StefanStrobel]

Hallo paulman2,

das mit dem Set ? ist nur eine normale Debug-Ausgabe. Die zeigt nichts falsches an. Die Konfiguration schein auch nicht falsch zu sein. Allerdings würde ich versuchen den Anschluss zunächst direkt mit einer /dev/tty.. zu machen, damit nicht irgend eine andere Software dazwischenfunken kann.
Ich konnte den Anschluss ohne übrigens Löten einfach über Klemmen machen.

Gruss
   Stefan (werde jetzt vermutlich frühestens morgen oder Montag wieder zum Antworten kommen)

[paulman2]

Hallo Stefan,

ich habe die Zeit mal genutzt um weiter zu experimentieren. Was habe ich getan:

- FHEM auf RPi installiert und direkt verwendet -> gleiches Problem
- FHEM auf Ubuntu 12.04 PC installiert und direkt angeschlossen -> gleiches Problem
- Serielles Kabel an die Klemmen auf der Konnektorplatine angeklemmt an der vorher die CC Ease hing (sowohl RPi als auch PC) -> gleiches Problem

Du schriebst ja, dass FHEM sich als CC Ease ausgibt und diese Befehle nutzt. Somit hätte es klappen können. Hat es aber leider nicht  Vielleicht ist etwas im Protokoll anders. Mein CC Ease hat die Version (auf dem kleinen Aufkleber mit der Verdrahtungsanleitung) H2-v0.6 .

Soweit von meiner Seite. Falls ich etwas dazu beitragen kann zu debuggen oder Protokolle mitzuschneiden mache ich das gerne. Allerdings brauche ich dann eine kleine Starthilfe (also welches Programm oder welche Einstellungen ich nutzen soll). Ich würde mich freuen wenn ich da etwas beitragen kann.

Viele Grüße
Paulman

[StefanStrobel]

Hallo paulman2,

Welche Fhem-Version verwendest Du denn?
Hast Du mal ein Update gemacht?

Bei verbose 5 gibt ja nicht nur das ComfoAir Modul den RAWBUFFER aus, sondernauch die DEVIO Routine aus FHEM zeigt beim Senden mit SW: den Hex-String der zu sendenden Daten. Bei Dir war da kein Hex-String sondern es sah nach binären Daten aus. Die dafür zuständige Änderung wär glaube ich im März ...

Bitte schick doch nochmal ein paar Log-Zeilen mit dem RAWBUFFER nachdem Du auf die aktuelle Version upgedated hast.

Gruß
    Stefan

[paulman2]

Hallo Stefan,

ich hatte Version 5.5 direkt von der Webseite als .deb. Da dachte ich nicht, noch ein Update machen zu müssen. Habe ich jetzt aber gemacht, wurde auch einiges gefunden.
Hier also noch einmal von der Konfiguration "Raspberry FHEM direkt an /dev/ttyUSB0 @ 9600" ein paar Zeilen Logfile (verbose 5):

2014.07.15 19:22:44 5: SW: 07f3
2014.07.15 19:22:44 5: Lueftung: raw buffer:
2014.07.15 19:22:45 5: Lueftung: handle send queue
2014.07.15 19:22:45 5: Lueftung: send busy, delay writing from queue
2014.07.15 19:22:46 3: Lueftung: timeout waiting for reply expecting 00e0 Request was 07f000df008c070f
2014.07.15 19:22:46 5: Lueftung: handle send queue
2014.07.15 19:22:46 4: Lueftung: handle queue sends get Ventilation-Status code: 000b frame: 07f0000b00b8070f and wait for 000c
2014.07.15 19:22:46 5: SW: 07f0000b00b8070f
2014.07.15 19:22:46 5: Lueftung: raw buffer: 07f307f000062d046e1eb3070f
2014.07.15 19:22:46 5: Lueftung: ParseFrames got frame: 07f307f000062d046e1eb3070f data 00062d046e1eb3 Rest
2014.07.15 19:22:46 5: Lueftung: read split frame into cmd 0006, len 45, data 046e1e chk 179
2014.07.15 19:22:46 4: Lueftung: read: wrong length: 3 (calculated) != 45 (header) cmd=0006, data=046e1e, chk=179
2014.07.15 19:22:46 4: Lueftung: read: wrong checksum: 112 (calculated) != 179 (frame) cmd 0006, data 046e1e
2014.07.15 19:22:46 5: Lueftung: raw buffer:
2014.07.15 19:22:47 5: Lueftung: handle send queue
2014.07.15 19:22:47 5: Lueftung: send busy, delay writing from queue
2014.07.15 19:22:48 3: Lueftung: timeout waiting for reply expecting 000c Request was 07f0000b00b8070f
2014.07.15 19:22:49 5: Lueftung: handle send queue
2014.07.15 19:22:49 4: Lueftung: handle queue sends get Temperaturen code: 00d1 frame: 07f000d1007e070f and wait for 00d2
2014.07.15 19:22:49 5: SW: 07f000d1007e070f
2014.07.15 19:22:49 5: Lueftung: raw buffer: 07f3f000d2094852545556282828070f
2014.07.15 19:22:49 4: Lueftung: read got Ack
2014.07.15 19:22:50 5: Lueftung: handle send queue
2014.07.15 19:22:50 5: Lueftung: send busy, delay writing from queue
2014.07.15 19:22:51 3: Lueftung: timeout waiting for reply expecting 00d2 Request was 07f000d1007e070f
2014.07.15 19:22:51 5: Lueftung: handle send queue
2014.07.15 19:22:51 4: Lueftung: handle queue sends get Ventilation-Levels code: 00cd frame: 07f000cd007a070f and wait for 00ce
2014.07.15 19:22:51 5: SW: 07f000cd007a070f
2014.07.15 19:22:51 5: Lueftung: raw buffer: f000d2094852545556282828070f07f307f0ce0e0f320f232d0301460000400f
2014.07.15 19:22:51 4: Lueftung: read got Ack
2014.07.15 19:22:52 5: Lueftung: handle send queue
2014.07.15 19:22:52 5: Lueftung: send busy, delay writing from queue
2014.07.15 19:22:53 3: Lueftung: timeout waiting for reply expecting 00ce Request was 07f000cd007a070f
2014.07.15 19:22:53 5: Lueftung: handle send queue
2014.07.15 19:22:53 4: Lueftung: handle queue sends get Betriebsstunden code: 00dd frame: 07f000dd008a070f and wait for 00de
2014.07.15 19:22:53 5: SW: 07f000dd008a070f
2014.07.15 19:22:53 5: Lueftung: raw buffer: 07f0ce0e0f320f232d0301460000400f07f3f000de140366321500140000000fea380000d9070f
2014.07.15 19:22:53 4: Lueftung: read got Ack
2014.07.15 19:22:54 5: Lueftung: handle send queue
2014.07.15 19:22:54 5: Lueftung: send busy, delay writing from queue
2014.07.15 19:22:55 3: Lueftung: timeout waiting for reply expecting 00de Request was 07f000dd008a070f

Ich hoffe, Du kannst damit etwas anfangen. Falls nicht, schreib einfach, was ich testen soll.

Viele Grüße,
Paulman

[StefanStrobel]

Hallo Paulman,

vielen Dank für die zusätzlichen Logs. Das Problem wird langsam klarer:
Wenn Du die empfangenen Daten im RAWBUFFER mit der Protokollbeschreibung vergleichts (siehe http://www.see-solutions.de/sonstiges/Protokollbeschreibung_ComfoAir.pdf), dann sieht man dass bei Dir immer wieder einzelne Bytes fehlen. Ich habe ein paar Blanks in die Logs eingefügt, damit es lesbarer wird.

2014.07.15 19:22:46 4: Lueftung: handle queue sends get Ventilation-Status code: 000b frame: 07f0000b00b8070f
and wait for 000c
2014.07.15 19:22:46 5: Lueftung: raw buffer: 07f3 07f0 00 062d 046e 1eb3 070f
hier kommt ein Ack (07f3), dann der Beginn eines Frames (07f0) und dann sollte der Befehl als 000c kommen. Es kommt aber nur 00. Das 0c fehlt. Im Rest der Nachricht fehlen nochmals einzelne Bytes.

2014.07.15 19:22:49 4: Lueftung: handle queue sends get Temperaturen code: 00d1 frame: 07f000d1007e070f
and wait for 00d2
2014.07.15 19:22:49 5: Lueftung: raw buffer: 07f3 f0 00d2 09485254555628 2828 070f
Hier ist wieder ein ACK, dann sollte der Beginn des nächsten Frame mit 07f0 angekündigt werden. Es fehlt aber diesmal das 07.
Die restlichen Bytes des Frame sind diesmal da.

2014.07.15 19:22:51 4: Lueftung: handle queue sends get Ventilation-Levels code: 00cd frame: 07f000cd007a070f
and wait for 00ce
2014.07.15 19:22:51 5: Lueftung: raw buffer: f000d2094852545556282828070f 07f3 07f0 ce 0e 0f 32 0f 23 2d 03 01 46 00 00 40 0f

Hier ist noch das alte kaputte Frame im Buffer, danach kommt das ACK auf den gesendeten Befehl (07f3), dann der Beginn eines neuen Frame (07f0) und dann sollte der Befehl des Antwort-Frames mit 00ce kommen. Diesmal fehlt das 00.
Am Ende des Frames fehlt diesmal auch noch das 07 vor dem 0f.

2014.07.15 19:22:53 4: Lueftung: handle queue sends get Betriebsstunden code: 00dd frame: 07f000dd008a070f
and wait for 00de
2014.07.15 19:22:53 5: Lueftung: raw buffer: 07f0ce0e0f320f232d0301460000400f 07f3 f0 00de 140366321500140000000fea380000d9 070f

auch hier ist das alte Frame noch im Puffer, dann kommt wieder ein Ack als Antwort auf die gesendete Anfrage und dann das Antwortpaket mit Befehl 00de.
Hier fehlt gleich am Anfang wieder ein 07 vor dem f0. Der Befehl kommt dann vollständig (00de) und auch am Ende passt das 070f.

Unterm Strich sieht das für mich so aus als ob wir hier kein anderes Protokoll haben. Deine Lüftung versteht die Befehle und antwortet. Nur leider sind die Antworten alle verstümmelt. Da immer andere Bytes fehlen ist das kein Protokollunterschied sondern ein Übertragungsfehler oder Fehler an der Steuerung der Lüftung.

Hat denn Deine CC Ease funktioniert oder funktioniert die auch nicht?

Gruss
   Stefan

[paulman2]

Hallo Stefan,

Danke für die Analyse. Es scheint tatsächlich so zu sein. Die CC Ease funktioniert übrigens problemlos. Wenn ich sie angeklemmt habe und die Lüftung einschalte springt sie an und nach einer kurzen Zeit hat sie die Uhrzeit eingestellt und auch die sonstigen Werte sind sichtbar, also z.B. die Bypassklappe. Lüfter hoch/runter, Badtaster etc. funktionieren alle.

Wie schließt Du denn die Anlage an den PC an, also welchen Seriell -> PC Adapter nutzt Du? Vielleicht ist meiner ja etwas überfordert? Evtl. sind die Spannungen zu hoch und es gibt eine Übersteuerung oder die Flanken sind unsauber und es kommt dadurch zu einer Fehlerkennung.

Ich habe es probiert mit einem USB Kabel mit PL2303 Chip und mit einem USB Kabel mit FTDI Chip (Nummer habe ich gerade nicht da). Das Ergebnis war vergleichbar schlecht in beiden Fällen.

Ich habe keine Messgeräte zu Hause ausser einem Multimeter. Falls ich damit etwas anfangen kann würde ich damit losmessen.

Viele Grüße,
Paulman