Neues Plugin ComfoAir (KWL Wohnraumlüftung Zehnder, Paul, Wernig)

[pavol]

Hallo johnson,

ich glaube mit raspPI geht 9N1 über UART nicht, über GPIO wäre es aufwändig zu proramieren (was ich bislang gelesen habe, habe keine praktische erfahrung damit)
ich habe ein arduino mega board und ein rs485 shield dazu bestellt, ich werde es in ein paar tagen ausprobieren und melde mich. Es gibt sowohl für den hardware als auch für software serial Umsetzungen für 9N1.

Der usb-rs485 ist aus china, link anbei.

Ich will mein LED Bedienteil weiterhin nutzen, laut doku darf bei benutzung von dem LED Bedienteil kein weitere Bedienteil angeschlossen werden, ich bin neugierig....

LG Pavol

[coderchris]

Der Mega kann das 9. Datenbit von der Hardware her schon, nur das Arduino Framework kann das nicht. Es gibt einen älteren Pullrequest, aber der geht nicht mehr in der aktuellen IDE. Somit verlässt man auch bei Arduino wieder den Standard und frickelt das irgendwie hin...

[johnson]

Hallo deival,

habe eine neue Version hochgeladen, hoffe das ist ok für dich da es ja dein Dokument ist.
Ich habe dem Bcast eine eigenes Tabellenblatt spendiert, dort habe ich zwei Updates drin. 1. Wochentag(Data3) 2. Lüfter an/aus(Data8)
Beim Datenregister TFT hab ich in Page 0x00 auch Wochentag(Data4) eingetragen. In Page 0x60 habe ich die Sensor-Kennlinien eingetragen(Data0 bis 7).

[pavol]

hallo coderchris

ich habe mir diesen pull angesehen: https://github.com/arduino/Arduino/pull/2291, ich glaube wenn es sauber umgesetzt wird, haben arduino jungs nichts gegen ein merge...c++ kann ich , so ich kann ausprobieren es noch einmal zu beantragen

lg pavol

[coderchris]

Ja, genau diesen Pull-Request von Bouni meinte ich. Meine C/C++-Zeit ist jetzt 20 Jahre her. Da versuche ich mich lieber nicht mehr dran

[deival]

Man muss ja nicht die UART des RasPi nehmen. Bei 9600 Baud reicht auch eine Bitbanging-Software-Lösung wie z.B. diese hier:

http://raspberrypi.stackexchange.com...rial-port-data
http://abyz.co.uk/rpi/pigpio/

Dafür sucht man sich GPIO's am RasPi aus hängt daran RX und TX des MAX487-Level-Converters ein bis zwei weitere GPIO's für Enable-Pins für senden und empfangen, und los gehts mit programmieren...

[pavol]

Hallo deival, vielleicht hast du recht mit raspPi und gpio, ich kann jetzt aber nicht einschätzen wie stabil es wird.  Bei konfiguration one master multiple slaves.  Ale anfragen sollen mit einem Ack beantwortet werden.  Das mega board und RS 485 soll am Freitag da sein, ich freu mich schon drauf LG Pavol 

[deival]

Hallo johnson,

ist kein Problem dass Du mein File weitergepflegt hast, ich habe meine Erkenntnisse mit Deinen "gemerged".
Habe an den nötigen Stellen eine Zweierkomplementumrechnung eingebaut...
...was das für Daten auf Page 0x70 sind kann ich mir immer noch nicht vorstellen....
....Temperaturdaten sind es scheinabr nicht da die Daten gleich bleiben....
....bzgl. Temperaturen sieht es immer noch nicht gut aus...ich sehe bis jetzt keine....

[deival]

Hallo pavol,

für den Schnelleinstieg:
meine Registersettings für die UARTs:
UCSR0A 0000
UCSR1A 0020
UCSR0B 00D8
UCSR1B 00DE
UCSR0C 0006
UCSR1C 0006

-> entscheidend ist das rot markierte Register

Die Register werden bei mir mit folgender Funktion konfiguriert:

