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

[johnson]

Hallo,

hier mal ein Log für die Novus 300 beim Start:

020001FD     ->Anfrage Bedienteil    
0102020210ED     ->Antwort        
020001FD     ->Anfrage Bedienteil
0102020210ED     ->Antwort
030001FC     ->Anfrage
030001FC     ->Anfrage
040001FB     ->Anfrage LüfterSlave   
010302040600FC     ->Antwort       
040001FB     ->Anfrage  LüfterSlave
010302040600FC     ->Antwort
050001FA     ->Anfrage
050001FA     ->Anfrage
060001F9     ->Anfrage
060001F9     ->Anfrage
070001F8     ->Anfrage
070001F8     ->Anfrage
120001ED     ->Anfrage
120001ED     ->Anfrage
130001EC     ->Anfrage
130001EC     ->Anfrage
140001EB     ->Anfrage
140001EB     ->Anfrage
150001EA     ->Anfrage
150001EA     ->Anfrage
160001E9     ->Anfrage
160001E9     ->Anfrage
170001E8     ->Anfrage
170001E8     ->Anfrage

Es werden alle Adressen von 02 bis 07 und 12 bis 17 abgefragt.
Hat jemand einen log für das LED-Bedienteil?

[johnson]

Hab was neues gefunden:
01110400021822110407080F0301000000000000C5
0x07=07, 0x08=08 0x0F=15 -> Datum 07.08.2015
0x18=24 0x22=34 0x11=17 ->17:34:24Uhr

[coderchris]

Ich kenne mich mit AVRs und so leider nicht wirklich aus. Um einen solchen Repeater zu bauen fehlt mir einfach das Wissen und die Zeit. Hab zwar noch ein Bus Pirate hier rum fliegen, aber noch nie solche Embedded Programmierung gemacht. Hab ja noch irgendwie die Hoffnung mit einem Standard RS485 Interface und emuliertem 9. Bit (Parity) weiter zu kommen. Dass der Master so viele Slaves anfragt stimmt mich ja schon hoffnungsvoll. Könntest du mir noch kurz Bestätigen, ob das wirklich 9N1 ist? Oder sind das sogar 9N2 oder noch schlimmer 9N1,5? Ich vermute langsam, dass mein RS485-Adapter kaputt ist oder ich einen Fehler in der Verdrahtung hab. GND ist durchgeschliffen, A mit A und B mit B verbunden. Einen 120 Ohm Widerstand hab ich auch schon versucht, aber bei nur 10m Leitung sollte das egal sein... Gruß Christoph

[johnson]

Ja es sind 9N1.
Kannst du mit einem Oszi prüfen ob dein Adapter wirklich 9 Bit also 8Bit plus Parity sendet.
Ich hatte mal einen China USB-Rs232 Adapter bei dem hab ich in HTerm auch 8M1 eingestellt, das hat der aber nicht gemacht.
Der hat die Daten immer als 8N1 gesendet.
Ich hoffe auch, dass ich evtl ein LED-Bedienteil simulieren kann, das wäre der einfachste Weg.
Hierfür brauch ich aber die Daten und die Adresse für das Teil.

[coderchris]

Wär ja schon glücklich, wenn das Ding 8 Bit plus Parity empfangen könnte. Ist (wie alles auf diesem Planeten) aus China, aber ist ein PL2303 drin, genau wie in meinem RS232-Adapter. Der Prolific sollte das eigentlich können. Vielleicht ist irgendwo nen Masseschluss oder sowas... ich suche dembächst mal hier nen anderen RS485 Bus und versuche den anzubinden. Mal sehen, was passiert...

[johnson]

Bei meinem RS232 ist ein CH340 Chip drin.
Hab heute versucht die Prüfsumme zu berechnen, ich komme aber nicht drauf.
Hast du die schon mal unter die Lupe genommen.

[coderchris]

Bisher nicht. Für einfachste Nachrichten war ich bei 00-1. Byte+2. Byte-3.Byte+4.Byte... aber das funktionierte nicht für längere Nachrichten. Dass das erste Byte negativ in das Prüftbyte eingeht, scheint zumindest offensichtlich...

[MatthiasS]

In meinem Baustein für den HS fische ich doppelte 07 auch aus der Checksumme.

[coderchris]

Klingt unkonventionell

[coderchris]

Andere Idee... FF xor 1. Byte xor 2.Byte xor ... +1... was wäre damit?

[coderchris]

Das mit dem xor+1 scheint sogar mit langen Nachrichten zu klappen... 01110400021822110407080F0301000000000000C5 Passt...

[lucipher]

Hi,

die Daten werden im Plugin nicht korrekt extrahiert wenn die Prüfsumme eine 07 ist.

