Ist bei mir genauso - und zwar erst wenn ich anfange viel auf dem Bus zu senden. Einziges echtes Problem dabei ist, dass manchmal der WW-Tank auf knapp 70° hohgeheizt wird. Habe noch nicht herausgefunden warum…
Dass es schlimmer wird, wenn gerade viel Action auf dem Bus ist, ist mir auch schon aufgefallen. Dass kann ich mir damit erklären, dass ich zwar mit dem SYN synchronisiert sende (also niemandem dazwischenfunke), es kann aber natürlich trotzdem sein, dass nach einem SYN mehrere sendebereit sind und gleichzeitig zu senden anfangen. Nur eigentlich sende ich immer mit der Absenderadresse 00, die laut Spezifikation die höchste Priorität hat, d.h. die anderen sollten dann eigentlich aufhören zu senden. Aber was weiß man…
Das erklärt aber immer noch nicht, warum unter normalen Bedingungen manchmal ein Byte falsch ist oder fehlt. Komisch ist, dass das Slave-ACK besonders oft fehlt. Ich werde nochmal mit dem Trimmer am eBus Koppler rumspielen und schauen, ob das eine Verbesserung bringt.
Danke, werde ich mal ausprobieren.
Werde ich auch so ähnlich machen (d.h. Zeitpläne auf einem Default lassen und dann per IPS die Temperatur, Betriebsmodus etc. am Regler einstellen), aber der Vollständigkeit halber möchte ich zu meinen Skripts auch eine Funktion zum Setzen der Zeitpläne hinzufügen, wenn ich’s hinkriege.
Genau dieses Problem hatte ich gerade auch zum ersten Mal!! :mad: 
Muss dem nachgehen…
Sorry, wenn ich diesen Thread hier zuspamme, aber ich habe gute Nachrichten:
Bzgl. der fehlerhaften Nachrichten, da habe ich einerseits meinen eBus Connector verbessert (neueste Version hier) und andererseits den Trimmer vom eBus Koppler justiert. Beides hat die Ergebnisse verbessert, sodass ich jetzt von knapp 20% fehlerhaften Nachrichten auf 8% runter bin. Die Fehler, die ich jetzt noch sehe, scheinen „legitim“ zu sein (und führe ich auf die Leitungsqualität zurück) und haben nichts mehr mit meinem Senden zu tun. Lustigerweise habe ich die Sache mit den fehlenden Slave-ACKs immer noch, aber das lässt sich ohnehin softwareseitig korrigieren.
Für das Problem mit der Überhitzung des Wasserspeichers habe ich - glaube ich - auch eine Lösung und zwar habe ich einfach das Drehrad an der Therme für die Wassertemperatur, anstatt von ganz am rechten Anschlag, auf die von mir gewünschte maximale Temperatur (bei mir 50°) eingestellt und das scheint die Temperatur zu begrenzen. Ich habe zum Testen den Regler abgekoppelt, damit ich den Brenner direkt und in Ruhe steuern kann. Der Speicher hatte eine Temperatur von 45°, am Drehrad an der Therme habe ich 55° eingestellt und dann habe ich dem Brenner den Befehl mit 60° Soll-Temperatur geschickt. Die Therme hat dann zu heizen angefangen, jedoch bei 55° von alleine aufgehört.
Das mit dem Setzen der Zeitfenster klappt übrigens auch. Danke für die Infos!
Ich schon wieder (jetzt aber zum letzten Mal - versprochen):
Nur zur Info, ich habe jetzt meine ganzen Skripts gepostet. Siehe hier.
Hallo,
vielen Dank für die Empfehlungen. Habe den eBus Koppler nun an eine vaillant geotherm vwl plus Luft/Wasserpumpe angeschlossen.
Gleichzeitig habe ich ich den eBUS Connector und den eBUS Manager installiert. Ich kann auch über den UDP Socket Daten empfangen. Allerdings komme ich mit der Adressierung noch nicht so recht klar. So wie ich das verstanden habe, muss ich die Adresse/n der Anlage beim Abfragen von Werten mitgeben. Hier gibt es eine Quelladresse und eine Zieladresse. Woher bekomme ich diese Adressen. Evtl kann mir das jemand an einem Datenmitschnitt kurz darstellen:
14.01.2013 10:30:28.00 | RECEIVED | 10 D0 B5 05 07 A5 FF 3F FE 10 E8 17 B4 BC FC FC 10 E8 17 D4 3F FF 00 FF 10 E8 07 D4 3E FE 10 E8 97 74 A8 00 E1 7E FC 10 0A DB 62 20 FE FF 10 08 4B 7C F8 B8 01 FF DF FE 10 88 4B 7C F8 B9 01 FF 00 FF 10 C8 4B 7C F8 0F 00 FF 00 10 E8 97 68 F8 77 80 CA FF 00 FF 10 E8 97 68 F0 03 EC FE 00 FF 10 E8 97 68 58 A0 FF 00 FA 10 D0 B5 04 FF F6 FC 10 A5 B5 04 FF 3F 1E FE FE F8 FA 10 25 B5 04 FE FF FF 00 EA 10 A5 B5 04 FF FF F8 F8 F0 F0 F0 FC FF 00 FA 10 25 B5 04 FF 3E FE 10 FE B5 05 FE D2 04 E8 4A 10 FE B5 05 03 FD
14.01.2013 10:30:36.00 | RECEIVED | 10 A5 B5 05 07 A5 3E FE 10 08 8B FC FC FC 00 FE 10 08 8B 2C 3F DF 00 FE 10 E8 83 F4 3F FF 10 E8 97 E8 A8 00 E1 7E FC 10 8A BB A2 E0 FE 00 09 00 02 86 FF 98 FF 07 00 00 A9 00 F0 10 23 B5 04 FF 3F 3E FE 3E 7E FC 10 23 B5 04 DC 3F 1F 3E FF FE 10 23 B5 04 F5 F8 F8 F0 F0 F0 FC FF 00 FA 7E 03 04 04 18 F8 47 FC 3E FC 7C 07 08 08 30 F0 10 FE B5 05 FC BA 0C F0 9A F7 10 FE B5 05 03 C1
Vielen Dank im voraus! 
Leider hat das das „Überhitzen“ das Speichers doch nicht gelöst, das kommt immer noch ab und zu (alle paar Tage mal) vor. Sehr komisch!
Was ich als Nächstes probieren werde (sobald ich dazu komme), wird sein, dass ich Ist- (B5 11) und Soll-Temperatur (B5 10) des Speichers überwache und sobald irgendwo etwas zu hoch wird, werde ich manuell einen Stopp-Befehl (ebenfalls mit B5 10) an den Brenner senden.
Das Format der Nachrichten ist QQ ZZ PB SB NN …
D.h. z.B. 10 A5 B5 05 07 A5 3E FE 10 08 8B FC FC FC …
QQ = Quelle = 10 = Regler
ZZ = Ziel = A5 = ???
PB = Primärbefehl = B5 = Vaillant-Befehl
SB = Sekundärbefehl = 05 = „Set Operational Data“
NN = Anzahl an Datenbytes = 07 = 7
usw.
Zum selber Senden kannst du als Quelle 00 nehmen (Computer), Ziel ist dann die Adresse des Teils, das du ansprechen willst (z.B. Regler, Brenner, …). Dabei ist zu beachten, dass meist als Ziel die Slave-Adresse (=Master-Adresse + 5) angegeben werden muss. D.h. 10 = Master vom Regler --> 15 = Slave vom Regler. Befehl vom Computer an Regler: 00 15 PB SB NN …
Mir kommen deine Nachrichten aber sehr lange vor. Bist du sicher, dass das in Ordnung ist? Vielleicht ist der Trimmer am eBus Koppler falsch eingestellt?
Erst einmal vielen Dank für deine Antwort. Worauf sollte ich beim Einstellen des Trimmers achten?
Bei mir blinkt die Data leuchte fröhlich vor sich hin. Gibt es denn typische Längen oder Längen die nicht überschritten werden sollten?
So habe jetzt nochmal an dem Trimmer gedreht und bekomme nun, meiner Meinung nach ordentliche Werte. Es klappt mittlerweile auch das Senden und Empfangen. Allerdings sind die Werte die ich nach dem Senden Empfange noch nicht so das gelbe vom Ei.
Ich würde mir zum Einstellen des Trimmers direkt den Datenstrom ansehen, z.B. mit hterm (eBus Connector vorher abstellen, im hterm einstellen, dass er bei AA eine neue Zeile beginnen soll).
So sieht das bei mir aus:
Das im Screenshot sind auch typische Nachrichtenlängen. In den Nachrichten steht außerdem ohnehin, wieviele Master- bzw. Slave-Daten-Bytes enthalten sind, also könnte man es auch genau nachzählen.
Bei mir - keine Garantie, dass es bei wem anderen gleich ist - verhält sich das mit dem Trimmer so (ich habe während des Einstellens den Datenstrom am Laptop mitverfolgt): Wenn ich ihn an den einen Anschlag drehe, wird nichts empfangen. Wenn ich ihn dann drehe, beginne ich zuerst die Nachrichten vom Regler zu empfangen (Absender 10). Wenn ich ihn weiter drehe, beginnen auf einmal die ganzen AAs über den Schirm zu flutschen, d.h. jetzt empfange ich auch die Therme. Das ist dann auch so ca. der Bereich in dem ich es eingestellt habe. Wenn ich dann noch weiter drehe, werden die Nachrichten fehlerhaft und wenn ich dann noch weiter drehe, empfange ich dann wieder gar nichts mehr.
Schwierig war, dass ich es zuerst in einem Bereich hatte, wo zwar alles empfangen wurde, ich im eBus-Manager dann aber eine hohe Fehlerrate hatte. Ich habe dann nochmal direkt mit hterm reingeschaut und von dort auch ein paar Testnachrichten gesendet, wobei ich gesehen habe, dass das, was er am Bus hört, ungleich war, als das, was ich gerade zuvor selbst gesendet habe. Habe dann wieder etwas mit dem Trimmer gespielt, sodass ich jetzt auch genau das höre, was ich auch sende und jetzt geht’s besser. In dem Bereich ist es nicht so einfach, weil die Nachrichten optisch ok aussehen und man erst den Inhalt anschauen muss, um zu sehen, ob es wirklich passt oder ab und zu mal ein Byte „umfällt“.
Ich habe jetzt eine Fehlerrate von knapp unter 8%. Vielleicht könnte man es noch besser einstellen, aber soweit funktioniert es für mich.
Könntest du mir deine hterm Konfig zur Verfügung stellen. Ich benötige die Einstellung für den Newline Character. Dieses „SYN“ gibt es bei mir nicht 
Super…bei mir ist auch alles soweit richtig getrimmt. Ich muss jetzt wie bei dir nur noch das Fine-Tuning vornehmen, da die gesendeten Strings nicht identisch mit empfangenen Strings sind.
Aber schon einmal vielen Dank für die Unterstützung!
Mittlerweile kann ich einige Werte ganz gut auslesen. Was mich nur verwundert ist folgendes:
Im eBus Empfänger Skript ist hinterlegt, dass Heizbetrieb, Warmwasserbetrieb usw. den Unterbefehl „01“ haben. Nun habe ich einige Zeit auf dem eBUS gelauscht und bei mir kommt kein Unterbefehl 01. Bei mir gibt es nur Unterbefehl 02 und 03. Liegt es vielleicht an einem unterschiedlichen Vaillant Heizungstyp?
Könnte gut sein, poste doch mal Beispieltelegramme.
Eine Frage an die Vaillant-Experten:
Ich kann die Quick-Veto-Temperatur („nur heute“-Temperatur) auslesen und setzen (HC1_QuickVetoTemp, Adresse 60 bzw. 3Ch). Das Problem ist, dass diese Temperatur nur übernommen wird, wenn Quick-Veto auch aktiviert ist. Wenn ich am Regler drehe, aktiviert sich das Quick-Veto und dann funktioniert auch das Ändern der Quick-Veto-Temperatur via eBus.
Nur leider funktioniert das Ein-/Ausschalten vom Quick-Veto via eBus nicht. Mein Regler VRT 370 scheint das entsprechende Flag (HC1_QuickVetoActive, Adresse 61 bzw. 3Dh) nicht zu unterstützen. Ich habe auch alle anderen Adressen, die irgendwas mit Quick-Veto zu tun haben könnten, probiert, aber auch ohne Erfolg.
Hat irgendwer eine Idee, was ich da noch probieren könnte (eine bestimmte Adresse oder überhaupt einen anderen Befehl)? Kann es wirklich sein, dass Vaillant gerade diesen einen Wert beim VRT 370 nicht implementiert hat?
PS: Weiß wer, ob es eine Variable vom Regler gibt, wo man auslesen kann, ob er sich im Tag- oder Nachtmodus (Sonne oder Mond am Display angezeigt) befindet? Momentan leite ich es mir indirekt her (wenn Soll-Temperatur = Soll-Temperatur Tag, dann Tag, wenn Soll-Temperatur = Soll-Temperatur Nacht, dann Nacht), aber kann man das vielleicht auch direkt auslesen?
Gab’s nicht den Parameter QuickVetoActive oder so?