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

[miwi]

Mein erster Gedanke war nicht zielfuehrend, denn er hat nicht das Prinzip der Bitmaskierung enthalten.
Hier ist einer, der deinem bisherigen Schema nahe kommt. Probiers  'mal mit Indirection:

1. In jeder Kommandozeile ist ein Index in eine Tabelle von Bitmustern. Da BSB_lan wohl kaum mehr als 256 Familien/Vatrianten unterstuetzen wird und wahrscheinlich nicht so viele in freier Wildbahn existieren, kann dieser Index ein Byte lang sein. Natuerlich kann der Index auch 16 bits lang sein, falls noetig.

2. Definiere ein struct mit einem hi und einem lo Teil, beide 32-bit Integers oder eine entsprechende class mit geeigneten Methoden.  Du hast so statt bisher 32 jetzt bis zu 64 bits bzw. Familien/Varianten, mit denen du arbeiten kannst.  Wenn das immer noch nicht reicht, eben noch eine weitere Int32 in die struct zufuegen, etc.  Natuerlich koennen manche struct Elemente auch weniger als 32 Bits gross sein, Hauptsache, die Gesamtzahl der Bits ist ausreichend Beispiel: 32bit long Integer und 16bit word). 

3. Definiere eine Tabelle, die diese structs als Elemente enthaelt. Welches Tabellenelement fuer ein Kommando zutreffen soll, benennt das eine Byte in der Kommandozeile. Damit jedem Kommando wie jetzt auch ein Bitmuster zugeordnet, das aber nicht in voller Schoenheit und Laenge in jedem Kommando stehen muss.

4. Definiere eine Zuordnung wie bisher zwischen je einer Familie/Variante und einem solchen mit Bit-Werten versehenen struct. Bisher definierst du als zugeordneten Wert eine 32-Bit Integer, jetzt ueber die struct 2x, 3x, n x 32bit Integers.

5. Pruefung zur Uebereinstimmung: wie bisher die beiden Bit-Werte ANDen. Jetzt werden eben hi, lo, und ggf. weitere struct Elemente jeweils mit dem Kontrollmuster aus (4) kombiniert.

Man braucht also kein array mit 256x256 Werten, denn die Zahl der uns bekannten und wirklich vorkommenden Familien/Varianten wuerde ein sparsly filled array mit grosser Verschwendung von Platz bedeuten.  Diese Loesung definiert nur fuer wirklich existierende Familien/Varianten ein Bitmuster und einen Index darauf.

[freetz]

Danke, miwi, aber hast Du die Idee, die ich Dir per Mail geschickt hatte, gelesen?