2015-12-23 19:10:50 ERROR    ComfoAir-cyclic ComfoAir: Ignored command: 07:f0:00:0c:06:3e:3e:03:da:03:ec:07:07:07:0f
2015-12-23 19:10:50 ERROR    ComfoAir-cyclic ComfoAir: Corresponding read command: 00:0b:00, decoded data: 3e:3e:03:da:03:ec:07 (raw: 3e:3e:03:da:03:ec:07)
2015-12-23 19:10:50 ERROR    ComfoAir-cyclic ComfoAir: Calculated checksum of 14 does not match received checksum of 7! Ignoring reponse.

Die Datenlänge sind 6 Bytes und es werden 7 extrahiert.

# Remove begin and checksum to get the data
        rawdatabytes = response[5:-3]

Das kann man aber über eine Selektion abfangen. Muss ich mal umschreiben. Aber nicht in den Weihnachtstagen. Sonst gibts von der Frau mecker.


Gruß

[johnson]

Hab mal in mein Log Tool die Prüfsumme selber berechnet ist das Byte ganz am Ende welches mit einem Leerzeichen getrennt ist

010302040615E9 E9
04110400020100047F00000200C0A80001010000FD FD
01000FF0 F2    
04110410113250FFFFF9FFF6FF0F0F5A02640300BC BE
01000FF0 F2          
04110420FA00B400050600A65D126428C8000011FE 00
01000FF0 F2          
041104303200058200000000ECFF00000000000079 79
01000FF0 F2          
04110440111450503214BE50000000000000000062 64
01000FF0 F2        
04110450111D2C39465164000000000000000000D5 D5
01000FF0 F2    
040001FB FB    
010302040615E9 E9
040001FB FB          
010302040615E9 E9
040001FB FB          
010302040615E9 E9
040001FB FB

Entweder ich hab Kommunikationsprobleme bei der falschen Prüfsumme oder hier muss man anders rechnen.
Hat einer von euch auch dieses Problem?
Hab mit dieser Formel die Prüfsumme ermittelt: FF xor 1. Byte xor 2.Byte xor ... +1.

[coderchris]

Da wird wohl die Prüfsumme doch etwas komplizierter sein. Dort wo sie falsch ist, muss nur +2 drauf gerechnet werden, dann passt es wieder. Aber warum hab ich auch noch nicht erkennen können. Da es aber immer so regelmäßig ist, würde ich Kommunikationsfehler ausschließen. Ich bin leider noch nicht so weit, da ich immer noch mit dem RS485 Empfänger kämpfe. Und mit RS232 weiter zu machen, macht keinen Sinn, da ich ja senden will und nicht nur empfangen... Gruß Christoph

[deival]

Habe auch eine Paul Novus 300 und habe einen ATmega644P dazwischen gehängt um mitzuloggen.
Vielen Dank erstmal für den Tipp mit den 9N1-Framing, da wäre ich so schnell nicht drauf gekommen!

Möchte nun auch was beisteuern:

Die Prüfsumme berechnet sich scheinbar wie folgt:

0xFE xor 1. Byte xor 2.Byte xor ...

(das "+1" am Ende fällt weg , "xor 1" wäre richtig gewesen, kann aber auch vereinfacht werden indem der Startwert auf 0xFE statt auf 0xFF gesetzt wird)

Bei meinem Programm (läuft direkt auf dem ATmega) kommt als berechnete "Checksum" immer 0000 raus weil ich die Checksumme mit einberechne. Die Ausgabe des Programms sieht so aus:

0100 0A 00 00 59 14 00 05 02 01 16 02 01 AA -> Checksum: 0000
0102 00 01 FD -> Checksum: 0000
0101 02 02 02 10 ED -> Checksum: 0000
0104 00 01 FB -> Checksum: 0000
0101 03 02 04 06 15 E9 -> Checksum: 0000
0105 00 01 FA -> Checksum: 0000
0101 03 02 05 01 00 FA -> Checksum: 0000

Die erste vierstellige Zahl ist die Adresse in 9bit-Format wie es vom Novus kommt.
Dann kommen die Daten die von der Novus kommen incl. Prüfsumme in Hex.
Das "-> Checksum: 0000" fügt mein Programm hinzu, "0000" ist dabei die berechnete Prüfsumme.

Noch was zu meiner Hardware:

Der Atmega644P hat zwei serielle Schnittstellen die eine hängt bei mir an einem MAX487 (RS485 Schnittstellenwandler wie auch im Novus verbaut) die andere als RS232-Schnittstelle am PC.
Zum PC benutze ich 115200 Baud um noch Daten zusätzlich ausgeben zu können, ohne dass mir die Buffer volllaufen....

Wäre vorstellbar ein kleines Gateway bestehend meiner Hardware zu bauen.....mit einem FTDI-USB Wandler an der UART zum PC dann könnte man das direkt am RaspberryPi betreiben ;-)