Umfrage: Interesse an Anbindung von Buderus Heizung an KNX

[tbi]

meeep,

also der 3964R_Send ist schon fettich und wupt auch schon durch den 3964R-Terminal erfolgreich durch.

Da geht ein DE sauber durch genauso wie ein A2 01 23 24 53 66. Ich weiß Mike, das ist im Sinne von Buderus Spinne aber es geht hier erstmal um 3964R und da wird nun nur noch ein "list_of_bytes" übergeben und der rest geht on the Fly.

Eigentlich sollte man nun das "list_of_bytes" mit dem Eingang 3 verbinden oder ?

Nils ich glaub jetzt brauche ich einen Zugang zum Git.

Gute Nacht

Tbi

[pmike]

Hallo Tbi,

Unserer Serverbaustein muß aber 3964R konform Payload empfangen sowie senden. Der Baustein muß also alle Payload empfangen können.
Erst, wenn er das sauber kann, geht es an die netten Buderus Infos

Das kommt mir sehr entgegen, da ich mit sauber abstrahierten Schichten besser umgehen kann. Dachte allerdings, dass dies aus Timing Gründen nicht vernünftig zu lösen ist.
Ich freue mich auf die nächste Testversion von dir und versuche mal bis dahin mit dieser Schlange warm zu werden. Seit Basic für die Z80 CPU kam ich mit tokenbasierten Sprachen nicht mehr in Berührung und das ist schon ein paar Donnerstage her.
Einrücken statt Klammern, typenlose Variablen, ... das wird sicher nicht einfach.

Viel Grüße
Mike

[tbi]

Ich habe das nur so nachgebaut wie MaPa das in seinem makebuderus.py gebaut hatte und dort hat er vorher halt auch auf "normal mode" geschaltet.

ansonsten mache ich nix anderes als er dort.

Ja, Nils. Aber er hat auch schon beide Schichten gemischt.

Wir sollten den Fehler nicht wiederholen.

Gruß Tbi

[tbi]

Hallo Mike,

deine Kritik an der 3964R Kapselung sehe ich noch nicht.

Das sind eben verschiedene Protokoll schichten. An die muß man sich halten, sonst wird man ganz sicher graue Haare kriegen. Wir sind mitten drin.

Bei mir kommt doch im Debugger der erste richtige Payload korrekt an:

HS Debug:
'Packet [165, 0, 0, 0, 6]'

ist das (Hex)-Gleiche wie im Terminal:
A5 00 00 00 06

Das ist ja nicht ausgeschlossen, dass das klappt.

Jedoch willst Du doch auch nicht, wenn du eine WWW-Seite aufrufts noch irgendwelche TCP befehle verwenden oder ?

Nur dass beim Baustein immer das gleiche Paket ankommt. Was ich mir nur so erklären kann, dass es entweder mit NAK oder gar nicht quittiert wird. Ich installiere mal den Drahthai.

Der Drahthai hilft immer beim sehen, jedoch sollten wir nicht den Fehler machen gleichzeit die Mauer zu maurern und zu verputzen. Es gibt bestimmt Künstler, die das können. Es ist jedoch nicht sehr praktisch.

Nehmt mir nicht böse, wenn ich so deutliche Worte verwende, aber ich habe Angst, dass es hier in die falsche Richting geht. Und unsere Zeit verbrennen wollen wir ja alle nicht.

Ich habe deinen Test nicht ganz verstanden, weshalb du z.B. ein DD an den Baustein schickst. Dieser Fall kann doch in der Realität nicht auftauchen, sondern immer nur vom Baustein zur Anlage. Oder doch?

Gut aufgepaßt. Ja auf der Buderus Ebene (Payload) macht das keinen Sinn .

Unserer Serverbaustein muß aber 3964R konform Payload empfangen sowie senden. Der Baustein muß also alle Payload empfangen können.

Erst, wenn er das sauber kann, geht es an die netten Buderus Infos

Ja, ist leider so, das 3964R ist schon eine ziemliche Hürde auf dem Weg dahin. Aber diesmal schaffen wir das. Der Server Baustein ist von der HS-Seite schon ganz gut. Er läuft im eigenen Thread, läßt sich gut debuggen und testen.

Das ist schon 'ne Menge.

Ich setze mich jetzt mal eine Woche hin und schreibe mal 3964R_Send und 3964R_Receive.

Nils vielen, vielen Dank !!!!!! ohne Dich hätte das sicher noch weitere vier Jahre gebraucht. Die Idee nach so einem Baustein ist nämlich nicht ganz neu

Nun kann man sich auch fragen, warum braucht es das 3964R ?

Damit Kollisionen verhindert werden ! Also es nimmt uns auch vieles ab.

Soweit erstmal

Tbi

[pmike]

