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

[freetz]

Kurzer Nachtrag zur LED: Leider tut sich da nicht nur nichts, das Ersetzen des 287ers durch die LED lässt gar keine Daten mehr durch, sowohl mit dem 2k2, als auch mit einem 560er und dem 287er als Vorwiderstand. Die LED ist die gleiche Variante, wie ich sie an der von Dir vorgesehenen Stelle benutze und sie ist auch heile. Langes Bein zu Vin, kurzes zu Rx, richtig?

Viele Grüße,

F.

[freetz]

Ich würde gerne die Frage von sokolok noch einmal "aufwärmen", wäre es nicht eigentlich einfacher
und sinnvoller die Anbindung tatsächlich über das OpenTherm Protokoll zu realisieren, ich zitiere hierzu einmal das Wiki von OpenTherm :
"OpenTherm ist herstellerunabhängig. Ein Regler von Hersteller A kann mit einer Heizung von Hersteller B kommunizieren."

Ich bin zwar nicht Gero, aber ich wäre, wenn es denn sinnvoll ist, bereit, da etwas Programmierarbeit zu investieren - wenn es denn sinnvoll ist, was ich im Moment nicht glaube. Was Gero entwickelt hat, ist eine web-basierte Schnittstelle zum BSB/LPB-Bus der Brötje/Elco-Thermen. OpenTherm ist, so wie ich es verstehe, ebenfalls ein elektrischer Bus. Statt des Mini-Webservers in Geros Sketch bräuchte man also einen zweiten elektrischen Ein- und Ausgang, so dass der Arduino-Sketch dann die Signale zwischen den beiden Anschlüssen (OpenTherm und BSB/LPB) entsprechend übersetzen würde. Dafür könnte man einen Teil von Geros Arbeit sicher übernehmen (der Teil, der die Befehle an den BSB/LPB-Bus schickt und empfängt), aber der OpenTherm-Teil müsste völlig neu entwickelt werden, sowohl die Hardware- als auch die Softwarekomponente. Und dann hätte man nur die Anbindung an ein Steuergerät geschaffen, das dann seinerseits wiederum über eine FHEM-kompatible Anbindung verfügen müsste, also vermutlich eine weitere Hardwarekomponente, wenn das Steuergerät selber nicht über Funk oder Web zugänglich ist. Also sehr viel Aufwand für etwas, was jetzt schon geht.

Hinzu kommt, dass eine Menge an Parametern, die dank Geros Entwicklung jetzt webbasiert konfigurierbar sind, nicht mehr gehen würde, weil die OpenTherm-Parameter doch recht generisch sind. Der einzige Vorteil, den ich in Deinem Vorschlag sähe, wäre, dass man eine anderes, ggf. günstigeres Raumsteuerungsgerät verwenden könnte. Aber das ist wie gesagt eine ganz andere Zielstellung.

Wenn es allerdings einzig und allein darum gehen sollte, bestimmte webbasierte Requests, die auf den OpenTherm-IDs basieren sollten, auf die entsprechenden BSB-Kommandos umzusetzen, dann würde ich mir das ggf. überlegen, da zu unterstützen. In dem Fall bräuchte ich dann aber deutlich mehr Infos über die einzelnen Parameterkomponenten, denn aus Deiner Auflistung wird nicht deutlich, wofür die einzelnen kommaseparierten Werte stehen.

F.

[freetz]

Hallo Gero,

hier noch mal ein Nachtrag zu den folgenden Werten, die ich letzte Woche an der Therme abgelesen hatte:

886: -15 Grad (ohne Nachkommastelle)
887: 75,0 Grad (mit einer Nachkommastelle)
888: 40,0 Prozent (mit einer Nachkommastelle)

Wenn ich nun diese Werte abrufe, bekomme ich bei 886 den Wert 241 Grad angezeigt, bei 888 sagt er mir "unknown type" und bei 895 "decoding error". Falls Du zur Fehlerbehebung noch mal einen Mittschnitt brauchst, sag' Bescheid.

F.

[cpet]

Hallo freetz,

mit den Details kenne ich mich ehrlich gesagt natürlich nicht so gut aus, aber ich habe da noch mal ein paar Sachen gefunden,
unter anderem ein Testtool für Windows sowie die Protocol Specification und habe dies mal angehangen.

Gruß
cpet

[freetz]

Hallo cpet,

es geht erst einmal gar nicht um die Details, sondern was damit bezweckt werden soll - meine Frage ist also eher allgemeiner Natur: Willst Du einfach eine fremde Steuerung an die Therme anschließen? Dann ist das hier einfach nicht das richtige Projekt dafür. Gibt es eine Möglichkeit, über OpenTherm die Therme einfacher in FHEM einzubinden? Dann müsstest Du sagen was dann einfacher wäre als bei der Variante von Gero, die ja reibungslos läuft. Irgendwelche Testtools und Spezifikationen würden wenn überhaupt erst in einem späteren Stadium etwas bringen.

