Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Ankündigung
Einklappen
Keine Ankündigung bisher.
Umfrage: Interesse an Anbindung von Buderus Heizung an KNX
sorry ... aber der Javacode ist ein Haufen Schrott ... wenn der in 2 Jahren nicht mehr geht wird den keiner (ausser vllcht der Meister der ihn geschrieben hat) fixen können weil der so unsauber geschrieben ist wie lange schon nichtmehr gesehen
Mir sind auch die Augen rausgetreten, hatte ich Dir ja gesagt. Das ist eine komplette State-Maschine mit zig Zuständen. Echter Overkill.
Ich denke, wenn wir es so machen, wie im JAVA Code und wie ich es auch vorgeschlagen habe, dann sind wir auf der sicheren Seite.
noch einen den ich nicht gelesen hab .........
sorry ... aber der Javacode ist ein Haufen Schrott ... wenn der in 2 Jahren nicht mehr geht wird den keiner (ausser vllcht der Meister der ihn geschrieben hat) fixen können weil der so unsauber geschrieben ist wie lange schon nichtmehr gesehen
Das Problem ist hier beim RS232 Gateway, dass es eben so implementiert ist wie es ist. Wir können daran nicht ändern.
sorry hatte ich überlesen. ja das ist dann wohl leider so, aber die Spezifikation liegt doch in Buderus Händen. Es sollte dann doch nicht SOO schwer sein da eine klare Aussage seitens Buderus zu bekommen das es denn so ist und das irgendwo zu vermerken und gegebenenfalls konfigurierbar im Baustein zu machen. Aber sich einfach Zufallswartezeiten auszudenken die nirgends spezifieziert sind finde ich nicht wirklich sinnvoll.
Tobias, ernsthaft .... es geht doch nicht darum wie es funktioniert. dann kann ich das AC01 auch einfach ignorieren.
Es geht a) darum das das ja auch irgendwo im Protokoll stehen muss, ich kann mir doch nicht einfach meine eigenen Spezifikationen ausdenken
b) das stauen der Daten damit eigentlich ja nur im Sendepuffer sind, ich aber ja Daten auf den Empfangsbuffer senden will. Dort ist (wie bei allen anderen Packeten ja auch erfolgreich) das DLE zum AC<busnr> welches ja gesendet wird, aber vom RS232 wohl nicht ordenltich verarbeitet wird.
Was macht denn ads Gateway überhaupt da???
Es will unbedingt sein AC01 loswerden, doch wenn ich das einfach ignoriere, und danach mein DC sende dann passt alles, weil erst ab da ja der directmode verlassen wird und sich der sendepuffer der Geräte leeren kann.
Ich würde gerne nochmal ein Wireshark davon sehen, was denn von uns in welcher Reihenfolge gesendet wird. Dieser "Zufallstimeout" da krieg ich die Pest... schon alleine das es Zufall ist oO
Wenn der andere mit DLE geantwortet hat, sendet er ganz normal. Da ist ja auch keine Konflikt.
Der Code ist ja so
Code:
if Zeichen == STX) ## Konflikt
Warten (zufällig zwischen 0-5 Sec.)
versuche es neu
if Zeichen == DLE
sende meine Payload
Also er versucht es im Konfliktfall einfach immer neu.
Da jeder Teilnehmer ja einen Puffer hat, ist das auch kein Problem.
Befindet sich das RS232 Gateway z.B. im Direkt Mode staut es sich dort auch. Ist der Direkt Mode beendet kann man sehr schön sehen, wie dann der Puffer geleert wird (Es kommen sehr schnell Daten). (da war auch mein Problem beim tracen, das kam zu schnell) Danach purzeln die Daten wieder einer nach dem anderen raus.
Das Problem ist hier beim RS232 Gateway, dass es eben so implementiert ist wie es ist. Wir können daran nicht ändern. Offensichtlich versteht es nicht wenn im Konfliktfall ein DLE geschickt wird dieses als Bestätigung zum Senden. Es interpretiert das Zeichen als Fehlerhafte Übertragung (NAK oder beliebiges Zeichen!!!) und überträgt die Payload erneut. Ich halte das für eine fehlerhaft Implementierung im RS232. Ich habe aber keine Zeit das mit Buderus zu diskutieren. Wir können das aber jetzt nicht ändern.
Ich denke, wenn wir es so machen, wie im JAVA Code und wie ich es auch vorgeschlagen habe, dann sind wir auf der sicheren Seite.
Das funktioniert jedefalls zuverlässig.
Das RS232 Gateway wird ja auch wieder versuchen zu senden. Es wird so schnell also nicht verhungern
Dann geht es wieder.Ich denke as ist eine Implementierungsfehler im RS232 Gateway. Wer weiß ? Wenn jedoch man kein DLE schickt geht es wieder sauber.
Code:
for _loop in xrange(3):
## STX senden
self.debug("STX senden")
self.sock.send( self._constants['STX'] )
self.debug("STX gesendet / warten auf DLE")
## auf daten warten, timeout ist QVZ
_r,_w,_e = select.select( [ self.sock ],[],[], self._constants['QVZ'] )
## wenn kein timeout QVZ
if self.sock in _r:
# 1 Zeichen lesen
data = self.sock.recv(1)
## wenn wir ein DLE empfangen
if data == self._constants['DLE']:
self.debug("DLE empfangen")
## erfolg zurück
return True
## Wenn wir beim warten auf ein DLE ein STX der Gegenseite erhalten stellen wir unsere Sendung zurück und lassen das andere Gerät seine Daten erstmal senden
elif data == self._constants['STX']:
self.debug("STX empfangen Initialisierungskonflikt")
time.sleep(self._constants['ZVZ'])
## DLE senden, dass wir Daten vom anderen Gerät akzeptieren senden
# self.sock.send( self._constants['DLE'] )
# self.debug("DLE gesendet")
## eigentlich Funktion aus dem connect zum lesen der payload hier ausführen
# self.read_payload()
### danach loop und erneuter sende Versuch
else:
self.debug("%r empfangen" % (data,) )
self.debug("Nach 3x STX senden innerhalb QVZ kein DLE")
return False
Da ja das alles auch gepufferd wird, ist das egal, ob da ein zweites mal versucht wird.
#* Umschalttemperatur für Absenkart "Außenhalt" bei Ferienbetrieb 1° genau Stellbereich -20 bis 10 °C
Bit 8 auf 1 wäe in dem System logisch bei einer negativen 1-Byte Zahl.
Das probiere ich spätestens Freitag mal aus. Wieso sind die Daten nicht in der Konfiguration (0x89) ??? Wie überprüfen wir, ob der richtige Wert in der Anlage angekommen ist?
BTW: Mir ist es letztens nicht gelungen die Uhrzeit neu zu setzen, wie in der Doku beschrieben. Habe mit dem Terminal getestet. Quittiert hat er schon mit DLE, aber die Zeit an der MEC2 blieb gleich.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Einen Kommentar schreiben: