Umfrage: Interesse an Anbindung von Buderus Heizung an KNX

[pmike]

Hallo Nils, hallo Tbi,
ich kann Matthias nur zustimmen und Beifall klatschen.

Perfekt - ich bin stolz auf euch
Meine Buderus-Therme freut sich schon....

... und bei meiner Therme war das Blau auch heute irgendwie heller als sonst! Habe mich schon den ganzen Nachmittag auf die Tests gefreut.

Und das sieht schon richtig toll aus:

DEBUG: 'STX <--- empfangen'
DEBUG: '---> DLE gesendet'
DEBUG: "Data 'A7'"
DEBUG: "Data '01'"
DEBUG: "Data '92'"
DEBUG: "Data '07'"
DEBUG: "Data '50'"
DEBUG: 'erstes DLE in DATA gefunden'
DEBUG: 'Received BBC -> OK'
DEBUG: Daten sind erfolgreich empfangen
DEBUG: "Reveice_Data 'A7 01 92 07 50'"
DEBUG: _3964r_Receive: Also in Empfangs Mode
DEBUG: 'STX <--- empfangen'
DEBUG: '---> DLE gesendet'
DEBUG: "Data 'A7'"
DEBUG: "Data '02'"
DEBUG: "Data '89'"
DEBUG: "Data '00'"
DEBUG: "Data '03'"
DEBUG: 'erstes DLE in DATA gefunden'
DEBUG: 'Received BBC -> OK'
DEBUG: Daten sind erfolgreich empfangen

@Nils: Wie kann ich im Debugger z.B. das "DD" senden, falls das auch schon zu testbar ist? Oder muss ich dazu den Baustein in den HS laden.

Was könnte ich von meiner Seite weiter tun, um euch zu unterstützen?

Liebe Grüße von einem dankbaren Nutzer&Tester

Mike

[NilsS]

Du kannst (wenn der Baustein das denn später mal unterstützt) den Eingang benutzen.

einfach beim debugger EN[3]="DDA4........" was auch immer dein hexstring ist senden, so die Theorie.

In der Praxis ist dieser Teil jedoch noch nicht funtkionsfähig.

Wir haben uns darauf verständigt, das wir die Ein/Ausgänge in lesbarem HEX senden, das sollte auch zum Debuggen nachher das beste sein.

Ich warte jedoch noch bis Tobias das soweit getestet hat wie es jetzt ist (also mit einer Liste mit dezimalen werten).

Wenn soweit alles funktioniert, werde ich die Funktionen anpassen, dass sie kleiner und lesbarer werden, und das Ein- wie auch Ausgang dann im genannten Format sind.

Dann könnt ihr loslegen die Bausteine für die Module zu bauen.

[NilsS]

bitte mal testen, ich hoffe ich habe alles sauber umgesetzt.

https://github.com/knxuf/buderus/tree/HEAD

[NilsS]

um dort die Testdaten von Tobias zu senden.

Send_Data = [ 0xA2 , 0x01 , 0x23, 0x24, 0x53, 0x66 ]

>>EN[3]="A20123245366"
>>run
im Logikdebugger

[NilsS]

sehr viele debug meldungen hinzugefügt
https://github.com/knxuf/buderus/tree/HEAD

ich hoffe das ich auch jede menge Daten bekomme

[tbi]

Hi Nils,
hab gerade angefangen, Kommt "ein ungülige Zeichen //0x10" empfangen" nach dem STX

Mach nachher weiter. Wir habe hier noch Besuch bekommen und den muß ich nun noch in Bett treiben

Weißt Du einen git Befehl um das letzte File vom Branch local zu kriegen ?

Viele Grüße

Tbi

[pmike]

Hi Nils,
die Eingabe von EN[3]="DD" ... habe ich irgendwie nicht hinbekommen. Ich lese am WE noch mal deine Anleitung zum Debugger.

Dafür habe ich in der Zeile 268 MODE_DIRECT statt MODE_NORMAL eingetragen und das Array in Zeile 277 auf Send_Data=[ 0xA2 , 0x01 ]
Man kann "DD" und "A201" leider nicht in einem 3964r Frame packen, sondern immer schön nacheinander, weil Einzelkommandos. Dann kommen auch die Konfigurationsdaten vom Gerät 1. Nach einer Minute ohne Action kommen dann die Normal-Modus Daten.
Das Ende der Konfiguration ist immer "AC <Ger.-ID>" auch wenn das Gerät nicht da ist.