F.

[gero]

hier nun wie versprochen die Telegramm-Mitschnitte der meisten noch fehlenden Parameter, ich hoffe, das ist es, was Du benötigst, ansonsten sag' noch mal Bescheid:

Danke für die Werte. Ich werde zusehen, dass ich die Informationen möglichst bald in eine neue Version integriert bekomme.

Gruß,
Gero

[freetz]

Prima, ich bin Montags bis Mittwochs nicht zu Hause, von daher könnte ich eventuelle Änderungen entweder davor oder danach testen, aber keine Eile, nur zur Info...

[gero]

Hallo Gero,

erst mal Klasse was Ihr hier schon auf die Beine gestellt habt, ich denke als nächsten Schritt auch darüber nach 
meine Brötje WBS22 mit in FHEM anzubinden (hat auch den LPB-Bus).

Ich würde gerne die Frage von sokolok noch einmal "aufwärmen", wäre es nicht eigentlich einfacher
und sinnvoller die Anbindung tatsächlich über das OpenTherm Protokoll zu realisieren, ich zitiere hierzu einmal das Wiki von OpenTherm :
"OpenTherm ist herstellerunabhängig. Ein Regler von Hersteller A kann mit einer Heizung von Hersteller B kommunizieren."

Zu den Mitbegründern von OpenTherm gehören fast alle Hersteller von Heizungsthermen bzw. Hersteller von Steuerungen.
Darunter z.B. auch Siemens die ja unter anderem auch die Regelungen für Brötje herstellen.
Das RRG von Brötje kommuniziert auch mit diesem BUS-Protokoll, und über dieses sind sämtliche Konfigurationen von der Therme Abruf-
und Steuerbar.
Da dies also über eine Herstellerunabhängige Schnittstelle geschieht wäre es deutlich Universeller und unterm Strich doch wahrscheinlich
auch deutlich einfacher umzusetzen als für zig. Geräte.

Ich kann natürlich verstehen das hier schon eine Menge Herzschmerz und Hirnschmalz eingeflossen sind, aber ich denke auch das eine
Umstellung bzw. Portierung auf OpenTherm gar nicht allzu schwierig sein dürfte.
Ich würde es auch selber versuchen, nur leider sind meine Programmierkünste mehr als Bescheiden.

Hallo Christian,

freetz hat deine Frage schon perfekt beantwortet:

Ich bin zwar nicht Gero, aber ich wäre, wenn es denn sinnvoll ist, bereit, da etwas Programmierarbeit zu investieren - wenn es denn sinnvoll ist, was ich im Moment nicht glaube. Was Gero entwickelt hat, ist eine web-basierte Schnittstelle zum BSB/LPB-Bus der Brötje/Elco-Thermen. OpenTherm ist, so wie ich es verstehe, ebenfalls ein elektrischer Bus. Statt des Mini-Webservers in Geros Sketch bräuchte man also einen zweiten elektrischen Ein- und Ausgang, so dass der Arduino-Sketch dann die Signale zwischen den beiden Anschlüssen (OpenTherm und BSB/LPB) entsprechend übersetzen würde. Dafür könnte man einen Teil von Geros Arbeit sicher übernehmen (der Teil, der die Befehle an den BSB/LPB-Bus schickt und empfängt), aber der OpenTherm-Teil müsste völlig neu entwickelt werden, sowohl die Hardware- als auch die Softwarekomponente. Und dann hätte man nur die Anbindung an ein Steuergerät geschaffen, das dann seinerseits wiederum über eine FHEM-kompatible Anbindung verfügen müsste, also vermutlich eine weitere Hardwarekomponente, wenn das Steuergerät selber nicht über Funk oder Web zugänglich ist. Also sehr viel Aufwand für etwas, was jetzt schon geht.

Hinzu kommt, dass eine Menge an Parametern, die dank Geros Entwicklung jetzt webbasiert konfigurierbar sind, nicht mehr gehen würde, weil die OpenTherm-Parameter doch recht generisch sind. Der einzige Vorteil, den ich in Deinem Vorschlag sähe, wäre, dass man eine anderes, ggf. günstigeres Raumsteuerungsgerät verwenden könnte. Aber das ist wie gesagt eine ganz andere Zielstellung.

Wenn es allerdings einzig und allein darum gehen sollte, bestimmte webbasierte Requests, die auf den OpenTherm-IDs basieren sollten, auf die entsprechenden BSB-Kommandos umzusetzen, dann würde ich mir das ggf. überlegen, da zu unterstützen. In dem Fall bräuchte ich dann aber deutlich mehr Infos über die einzelnen Parameterkomponenten, denn aus Deiner Auflistung wird nicht deutlich, wofür die einzelnen kommaseparierten Werte stehen.

F.

