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

[freetz]

So, ich habe jetzt ein paar ausprobiert, mit 0x08 bzw. 0x18 sollte sich nur die Uhrzeit veränern. Könntest Du das mal gegenprüfen, sust?

[sust]

Moin,

Die Wirkung des  param[8]=0x00 oder param[8]=0x01 beim Heizungsparameter 0 war nach meinen Versuchen identisch, das gesamte Datum und die gesamte Zeit wurden übernommen, das Sommerzeitflag wurde je nachdem ob das Datum innerhalb oder außerhalb des mit dem Heizungsparameter 5 und 6 gesetzten Zeitraums lag, gesetzt oder gelöscht.

Die Wirkung des param[8]=0x16 beim Heizungsparameter 0 hatte ich ja schon mal getestet. Es wurde immer nur das Datum übernommen, der Rest nicht. Fiel das gesetzte Datum in den Sommerzeitraum, wurde das Sommerzeitflag gesesetzt, im anderen Fall gelöscht. Nach deinen Erkenntnissen zum param[8]=0x17, nehm ich an, das sich dann der Heizungsparameter 0  identisch verhält egal ob  param[8]=0x16 oder param[8]=0x17 genutzt wird.

Mit dem ESP32 hab ich auch schon mal geliebäugelt, aber eigentlich hab ich mit dem Mega alles was ich brauch.
Denn ich wollte ja "nur" den Raumwert der Heizung übermitteln, und diese Möglichkeit hab ich 2018 mit BSB_Lan bekommen.Von einem vernünftigen Messpunkt via WlAN ins Netzwerk und dann via BSB_lan zur Heizung.
Das es für die Thision ja nur eine rein kabelgebundene Möglichkeit dafür gibt, kennst du ja von deiner. In meinem Fall hätte ich für die kabelgebundene Lösung Wände im halben Haus aufstemmen (lassen) müssen.

Das was ich darüber hinaus mache, würden einige als ungebremsten Forscherdrang bezeichnen, andere als unnötige Spielerei.
Naja, auch das (scheinbar) Unnötige ist manchmal wohltuend interessant.

Huups, jetzt schreib ich das gerade und seh in der Vorschau, das du  was gefunden hast.
Das Test ich mal gleich. 

[sust]

Ja, Das geht!

param[8]=0x18 setzt beim Heizungsparameter 0 nur die Zeit von Stunde bis Sekunde! Der Rest ist piepegal.
Das ist exakt das was wir für den Heizungsparameter 1 benötigen würden.
Und wir können die altbekannte CmdId und den Telegrammaufbau der BSB_Lan des Heizungsparameter 0 verwenden! Lediglich das Flag muss auf 0x18 gesetzt werden. Sauber!!!

Der param[8]=0x08  geht nicht bei mir. Zwar wird die Stunde bis Sekunde geändert, aber auch das Jahr und der Wochentag. Der Tag und der Monat nicht!!??
Damit ist er für die Heizungsparameter 1,2 u.3 unbrauchbar.

Es fällt mir insgesamt noch was auf: Die param[8] mit 0 u.1 sind ja funktionsgleich. Das gilt auch für param[8] mit 16 u. 17. Beide Pärchen haben aber miteinander verglichen eine Gemeinsamkeit: das niederwertigste bit im param[8]

Wenn man das auf dein gefunden Wert 0x08 anwendet gehört dazu der funktionsgleiche Wert 0x09. Und zu deinem gefundenen Wert 0x18 gehört der funktionsgleiche Wert 0x19.
Was man mit dem Unterscheidungsmerkmal niederwertigstes Bit im param[8] nun anfangen können... muss die Zukunft zeigen.
Irgendwas muss es sein, warum dann sonst die funktionsgleichen Doubletten?

[freetz]

Ah, gut beobachtet, ich hatte bei meinen Versuchen nur Zeit und Tag geändert, deswegen hat bei mir 0x08 auch gepasst. Ich vermute, dass es generell ein Bit-Feld ist, das sagt, welche Werte übernommen werden und welche nicht. Vielleicht bezieht sich das niederwertigste Bit damm doch auf das Sommer-/Winterzeit-Flag?
Um dann alle Parameter abbilden zu können, müssten wir jetzt noch herausfinden, welcher Wert dann nur das Jahr ändert und sonst alles intakt lässt...
Auf jeden Fall schön zu sehen, dass man auch nach sieben Jahren hier im Thread immer noch neue Sachen lernt ...