Supi!

So könnte man in einer Schleife die Initialdaten holen und die Einzelwerte mit den Normal-Mode Daten aktualisieren. Ein Kesselbaustein fragt dann z.B. den Typ "0x92" ab und bekommt die 60 Byte Daten vom
Grundbaustein im aktuellen Status zur Weiterverarbeitung. Allerdings weiß ich nicht, wie man 60Byte zwischen zwei Bausteinen übertragen könnte.

ich hoffe das ich auch jede menge Daten bekomme

Ich kann dir meine Konfigurationsdaten als Hexdump schicken, wenn das hilft. War die Frage so gemeint?

Viele Grüße
Mike

[NilsS]

Tobias das ungültige Zeichen kannst du einfach ignorieren, das baue ich noch um. Das kommt aus dem anderen thread. Das sollte eigentlich nicht stören

Edit: Mist klar das read schnappt das DLE da natürlich weg.

[NilsS]

Fixed

[NilsS]

@mike

Ich glaube du hast die falsche Version. meine Version die das kann ist nicht im Master sondern im Head

git checkout Head
git pull HEAD

[NilsS]

Allerdings weiß ich nicht, wie man 60Byte zwischen zwei Bausteinen übertragen könnte.

keine Sorge da ja alle als hex String kommen können die einfach über ein 14byte iko im HS verarbeitet werden. Genau so wie es hsfusion jetzt mit den connectoren macht. Da geht bis 10kbyte sogar remanent.

[pmike]

@mike

Ich glaube du hast die falsche Version. meine Version die das kann ist nicht im Master sondern im Head

git checkout Head
git pull HEAD

Mmh, ich habe dirkt das Zipfile von hier genommen (weil ich mir den Client sparen wollte) und dann EN[3]="DD"+run eingegeben:

DEBUG: 'STX <--- empfangen'
DEBUG: '---> DLE gesendet'
DEBUG: "Data 'A7'"
DEBUG: "Data '01'"
DEBUG: "Data '89'"
DEBUG: "Data '1A'"
DEBUG: "Data 'AB'"
DEBUG: 'erstes DLE in DATA gefunden'
DEBUG: 'Received BBC -> OK'
DEBUG: Daten sind erfolgreich empfangen
DEBUG: "Reveice_Data 'A7 01 89 1A AB'"
DEBUG: _3964r_Receive: Also in Empfangs Mode
EN[3]="DD"
>> run
teste Bedingung in Zeile 49: 'EI'
teste Bedingung in Zeile 52: 'EI'
teste Bedingung in Zeile 53: 'EC[3]'
starte Formel: 'SN[1].incomming(EN[3])'
DEBUG: "incomming message 'DD'"
RunTime: 0.000419
Ausgabe: 0|0|0|0
Ergebnis: None
-------

Nach ca. 2s Denkpause spuckt er weiter Normalmode Daten aus. Das dürfte er im Direktmodus aber erst nach 1min und auf "A201" reagiert er deshalb auch nicht. Nach meiner Vermutung ist nicht sichergestellt, dass der Befehl solange gesendet wird, bis ein DLE von der Anlage kommt.

Mike

[tbi]

So, nachdem mir doch die Augen zugefallen waren, hier mal ein Test, scheint sich gelohnt zu haben noch ein Nickerchen zu machen

Also das Umschalten zwischen Read und Write Thread scheint jetzt zu gehen.
Auch der * und die Leerzeichen werden umgesetzt. => dreimal send geht und die Leerzeichen sind entfernt.

Aber das Empfangen geht noch nicht.

Das Bild vom Debugger im Anhang

In den Kongfig steht das AN[3]="A2 01 23 24 53 66" übrigens. geht auch.

und der Log om Terminal:
einfach:

-> A2 01 23 24 53 66 
-> DD 
-> A2 01 
-> DE 
<- 0B 90 06 00 08 44  (error: timeout - no DLE after STX)
-> DD 
-> A2 01 
-> DE

mit trace