Hi Nils,
ich habe ein "self.debug("NAK sent")" als Zeile 298 in den Timout Zweig eingefügt. Der kommt:

DEBUG: 'NAK sent'
DEBUG: "Packet ''"
DEBUG: "Packet 'A5 00 00 00 06'"
DEBUG: 'NAK sent'
DEBUG: "Packet ''"
DEBUG: "Packet 'A5 00 00 00 06'"
DEBUG: 'NAK sent'
DEBUG: "Packet ''"
DEBUG: "Packet 'A5 00 00 00 06'"
DEBUG: 'NAK sent'
DEBUG: "Packet ''"
DEBUG: "Packet 'A5 00 00 00 06'"

VG
Mike

[pmike]

Hallo Nils,
ich habe die Anlage über das Terminal in den erweiterten Modus gebracht, damit ich einen Definierten Ausgangszustand habe. Ansonsten ist durch den Wechsel Terminal-Baustein und zurück wohl kein nachvollziehbares Ergebnis zu erzielen.
Irgendwann ist die Minute um und dann kommte wieder das:

DEBUG: "Packet ''"
DEBUG: "Packet ''"
DEBUG: "Packet ''"
DEBUG: "Packet ''"
DEBUG: "Packet ''"
DEBUG: "Packet ''"
DEBUG: "Packet ''"
DEBUG: "Packet ''"
DEBUG: "Packet ''"
DEBUG: "Packet ''"
DEBUG: "Packet ''"
DEBUG: "Packet ''"
DEBUG: "Packet 'A5 00 00 00 06'"
DEBUG: "Packet ''"
DEBUG: "Packet 'A5 00 00 00 06'"
DEBUG: "Packet ''"
DEBUG: "Packet 'A5 00 00 00 06'"
DEBUG: "Packet ''"
DEBUG: "Packet 'A5 00 00 00 06'"
DEBUG: "Packet ''"
DEBUG: "Packet 'A5 00 00 00 06'"
DEBUG: "Packet ''"
DEBUG: "Packet 'A5 00 00 00 06'"
DEBUG: "Packet ''"
DEBUG: "Packet 'A5 00 00 00 06'"
DEBUG: "Packet ''"
DEBUG: "Packet 'A5 00 00 00 06'"
DEBUG: "Packet ''"
DEBUG: "Packet 'A5 00 00 00 06'"

Viele Grüße
Mike

[NilsS]

hab mal anzeige auf hex gesetzt und beim nak eine debug ausgabe eingefügt.

[NilsS]

Ich habe das nur so nachgebaut wie MaPa das in seinem makebuderus.py gebaut hatte und dort hat er vorher halt auch auf "normal mode" geschaltet.

ansonsten mache ich nix anderes als er dort.

[pmike]

Hallo Tbi,
deine Kritik an der 3964R Kapselung sehe ich noch nicht. Bei mir kommt doch im Debugger der erste richtige Payload korrekt an:

HS Debug:
'Packet [165, 0, 0, 0, 6]'

ist das (Hex)-Gleiche wie im Terminal:
A5 00 00 00 06

Nur dass beim Baustein immer das gleiche Paket ankommt. Was ich mir nur so erklären kann, dass es entweder mit NAK oder gar nicht quittiert wird. Ich installiere mal den Drahthai.

Ich habe deinen Test nicht ganz verstanden, weshalb du z.B. ein DD an den Baustein schickst. Dieser Fall kann doch in der Realität nicht auftauchen, sondern immer nur vom Baustein zur Anlage. Oder doch?

Viele Grüße
Mike

[tbi]

Hi Mike,

setze im 3964R-Terminal Trace und Loop und du siehst exakt die 3964R Schicht. Das was ich oben geposted hab ist genau von da.

So, ich habe mal vom Terminal ein DD auf den Logikbaustein geschickt:

Man sieht deutlich die drei STX ankommen, aber der Baustein erwartet Dez. 16 => hex 10 das ist das DLE. Das ist aber die Antwort auf das STX was der Baustein dann schicken muß.

Hier Sender seitig

1354454646978 - COM2 - (z00) sending: STX
1354454648991 - COM2 - (z01) sending: STX, because QVZ is over
1354454650994 - COM2 - (z11) sending: STX, because QVZ is over
1354454652997 - COM2 - (z12) QVZ is over
1354454652997 - COM2 - (z12) After STX no DLE within QVZ-time. Unable to send the data. Please try again. Rejecting the data !!!

Gruß Tbi

[pmike]

Hallo Nils,
das sieht schon besser aus:

Ausgabe: 0|0|0|0
Ergebnis: None
-------
teste Bedingung in Zeile 52: 'EI'
starte Formel: 'buderus_connect(locals())'
RunTime: 0.000355
Ausgabe: 0|0|1|0
Ergebnis: <__main__.buderus_connect object at 0x01AA0670>
-------
>> DEBUG: 'Request mode 222'
DEBUG: 'set mode accepted'
DEBUG: 'Normal Mode gesetzt'
DEBUG: 'Packet [165, 0, 0, 0, 6]'
DEBUG: 'Packet []'
DEBUG: 'Packet [165, 0, 0, 0, 6]'
DEBUG: 'Packet []'
DEBUG: 'Packet [165, 0, 0, 0, 6]'
DEBUG: 'Packet []'
DEBUG: 'Packet [165, 0, 0, 0, 6]'
DEBUG: 'Packet []'
DEBUG: 'Packet [165, 0, 0, 0, 6]'
DEBUG: 'Packet []'
DEBUG: 'Packet [165, 0, 0, 0, 6]'
DEBUG: 'Packet []'
DEBUG: 'Packet [165, 0, 0, 0, 6]'
DEBUG: 'Packet []'
DEBUG: 'Packet [165, 0, 0, 0, 6]'
DEBUG: 'Packet []'
DEBUG: 'Packet [165, 0, 0, 0, 6]'
DEBUG: 'Packet []'

Kann es sein, dass du den "A5 ..." Payload nicht mit einem DLE quittierst?

Wenn ich das Terminal benutze - 3964R sehe ich da auch nicht mehr sondern nur Payload - kommt das hier (Ohne, dass ich vorher Daten sende):

A5 00 00 00 06 
A7 01 82 02 1F 
A7 01 82 03 1F 
A7 01 83 02 2B 
A7 01 83 03 22 
A7 01 85 00 50 
A7 01 85 01 52 
A7 01 89 00 01

Das Terminal schickt wohl ein DLE auf das STX der Anlage.

Frag mich, was "A5 ..." bedeutet. Keine Ahnung, weil nicht dokumentiert!

Wenn ich ein DD erfolgreich versendet habe, ist für 60 Sekunden Ruhe auf dem Bus. Danach beginnt es wieder wie oben "A5...."
Sende ich während der Minute ein "A2 01" kommt das hier:

AB 01 82 00 80 02 20 2C 00 6E 
AB 01 82 06 00 00 64 9C 80 00 
..... weitere Konfigurationsdaten ...
AB 01 9A 2A 03 0C 01 10 21 0C 
AB 01 9A 30 01 6F AD 10 21 1C 
AB 01 9A 36 07 11 03 1C 07 6E 
AB 01 9D 00 6E 80 00 00 00 50 
AC 01

[tbi]

Hi,

also ein Senden eines DD als Payload sieht dann so aus:

1354452322005 - COM2 - (z00) sending: STX
1354452322376 - COM2 - (z01) receive: DLE
1354452322376 - COM2 - (z01) sending: DD 10 03 CE 
1354452322516 - COM2 - (z14) receive: DLE, i.e. data send successful

von der Empfängerseite aus gesehen:

1354452322125 - COM4 - (z00) receive: STX
1354452322496 - COM4 - (z00) sending: DLE
1354452322496 - COM4 - (z00) receive: DD 
1354452322496 - COM4 - (z21) receive: DLE
1354452322496 - COM4 - (z22) receive: ETX
1354452322496 - COM4 - (z23) receive: BCC=[CE], is ok
1354452322496 - COM4 - (z23) sending: DLE

Nun das ganze für ein DE

1354452613054 - COM2 - (z00) sending: STX
1354452613354 - COM2 - (z01) receive: DLE
1354452613364 - COM2 - (z01) sending: DE 10 03 CD 
1354452613564 - COM2 - (z14) receive: DLE, i.e. data send successful

vom Empfänger aus gesehen:

1354452322496 - COM4 - (z23) sending: DLE
1354452613144 - COM4 - (z00) receive: STX
1354452613324 - COM4 - (z00) sending: DLE
1354452613324 - COM4 - (z00) receive: DE 
1354452613494 - COM4 - (z21) receive: DLE
1354452613504 - COM4 - (z22) receive: ETX
1354452613514 - COM4 - (z23) receive: BCC=[CD], is ok
1354452613514 - COM4 - (z23) sending: DLE

Also nächstes ware ja ein A2 01 im Direkt mode dran.

Sender seitig:

1354452932863 - COM2 - (z00) sending: STX
1354452933194 - COM2 - (z01) receive: DLE
1354452933194 - COM2 - (z01) sending: A2 01 10 03 B0 
1354452933364 - COM2 - (z14) receive: DLE, i.e. data send successful

Empfangsseitig