[sust]

Ja, man lernt nie aus....

Hinsichtlich Jahr Einstellung würd ich klar ein Flag favorisieren was Tag, Monat, Jahr und Wochentag einstellt.
Da der Kessel ja eine zeitlang den falschen Wochentag behalten könnte müsste der ja sowieso berechnet werden.
Zur Berechnung des Wochentages brauchen wir sowieso den Tag und den Monat, ein setzen schadet also nicht.
Nur wo kriegt man das her, wenn man nur die Eingabe des Jahres freigeben will?

Ich hab mir in den letzten Tagen Gedanken gemacht wie ich neue cases für Heizungsparameter 2 und 3 in der V0.44 unterbringen könnte.
Also ausgerechnet nicht für den jetzt bekannten 1er.
Hab auch was gefunden was meinem copy und paste Talent entspricht.
Hier der für das Jahr:

Code Auswählen Erweitern

case VT_YEAR: // ?
      {
        int d,m,y;
        if(1!=sscanf(val,"%d",&y))
        return 0;
        SetDateTime();
        GetDateTime(date);
        d=(day());
        m=(month());
      param[0]=0x01;
      param[1]=y-1900;
      param[2]=m;
      param[3]=d;
      param[4]=dayofweek(d,m,y);
      param[5]=0xff;
      param[6]=0xff;
      param[7]=0xff;
      param[8]=0x??; //???
      param_len=9;
      }
      break;

Das funktioniert auch einwandfrei, wenn ich den param[8]=0 verwende und den case als VT_DATETIME flashe, allerdings wird natürlich die Zeit jedesmal zerstört.. Zeigt aber, das dies hier dargestellte in der V0.44 funktioniert...wenn wir ein wirkungsvolles Flag hätten.

Mein case VT_Monday sieht identisch aus , nur das Tag und Monat eingegeben werden und das Jahr "besorgt" wird.
Braucht man eigentlich  die Funktion GetDateTime(date); überhaupt? Liest sich jetzt für mich irgendwie so doppelt gemoppelt?
Aber nein , ich flash nicht schon wieder den Mega...
Und meld mich auch erstmal ab, bis morgen.
Tschüß

Wo sind die anderen eigentlich? Sind wir hier alleine?
Und wer kann Hawkk aus dem Beitrag#5557  ?? oder so ähnlich ..  helfen?

[freetz]

Hawkk hatte ich schon geschrieben, was noch für Infos benötgit werden, um weiterzuhelfen, da ist bisher aber noch nichts gekommen.

Dafür habe ich jetzt das Status-Byte dekodiert. Jedes Bit bezieht sich auf einen Teil der Payload des Datums- und Uhrzeit-Telegramms:

Bit 0: Sommerzeit?
Bit 1: Uhrzeit
Bit 2: Wochentag
Bit 3: Monat und Tag
Bit 4: Jahr

Ein gesetztes Bit (1) bedeutet, dass der entsprechende Teil nicht in der Heizung aktualisiert wird, ein nicht-gesetztes Bit (0) bedeutet demzufolge, dass der Teil aktualisiert wird.

Die Reihenfolge entspricht auch dem (umgekehrten) Aufbau der Payload des Telegramms: Nach dem Enable-Byte kommt zuerst das Jahr, dann Monat und Tag, dann die Uhrzeit und dann das Sommer-/Winterzeit-Flag (00 = Winterzeit, 01 = Sommerzeit).
Ich konnte Bit 0 leider nicht so genau überprüfen, wie die anderen Payload-Teile, weil der Wert bei meiner Therme sofort nach der Abfrage korrigiert wird. Trotzdem muss es eine Bedeutung haben, wenn beim Setzen der Sommer-/Winterzeit-Datumsangaben die 0x16 verwendet wird (Bit 0 nicht gesetzt = Sommer-/Winterzeit-Flag wird aktualisiert), und bei den Feriendaten die 0x17 (Bit 0 gesetzt = Sommer-/Winterzeit-Flag wird nicht angefasst).

