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

[miwi]

freetz: "Eine XML-Datei mit einer strukturierten Sammlung aller Kommandos ist sicherlich für die generelle Arbeit mit dem BSB-Bus hilfreich, aber mir ist noch nicht ganz klar geworden, wie das für dieses konkrete Projekt helfen kann ..."
Antwort: Fredrik, diese Darstellung ist ganz allgemein fuer alle Projekte gedacht, die sich an den SIEMENS BSßBus hängen wollen.

stan23: "Außerdem würde ich die Ergebnisse gerne als JSON statt html zurückliefern, weil ich mich dann das Parsen in OpenHAB wesentlich leichter ist."
Antwort: stan23, haben Sie denn ein binding für den BS-Bus am laufen?  Das interessiert mich sehr, weil ich an eine Entwicklung, allerdings auf der Basis des schon als OpenHAB binding existierenden stiebelheatpump Projekts, denke.  Jetzt wird evtl. ein weiterer Grund klar, warum es bei mir schon 'mal eine XML-Definition der Kommandos gibt.

So, und hier kommen einige Dateien, wie sie auf meinem PC liegen. Es handelt sich
a) um die von Jens am 2016-11-10 hier eingstellte Datei 20161110-BSB_lan.ino (von mir mit Datum im Namen versehen)
b) um die auf meinen PC derzeit aktuelle Datei broetje_miwi.ino. In dieser Datei habe ich einige Brötje-Meldungen nach eigenem Gusto verändert und - zumindest in meinen Augen - etwas klarer formuliert.
Klarstellung: Solche Änderungen sind rein privater Natur und für Andere ein "don't care"; die originalen Texte im Projekt können unverändert bleiben,  ich bin aber die Unterschiede nicht zeilenweise durchgegangen und habe alles zurückgeändert, bevor ich die Datei hier einstelle.
Aus dieser Datei hat mein Programm die XML-Datei erstellt.
c) um die patch-Datei 20161110.patch
Die patch-Datei ist riesig; anscheinend meint diff, es findet nur Unterschiede.

Viel Spaß.

Zur Sicherheit ist hier auch die XML-Datei noch einmal dabei. Auch das Programm, das sie erzeugt, entwickelt sich ja weiter.

[stan23]

stan23, haben Sie denn ein binding für den BS-Bus am laufen?  Das interessiert mich sehr, weil ich an eine Entwicklung, allerdings auf der Basis des schon als OpenHAB binding existierenden stiebelheatpump Projekts, denke.  Jetzt wird evtl. ein weiterer Grund klar, warum es bei mir schon 'mal eine XML-Definition der Kommandos gibt.

Bisher habe ich kein eigenes Binding geplant, sondern das Http-Binding benutzt.

Ich bin mir auch nicht sicher ob man da ein eigenes Binding benötigt, oder nur eine hübsche Liste aus Items anlegt (die ihre ID in schönsten Fall irgendwie aus dem XML beziehen).

[miwi]

stan23, PN.

Die letzte XML-Datei ist aus dem "raw" source code gebaut worden.  Darin kommen Elemente vor, die nicht Brötje-spezifisch sind.
Das wird durch die Logik, die conditional compile sections definiert, verursacht.

Wenn ich die XML-Datei wie oben einmal ohne und einmal mit "#define BROETJE_SOB" baue, ergeben sich Unterschiede bei
ProgNr 2270
ProgNr 5950, 5951, 5957, 5960, 5961, 5962, 5964
ProgNr 6046
ProgNr 6801 bis 6819
ProgNr 7841
ProgNr 9000

Die verschiedenen #ifdefs im Code funktionieren hoffentlich wie sie sollen.

Anbei die XML-Datei für #define BROETJE_SOB aktiviert

[freetz]

Hallo miwi,

danke für die Dateien, aber so ist der Diff natürlich nicht sinnvoll zu gebrauchen. Abgesehen von den Änderungen der Bezeichnungen hast Du weiter oben von ein paar kleinen Fehlern gesprochen, vielleicht kannst Du die entsprechenden Zeilen noch einmal filtern und posten, dann könnte man die sicherlich einfacher einarbeiten.

Gruß,

F.

[miwi]