Mir kam die Idee, mit den Gerätefamilien wie mit den ENUM-Parameter-Optionen zu verfahren und mit Pointern auf char bzw. byte arrays zu arbeiten. Das wäre ein 16-Bit Wert pro Zeile (also sogar nur die Hälfte als die momentane Device ID. Wenn der Pointer 0 ist, gilt die CommandID für alle Geräte. Wenn er auf ein char array zeigt, enthält jeder Eintrag zuerst zwei Byte für Familie/Variante und dahinter die dafür gültige CommandID. Das ganze würde vermutlich sogar weniger Speicher verbrauchen als jetzt, wo ich Parameter mit mehreren bekannten CommandIDs entsprechend mehrfach anlege, also jedes Mal 19 Byte verbrauche. So bliebe es bei einer Zeile pro Parameter (wenn alle Texte identisch sind), und pro vom Default abweichendem Eintrag 6 Byte.

Vorausgesetzt, ich habe Deine Variante richtig verstanden habe, könnte man theoretisch alle Kombinationen abbilden, ohne sich jetzt wieder auf eine angenommene Zahl zu begrenzen. Denn die Anzahl betroffener Parameter mit mehreren CommandIDs ist ja eigentlich überschaubar. Gleichzeitig bliebe auch das bitweise vergleichen enthalten. Oder habe ich da was übersehen?

[miwi]

Danke, miwi, aber hast Du die Idee, die ich Dir per Mail geschickt hatte, gelesen?

Ehem .. nein.  Habe ich nun, sie sollte auch funktionieren.  Unseren Methoden ist gemeinsam, dass sie in den cmdtbl weniger Platz als jetzt belegen, deine zwei weniger, meine drei weniger. Das ist schon 'mal  gut.

Die Methode, die ich geschildert habe, ist kein neues Konzept, sondern erweitert das schon verwendete um weitere bits. Stimmt, die Zahl ist durch das jeweilige Design begrenzt, kann aber wie beschrieben jederzeit beliebig angepasst werden. Des weiteren glaube ich, das von dir benannte "optische Problem" wuerde sich hier nicht stellen.  Uebrigens, man kann diese indirection Methode schon auf die jetzige Ausfuehrung mit ihren 32-bit patterns als feasibility study anwenden.  Dann musst Du schlussendlich nur noch die 32-bit Werte aufbohren, um zu einer erweiterten Loesung zu kommen. 

Ja, die Methode, die du schilderst, kann an beliebig viele viele Varianten adaptiert werden, was IMNSHO ein theoretischer Vorteil ist, da wir sooo viele gar nicht brauchen.  Wie performant sie ist, muss man genau so wie bei meinem Vorschlag dann sehen.

Ich schau' mal, ob und wie sich das umsetzen lässt, ohne den Code massiv umzustricken

Siehe oben.   "Meine" Loesung belaesst das Konzept an sich wie es war, was wenig Eingriffe in den bestehenden Code bedingt.  Deine Idee damals mit den bit patterns war und ist elegant.

Schlussendlich musst du die beiden Vorschlaege gegeneinander abwaegen.

Wenn du noch darueber "reden" willst, koennen wir wieder zur E-Mail greifen, denke ich.

[freetz]

Ich hatte die Frage ja bewusst ins Forum gestellt, damit sich auch andere dazu äußern können, und ich dachte, dass das auch der Grund ist, warum Du jetzt von Mail auf Forum umgestiegen bist.

Was ich nicht verstehe, ist, wieso Dein Vorschlag weniger Eingriffe in den Code bedeuten sollte - denn es müsste ja trotzdem vom jetzigen Auslesen des Bitmusters auf die neue Tabelle umgestellt werden. Das wäre bei beiden Varianten der Fall. Die Speicherersparnis wäre auch nur gegeben, wenn Du auf ein Byte reduzierst, was ich aus Gründen der Skalierbarkeit nicht machen würde. Die Performance-Frage würde sich (wie gesagt, wenn überhaupt) bei Deinem Modell auch eher stellen, denn es müsste ja bei jeder Abfrage auch zusätzlich auf die Structs/Tabellen zugegriffen werden, bei meiner Variante nur dann, wenn überhaupt ein Pointer hinterlegt ist. Und ein späteres erneutes "Aufbohren" würde ich auch gerne verhindern wollen. Wenn ich jetzt noch einmal Zeit investiere, dann in eine "richtige" Lösung, denn es gibt inzwischen immer mehr Interesse aus osteuropäischen Ländern, die ganz andere Thermen haben, aber auch die Siemens-Steuerung verwenden (Baxi z.B.). Da werden mit der Zeit sicher noch eine Reihe an neuen Gerätefamilien kommen. Die Tatsache, dass wir von 90 bis über 200 nun schon solche vertreten haben, deutet schon darauf hin...

[miwi]

Was ich nicht verstehe, ist, wieso Dein Vorschlag weniger Eingriffe in den Code bedeuten sollte - denn es müsste ja trotzdem vom jetzigen Auslesen des Bitmusters auf die neue Tabelle umgestellt werden. Das wäre bei beiden Varianten der Fall.

An dieser Stelle im Code (oder vielmehr den DEFINITIONS von bit patterns am Kopf der source Datei) ist das richtig. Aber die Vergleiche der bit patterns bliebe im CODE prinzipiell und funktionell erhalten, nur auf mehr bits erweitert.  Das heisst fuer mich "weniger Eingriffe in den Code" und Beibehalten des Konzepts, das ich gut finde. 
Das Verfahren mit dem Index und einer Tabelle als pattern definition im Kopf der Sourcedatei koennte schon in den jetzigen Code eingebaut und getestet werden. Anschliessend statt der long integers als bit patterns ein struct zu nehmen, ist dann nur noch eine kleine Erweiterung.

Die Speicherersparnis wäre auch nur gegeben, wenn Du auf ein Byte reduzierst, was ich aus Gründen der Skalierbarkeit nicht machen würde.

Musst du ja nicht; ich hatte schon von Anfang an die Moeglichkeit offen gelassen, auch einen 16-bit Index zu verwenden. Speicher in der cmdtbl sparen sowieso beide Verfahren.  An dem moeglicherweise einen Byte Unterschied mache ich keinen Vorteil fest, der das von mir vorgeschlagene Verfahren heraushebt.

Die Performance-Frage würde sich (wie gesagt, wenn überhaupt) bei Deinem Modell auch eher stellen, denn es müsste ja bei jeder Abfrage auch zusätzlich auf die Structs/Tabellen zugegriffen werden, bei meiner Variante nur dann, wenn überhaupt ein Pointer hinterlegt ist.

Bei dem Modell, das ich vorgeschlagen habe (ich will nicht von "meinem" Modell sprechen, sonst kommt der Gedanke "NIH" auf), muss der Code keine ENUMS durchsuchen, was du durchaus richtig als performance impact genannt hast; der Zugriff wuerde stattdessen ueber einen Index direkt das Tabellenelement adressieren.  Andererseits entfaellt bei dem von dir vorgeschlagenen Verfahren die Suche bei NULL pointern - jedes Verfahren hat also einen Vorteil. Dass der zwar vorhandene  "optische Nachteil" bei der Anzeige bei dem ENUM-Verfahren wirklich schwer wiegt, denke ich nicht.

Wenn der Pointer 0 ist, gilt die CommandID für alle Geräte. Wenn er auf ein char array zeigt, enthält jeder Eintrag zuerst zwei Byte für Familie/Variante und dahinter die dafür gültige CommandID. Das ganze würde vermutlich sogar weniger Speicher verbrauchen als jetzt, wo ich Parameter mit mehreren bekannten CommandIDs entsprechend mehrfach anlege, also jedes Mal 19 Byte verbrauche. So bliebe es bei einer Zeile pro Parameter (wenn alle Texte identisch sind), und pro vom Default abweichendem Eintrag 6 Byte.

Da koenntest Du evtl. Platz sparen; wenn sich die Texte unterscheiden, muesstest du (1) entweder eine eigene Zeile in der cmdtbl vorsehen oder (2) das ENUM Dings noch generell um einen pointer auf string erweitern, der bei unveraendertem Text NULL ist (und den default string bedeutet) oder bei einem OEM-spezifischen Text darauf deutet.  Ersteres waere wohl platzsparender.

Die Entscheidung fuer das ganze Verfahren liegt selbstverstaendlich bei dir.  Wenn ich an deiner Stelle waere, wuerde ich wahrscheinlich versuchen, ein bewaehrtes Konzept beizubehalten, es sei denn es sprechen gewichtige Gruende dagegen.

Gibt es sonst gar keine Software-affinen Menschen hier?

[Schotty]

Gibt es sonst gar keine Software-affinen Menschen hier?

..software-affin schon, wenn es um Benutzen und ggf Fehlersuchen geht - aber bei der Entwicklung bin ich leider raus. Ideen kann ich bei DEM Programmierniveau leider absolut keine liefern.. 

[freetz]

So, im Vorfeld für welche Änderung auch immer, habe ich im jetzt aktuellen GitHub-Master die Sammelfamilie DEV_BROETJE entfernt und in die entsprechenden Einzelfamilien umgesetzt. Diese hatte ich ursprünglich mal in der Annahme angelegt, dass es größere Gemeinsamkeiten innerhalb der Brötje-Geräte geben würde, aber das hat sich über die Zeit als falsch herausgestellt und nun verwirrt sie eher und nimmt einen "Familienplatz" ein, den man auch anderweitig verwenden könnte.

Eine Bitte an die Brötje-Nutzer: Bitte einmal die aktuelle Version installieren und vorher und nachher überprüfen, ob die folgenden Parameter noch korrekt sind:

/900/1200/1500/2270/5950/5951/5957/5960/5961/5962/5963/5964/6030/6031/6032/7841/8324/8326/8329/8338/8339/9000

(lässt sich so direkt als eine URL abrufen). In der nächsten "offiziellen" Version wird diese Änderung fix sein, also bitte bis dahin rückmelden, weil da durchaus relevante Parameter darunter sind.

Danke und Gruß,

F.

[Schotty]

Eine Bitte an die Brötje-Nutzer: Bitte einmal die aktuelle Version installieren und vorher und nachher überprüfen, ob die folgenden Parameter noch korrekt sind:(...)

Also VOR dem Flashen der aktuellen Version die genannten Parameter abrufen, DANN Flashen und dann nochmal abrufen? Oder was meinst du mit "installieren und vorher und nachher überprüfen"?

Bin noch unterwegs und kann leider nicht testen - sobald ich wieder vor Ort bin, kommt die Rückmeldung.

[freetz]

Ja, also einmal abrufen, bevor man die neue Version installiert und dann noch einmal, nachdem man sie installiert hat.
Betroffen sein dürften eigentlich nur die folgenden Gerätefamilien:
90, 96, 98, 107, 108, 162, 163

Pro Gerätefamilie ist natürlich nur eine Rückmeldung nötig - von daher bitte bei der Rückmeldung die getestete Gerätefamilie mit angeben, dann kann ich die "abhaken"...

Danke und Gruß,

F.

[stan23]

Gibt es sonst gar keine Software-affinen Menschen hier?

Hier, ich mache das beruflich
Ich hatte gestern früh eine Antwort getippt aber vergessen abzuschicken.

Mein Vorschlag geht in eine ähnliche Richtung:

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.

Das hat allerdings den Nachteil, dass das Mapping für jede neu gefundene Kombination erweitert werden muss, aber gewisse Anpassungen sind ja jetzt schon für neue Familien zu machen.

Und wenn 32 Bit für 32 Kombinationen nicht mehr ausreichen muss man eben erweitern, auf 48 oder 64 Bit.

Das ist mehr oder weniger was auch miwi vorschlägt

[freetz]

Danke! Das Mapping habe ich ja jetzt schon, das war auch mein erster Gedanke, aber ich benutze, dass ich mit Einbeziehung der Gerätevariante schnell die 32 Kombinationen sprengen werde. Und der Arduino hat ja glaube ich nur 32 Bit lange Variablen, wie soll ich da dann auf 48, 64 oder mehr aufstocken?

[FunkOdyssey]

a) Die Parameter sind nicht mehr auslesbar, weil die Auto-Detection fehlgeschlagen ist. 8700 und die anderen Parameter sind solche, für die es mehrere CommandIDs gibt. Wenn Deine Gerätefamilie entweder unbekannt ist oder beim Start nicht richtig erkannt wurde, werden diese Parameter nicht angezeigt. Der Grund, warum es vorher angezeigt wurde, ist, dass es vorher eben nur eine CommandID für die entsprechenden Parameter gab. Wenn jetzt eine Gerätefamilie nicht für einen Parameter hinterlegt ist, weiß das Programm nicht, welcher der richtige ist. Und anstatt zwei oder mehrere (möglicherweise falsche) Kommandos an die Therme zu senden, wird dieser Parameter nicht angezeigt.
I.d.R. ist das erledgit, sobald die unbekannte Gerätefamilie in den Conde eingepflegt wird. Gerätefamilie 162 ist aber eigentlich hinterlegt, auch für Parameter 8700. Insofern sollte das klappen. Die Autoerkennung wird aber nur beim Hochfahren des Arduino durchgeführt, daher wie schon bereits gesagt: Schau' beim Hochfahren auf den SerMo und sieh nach, was für eine Gerätefamilie da erkannt wird. Wenn das nicht klappt, bleiben die genannten Parameter (für Dich) unbekannt.