1354762304401 - COM2 - (z00) receive: STX
1354762304581 - COM2 - (z00) sending: DLE
1354762304581 - COM2 - (z00) receive: A2 01 23 24 53 66 
1354762304621 - COM2 - (z21) receive: DLE
1354762304621 - COM2 - (z22) receive: ETX
1354762304621 - COM2 - (z23) receive: BCC=[82], is ok
1354762304621 - COM2 - (z23) sending: DLE
1354762351739 - COM2 - (z00) receive: STX
1354762351919 - COM2 - (z00) sending: DLE
1354762351919 - COM2 - (z00) receive: DD 
1354762351949 - COM2 - (z21) receive: DLE
1354762351949 - COM2 - (z22) receive: ETX
1354762351949 - COM2 - (z23) receive: BCC=[CE], is ok
1354762351949 - COM2 - (z23) sending: DLE
1354762351969 - COM2 - (z00) receive: STX
1354762352149 - COM2 - (z00) sending: DLE
1354762352149 - COM2 - (z00) receive: A2 01 
1354762352179 - COM2 - (z21) receive: DLE
1354762352179 - COM2 - (z22) receive: ETX
1354762352179 - COM2 - (z23) receive: BCC=[B0], is ok
1354762352179 - COM2 - (z23) sending: DLE
1354762352199 - COM2 - (z00) receive: STX
1354762352380 - COM2 - (z00) sending: DLE
1354762352380 - COM2 - (z00) receive: DE 
1354762352410 - COM2 - (z21) receive: DLE
1354762352410 - COM2 - (z22) receive: ETX
1354762352410 - COM2 - (z23) receive: BCC=[CD], is ok
1354762352410 - COM2 - (z23) sending: DLE

1354762362194 - COM2 - (z00) sending: STX
1354762364197 - COM2 - (z01) sending: STX, because QVZ is over
1354762366199 - COM2 - (z11) sending: STX, because QVZ is over
1354762368202 - COM2 - (z12) QVZ is over
1354762368212 - COM2 - (z12) After STX no DLE within QVZ-time. Unable to send the data. Please try again. Rejecting the data !!!
1354762388662 - COM2 - (z00) receive: STX
1354762388842 - COM2 - (z00) sending: DLE
1354762388852 - COM2 - (z00) receive: DD 
1354762388872 - COM2 - (z21) receive: DLE
1354762388872 - COM2 - (z22) receive: ETX
1354762388872 - COM2 - (z23) receive: BCC=[CE], is ok
1354762388882 - COM2 - (z23) sending: DLE
1354762388892 - COM2 - (z00) receive: STX
1354762389072 - COM2 - (z00) sending: DLE
1354762389072 - COM2 - (z00) receive: A2 01 
1354762389102 - COM2 - (z21) receive: DLE
1354762389102 - COM2 - (z22) receive: ETX
1354762389102 - COM2 - (z23) receive: BCC=[B0], is ok
1354762389102 - COM2 - (z23) sending: DLE
1354762389122 - COM2 - (z00) receive: STX
1354762389303 - COM2 - (z00) sending: DLE
1354762389303 - COM2 - (z00) receive: DE 
1354762389333 - COM2 - (z21) receive: DLE
1354762389333 - COM2 - (z22) receive: ETX
1354762389333 - COM2 - (z23) receive: BCC=[CD], is ok
1354762389333 - COM2 - (z23) sending: DLE

Also Senden geht and empfangen hängt.

Gute Nacht

Tbi

[NilsS]

Mmh, ich habe dirkt das Zipfile von hier genommen (weil ich mir den Client sparen wollte)

Hmm das ist ja komisch, das ist nicht aktuell oO

https://raw.github.com/knxuf/buderus...264_Buderus.py

das sollte immer das aktuelle aus dem git sein

EDIT:

oh fast vergessen updated und hoffenltich fixed

[NilsS]

Antwortet ein Gerät auf den Sendewunsch (Zeichen STX) seines Peripheriegerätes innerhalb der
Quittungsverzugszeit QVZ nicht mit der Quittung DLE oder NAK, sondern ebenfalls mit dem Zeichen STX,
liegt ein Initialisierungskonflikt vor. Beide Geräte möchten einen vorliegenden Sendeauftrag ausführen.
Das Gerät mit der niederen Priorität stellt seinen Sendeauftrag zurück und antwortet mit dem Zeichen
DLE. Das Gerät mit der höheren Priorität sendet daraufhin seine Daten in der vorher beschriebenen
Weise. Nach dem Verbindungsabbau kann das Gerät mit der niederen Priorität seinen Sendeauftrag
ausführen.

Wie sollen wir das machen? wer hat die höhere Priorität? wollen wir uns unterordnen und erst empfangen?