Nun, wenn ich bedenke, dass die Umwandlung der command codes von lowercase hex in uppercase hex sehr viele Zeilen betrifft, dann ist es schon verständlich, dass die diff-Datei groß ist.  Deswegen habe ich ja auch gleich die Vergleichsdatei broetje_miwi.ino mit dazu gestellt.

Ich habe mit diff -Eiw noch einmal eine Datei erstellt, die die Unterschiede konzentriert zusammenfasst.  Und hier ist eine Liste:

1. Die "parameter types" sind in Gruppen von 8-bit, 16-bit, 32,-bit usw.
gegliedert und innerhalb jeder Gruppe alphabetisch geordnet.  Der Inhalt des
"nullable" flags 0x01 oder 0x05 ist in den Kommentaren vermerkt.
Ob die beiden Werte so richtig angewendet werden, bin ich mir nicht sicher. 

2. STR29 ist eine neue Beschreibung.
   Ebenso STR5721, 5734, 5737, 5774, 6631

3. STR42, STR9563 Tippfehler korrigiert
   dito bei ENUM1300 "\0\x02"

4. NEU:
   ENUM20, ENUM22, ENUM23, ENUM29, ENUM40, ENUM42
   ENUM44, ENUM46, ENUM47, ENUM48, ENUM3510, ENUM3541
   ENUM3544, ENUM4133, ENUM5040, ENUM5711, ENUM5712
   ENUM5734, ENUM5737, ENUM5770 (erweitert), ENUM5774,
   ENUM5909, ENUM5930, ENUM6623, ENUM6624, ENUM6631,
   ENUM7119, ENUM8100,

5. Neue #defines
   ENUM1380, ENUM1461, ENUM5896 (conditional compile),
   ENUM5909, ENUM8102 bis ENUM8130,

6. #defines in numerischer Reihenfolge eingeordnet
   ENUM5902, ENUM5904, ENUM5908, ENUM5982

Entsprechend den obigen Neuerungen habe ich einige Kommandos geaendert
bzw. eingefuegt (alle Angaben beziehen sich auf die ProgNr):
20, 22, 23, 26, 27, 29, 30, 31, 40, 42, 44, 46, 48, 120, 121, 1326, 1380,
1420, 1450, 1461, 1470, 1472, 1600, 2008, 2010, 2012, 2014, 2033,
2035, 2037, 2039, 2044, 2046, 2048, 2050, 2065, 2080, 3510, 3541,
3544, 3550, 4102, 4133, 5040, 5711, 5712, 5721, 5734, 5737, 5774,
5909, 6623, 6624, 6631, 7119, 7120, 8100 bis 8130,

.. vielleicht kannst Du die entsprechenden Zeilen noch einmal filtern und posten, dann könnte man die sicherlich einfacher einarbeiten.

Das Einarbeiten ist in der broetje_miwi.ino schon erledigt.

[freetz]

Vielen Dank für die Erläuterungen, dass die Änderungen: der ino schon eingearbeitet sind, sagte ich mir, aber es geht ja dann darum, diese in den (inzwischen erweiterten) Sketch von Gero zu überführen, daher meine Frage nach den Fehlern...

[miwi]

freetz, PN

[Jewe]

Ah. Jetzt wird per PN kommuniziert.

Gesendet von meinem F5121 mit Tapatalk

[freetz]

Keine Sorge, das war (in meinem Fall) sinnvollerweise das Verlegen einer doch eher speziellen Diskussion über die Möglichkeiten der Diff-Erzeugung ...
Ich werde Gero mal per PN anschreiben und fragen, wie er sich das am besten vorstellt und entweder meldet er oder ich mich dann wieder, wie wir die verschiedenen Entwicklungen am einfachsten zusammenführen.

Bezüglich der Platinen würde ich noch bis Weihnachten auf Interessensbekundungen warten und dann zum neuen Jahr hin die Bestellung aufgeben. Bis jetzt gibt es zwei Interessierte, was den Preis pro Platine natürlich gerade nicht so interessant macht. Vielleicht ist das aber für den einen oder anderen noch mal ein Anstoß...

Gruß,

F.

[gero]

Hallo,

