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

[freetz]

Was die veränderten Parameter angeht, haben wir da wohl das gleiche Problem wie bei numsi, denn für die Gerätefamilie 162 sind die (für Dich) "neuen" Parameter irgendwann so gemeldet worden. Ich kann sie von daher nicht einfach wieder umstellen, ohne die Funktionalität für jemand anderen zu zerstören - zumindest bis ich die neue Variante der Erkennung umgesetzt habe.
Was ich dafür von Dir bräuchte:
- Einen Telegramm-Mitschnitt der betroffenen Parameter wir in der FAQ beschrieben
- Die dazu an der Therme angezeigten Werte
- Deine Gerätevariante

Das seltsame ist, dass Du ja trotzdem Daten angezeigt bekommst, erscheinen diese denn bei Dir an der Therme bei anderen Parametern?

[miwi]

Und der Arduino hat ja glaube ich nur 32 Bit lange Variablen, wie soll ich da dann auf 48, 64 oder mehr aufstocken?

Generelle Antwort: Indem du dir selbst einen Variablentyp mit mehr bits definierst.  In Standard C wuerde ich ein struct nehmen, in C++ eine Klasse, die solche langen Daten verarbeitet.  Nicht umsonst ziehen manche C++ Buecher eine Analogie zwischen structs un Klassen.

Spezielle Antwort: Schau einmal in das Paket, das ich dir geschickt habe.  Darin habe ich eine BSB_lan Version als feasibility study  programmiert, die einen 64-bit Typ mit einem struct implementiert.  Wie schon frueher erwaehnt, kann man das noch kapseln und eine class schreiben, die dann auch die 64-bit Arithmetik beherrschen sollte, die du wahrscheinlich haben willst, wenn du Einzel-patterns addierst und subtrahierst.  Die Arithmetik ist, wie in meiner E-Mail beschrieben, eine noch offene Baustelle, die man aber entweder in C oder C++ loesen kann.  Ichwollte die Auswirkung auf die cmdtbl und BSB_lan.ino demonstrieren (und selbst sehen), wenn man das bisherige Verfahren auf 64 bit portiert.

[Schotty]

Was die veränderten Parameter angeht, haben wir da wohl das gleiche Problem wie bei numsi, denn für die Gerätefamilie 162 sind die (für Dich) "neuen" Parameter irgendwann so gemeldet worden.

Was mir diesbzgl gerade durch den Kopf ging:
Wenn ich mich recht erinnere, hat doch vor ca 20Seiten User postman oder hsepm für die Fam 162 (LMS14) diverse neue Parameter geliefert? Wurden die neuen Parameter nach Implementierung von anderen LMS14-Besitzern nochmal getestet/gegengecheckt? (Bitte nicht falsch verstehen! Nix gegen Euch @hsepm/@postman, aber manchmal unterlaufen beim Dekodieren Fehler.. )
Sind die Gerätevarianten der LMS14-Regler, von denen die neuen Parameter stammen, mit bisher existenten Reglern identisch oder ebenfalls neu/abweichend?
Ansonsten: Welche Software-Versionen der Regler liegen vor? Vielleicht kann es daran liegen, dass mit aktualisierter Regler-Firmware Änderungen stattfanden..?
Ab welcher BSB-LAN-Version sind die o.g. neuen Parameter implementiert? Sprich, vielleicht mal testen, ob die vorherige Version noch einwandfrei lief und dann mal mit der dann aktualisierten Version (nach Implementation der neuen Parameter) testen? @FunkOdyssey

[miwi]

Zitat stan:

Ich würde nicht alle Kombinationen aus Familie und Variante vorsehen, sondern daraus ein Mapping erstellen: ein Bit pro bekannter Kombination.
Bisher hast du 18 Bits bzw. Kombinationen durch ein 1 zu 1 Mapping aus der Gerätefamilie. Jetzt kommt eine 19. Kombination hinzu.

Non modo, sed etiam ...

Plus die derzeit 55 Kombinationen, die Frederik durch UEBERLAGERUNG (+/- Arithmetik mit den Bit Pattern) zusaetzlich herstellt.  Das war noch eine nette kleine Ergaenzung, die ich in gleicher Weise wie bisher beruecksichtigen wollte.  Aber vielleicht fuehrt Frederiks Ansatz zu einer noch einfacheren Loesung.  Sein bisheriger Ansatz mit der Subtraktion, wo ein Modell herausfallen soll un der Addition, wo ein einzelnes Modell zusaetzlich einbezogen wird, fand ich sehr elegant.

Das ist mehr oder weniger was auch miwi vorschlägt