1354452613514 - COM4 - (z23) sending: DLE
1354452932984 - COM4 - (z00) receive: STX
1354452933164 - COM4 - (z00) sending: DLE
1354452933164 - COM4 - (z00) receive: A2 01 
1354452933324 - COM4 - (z21) receive: DLE
1354452933324 - COM4 - (z22) receive: ETX
1354452933334 - COM4 - (z23) receive: BCC=[B0], is ok
1354452933334 - COM4 - (z23) sending: DLE

Darauf schickt dann das RS232 Gateway die Monitordaten. Da das bei mir noch in der Post ist, muß hier ein anderer helfen.

Aber es geht ja erstmal um 3964R. Und das sieht man hier ja super. Eben auch die BCC

Nachtrag: Das steht genau im ersten Dokument, was Mike angehängt hat.
Gruß Tbi

[pmike]

Hallo Nils,
das "DE" braucht es initial IMHO gar nicht und ich kenn auch nur "DC" zum Verlassen des Direktmodus, den die Steuerung nach spätestens einer Minute ohne Kommando im erweiterten Modus sowieso verläßt (Seite 5).

Wenn ich ein "DLE" auf ihr "STX" schicke, fängt sie auch gleich von Änderungen im Normalmodus zu erzählen an.

Für alle die jetzt den Faden verloren haben, noch mal der letzte bekannte Stand der Kommunikation von Buderus im Anhang.

Viele Grüße
Mike

[pmike]

Hallo Gaston,
so wie du es beschreibst, verstehe ich deine Verärgerung und es freut mich, dass wir jetzt wieder "on the same page" sind.

Hier muss ich nachhaken:

Ich denke aber dass der Markt nun eh dafür zerstört ist so dass ich es wohl nicht mehr veröffentlichen werde.

Wie kommst du darauf? Buderus hat nach jahrelanger Investition in Schnittstellen und dergleichen alles wieder zurückgefahren, da die Kunden, viele Heizungsinstallateure und der Regionalvertrieb von Buderus selbst damit nicht klargekommen sind und somit die immer höheren Preise für Buderus Regelungen auch nicht wirklich begründet werden konnten. Also ist aus der Ecke nicht viel zu erwarten, obwohl man ja zumindest eine Erweiterung des EIB Moduls mit mehr Daten recht einfach herstellen könnte.
Die Leute, die hier in dem Board unterwegs sind, stellen einen Bruchteil deiner möglichen Kunden dar (E-Handwerk, Planer, ...). Vielmehr sind es doch die Kunden der Leser dieses Forums (Häuslebauer, Zweckbauer, ...). Diese wiederum dürfte der Disput wenig interessieren, sollten sie überhaupt davon erfahren. Die zahlen lieber, gerade weil sie einen Hintern wollen, in den sie treten können, wenn etwas nicht richtig funktioniert. Diese Hintern gehören zwar an vorderster Front wieder genau zu denen, die hier mitlesen und deine Bausteine implementieren. Doch das ist schlimmstenfalls ein kleines Handicap, aber ganz sicher keine Beeinträchtigung deiner Reputation hier. Diesen Vertriebskanal hier kannst du eh nur mit Qualität des Produktes und einfacher Handhabung überzeugen. Zugegeben, es gehört auch etwas Marketing zum Erfolg.

Wie sehen das eigentlich die anderen Interessenten der Logamatic Anbindung, die von der Programmierung diverser Logikbausteine genauso wenig Ahnung haben wie ich?

Viele Grüße
Mike

[tbi]

Hi Nils,

Was sollte das TCP connect zum Moxa mit dem STX etc zu tun haben? Der Status der seriellen Verbindung ist unbekannt, daher sende ich erstmal die Anforderung zum "normal Mode". Danach wird dann empfangen. Das sollte eigentlich schon so passen

Das :

          MODE_NORMAL = 0xDE
          MODE_DIRECT = 0xDD

ist schon Buderus PayLoad und hat noch nichts mit 3964R zu tun.

Beispiel für einen fehlerlosen Datenverkehr: bei Empfang
Prozedur 3964R                        Peripheriegerät
                               <--                 STX
       DLE                    -->
                                <--          1. Zeichen  (Könnte ein 0xDD) sein
                                <--
                                <--
                                <--           n. Zeichen
                                <--               DLE
                                <--               ETX
                                <--               BCC
      DLE                     -->

Das ist genau das Signalspiel. Senden ist eigentlich nur umgekehrt.

Aber der Aktuelle Code schickt gleich ein DE raus, kann nicht gehen.

Ich werde jetzt mal mit dem 3964R-Terminal Das Verschicken von DD oder DE mal aufzeichen. Mal von beiden Seiten aus gesendet.

Dann wird das klarer.

@Mike: Ich denke da das 3964R noch nicht geht, kommt bei dir der Fehler. Der Bebugger läuft jedenfalls mit dem Baustein hoch und versucht was zu machen.

Gruß Tbi