void uartSetFrameFormat(u08 nUart, u08 databits, u08 parity, u08 stoppbits)
{
    u08 reg = 0;
    
    u08 ninebit = 0;    
    
    switch (databits)
    {
        case 5:        reg = 0; /* value must be 0 */ break;
        case 6:        reg = (1<<UCSZ00); break;
        case 7:        reg = (2<<UCSZ00); break;
        default:
        case 8:        reg = (3<<UCSZ00); break;
        case 9:        reg = (3<<UCSZ00);
                    ninebit = 1;
                    break;
    }
    
    switch (parity)
    {
        default:
        case 0:        reg |= 0; /* value must be 0 */ break;
        case 2:        reg |= (2<<UPM00); break;        //EVEN
        case 3:                                        //ODD
        case 1:        reg |= (3<<UPM00); break;        //ODD        
    }
    
    switch (stoppbits)
    {
        default:
        case 1:        reg |= 0; /* value must be 0 */ break;
        case 2:        reg |= (1<<USBS0); break;                
    }
    
    if(nUart)
    {
        if (ninebit != 0)
        {
            UCSR1B |= (1<<UCSZ12);
        }
        else
        {
            UCSR1B &= ~(1<<UCSZ12);
        }
        
        UCSR1C = reg;
    }
    else
    {
        if (ninebit != 0)
        {
            UCSR0B |= (1<<UCSZ02);
        }
        else
        {
            UCSR0B &= ~(1<<UCSZ02);
        }
        
        UCSR0C = reg;
    }
}

Aufruf:

uartInit();                    // initialize UARTs (serial ports)
//UART zum PC
uartSetBaudRate(0, 115200);    // set UART0 speed    
uartSetFrameFormat(0, 8, 0, 1);        //UART0 = 8N1
//UART zur Lüftung
uartSetBaudRate(1, 9600);    // set UART1 speed
uartSetFrameFormat(1, 9, 0, 1);        //UART1 = 9N1

-> keine Garantie auf Richtigkeit (aber ich kann sagen: bei mir funktionierts)!
-> Das ganze läuft auf einem ATmega644P auf einem selbst gebauten Board.

Das neunte Datenbit ist im UCSRxB versteckt und beim senden muss was besonderes beachtet werden, einfach das ATmega Datenblatt lesen da sind sogar C-Codebeispiele drin....

Noch ein Nachtrag zur Stabilität: Ich würde auch ein "Gateway" in Form eines ATmega gegenüber der Software-UART-Lösung bevorzugen, auch schon wegen der Ausfallsicherheit ist ein ATmega wesentlich stabiler als ein EmbeddedSystem wie der RasPi bei dem zu jedem Zeitpunkt die SD-Karte aussteigen kann ...die Software die auf dem ATmega läuft ist dann auch noch überschaubar, und unabhängig von irgendwelchen Bugs die in evtl. verwendeten unendlich komplexen Libraries stecken....

[johnson]

Hallo deival,

kannst du bestätigen dass in Page 0x20/ D2 vom TFT Lüfterlaufzeit in Tagen drin steht, denn bei mir ändert sich der Wert nicht.
Könnte aber auch sein, dass ich eine alte Firmware habe in der dies noch nicht drin steht.

0x70 ist der Volumenstrom, hab ich gerade in der Bertiebsanleitung auf Seite S 37 gefunden, siehe Bild anbei.

[deival]

Eigentlich hatten sich die Werte schon verändert, an dem Tag als ich es mit aufgenommen habe Stand 28 dezimal drin, was mit der Anzeige im Display übereistimmte. Bei meiner vorherigen Aufzeichnung stand da 35 was in etwa hin kommt. Ich kann das heute Abend nochmal checked. Nehme dann auch die Firmwareversionen mit auf.

[deival]

Hallo johnson,

also Page 0x20 Databyte 2 ist auf alle Fälle die Lüfterlaufzeit in Tagen.
Am zweiten Januar stand da 35d heute nur noch 25d.
Meine Firmwareversionen lauten:
SWZ.0015.B.2.9G
SWZ.0016.B.2.5F
ETA.0017.E.2.8M
ST0.0040.E.2.4E
Ich habe die Volumenstöme des LED-Bedienteils mit aufgenommen, siehe Anhang.
Könnte vielleicht die 0x103er Adresse das LED-Bedienteil sein?