Danke für die Erläuterungen. Das erklärt natürlich einiges.
Irgendwie scheine ich -trotz mehrfacher Resets - Probleme mit der Autoerkennung gehabt zu haben.
Ich habe das nun noch einmal mit dem SerialMonitor mitgelesen:

Code Auswählen Erweitern

?? address: 7
Destination address: 0
READY
free RAM:6053
192.168.24.45
RGT2->HEIZ QUR 6225 Konfiguration -  Gerätefamilie:
DC 87 00 0B 06 3D 05 00 02 EC E6
HEIZ->RGT2 ANS 6225 Konfiguration -  Gerätefamilie: 162
DC 80 07 0E 07 05 3D 00 02 00 00 A2 17 5A
Device family: 162
Device ID: 2048
DISP->HEIZ QUR 8310 Diagnose Erzeuger -  Kesseltemperatur:
DC 8A 00 0B 06 3D 0D 05 19 4F 8C
HEIZ->DISP ANS 8310 Diagnose Erzeuger -  Kesseltemperatur: 34.5 °C
DC 80 0A 0E 07 0D 3D 05 19 00 08 A1 93 E9
DISP->HEIZ QUR 8310 Diagnose Erzeuger -  Kesseltemperatur:
DC 8A 00 0B 06 3D 0D 05 19 4F 8C
HEIZ->DISP ANS 8310 Diagnose Erzeuger -  Kesseltemperatur: 34.5 °C
DC 80 0A 0E 07 0D 3D 05 19 00 08 A1 93 E9