Zusammengefasst bedeutet das für die Parameter 0 bis 6:
0 (Datum und Uhrzeit): Status-Byte = 0x00
1 (Stunden, Minuten (und Sekunden)): Status-Byte = 0x1D
2, 5 und 6 (Tag/Monat): Status-Byte = 0x16
3 (Jahr): Status-Byte = 0x0F

Die Frage ist jetzt, ob es trotzdem weiterhin Sinn macht, mehrere cases für Uhrzeit- und Datumsänderungen zu haben, oder ob man das durch entsprechendes Parsen des Übergabestrings vereinfachen kann. Das muss ich mir noch mal durch den Kopf gehen lassen. Und man müsste überlegen, ob man sich weiterhin an die Original-Parametrierung hält oder die eher weniger sinnvolle Trennung von Tag/Monat und Jahr zu einem Datum zusammenführt und zusätzlich noch eine reine Uhrzeit-Einstellung hinzufügt.

[Luposoft]

Ein liebes Hallo in die Runde,

ihr beschäftigt euch grad so intensiv mit der Uhrzeit-Einstellung.

Da hab ich grad auch mit zu tun.
Ich wollte wissen, wie genau die Uhr der Heizung eigentlich ist.
Folgenden Test habe ich gemacht:
Ich frage alle 10 Minuten den Parameter 0 ab und  vergleiche ihn mit der Fhem-Zeit (bei mir nen Raspi mit NTP-Synchronisierung)
Da gibts ein bemerkenswertes Muster.
Die Differenz beider Zeiten läuft bis 14s hoch, geht dann wieder auf 0, um dann wieder zu steigen.
Das alles in einem Rhytmus von meistens ca. 1h 50min.

Meine Schlußfolgerung:
Das Bediengerät geht ziemlich genau
die Uhrzeit des Kessels selbst ist hundsmiserabel

das Bediengerät aktualisiert die Uhrzeit des Kessels regelmäßig
(die 1h 50min sind nicht konstant, vielleicht erfolgt die Sendung auch bei Überschreitung einer voreingestellten Zeitdifferenz)

das passt doch mit euren Boabachtungen zusammen, oder?

Ich versuche jetzt den Weg, dem BSB-LAN über NTP eine Uhrzeit zu geben...

[freetz]

Hier noch ein interessanter Mitschnitt, was passiert, wenn man die Uhrzeit setzt:
Einmal mit 0x16:

Code Auswählen Erweitern

GET /4444/Y03,053D000B,017803010400000016 HTTP/1.1                             
LAN->HEIZ SET    0 Uhrzeit und Datum - Datum/Zeit: ---                         
DC C2 00 14 03 3D 05 00 0B 01 78 03 01 04 00 00 00 16 B8 AF                     
HEIZ->LAN ACK    0 Uhrzeit und Datum - Datum/Zeit:                             
DC 80 42 0B 04 05 3D 00 0B 86 75                                               
HEIZ->ALL  00    0 Uhrzeit und Datum - Datum/Zeit: ---                         
DC 80 7F 14 00 05 00 00 6C 01 79 03 01 05 10 24 31 00 7D 5A                     
DISP->ALL  INF    0 Uhrzeit und Datum - Datum/Zeit: 01.03.2021 16:36:49         
DC 8A 7F 14 02 05 00 00 6C 00 79 03 01 05 10 24 31 01 D6 4E

Und so sieht es aus, wenn man stattdessen 0x17 nimmt:

Code Auswählen Erweitern

GET /4444/Y03,053D000B,017803010400000017 HTTP/1.1                             
LAN->HEIZ SET    0 Uhrzeit und Datum - Datum/Zeit: ---                         
DC C2 00 14 03 3D 05 00 0B 01 78 03 01 04 00 00 00 17 A8 8E                     
HEIZ->LAN ACK    0 Uhrzeit und Datum - Datum/Zeit:                             
DC 80 42 0B 04 05 3D 00 0B 86 75                                               
HEIZ->ALL  00    0 Uhrzeit und Datum - Datum/Zeit: ---                         
DC 80 7F 14 00 05 00 00 6C 01 79 03 01 05 10 25 0B 00 A0 34                     
DISP->ALL  INF    0 Uhrzeit und Datum - Datum/Zeit: 01.03.2021 16:37:11         
DC 8A 7F 14 02 05 00 00 6C 00 79 03 01 05 10 25 0B 00 1B 01