[johnson]

Hallo deival,

kann es sein, dass du Filterrestlaufzeit meinst?
Die Tage wurden ja weniger oder?
Dann kann es sein, denn bei mir ist aktuell 0 in der Anzeige und auch im log.

Ich glaube, dass die Bedienteile immer auf Adrsse 0x102 sind.
Im log von pavol ist das LED Bedienteil auch auf 0x102

02 00 01 FD

01 02 02 82 10 m6D

Ich schätze aus der Antwort erkennt der Master ob es das LED oder das TFT ist.

Beim TFT sieht es ja so aus:
02 00 01 FD
01 02 02 02 10 ED

Irgendwo muss dem Slave doch noch mitgeteilt werden wenn er die Lüfterstufe umschalten ob es sich eine Stufe für das TFT handelt oder für das LED, oder?

Ich kann aktuell noch nicht auf den Bus schreiben, ich höre nur mit.

[deival]

Hallo johnson,

Ja ich meine die Filterrestlaufzeit!

Ja das mag so sein.

Ich verstehe aber immer noch nicht wie ich das dann ohne Registrierung beim Master beeinflussen können soll.
Das ist mit Registrierung beim Master schon zeitkritisch ohne Ende, mein gepuffertes empfangen führt schon dazu dass der Master doppelte Nachfragen raus schickt...

Hab heute versucht die Register in ein Array einzulesen (hat geklappt) und dann eine nur um die Lüfterstufe veränderte Page 0x00 an den Master raus zu schicken
-> ohne Erfolg nur Kollisionen am Bus....wie erwartet eigentlich...

[franzmm]

Hallo zusammen,

ich habe das Comfoair Plugin weitgehend erfolgreich im Einsatz, bis auf die Tatsache, dass ich ziemlich häufig Übertragungsfehler gemeldet bekomme. Das habe ich mir nun in einer längeren Debug Sitzung angeschaut und versucht zu analysieren. Ich bin mir inzwischen relativ sicher, dass das Problem auftritt, wenn die Acknowledge Sequenz (2 Bytes) zerstückelt, also als 2 aufeinander folgende Bytes ankommt (was in meinem Fall wohl recht oft vorkommt). In diesem Fall wird sie nicht mehr als ACK erkannt und auch nicht aus dem Telegram entfernt, womit dann die Checksumme nicht mehr stimmt und das Telegram als fehlerhaft geloggt wird.
Siehe Code: Kommentar "# Cut away old ACK (but only if the telegram wasn't started already)", falls nun ein einzelnes Byte kommt, wird es nicht als ACK erkannt, sondern stattdessen als Telegramstart interpretiert und mit dem Beginn des Telegramms wird nicht mehr nach ACK gesucht.
Hat jemand ähnliches festgestellt?
Leider sind meine Pythonkenntnisse zur Lösung des Problems (noch) recht begrenzt....

                # Try to receive a packet start, a command and a data length byte
                firstpartlen = len(self._packetstart) + self._commandlength + 1
                while self.alive and len(packet) < firstpartlen:
                    try:
                        bytestoreceive = firstpartlen - len(packet)
                        self.log_debug('Trying to receive {} bytes for the first part of the response.'.format(bytestoreceive))
                        chunk = self.read_bytes(bytestoreceive)
                        self.log_info('Received {} bytes chunk of response part 1: {}'.format(len(chunk), self.bytes2hexstring(chunk)))
                        if len(chunk)  == 0:
                            raise Exception('Received 0 bytes chunk - ignoring packet!')
                        
                        # Cut away old ACK (but only if the telegram wasn't started already)
                        if len(packet) == 0:
                            chunk = self.remove_ack_begin(chunk)
                        packet.extend(chunk)
                    except socket.timeout:
                        raise Exception("error receiving first part of packet: timeout")
                    except Exception as e:
                        raise Exception("error receiving first part of packet: {}".format(e))

Gruß

Franz