Sieht nun alles gut aus. Warum plötzlich? Keine Ahnung. Vermutlich weil ich mich erstmals daran gehalten habe, die Therme beim Anschließen am BSB auszuschalten. Vorher hatte ich alles vorne am Diagnoseport und da war mir das egal. Nun habe ich mich am FB-Anschluss bedient und habe mit meiner aktuellen Verkabelung ein größeres Kurzschlussrisiko (am Arduino).

Zusätzlich habe ich aber auch die Gerätefamilie 162 in der Config fest hinterlegt. Dann passiert mir das so schnell nicht noch einmal.

b) Ja, die Kategorien haben sich geändert, aber das hat keine Auswirkung auf die Parameter. Falls Du nicht (unsinnigerweise, weil viel zu lange den Arduino und den Bus blockierend) ganze Kategorien parst, hat das auf Dich keine Auswirkung.

Ich habe die gesamte Fehler-Kategorie abgerufen, weil sich die Anzahl der erwünschten Parameter mit der ganzen Kategorie deckte.

Hier habe ich noch eine Merkwürdigkeit entdeckt. Und zwar werden mir einige Parameter der Fehlerkategorie nicht mehr angezeigt bzw. mit anderen Beschreibungen angezeigt. So vermisse ich 6805, 6806, 6815. Siehe Soll/Ist im folgenden CODE.