ersteinmal vielen Dank, dass einige von Euch an der weiteren Pflege des Projektes mitwirken, bzw. diese übernehmen wollen
Ich halte es für sinnvoll, den Code auf github oder ähnlichem zu publizieren, damit auch eine Nachvollziehbarkeit der Änderungen gegeben ist.
Ebenso sinnvoll ist es alle Kommandos, Wertebereiche, usw. in einer zusätzlichen Datei (XML oder ähnlichem) zu pflegen.

Ich habe mal meine letzte (ungetestete) Version hier angehängt.
Die wesentlichen Änderungen neben dem Einpflegen neuer Parameter und entfernen einiger doppelter CommandIDs sind
- das Entfernen des IPWE und EthRly Interfaces
- das Hinzufügen eines GPIO-Interfaces

Ich weiß nicht, wieviele von euch das IPWE und EthRly Interface wirklich verwenden. Sollte es benötigt werden, muß es natürlich im Sketch verbleiben. Das GPIO-Interface habe ich angefangen, aber es ist noch komplett ungetestet und vielleicht (je nach Usecase) noch nicht vollständig genug. Ob ihr meine letzten Änderungen verwendet oder verwerft, liegt ganz bei euch.

Noch einmal zu meinen Beweggründen das Projekt abzugeben:
Es liegt auf jeden Fall nicht am fehlenden Interesse das Projekt weiterzuführen. Aber leider gibt es in meinem Beruf Zeiten, in denen man private Projekte hintenanstellen und auch die Arbeit in seiner Freizeit weiterführen muß. Dies hat in den letzten Monaten dazu geführt, dass ich auf Anfragen hier im Thread nur sehr langsam antworten konnte und nicht wirklich mit der Qualität in den Sketch einpflegen konnte, die ich gerne gehabt hätte. Ich möchte vor allem nicht der Grund sein, weshalb das Projekt einschläft oder nur sehr schleppend vorangeht.

Ich hoffe, dass ihr einen gemeinsamen Weg findet und werde weiterhin interessiert hier mitlesen.

Vieln Dank für euer Mitwirken,
Gero

[freetz]

Hallo Gero und alle,

@Gero: Danke für die Datei - ich sehe beim Überfliegen, dass die EthRly-Funktion schon entfernt ist (was ja mit der direkten GPIO-Ansteuerung auch Sinn machen würde), aber das IPWE noch drin ist, obwohl Du oben schreibst, dass es auch entfernt wäre? Ich wollte hier nur sicher gehen, dass dann alles noch drin ist und Du nicht einen Teil vergessen hast. Man könnte so oder so noch mal schauen, ob man das mit einem conditional versieht, dann kann es jeder (so wie bei den OneWire-Sensoren) selber entscheiden, ob er es mit auf dem Gerät haben will.

@alle: Ich habe jetzt einmal unter
https://github.com/fredlcore/bsb_lan
alle bisherigen Versionen bis 0.15a auf GitHub eingespielt. Mein nächster Schritt wäre dann, die 0.16-Version von Gero mit der Fassung von miwi abzugleichen und die dann als 0.17 einzuspielen. Danach ist dann jeder herzlich eingeladen, Änderungsvorschläge und Command-ID-Ergänzungen direkt über GitHub beizutragen. Man muss sich einmal anmelden und kann dann in wenigen Schritten Änderungen hochladen, die dann freigegeben werden können und dann letzlich zu einer neuen Version führen.
Eine kurze (englische) Anleitung findet sich hier:
https://guides.github.com/activities/hello-world/

Gruß,

F.

[freetz]

So, Version 0.17a ist nun online, das ist die aus Geros 0.16 und miwis Ergänzungen zusammengeführte Fassung, die ich dann noch um ein paar überflüssige Anführungszeichen bereinigt habe und die nun zumindest fehlerfrei kompiliert.
Ich würde miwi, Jens (und wenn möglich auch Gero) bitten, die Version einmal zu prüfen und idealerweise in einer Live-Umgebung zu testen. Ich selber kann das erst machen, wenn ich meine FHEM-Installation auf die neue GPIO-Syntax angepasst habe, da das EthRly-Segment ja jetzt fehlt.
Ich würde in dem Zug den Rückgabewert der GPIO-Funktion von "HIGH/LOW" auf "1/0" ändern, da dies dann mit den bisherigen Rückgabewerten übereinstimmen würde und die Anpassungen dann geringer ausfallen würden. Nur zur Info, falls sich jemand vor mir daran machen würde.

