Ankündigung

Einklappen
Keine Ankündigung bisher.

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

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • pavol
    antwortet
    Hi all,

    folgende Erkenntnisse:
    1. Mein LED Bedienteil registriert sich nach dem Start mit
    01 02 02 82 10 6D
    01 02 02 92 10 7D

    in eurem log sehe ich
    01 02 02 02 10 ED
    01 02 02 02 10 ED

    ist damit LED Bedienteil von TFT zu unterscheiden?


    2. Versuch sich unten 0x03 mit arduino zu registrieren
    Auf Anfrage 03 00 01 FC -> beantwortet Arduino 01 02 02 03 10 EC
    KonfigInfo 03 11 04 xxx... -> beantwortet Arduino mit ACK

    Es klappt, Arduino bekommt config für Registeradressen 00 bis F0 , nachdem aber keine Abfrage mehr. Master fragt die adressen 02 und 04 ab aber 03 nicht? Registerdaten sind die gleiche die master auf adresse 02 schickt, sind nur verschoben, das was adresse 02 auf dem register 00 hat, bekommt adresse 03 auf dem register A0, 10 -> B0, 20 -> C0 usw


    3. Versuch sich unten 0x12 mit arduino zu registrieren
    Auf Anfrage 12 00 01 FC -> beantwortet Arduino 01 02 02 12 10 FD
    KonfigInfo 03 11 04 xxx... -> beantwortet Arduino mit ACK

    wie oben, arduino bekommt konfig (identisch mit adresse 02) aber keine Abfrage mehr seitens master???

    4. Versuch sich unten 0x13 zu registrieren
    Master versucht konfig auf 0x12 zu schicken, da antwortet natürlich keinen und dann gibt stop, keinerlei traffic mehr auf dem bus

    Mir ist nicht klar wie die registration von weiteren TFT Bedienteilen funktionieren soll. Lohnt sich es hier weiter zu forschen?

    Mit aktuellen Kenntnissen siehe ich folgende Lösungen:

    a.) Mit einem Schalter entweder TFT(LED) Bedienteil oder Arduino mit bus verbinden. Eine einfachere Lösung, wenn ein manuelle Kontrole/Eingriff gewünscht ist, schalter umschalten, status prüfen, zurückschalten :-) nicht schön, weil das Bedienteil meiste zeit tot ist

    b.) arduino -in-the-middle-attack :-) arduino unterbricht kommunikation zwischen master und bedienteil, 2 buse - auf einem übernimmt arduino role von bedienteil + anbindung iot oder knx, auf zweitem bus simuliert arduino master - hier hängt auch das TFT bedienteil, arduino gibt config info, anfragen und broadcast messages weiter, datenänderung antworten von bedienteil werden auf erstes bus übergeben. ein bisschen kompliziert, aber es sollte sauber funktionieren



    arduino-in-the-middle-attack.png

    Angehängte Dateien
    Zuletzt geändert von pavol; 27.01.2016, 12:15.

    Einen Kommentar schreiben:


  • coderchris
    antwortet
    Mich kribbelts auch einen Mega zu bestellen... ;-) hab nur leider wenig Zeit...

    Einen Kommentar schreiben:


  • pavol
    antwortet
    Hi,

    aktueller Status:
    *arduino mega + rs485 shield, angepasste SoftwareSerial 9N1 - ich kann die Daten auslesen

    Ich habe versucht das Board als adresse 03 zu registrieren, ich bin aber gescheitert, die Antworten werden ignoriert, oder ich schicke keine Antworten. Um zu prüfen ob transmit über rs485 funktioniert, überlege ich ein simulator von "master" zu schreiben und direkt mit LED Bedienteil kommunizieren.

    Pavol

    Einen Kommentar schreiben:


  • franzmm
    antwortet
    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....

    Code:
                    # 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

    Einen Kommentar schreiben:


  • deival
    antwortet
    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...

    Einen Kommentar schreiben:


  • johnson
    antwortet
    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.
    Zuletzt geändert von johnson; 12.01.2016, 21:19.

    Einen Kommentar schreiben:


  • deival
    antwortet
    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?
    Angehängte Dateien

    Einen Kommentar schreiben:


  • deival
    antwortet
    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.

    Einen Kommentar schreiben:


  • johnson
    antwortet
    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.
    Angehängte Dateien
    Zuletzt geändert von johnson; 12.01.2016, 09:52.

    Einen Kommentar schreiben:


  • deival
    antwortet
    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:

    Code:
    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:
    Code:
    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....
    Zuletzt geändert von deival; 11.01.2016, 22:53.

    Einen Kommentar schreiben:


  • deival
    antwortet
    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....
    Angehängte Dateien

    Einen Kommentar schreiben:


  • pavol
    antwortet
    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 

    Einen Kommentar schreiben:


  • deival
    antwortet
    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...

    Einen Kommentar schreiben:


  • coderchris
    antwortet
    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

    Einen Kommentar schreiben:


  • pavol
    antwortet
    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

    Einen Kommentar schreiben:

Lädt...
X