Interessant ist, dass nach dem Setzen der Uhrzeit die Therme einen bisher unbekannten Telegrammtyp an alle Busteilnehmer sendet, nämlich 0x00. Dieser scheint (zumindest) das Display zu veranlassen, per INF seine Uhrzeit an alle Teilnehmer zu senden. Ich dachte zuerst, dass der Unterschied im "Sommerzeit-Byte" von dem Status-Byte herrührt (0x16 hat einen Unterschied bei den letzten beiden Telegrammen, 0x17 nicht), aber das ließ sich nicht über die Status-Bytes reproduzieren. Vielmehr scheint es so zu sein, dass das Display zwischen der neuen Zeitinfo der Therme und dem Aussenden des eigenen INF-Telegramms den Sommerzeit-Status noch nicht schnell genug berechnen konnte. Somit bleibt weiterhin unklar, welche Auswirkungen Bit 0 im Status-Byte auf die Sommerzeitberechnung hat.

[freetz]

@Luposoft: Ja, es kann sein, dass nur im Display eine RTC verbaut wurde und man im Regler in der Therme die Zeitberechnung einfach nur auf Basis des Prozessortakts berechnet und dann regelmäßig vom Display korrigiert wird. Letztlich macht das der Arduino ja genauso (und hat von daher ja auch keine wirklich genaue Uhr).

An NTP hatte ich damals auch gedacht, aber da ich nicht voraussetzen wollte, dass die BSB-LANs alle im Internet hängen, bezieht BSB-LAN die genaue(er) Uhrzeit von der Therme. Da wir hier ja keine Sekundengenauigkeit brauchen und das Display ja ausreichend genau ist, reicht es im Zweifelsfall per Hand über das Webinterface oder über ein periodisch aufgerufenes Script die Uhrzeit zu setzen.

[sust]

@ Luposoft  ja, die schlechte Uhr im Kessel kann ich bestätigen.
Denn wenn ich im laufenden Betrieb das Display entferne (Nachahmung auf eigene Gefahr!) dann läuft die Uhr im Kessel weiter, nach 24 Stunden ging sie aber um 10 Minuten nach.
Das wiederholte sich nach Korrektur bis zum  nächsten und übernächsten  Tag wieder.
Interessant war, wenn man die Heizung in diesem Zustand komplett ausschaltete, und danach (ohne Display) wieder anschaltete, war die Zeit gelöscht.
Der "Rest" alle Temperaturvorgaben, alle anderen Zeitvorgaben sind noch noch da gewesen!

Stöpselte man in diesem Zustand das Display wieder an (Nachahmung auf eigene Gefahr) war die genaue Zeit wieder da.
Das Display war insgesamt 3 Tage ohne Stromversorgung!
Wegen der Genauigkeit würd ich sagen, im Bediengerät werkelt ein hochwertiger Quarz.

Wenn du mit  NTP die Heizung "abgleichen" willst, ist aber klar das allein durch die Kollisionsprüfung ein Fehler von bis zu 1 Sekunde eintreten kann. Oder? 

@freetz du hast ja wieder neue "flags" gefunden. Und gleich noch eine Bildungsregel um noch fehlende zu ermitteln dazu.
Die mich noch interessieren wären der gesamte Datumsblock ohne Zeit, sowie nur der Wochentag.
Das wäre dann "nachgerechnet" ja 0x02  u. 0x03 für den Datumsblock.
Und für den Wochentag alleine 0x1A u. 0x1B.
Stimmt das? Hast du das auch mal im Praktischen geprüft?
Bei meiner V0.44 geht das ja nicht ohne andauerndes flashen...