Code Auswählen Erweitern

Soll: 6805 Fehlercode 3
Ist: 6805 Fehler - SW Diagnosecode 1: 422 - not found

Soll: 6806 Historie 4 Datum Uhrzeit
Ist: 6806 Fehler - FA Phase 1: 10

Soll: 6815 Fehlercode 8
Ist: 6815 Fehler - SW Diagnosecode 2: 426 - not found


[Schotty]

Danke für die Erläuterungen. Das erklärt natürlich einiges.

Sorry FunkOdyssey, aber da kann ich nun doch nicht 'widerstehen' auf das Handbuch zu verweisen: FAQ 14.9 Warum werden manchmal bestimmte Parameter nicht angezeigt? 

[FunkOdyssey]

Absolute Zustimmung. Ich habe das Handbuch und die Wiki-Dokumente auf GitHub alle mehrmals gelesen, da ich mich vor diesen Schritt vernünftig vorbereiten wollte. Dennoch habe ich diesen FAQ-Eintrag überlesen. Sorry.

[Schotty]

..alles gut..

Wackelkontakt bei der neuen Verkabelung kannst du ausschließen? Hast du evtl ein sehr langes oder ungeschirmtes Kabel verwendet und parallel zu stromführenden (230V-)Leitungen verlegt? Manchmal KANN das komisches Fehlverhalten nach sich ziehen..