Bei der hier vorgestellten Lösung handelt es sich um eine webbasierte Schnittstelle zu Heizungen, die über das BSB-Protokoll kommunizieren.
Bitte beachte, dass von dem Sketch nur das BSB-Protokoll unterstützt wird. Am LPB-Protkoll ist evtl. Peppi noch dran.
Meine Heizung spricht kein OpenTherm. Die Frage ist, welche Vor- und Nachteile es hätte ein OpenTherm kompatibles Webinterface anzubieten. Da bin ich mir zur Zeit noch sehr unsicher.

Gruß,
Gero

[gero]

Kurzer Nachtrag zur LED: Leider tut sich da nicht nur nichts, das Ersetzen des 287ers durch die LED lässt gar keine Daten mehr durch, sowohl mit dem 2k2, als auch mit einem 560er und dem 287er als Vorwiderstand. Die LED ist die gleiche Variante, wie ich sie an der von Dir vorgesehenen Stelle benutze und sie ist auch heile. Langes Bein zu Vin, kurzes zu Rx, richtig?

Da hilft nur messen und Fehler suchen.
Ganz ehrliche Frage: Wie wichtig ist dir die LED?
Ich habe gerade keine Lust und Zeit meinen verbauten, lauffähigen Adapter umzulöten.

Gruß,
Gero

[freetz]

Nein, so war das auch gar nicht gemeint, dass Du Deinen Adapter auseinandernehmen sollst. Ich wollte nur sicher gehen, dass ich nichts grundsätzlich falsch gemacht habe und Du hattest ja nach einer Rückmeldung gefragt. Natürlich geht es auch ohne die LED (an der Stelle)...

[sokolok]

Hallo.
In my opinion, the project should be completed - and the web interface is 30% of practicality and ease of use.
I as a user, for example, is important and visual viewing parameters and the accumulation of statistics.
OpenTHERM de-facto standard for management and control systems for intelligent home heating, for it is written, a lot of applications for any purpose and platform.
http://otgw.tclcode.com/index.html#intro just an example of one of the most popular projects, open source and powerful community.
As an option, the integration of the existing controller in the control system based on OpenHUB example, requires minimal effort.
Unfortunately Siemens still continues the policy of promoting its own standards undocumented, and very tight turns on the use of universally recognized protocols.
Try to look at the issue from this side.
I like see more prospects in the development of the converter ISR / LBP beads - OpenTHERM, and from the point of view of interoperability and in terms of practicality.

[freetz]

Sokolok,
as we discussed further up in German already: Gero's interface is a web-to-BSB interface. What you are asking for is a OpenTherm-to-BSB interface which would require a completely newly designed, additional electrical interface component in order to send and receive data to/from other OpenTherm devices. This is not something that could be done by adjusting Gero's code. It would also not only need an OpenTherm environment to test its functuality (which I don't have and I assume Gero doesn't either), you still would need a web-to-OpenTherm interface (such as the one you linked to in your post) in order to use the OpenTherm tools you want. So in the end you would have to have two interfaces, plus you lose quite a lot of information (because OpenTherm does not have matching commands to all the BSB parameters), only to do something you can already do with FHEM (control devices and have graphical data)? If FHEM is too complicated for you (as it is still to me) and you use Max! thermostats, you can also try MaxBuddy and have full control over your thermostats and have graphical display of your data, too.

If you really need OpenTherm compatibility, take a Raspberry Pi, receive OpenTherm commands on the Pi (you'd need to figure out how to do that) and translate the commands to the respective http-commands of Gero's interface. That should be a relatively easy to do option if you really want to go ahead with this. However, I don't think anyone here can help you with that due to us lacking OpenTherm devices, so you should rather ask the OpenTherm community. If it's really powerful, it should be no big issue to get this idea translated into practice.

F.

[sokolok]

Hello Freetz.
You probably do not understand me correctly.
I talked about the web interface on the adapter, such as it was in the first version, or the option of adapting to the existing web interface (openterm as an example)
WBR.

[freetz]

Ok, so you mean the output of the web-interface (i.e. the responses given to URL-based commands) should be adapted/adjusted? While that would be possible (and if it's exactly clear how the command conversion should take place, I would be willing to help), this still would not necessarily have to take place in the firmware. A wrapper could be written, running on a NAS, a raspberry or wherever, that takes whatever URL-based commands, converts them and sends them to Gero's interface and returns the responses accordingly. That was basically my suggestion in the last paragraph.

However, I do not know how the interfaces was like in the first version, so I can't comment on that, but as I said, if you have a clear description on how commands should be sent and received, something might be possible, especially since Gero added the value-only return format for the query command which I am using in the ipwe section of the firmware for my purposes.

[sokolok]

P.S.
I do not need an interface openterm, I do not use it - I have the whole system is based on Siemens.
Here's the problem that Siemens no decent software, there is no clear and simple display facilities.
I was holding a Webserver OZW772, it's terrible for configuring and programming ....
But other options have not yet seen ....
Proposal to use openterm - is an attempt to unify the decision, the opportunity to use different systems and different projects.