Das Zusammenfassen der Einstellung von Tag,Monat und Jahr könnte man machen, warum nicht.
Wenn der 0x02 funktioniert steht ja auch dem Setzen des gesamten Datums mit einem Telegramm nichts im Wege.
Weitere Zusammenfassungen womöglich auch noch über verschiedene CmdIds (Vacationprog,Summerperiod) hinweg würd ich nicht machen.
Das liegt aber auch an meinen Kenntnissen in dem Bereich...
Aber wenn dich das reizt, mit den Entwicklern der Heizungssoftware gleichzuziehen, mach doch.
Bei meiner V0.44 konsolidiere ich wohl lieber nur. Das heißt, für die Einstellmöglichkeiten lass ich das so wie es mal ganz zu Anfang geplant wurde. -Jahr und Tag/Monat getrennt.
Das passt dann aber auch zu dem, was man an Einstellmöglichkeiten im Bediengerät vorfindet.
Und ich häng einfach nur 3 neue cases ran. Und bin durch damit. 

Das bei deinen praktischen Versuchen der Tag/Monat Einstellung ein INF vom Display mit einem falschen Wochentag  verschickt wird, verblüfft mich.
Denn alle Setzungen  und dann Nachfragen ans Display via Web Interface wurden bei meinen Versuchen hinsichtlich Wochentag  immer berichtigt, wenn ich was falsches  veranlasst hatte...
Das berechnen des Wochentages dauert doch nur ne'Millisekunde...

[postman]

Moin zusammen,

An NTP hatte ich damals auch gedacht, aber da ich nicht voraussetzen wollte, dass die BSB-LANs alle im Internet hängen

Kleiner Tipp am Rande; ich lasse meinen Router mit einem Zeitserver (Internetprovider) synchronisieren und nutze dann den NTP vom Router. Da braucht der BSB keine Internetverbindung. Als Zeitserver könnte da dann die IP-Adresse vom Router oder in Luposofts Fall die vom Raspi eintragen. sollte funktionieren.

Gruß Uwe

[freetz]

Stimmt, das sollte gehen, danke für den Tipp!

[Pat]

Genau, halt für den Fall, dass man im FHEM den Klartext der Dropdowns haben will, anstatt der numerischen Werte.

Hallo freetz,
sorry für die Frage, dein posting ist schon etwas älter, aber für mich ist es aktuell relevant.
Ich nutze eine homematic clasic und möchte nicht den Staus als Wert anzeigen lassen, sondern als Klartext. Gibt es dafür eine Lösung?
Danke im Voraus

[freetz]

Ja, über JSON, z.B. so für Parameter 700:
/JQ=700

[Pat]

ich frage den Status und die Warmwassertemeratur so ab und bringe sie zur Anzeige:

! BSB-Adapter Wert abfragen by Bratmaxe
! 29.10.2018 - V0.1 - Erste Version

string CuxGeraetAbfrage = "CUX2801003:3"; ! GeräteAdresse des CuxD Execute Gerätes, welches die Abfragen ausführt
string CuxGeraetLogging = "CUX2801003:4"; ! GeräteAdresse des CuxD Execute Gerätes, welches das Logging ausführt, Leer ("") lassen, wenn kein Cuxd-Highcharts Logging gewünscht
string IPAdresseBSB = "192.168.178.88"; !IP_Adresse des BSB-Adapters
string Wort = "8000"; !Parameternummer: Beispiel Außentemperatur = 8700, Betriebsmodus = 700
string Variablename = "BOB_Status_Heizkreis"; ! Name der Systemvariable
boolean Durchschnitt24h = false; ! true = Durchschnittswert holen, false = aktuellen Wert holen - diese muss vorher in der BSB_lan_config.h konfiguriert wurden sein!!!

usw.

die Abfrage erfolgt hiermit:

var C2 = dom.GetObject("hs_display1_view1:C2");
var temp3 = dom.GetObject("BOB_TWW_Temp").Value().ToString(1);
var temp4 = dom.GetObject("BOB_Status_Heizkreis").Value().ToString(1);
var stringC2 = "{fontSize:25}{img:heating3_256.png}{color:green}{text:Kessel<br></br>TWW: " + temp3 + "°C<br></br>Status:<b></b> " + temp4 + "}" ;
C2.State(stringC2);
WriteLine(stringC2);


Wie kann ich denn nun die Abfrage entsprechend ändern?
(Ich bin im Prinzip noch Anfänger)
Dankeschön