Als nächsten Schritt würde ich die .ino in drei Teile aufsplitten: Den Konfigurations-Teil, den CommandID-Teil und den eigentlichen Programmcode. Da nicht jeder von uns an allen drei Teilen (gleich intensiv) arbeitet, macht das das Einpflegen von Änderungen einfacher. Außerdem muss damit dann nicht bei jedem Update der Konfigurations-Teil erneut angepasst werden.

Gruß,

F.

[miwi]

Ein Dankeschön an freetz, der diese Arbeit übernommen hat!  Frederik hat, wie ich etwas verlegen festgestellt habe, gleich ein paar meiner Syntaxfehler korrigiert, über die der Compiler bestimmt gemeckert hat. Die Idee, das Programm in Teile zu zerlegen, sollte die zukünftige Arbeit vereinfachen.

Nun etwas anderes: Falls jemand den Busverkehr "live" anzeigen und dabei die Telegramme auseinandergenommen sehen möchte, habe ich dafür ein Python 2.7 Programm.  Voraussetzung ist ein Computer mit RS232-Interface, auf dem dieses Programm läuft.  Mit einem Laptop oder einem Raspberry mit Display (siehe Bild) kann man dann mitlesen, was sich auf dem Bus tut. Das Programm DEKODIERT die Nutzdaten NICHT, sondern zeigt Source/Dest, Telegrammtyp (GET, RET, INF, ..), cmdCode, Nutzdaten in hex, und CRC an.

Eine andere Möglichkeit, die ich schon verwendet habe, sind ein RS232-Sniffer wie z.B. EZ-Tap Pro (https://www.stratusengineering.com/product/ez-tap/), ein Laptop, der die Sniffer-Logdatei mit timestamps speichert, und ein Audiorecorder, mit dem ich festhalte, was ich an der Steuerung einstelle. Da der Audiorecorder bei der Wiedergabe die verflossene Zeit anzeigt, ist ein Bezug zu den mit timestamps versehenen Telegrammen in der Logdatei direkt herstellbar  Andere haben, wie sie in den Foren berichtet haben, einen Videorecorder eingesetzt.

[freetz]

So, Version 0.18 ist auf GitHub, hier sind nun Config-, Definitions- und Programmcode getrennt, die GPIOs können nun auch über 9 angesteuert werden und es findet eine Prüfung auf geschützte Pins statt, so dass nicht aus Versehen von anderen Programmbibliotheken genutzte Pins geschaltet werden können. Welche Pins das sind, kann jeder frei in der Config definieren.
IPWE habe ich auch wieder aktiviert und meine über die Zeit erfolgten Aktualisierungen eingepflegt. Wir haben immer noch Speicher genug, und wenn es doch mal eng werden sollte, kann man immer noch mal über eine Entfernung nachdenken.

Gruß,

F.

[freetz]

Zum neuen Jahr Euch erst einmal alles Gute und auch gleich eine neue Version der Software. Version 0.19 bringt Folgendes:

- Die Möglichkeit, mit DHT22-Sensoren die Temperatur und Luftfeuchtigkeit abzufragen (URL-Parameter /H)
- Die Möglichkeit, mit dem Parameter /A für definierte Werte einen gleitenden 24h Durchschnittswert zu liefern (und dabei nur 4 Byte pro Wert zu verbrauchen), ideal z.B. für Brennermodulation oder Außentemperatur
- IPWE liefert ebenfalls die ausgewählten Durchschnittswerte
- IPWE kann nun aus der Kompilation herausgenommen werden, wenn man den Speicher (perspektivisch) für andere Dinge benötigt
- ein Bugfix für Elco Thision-Geräte (doppelte Definition des Brennermodulationswerts)
- Entfernen von einigen Leerzeichen am Ende einiger Definitionen
- Der URL-Parameter /temp wurde entfernt, da er identisch ist mit /T

Gruß,

F.