Ja, im Ergebnis bin ich auch zu einer Tabelle (oder mapping) gekommen, die die "Basismodelle" und die durch Ueberlagerung erhaltenen Modelle enthaelt.  Zu jedem Eintrag gehoert dann ein 64-bit pattern, fuer die Basismodelle fest definiert, fuer die anderen von diesen Festdefinitionen arithmetisch abgeleitet.

[FunkOdyssey]

Sind die Gerätevarianten der LMS14-Regler, von denen die neuen Parameter stammen, mit bisher existenten Reglern identisch oder ebenfalls neu/abweichend?

Daten von hsepm: (Quelle: https://forum.fhem.de/index.php/topic,29762.msg740800.html#msg740800)

Code Auswählen Erweitern

6223 Konfiguration - Bisher unbekante Geräteabfrage: unknown type 000014
6224 Konfiguration - Geräte-Identifikation: LMS14.001A100 0.00
6225 Konfiguration - Gerätefamilie: 162 162.00
6226 Konfiguration - Gerätevariante: 16 16.00
6227 Konfiguration - Objektverzeichnis-Version: 0.2 0.20
6228 Konfiguration - Bisher unbekante Geräteabfrage: unknown type 000014

Daten von postman: (Quelle: https://forum.fhem.de/index.php/topic,29762.msg731453.html#msg731453)

Code Auswählen Erweitern

6224 Konfiguration - Geräte-Identifikation: LMS14.001A100       
6225 Konfiguration - Gerätefamilie: 162       
6226 Konfiguration - Gerätevariante: 17   

Meine Daten:

Code Auswählen Erweitern

6223 Konfiguration - Bisher unbekannte Geräteabfrage: unknown type 000014
6224 Konfiguration - Geräte-Identifikation: LMS14.001A100 0.00
6225 Konfiguration - Gerätefamilie: 162 162.00
6226 Konfiguration - Gerätevariante: 14 14.00
6227 Konfiguration - Objektverzeichnis-Version: 0.1 0.10
6228 Konfiguration - Bisher unbekannte Geräteabfrage: unknown type 000014
Meine Software-Version ist: v2.3

Ich werde mal die Tage mitloggen und schauen.
Das was mir nun unter den "falschen" Parameter angezeigt wird, gehört auch zur Fehlerkategorie. Ich könnte mir vorstellen, dass man Fehlercode mit  "SW Diagnosecode" verwechselt hat. 

Wie bereits erwähnt, hatte ich alle Parameter bereits erfolgreich (damals noch v0.32) auslesen können. Die Codes waren also alle schon vorhanden. Ich schaue mal, wie ich helfen kann. Danke.

[Schotty]

Danke @FunkOdyssey

Ich wüsste echt gerne mal, was es generell mit den Varianten auf sich hat.. Ob das die jeweiligen (Vor-)Konfigurationen der -in diesem Fall- auf den ersten Blick identischen LMS14.001A100-Regler für das jeweilige Heizungsmodell beschreibt..? 

(Schade, dass keiner der Hersteller 'Mitleid' mit uns hat und mal etwas Licht ins Dunkle bringt, quasi-anonym würde ja reichen  Ich würde glatt ein Sixpack drauf wetten, dass still mitgelesen wird.. )

[Schotty]

Ich werde mal die Tage mitloggen und schauen.
Das was mir nun unter den "falschen" Parameter angezeigt wird, gehört auch zur Fehlerkategorie. Ich könnte mir vorstellen, dass man Fehlercode mit  "SW Diagnosecode" verwechselt hat. 

Wie bereits erwähnt, hatte ich alle Parameter bereits erfolgreich (damals noch v0.32) auslesen können. Die Codes waren also alle schon vorhanden. Ich schaue mal, wie ich helfen kann. Danke.

Ja, das wirst du zur Überprüfung vielleicht mit eigenem Dekodieren der 'falschen' Fehlerkategorie-Parameter klären können.. Bin gespannt..

[freetz]

Danke fürs raussuchen der Daten, FunkOddyssey, das zeigt, dass bei den drei Geräten drei unterschiedliche Gerätevarianten vorhanden sind, die die Unterschiede erklären könnten. Deine Logs bräuchte ich trotzdem noch, aber da die Parameter als solche stimmen, wird bei den anderen vermutlich kein Fehler unterlaufen sein. Trotzdem wäre auch von den beiden noch mal eine Rückmeldung hilfreich, um ganz sicher zu gehen...

[hsepm]

Was mir diesbzgl gerade durch den Kopf ging:
Wenn ich mich recht erinnere, hat doch vor ca 20Seiten User postman oder hsepm für die Fam 162 (LMS14) diverse neue Parameter geliefert? Wurden die neuen Parameter nach Implementierung von anderen LMS14-Besitzern nochmal getestet/gegengecheckt? (Bitte nicht falsch verstehen! Nix gegen Euch @hsepm/@postman, aber manchmal unterlaufen beim Dekodieren Fehler.. )
Sind die Gerätevarianten der LMS14-Regler, von denen die neuen Parameter stammen, mit bisher existenten Reglern identisch oder ebenfalls neu/abweichend?
Ansonsten: Welche Software-Versionen der Regler liegen vor? Vielleicht kann es daran liegen, dass mit aktualisierter Regler-Firmware Änderungen stattfanden..?
Ab welcher BSB-LAN-Version sind die o.g. neuen Parameter implementiert? Sprich, vielleicht mal testen, ob die vorherige Version noch einwandfrei lief und dann mal mit der dann aktualisierten Version (nach Implementation der neuen Parameter) testen? @FunkOdyssey

Ich habe noch nix (keine SerMon logs) geliefert, leider zu sehr beruflich eingespannt. Habe es aber vor, aber erst nach dem Upgrade auf die neueste Version. Vermutlich am kommenden Wochenende

[freetz]

So, erst einmal ein großes Danke an miwi, der mal einen Aufschlag für die von ihm und stan23 vorgeschlagenen Mappings gemacht hat. Finde ich an sich eine elegante Lösung, und ich habe dabei auch noch mal eine Menge gelernt.
Ich habe mich nun aber für einen noch anderen, viel einfacheren Weg entschieden:
Beim Durchgehen aller mehrfach belegten Parameter (also da, wo Geräte addiert werden), ist mir aufgefallen, dass ich in der Vergangenheit zwei Fehler gemacht habe:

1. Die vorher schon beschriebene Annahme, dass es größere Gemeinsamkeiten innerhalb eines Herstellers gibt - daraus resultierte früher das Definment "#define BROETJE", das ich dann als DEV_BROETJE mit in das dann neue System übernommen habe. Nach Durchsicht der Quellen war letztlich DEV_BROETJE in den allermeisten Fällen DEV_BR_SOB. Damit ließen sich dann die allermeisten Bandwurmdefinitionen (sowas wie DEV_ALL-DEV_BROETJE+DEV_BR_BOB+DEV_BR_PEV+DEV_BR_ISC) in eine DEV_ALL-DEV_BR_SOB und eine DEV_BR_SOB Zeile auflösen.

2. Bei neuen CommandIDs habe ich immer gleich DEV_ALL gesetzt, in der irrigen Annahme, dass der erste gemeldete Parameter immer der allgemeine Parameter ist und nicht der spezielle. So gibt es dann dann sowas wie Parameter 6031, wo eine Menge Geräte von DEV_ALL "abgezogen" werden, nur um in der nächsten Zeile im gleichen Bandwurmverfahren hinzugefügt zu werden. Da ist es dann wohl so gewesen, dass die erste Zeile eben der Spezialfall war, dessen Gerätefamilie ich damals noch nicht abgefragt habe, und die zweite Zeile der allgemeine Fall. Wenn man dann einmal weiß, welchen Ursprungs die erste Zeile war, lässt sich auch diese einfach in ein DEV_ALL-DEV_XX_YYY und ein DEV_XX_YYY umwandeln.

Es bleiben dann vielleicht ein Dutzend Fälle übrig, wo eine CommandID gleichzeitig ein "Spezialfall" ist und trotzdem noch für mehr als eine Therme passend ist. Bei allen anderen Fällen hat man letztlich auch pro Therme, die nicht zu DEV_ALL passt, eine Zeile.
Vor dem Hintergrund habe ich nun überlegt, dass ich den 32-Bit Wert cmd_tbl.devices durch zwei 8-Bit Werte .family und .variant ersetzen werde. Es gibt dann weiterhin einen allgemeingültigen Wert (255/255) und davor für jeden Spezialfall eine Zeile, in der für jede Gerätefamilie/variante die entsprechende CommandID definiert ist (auch hier ist 255 in der Gerätevariante dann ein catch-all).

Diese Variante hat mehrere Vorteile:

- Es gibt nicht mehr das Problem, dass eine Reihe von Parametern bei neuen Gerätefamilien erst einmal nicht funktionieren (und trotz verschiedenen Hinweisen auf der Webseite und im Handbuch und der FAQ ist das hier im Forum ja ein wiederholt auftretendes Problem).
- Die Speicherersparnis von 2 Byte pro Zeile gleicht die vielleicht 1-2 Dutzend Mehreinträge wieder aus (auch wenn die Speicherersparnis nicht so groß ist, wie bei miwis Vorschlag).
- Die Tabelle bleibt auch für nicht-Programmierer einfacher zu erweitern, weil man bei einer neuen CommandID für einen bestehenden Parameter nur die Gerätefamilie/-variante austauschen muss.
- Parametereigenschaften wie CommandID oder Gerätezugehörigkeit bleiben alle in einer Tabelle und sind auf einen Blick erkenntlich.
- Es gibt keine Performance-Einbußen und ausgeblendete Parameter bleiben ausgeblendet.

Schließlich ist das auch die Lösung, die sich für mich am schnellsten umsetzen lässt, denn auch wenn ich miwis Lösung nachvollziehen konnte, müsste ich für eine Umsetzung dann doch noch mehr Zeit investieren, um sie wirklich zu internalisieren - dafür programmiere ich einfach noch nicht lange genug in C ...

Auf jeden Fall vielen Dank Euch beiden für den wertvollen Input!

Gruß,

F.

[freetz]

Und wo wir gerade bei dem Ausfindigmachen der Ursprünge der Daten sind: Eine Reihe von Parametern hatte damals the_muggle geliefert, der eine Logon B G2Z2 hat - falls Du hier noch mitliest oder jemand anderes eine solche Therme hat, wäre es prima, wenn wir dafür die Gerätefamilie und -variante (Parameter 6225 und 6226) kriegen könnten, denn diese Therme ist auch einer dieser "Spezialfälle", die damals mit DEV_ALL als allgemeingültig gesetzt wurde.

Danke!

[postman]

Hallo Schotty,

Was mir diesbzgl gerade durch den Kopf ging:
Wenn ich mich recht erinnere, hat doch vor ca 20Seiten User postman oder hsepm für die Fam 162 (LMS14) diverse neue Parameter geliefert? Wurden die neuen Parameter nach Implementierung von anderen LMS14-Besitzern nochmal getestet/gegengecheckt? (Bitte nicht falsch verstehen! Nix gegen Euch @hsepm/@postman, aber manchmal unterlaufen beim Dekodieren Fehler.. )
Sind die Gerätevarianten der LMS14-Regler, von denen die neuen Parameter stammen, mit bisher existenten Reglern identisch oder ebenfalls neu/abweichend?
Ansonsten: Welche Software-Versionen der Regler liegen vor? Vielleicht kann es daran liegen, dass mit aktualisierter Regler-Firmware Änderungen stattfanden..?
Ab welcher BSB-LAN-Version sind die o.g. neuen Parameter implementiert? Sprich, vielleicht mal testen, ob die vorherige Version noch einwandfrei lief und dann mal mit der dann aktualisierten Version (nach Implementation der neuen Parameter) testen? @FunkOdyssey

Die Parameter habe ich mit copy/paste dem Serialmonitor ausgelesen und kopiert. Das sollte so passen, zumindest für SW-Version meiner Steuerung. 

Ich habe die BSB_Lan Verion 0.40 installiert, die von freetz als letzte "Tat" im Januar veröffentlicht wurde
Ob das jetzt die aktuellste Version ist, kann ich nicht sagen.
SW-Version meines Reglers ist lt. Parameter 6220 2.3
Damit funktioniert es jedenfalls
Leider kann ich aber derzeit nicht weiterhelfen, da ich ausser Gefecht bin

Gruß Uwe

[freetz]

Hallo Uwe,

danke, das hilft schon mal insofern weiter, als dass man bei copy/paste nicht viel falsch machen kann - und wenn die Parameter bei Dir richtig angezeigt werden, dann stimmen die auch. Gerätefamilie und -variante haben wir ja von Dir, insofern kann man damit erst mal arbeiten...

[postman]

Hallo freetz,
schön, dass ich doch weiterhelfen konnte.
Sag mal, gibt es eventuell die Möglichkeit, in der Startseite des BSB-Lan ein "Herstellungsdatum" der Version einzubauen; damit man weiß, von wann die Version stammt? Wenn ich das richtig sehe, gibt es die Version 0.40 in verschiedenen Versionsständen.
Das wird so etwas unübersichtlich; vor allen wenn man selbst nicht immer mitbekommt, das etwas geändert wurde.

Gruß Uwe

[FunkOdyssey]

Ich war noch Karneval feiern und muss mal schauen, wann ich ein paar ruhige Minuten finde, mich mit dem Notebook an die Therme zu setzen.
Ich bleibe aber am Ball. Scheinbar haben Uwe und ich identische Anlagen. Daher verstehe ich die Unterschiede nicht.
Danke postman und hsepm für die Rückmeldungen.