LAN-Anbindung für BSB-Bus (Brötje, Elco Thision etc.)

[sust]

Noch eine Ergänzung zu meinem Beitrag:
Der "irgend jemand" der einen falsch zum Kessel 0 gesendeten Wochentag "irgendwann" mal korrigiert ist das Bediengerät, das bearbeitet ein Datum Zeittelegrammetwas anders als der Kessel. Und korrigiert einen falschen Wochentag sofort.
Gibt es nicht ein (un)regelmäßiges inf/broadcast vom Bediengerät? Damit wird dann auch
der Fehler im Kesseldatum korrigiert. Kommt es zufällig zwischem dem Setzen des 0er und einer Abfrage, ist man verblüfft....

Und ja freetz, ich hab deine Frage nicht richtig beantwortet.
Deine Frage zu den Wochentagsblöcken: Ich hab nichts dazu gefunden. Im Antworttelegramm zum 0er wird nur der aktuelle Wochentag geliefert.
Ob man über noch unbekannte "flags" da etwas abfragen/steuern kann müsste noch geklärt werden....Wenn man mag.

[freetz]

Ja, es gibt einen unregelmäßigen Broadcast mit der Uhrzeit und Datum, ich weiß aber aus dem Kopf nicht mehr, wer das sendet, aber in dem Fall macht es wohl Sinn, dass es das Display ist.

Was genau meinst Du mit "Im Antworttelegramm zum 0er wird nur der aktuelle Wochentag geliefert"? Welches Antworttelegramm meinst Du da genau?

Ich bin die Tage nicht vor Ort an der Therme, aber könnte mal jemand loggen, ob es unterschiedliche Telegramme gibt, wenn man die Parameter 1, 2 oder 3 getrennt voneinander ändert? Vielleicht kriegen wir da die noch offenen Flags raus. Ansonsten muss man es mit Ausprobieren versuchen, es scheint ja irgendwie aufsteigend etwas zu sein, denn 0x16 und 0x17 sind für mich sonst nicht besonders aussagekräftig...

[sust]

@ freetz deine Frage:

Was genau meinst Du mit "Im Antworttelegramm zum 0er wird nur der aktuelle Wochentag geliefert"? Welches Antworttelegramm meinst Du da genau?

sollte eigentlich noch die Frage von dir einen Beitrag davor beantworten:

Was meinst Du mit "Wochentag"? Sowas wie "Mo" bis "So" wird doch nur bei PPS-Systemen geführt, bei BSB/LPB rechnet die Therme das ja intern automatisch um. Oder welchen Parameter meinst Du?

Es gibt in der DateTime Parameterbearbeitung (0,1,2,3er Heizungsparameter) keinen Platz für Wochentagsgruppen, eben nur eine Stelle für den" aktuellen" Wochentag (im Gesamttelegramm die 7.Stelle von rechts.)
Das Antworttelegramm auf 'Y06,0505000B'(mein 0er) war gemeint.
Da sieht man dann als Hex-Zahl alles was der Parameter zu bieten hat. Ich stell dazu in einem Extra Beitrag mein Probieren von gestern und heute morgen ein. Das kann man dann auch als Handlungsvorlage für eigenes Probieren nehmen..

Das mitloggen der 1,2 und des 3er Heizungsparameter geht nicht. Wird wohl nur im Bediengerät verhandelt.
Wenn man da was erforschen will, bleibt nur das probieren...

[freetz]

Ok, Antworttelegramme gibt es ja auf QUR (Abfrage) und SET-Telegramme, von daher war mir nicht klar, auf was Du Dich da genau beziehst. Aber jetzt ist es klar, auch, dass es bei 1,2 und 3 keine Telegramme gibt. Dann wird alles über das 0er-Telegramm verhandelt, bzw. über die herausgefundenen Abweichungen von VT_SUMMERPERIOD.
Wenn es da also keine genaueren Infos dazu gibt, kann ich da auch nichts umsetzen, bzw. ist mir persönlich die Relevanz zu gering, als dass ich mich da auf die Suche machen würde. Denn gerade die Uhrzeit alleine einzustellen wäre ja etwas, was man auch mal brauchen könnte. Das Datum wird man ja eher selten bis nie verstellen (müssen)...

[sust]

Das du das alles machen sollst will ich auch nicht.
Evtl. können doch aber auch mal andere User sich mal auf die Suche machen.

Oder?

[sust]

Es ist ja festgestellt worden, das die Heizungsparameter 0,1,2,3 (case VT_DATETIME) 5 u. 6(VT_SUMMERPERIOD) sowie 632,633 u.w (VT_VACATIONPROG) vom Telegrammaufbau her identisch sind.
die Anzahl der Eingabedaten sich aber stark unterscheiden.
Die Steuerung dafür scheint durch die letzte Stelle im payload geregelt zu werden.
BSB_ lan spricht diese Stelle über 'param[8]= x 'an.
Für den Heizungsparameter 0 lautet er: param[8]=0x00 und damit wird der gesamte Datum/Zeit Datensatz in der Heizung von Jahr bis Sekunde gesetzt.
Für den Heizungsparameter 5 lautet er: param[8]=0x16 und damit wird allein das Datum gesetzt.
Die 1. Frage die man sich stellen könnte ist was passiert wenn ich die 0x16 im BSB_lan für den Heizungsparameter 0 verwende?
Das hab ich in meiner V0.44 gemacht und zeige euch hier das Ergebnis.
Die Darstellung kann , wenn ihr die V0.44 nicht mehr verwendet, etwas abweichen. Im Prinzip ist es aber identisch.

Als erstes musste ich die Änderungen in den Mega flashen
dann hab ich mit dem Befehl P0,66,0 als Adressat den Kessel eingestellt.

1.Browser -Befehl
http://<ip>/Y06,0505000B
das Antworttelegramm dazu:
0 Uhrzeit und Datum - Datum/Zeit: 30.03.2021 06:01:37
DC C2 00 0B 06 05 05 00 0B 6A 8B
DC 80 42 14 07 05 05 00 0B 00 79 03 1E 02 06 01 25 01 D5 93

2.Browser Befehl( ein komplett abweichender Datensatz):
http://<ip>/S0=18.12.2020_03:30:33

3. Browser Befehl(Überprüfung):
http://<ip>/Y06,0505000B
ergibt Antworttelegramm:
0 Uhrzeit und Datum - Datum/Zeit: 18.12.2021 06:02:28
DC C2 00 0B 06 05 05 00 0B 6A 8B
DC 80 42 14 07 05 05 00 0B 00 79 0C 12 02 06 02 1C 00 A2 E5

Wie man sieht, ist nur der Kalendertag und der Kalendermonat gesetzt worden Der Rest nicht. 2 Stellen im Telegramm sind noch interessant: Die 7. letzte Stelle von rechts: Wert 02--das ist der Wochentag 02- Dienstag passt zum 30.03 aber nicht zum 18.12. (06)
und die 3. letzte Stelle von rechts: 01 und dann 00. Das ist das Sommerzeitflag. und scheint neu gesetzt worden zu sein. Dagegen hab ich nichts.

Dann hatte ich noch Mit P0,66,10 das Display/Bediengerät adressiert.
Hier die Ergebnisse

1. Browserbefehl:
http://<ip>/Y06,0505000B
das Antworttelegramm dazu:
0 Uhrzeit und Datum - Datum/Zeit: 29.03.2021 18:20:54
DC C2 0A 0B 06 05 05 00 0B 99 C5
DC 8A 42 14 07 05 05 00 0B 00 79 03 1D 01 12 14 36 01 7C 90

2.Browserbefehl
http://<ip>/S0=18.12.2020_03:30:33

3.Browserbefehl:
http://<ip>/Y06,0505000B
Antworttelegramm dazu:
0 Uhrzeit und Datum - Datum/Zeit: 18.12.2021 18:21:32
DC C2 0A 0B 06 05 05 00 0B 99 C5
DC 8A 42 14 07 05 05 00 0B 00 79 0C 12 06 12 15 20 00 DA 6A

Es ist alles so wie oben nur der Wochentag ist weder passend für den 29.03.21(01) noch dem Set Befehl 18.12.2020(05,) kann daher nicht vom  S0 Telegramm kommen, sondern ist vom Bediengerät neu für den 18.12.2021 (06) berechnet worden.
Blöd ist nur das eine evtl. Setzung auf 05 nicht mehr zu erkennen ist. Man sollte also immer den Heizkessel als Adressaten nehmen und nicht das Bediengerät.

Aber gibt es nicht einen Zeitabgleich zwischen Kessel und Bediengerät?
Ja man muss im 1. Testfall nur lang genug warten dann wechselt der Wochentag von 2 auf 6....(abfragen mnuss man das natürlich)
Soll heißen, bei Wechsel des Wochentages vom 1. zum 3. Browserbefehl sollte man sofort einen neuen Versuch starten. Denn der Abgleich wiederholt sich erst nach mehreren? Minuten  Ist der Abgleich für den Wechsel verantwortlich, erkennt man das beim 2. zeitnahen Versuch.

Jetzt könnte man natürlich fragen verwendet das Bediengerät für das Setzten des Monats und Tages  dieselbe Softwareroutine die wir adressiert haben oder haben die Entwickler nochmal was völlig neues gezaubert?
Ich würd sagen nein, das Bediengerät benutzt exakt die Softwareroutine die wir auch adressiert haben. Und für das Jahr oder Datumskombinationen? und was ist mit der Zeit?  Auch nicht, mein ich. Da müsste man wohl auch nur nach suchen, dann findet man das.
Wenn man will. Und sei es nur Just for Fun. 

[freetz]

Danke für Deine ausführliche Recherche, sust! Da hast Du ja einiges herausgefunden, prima!
Verstehe ich das richtig, dass es dann beim letzten Payload-Byte von VT_DATETIME nicht nur um die 0x00 geht, sondern dass es auch 0x01 sein könnte, was dann die Sommerzeit wäre? Ich vermute, dass ein falscher Eintrag hier dann auch wieder von der Bedieneinheit korrigiert wird?

Was ich nicht ganz verstehe: Wenn Du das Bediengerät ansprichst und auf den 18.12.2020 setzt, warum steht da dann in der Abfrage darauf der 18.12.2021? Und beim Wechsel des "Wochentag von 2 auf 6" frage ich mich, wo da jetzt die 2 her kommt? Oder ist das ein Tippfehler?

Für das weitere Experimentieren habe ich den /Y Befehl so erweitert, dass man nun auch eine Payload mitsenden kann, was für das Setzen von Parametern hilfreich sein kann. sust, Du kannst ja mal schauen, ob sich diese Änderungen halbwegs direkt in Deine 0.44 integrieren lassen:
https://github.com/fredlcore/BSB-LAN/commit/0e0fa7a2f1fa494cc8c76514676167e543b171d7#diff-228b1d315444a8461515ac5c0f97909b36aee0b7e5849a717da1c7348fbad5bc

Dann sollte ein Aufruf wie z.B. dieser hier:
/Y03,2D3D058E,010540
Die Komforttemperatur in HK 1 auf 21 Grad stellen.
Das erste Byte hinter dem zweiten Komma ist das Enable/Disable-Flag (entweder 01 oder 06, nachzusehen in der optbl[] , 4. Spalte, in der _defs.h), danach folgt die eigentliche Payload (hier: 0x0540 = 1344 / 64 = 21 Grad). Bei der Uhrzeit wäre das Enable-Flag auch 01, dahinter dann die Parameter wie in VT_DATETIME bzw. VT_SUMMERPERIOD beschrieben.

Wie wir das Datum alleine setzen, hat sust ja schon herausgefunden. Wenn man jetzt wissen will, wie die Uhrzeit geschrieben wird, müsste man die nicht genutzten Felder auf FF setzen und beim letzten Payload-Byte dann ausprobieren, welcher Wert dann dazu führt, dass dann auch nur die Uhrzeit übernommen wird, bzw. kein Fehlertelegramm kommt (zu erkenenn an einer 08 an fünfter Stelle).

Was die Bedieneinheit angeht, denke ich, dass diese einfach immer die komplette Uhrzeit an die Heizung und andere Interessierte übermittelt. Da wird vermutlich nichts einzeln an Bestandteilen gesendet. Trotzdem könnte es sein, dass über das letzte Byte (param[8]) eine allgemeine Steuerung möglich ist, weil diese ja für VT_SUMMERPERIOD und andere Parameter gebraucht wird.

[Hawwk]

Hallo,

ich bekomme folgende Fehlermeldung beim Hochladen des Skets auf den Arduino:

sketch\src\ArduinoMDNS\MDNS.cpp: In member function 'int MDNS::begin(const IPAddress&, const char*)':
sketch\src\ArduinoMDNS\MDNS.cpp:150:27: error: 'class UDP' has no member named 'beginMulticast'
  statusCode = this->_udp->beginMulticast(mdnsMulticastIPAddr, MDNS_SERVER_PORT);
                           ^
exit status 1
Fehler beim Kompilieren für das Board Arduino Due (Programming Port).

Kann mir vielleicht jemand beim dem Problem helfen?

[sust]

Moin,

@freetz danke erstmal für Erweiterung des Y Befehls. Ich brauche allerdings ein wenig Zeit das zu verstehen und testen. Meld mich aber bestimmt.

zu deine Fragen/Anmerkungen:

Verstehe ich das richtig, dass es dann beim letzten Payload-Byte von VT_DATETIME nicht nur um die 0x00 geht, sondern dass es auch 0x01 sein könnte, was dann die Sommerzeit wäre?

Ja, ich vermute das es 256 Möglichkeiten ein Steuerflag zu setzen gibt...Das die einer allein durch flashen testet ist "unmenschlich". "Solidarität" und "Brüderlichkeit" ist jetzt gefragt...
Nein, es ist nicht auch ein An/ Aus Knopf für die Sommerzeit, sondern eine Anweisung zur Bearbeitung von davor gelieferten Daten.
Das Plätzchen für An/Aus ist ja auch nicht nötig, denn es wird ja über die Heizungsparamter 5 u. 6 geregelt.
In dieser Form seh ich das hier allerdings bewusst auch zum 1. Mal.
Das ein Antwort- vom  Befehls-Telegramm abweicht kennen wir aber schon, denk mal an die Aktivierungs "6" für die Ferienzeit. Fragt man ab bekommt man die "1" am Platz der "6"geliefert. 
Fragt man den 0er ab, wird der Platz von einem Statuswert genutzt. Ist doch aber irgendwie auch  sinnvoll? oder?

Ich vermute, dass ein falscher Eintrag hier dann auch wieder von der Bedieneinheit korrigiert wird?

Das braucht das Bediengerät ja nach dem oben Gesagten nicht tun, weil man ja "Bearbeitungsanweisungen" für die gelieferten zu setzenden Daten und einem "Status" im Antworttelegramm unterscheiden kann.

Wenn Du das Bediengerät ansprichst und auf den 18.12.2020 setzt, warum steht da dann in der Abfrage darauf der 18.12.2021?

Weil das Flag 16 nur den param[2] und [3] verarbeiten lässt. der Rest z.B. param[1]ist egal.

nd beim Wechsel des "Wochentag von 2 auf 6" frage ich mich, wo da jetzt die 2 her kommt? Oder ist das ein Tippfehler?

Du beziehst dich wohl auf den 1. Test da war das Ausgangsdatum der 30.03.2021 ein Dienstag ="2"   
Dieser wird auch wegen dem Flag 16 nicht geändert. Erst die Logik des Bediengerätes ändert die dann.Der 18.12.2021 ist ein Samstag  ="6". 

Nein es ist kein Tippfehler, denn ich hab das was ich am Besten kann angewendet: 'copy und paste' 

....Wenn man jetzt wissen will, wie die Uhrzeit geschrieben wird, müsste man die nicht genutzten Felder auf FF setzen und beim letzten Payload-Byte dann ausprobieren....

Ja das ist ein Weg zum testen. Wobei man auch 23:59:59 oder 24:60:70 oder 99:99:99 setzen könnte .Die Heizung macht aus allem 23:59:59 Und dies auch aus "FF"
Wobei FF in der V0.44 verweigert wird wenn man den S0 zum testen nimmt.
Ich rate aber davon ab, weil sofort ein Überlauf erfolgt. Der verwirrt nur. Irgendein anderes Datum/Zeit Konstrukt was aber vom Ausgangswert komplett abweicht, ist besser.

Was die Bedieneinheit angeht,.... Da wird vermutlich nichts einzeln an Bestandteilen gesendet....

Ja, das seh ich auch so.
Das Macht Der Kessel 0 aber auch. Nur das er auch falsches annimmt und weitergibt.

Trotzdem könnte es sein, dass über das letzte Byte (param[8]) eine allgemeine Steuerung möglich ist, weil diese ja für VT_SUMMERPERIOD und andere Parameter gebraucht wird.

Ja, da stimm ich zu. Das Motto zur Zeit  könnte lauten "Testen, testen, testen...."
Mit einem relevanten Ergebnis könnte freetz dann BSB_ lan "impfen". 
Da meine V0.44 nicht mehr geimpft wird, muss die wohl dann in Quarantäne .....

[freetz]

Ich vermute sehr stark, dass param[8] dennoch ein Flag für Sommer- und Winterzeit ist, denn bei einer Abfrage hat das Telegramm ja genau diese Funktion. Und mir ist kein Telegramm bekannt, wo in der Payload die gleiche Stelle unterschiedliche Funktionen hat. Parameter 5 und 6 sind m.E. dafür da, dass die Therme automatisch selber diese Umstellung vornehmen kann, ohne dass dafür ein extra Telegramm gesendet werden muss. Aber letztlich ist das ja auch nicht wirklich praktisch relevant.
Das, was Du mit "1" und "6" meinst, verstehe ich nicht richtig, vermute aber, Du meinst das Enable/Disable Byte, das 0/1 oder 5/6 sein kann. Das ist ja aber nicht eigentlicher Teil der (Daten-)Payload.

Wer die neue Version installiert hat, kann vom Prinzip her relativ einfach mit einem Script zuerst über /Y mit einem bestimmten Flag z.B. nur die Uhrzeit setzen und dann wieder abfragen, um zu sehen, was sich geändert hat. Dann enifach das Flag um eins inkrementieren und wiederholen. Damit sollte man die 256 Varianten schnell durch haben.

[freetz]

Hallo,

ich bekomme folgende Fehlermeldung beim Hochladen des Skets auf den Arduino:

sketch\src\ArduinoMDNS\MDNS.cpp: In member function 'int MDNS::begin(const IPAddress&, const char*)':
sketch\src\ArduinoMDNS\MDNS.cpp:150:27: error: 'class UDP' has no member named 'beginMulticast'
  statusCode = this->_udp->beginMulticast(mdnsMulticastIPAddr, MDNS_SERVER_PORT);
                           ^
exit status 1
Fehler beim Kompilieren für das Board Arduino Due (Programming Port).

Kann mir vielleicht jemand beim dem Problem helfen?

Ich tippe auf eine veraltete Ethernet-Library, mehr kann ich aber auch nicht sagen, weil nicht klar ist, ob Du den Arduino über LAN oder die WLAN-Brücke anbindest, etc. Wenn das Problem bestehen bleibt, dann bitte das komplette Protokoll (in Code-Tags) hier posten.

[sust]

Ja, freetz, das mit dem Flag für Summerperiod könnte so sein wie du das siehst.
Ich wollte darauf hinweisen, das es eigentlich nicht nötig wäre ein Flag für Summerperiod im Sendetelegramm zu haben. Weil es meiner Meinung nach "doppelt gemoppelt" wäre
Das ich es für unwahrscheinlich halte, heisst nicht das es absolut  100% sicher so ist.

Wissen tun wir es erst, wenn getestet.

Ein Indiz gegen das Summerperiodflag hab ich noch.
Schau dir mal den 1.Test nochmal an. Da kippt ja das Summerperiodflag von 1 nach 0. Ohne direkte Setzung.  Adressat war ja der Kessel.
Wenn wir jetzt das mögliche Summerperiod Flag mit param[8]=0x01 setzen würden, müsste dann nicht die Kessellogik den sofort wieder auf 0 setzen wenn es aktuell der 18.12.2021 wäre?
Ist natürlich nur ein Indiz. Absolut ist das nicht...

Was meinst du mit unterschiedliche Funktionen gibt es nicht?
Ein elektronischer Lichtschalter hat für mich eine einheitliche Funktion, ich setz die "1" und bekomm die "1" bei Abfrage zurück.
Beim 0 er mit paramn[8]=16 geb ich die Anweisung "setz das Datum"
und bekomm auf Nachfrage zurück "es ist Winterzeit" (positionsbezogen verglichen). Da wird doch ein Status zurückgemeldet der direkt mit dem Befehl positionsbezogen nichts zu tun hat.
Oder versteh ich deinen Funktionsbegriff nicht richtig?

Ja, genau das meinte ich mit der 1 und 6 genauso wie du das interpretiert hast.

Ich versuch mal dem Link der letzten Mail zu folgen, mal sehen was ich da schaff.

[freetz]

Ich habe gerade mal getestet, indem ich Parameter 5 mit param[8] auf 0x17 geschrieben habe. Das ging problemlos durch und hat das neue Sommerzeit-Beginn-Datum gesetzt. Möglicherweise hat dieser Parameter eine Funktion, aber zumindest für das Setzen eines reinene Datums macht 0x16 und 0x17 keinen Unterschied.

[sust]

Dann könnte man  den Parameter 632 evtl. mit 0x16 auch zum Verstellen des Ferienzeit Beginns nutzen.

Das mit der identischen Funktion gibt es mindestens nocheinmal: Ich hab für den Parameter 0 mit param[8] = 0x01  auch alles von Jahr bis Sekunde verändern können.
Allerdings musste ich die V0.44  dafür flashen.
Deine Software-Änderungen für den Y Befehl konnte ich mit meinen Kenntnissen nicht in der V0.44 unterbringen. Das ist sehr schade, denn ein Y-Befehl der setzen kann wäre toll.

[freetz]

Das mit 0x01 würde ja zumindest mit meiner Annahme gehen, wenn das das Sommerzeit-Flag ist. Interessant wäre es, ob es auch mit 0x16 und 0x17 klappt.
Was die 0.44 angeht: Wenn Du nicht auf den Due bzw. die neue Platine wechseln willst, kannst Du ja auch einfach einen NodeMCU ESP32 für ein paar Euro besorgen, wenn WLAN grundsätzlich kein Hinderungsgrund ist. Dann kannst Du die alte Platine fliegend verkabeln und trotzdem an den Neuerungen teilhaben. Denn es ist inzwischen nicht nur wegen des Flash-Speichers, sondern auch wegen des RAMs so, dass der Mega keine Funktionsupdates mehr bekommen kann.

EDIT: Sorry, Du hattest ja schon geschrieben, dass man mit dem 0er Parameter und dem Flag 0x16/0x17 nur das Datum setzt.