Umfrage: Interesse an Anbindung von Buderus Heizung an KNX

[Gaston]

Hallo Gaston,
ich wollte dich nicht belehren und es tut mir leid, wenn das so bei dir ankam. Es war nur der etwas provokante Versuch, dich entweder dazu bringen Nils zu helfen und/oder deine Version weiter zu verfolgen.

Ist im prinzip kein problem aber bei diser Sache bin Ich eh schon auf Hundert da liegen die Nerven etwas blank. Das hat natürlich nichts mit Dir zu tun.

Ich weiß natürlich nicht, wie MaPa dir sein Projekt vorgestellt hat und was ihr besprochen habt, dass du gleich das Handuch geworfen hast.

Das ist der springende Punkt. Ich hab das Projekt eingestellt weil es mir im July so vorgestellt wurde dass es sofort veröffentlicht werden könnte. Somit war es meinem Projekt etwas voraus und soweit Ich das beschrieben bekommen hab im Aufbau ähnlich.

Ich vermutete - in meiner Wahrnehmung - ein typisches Kommunikationsproblem:

Ja, aber leider hast du "Wahrnehmungsproblem" gesagt. Das Wahrnehmungsproblem is in meinen Augen immer ein Fehler des "Empfängers", ein Kommunikations Problem kann aber an beiden Enden der Kommunikation seinen Ursprung haben.

Naja, wie gesagt, da liegen die Nerven zur Zeit etwas blank

Revidierst du nun deine Entscheidung noch mal? Wenn ja, in welche Richtung (OSS oder Kaufbaustein)?

Das steht noch nicht fest aber Ich denke aber dass der Markt nun eh dafür zerstört ist so dass ich es wohl nicht mehr veröffentlichen werde. OSS kommt aus verschiedenen Gründen nicht in betracht.

Gruss,
Gaston

[tbi]

So Nils,

hab es nun zum Laufen bekommen.

Also der erste Durchstoß auf der Teststrecke war da. Aber es stimmt noch was nicht.

Im Moment willst Du im Baustein ja gleich im Connect schon was absetzen. Das gehört da nicht hin. Daten Bytes und 3964R muß klar getrennt bleiben.

Es gibt nur die beiden Proceduren 3964R_Send und 3964_Receive.

Nur dort kann es STX, DLE, NAK, .. geben. Sonst nirgends.

Also wenn das TCP connect erfolgt ist, kann es nur zwei Ereigisse geben.

Entweder jemand hat was auf den "Send" Eingang gelegt, dann wird das was da anliegt 3964R konform gesendet oder es wird 3964R konform auf dem Draht gelauscht, ob was kommt. Wenn was gekommen ist, wird die PayLoad dann nach "Data" rausgepustet. .... und soweiter.

Ich muß aber mal genau bei mir auf den Draht schauen (WireShark), was da nun wirklich rüber geht. Ich vermute da kommt noch etwas mehr mit als soll. In so einem Moxa (hier Xport) kann man viele Parameter einstellen.

So, jetzt kann ich jedenfalls richtig testen.

Der Debugger ist toll. Hab ihn nun zum ersten Mal benutzt.

Gruß Tbi

[NilsS]

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

[pmike]

Hallo Nils und Tbi,
danke für die Anleitung. Jetzt bin ich schon ein gutes Stück weiter. Allerdings fällt es nach Empfang des DLE auf einen Fehler (Zeile 232). Eine Zuweisung für "msg" kann ich nicht sehen, aber das mag daran liegen, dass ich nur mit typisierten Programmiersprachen halbwegs klarkomme. Bin noch im Python-Anfänger-Modus.

@Tbi: Bist du da schon weiter? Ich denke für Nils ist es ohne reale HW extrem schwierig.

Viele Grüße
Mike

[NilsS]

fixed versuchs jetzt nochmal, hatte msg statt _msg geschrieben

[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

[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

[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

[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 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 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 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

[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.

[NilsS]

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

[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