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

Begonnen von justme1968, 29 November 2014, 19:50:40

Vorheriges Thema - Nächstes Thema

miwi

Schoen, dass sich fuer beide Projekte etwas Gutes aus den jeweiligen Entwicklungen ergibt!  Ich schaetze beide Entwicklungen, bin aber wegen der hoeheren Aktivitaet dann hier geblieben.  Mit welchem Pi Interface soll denn diese neue Interfaceplatine verbunden sein, mit dem Hardware UART oder mit einem Software UART aehnlich dem Arduino?  Hast Du damit schon eigene Erfahrungen gesammelt, Frederik?

HARDWARE UART am Raspi: Mit ist es schleierhaft, wie der RaspPi mit dem Hardware UART feststellen will, ob auf dem Bus Stille herrscht, bevor er zu senden anfaengt, und wie er waehrend des Sendens Kollisionen erkennen kann.

SOFTWARE UART am Raspi: Ich weiss nicht, ob der RaspPi ein Software UART an GPIO pins mit der geforderten timing-Praezision bedienen kann. Die Latenzzeiten bei einem Nicht-Realtime OS koennen deutlich laenger als das bit-timing sein. Ohne den Linux realtime patch beobachtet man Latenzzeiten, die mehr als 350 us lang sein koennen.  Selbst MIT dem realtime patch liegt die max. Latenzzeit bei ungefaehr 60 us, bei fast einem Drittel der bit-time.  Referenz: "Raspberry Pi real-time kernel" (https://emlid.com/raspberry-pi-real-time-kernel/).   Da ein bit 208 us lang  ist und man beruecksichtigen muss, dass sich die timing-Fehler innerhalb eines byte frames mit 11 bits akkumulieren, habe ich Zweifel, ob sich ein S/W UART unter Linux auf dem Raspi sicher betreiben laesst.  Bei einem kontinuierlichem Strom von Zeichen machen sich solche verlaengerten timings erst Recht bemerkbar.

Ich habe mir solche Ergebnisse anderer Entwickler angeschaut und bin zu dem Schluss gekommen, dass ein software UART beim Pi wegen der Latenzzeiten im Betriebssystem WAHRSCHEINLICH nicht fehlerfrei funktioniert.  Deswegen habe ich den Gedanken verworfen, einen Linux LP-Bus-Treiber mit SW-UART fuer Raspberry GPIO-Pins zu schreiben.  Die Funktion waere aehnlich der des Arduino gewesen.

ALTERNATIVE 1: Denkbar waere evtl. eine eine Loesung mit pigpio, obwohl dort parity handling fehlt (und extern im user code dazugestrickt werden muss) und pigpio leider im user space laeuft.  Versuchsweise habe ich 'mal Python-Code geschrieben, der mir zu 8 Datenbits ein odd parity bit dazu baut und an pigpio uebergibt. Sehr merkwuerdig ist, wie pigpio bei mehr als 8 bits zwei Bytes aneinandereiht erhalten will und wo dabei das neunte, das Parity-Bit, steht: im LSB des zweiten Byte.  Aber auch pigpio muesste (a) vor dem Senden auf einen stillen Bus warten koennen und (b) beim Empfang nach etwa 4ms Stille beschliessen, dass ein vollstaendiges Telegramm angekommen ist. Da kommt mir die Beschreibung der pigpio Funktionen nicht ganz klar vor.  Anm.: Das bit timing von gesendeten Daten war uebrigens tadellos, was dem DMA-Zugriff geschuldet ist, dessen timing unabhaengig vom scheduling des OS ist.

ALTERNATIVE 2: Ich tendiere, um nicht das Rad neu erfinden zu muessen, zu einer zweiten Alternative mit einer I/F-PLatine, auf der zusaetzlich ein Arduino micro sitzt, der ausschliesslich das Bus timing besorgt. Diesen Code haben wir ja schon. Er muss nur von einer endless loop umschlossen werden, die immer ein ganzes Telegramm vom Bus oder vom Raspberry empfaengt und es jeweils an die andere Seite weiter sendet.  Da die Kommunikation mit dem Bus im Halbduplex-Verfahren ablaeuft, braucht es auch kein flow control, solange der Computer in der Lage ist, empfangene Telegramme zu verarbeiten, bevor ein neues Telegramm ankommt.  Abgesehen davon koennte man den Bus sowieso nicht mit flow control bremsen.

Die I/F Platine kann dann mit einem Computer verbunden sein, auf dem ein nicht-realtime OS wie Linux und sogar mit einer Hochsprache wie Python oder Java laufen, dessen timing von dem des Buses unabhaengig ist. 

freetz

Hallo miwi,

die Platine wird mit dem Hardware-UART verbunden. Ob und wie Johannes' Lösung Kollisionen auf dem Bus vermeidet, müsstest Du ihn fragen, bzw. im (Pyhton-)Quellcode auf seinem GitHub-Repository nachlesen. Ich kann nur sagen, dass es an sich funktioniert hat, es kann aber auch sein, dass Johannes' Lösung für eine 1:1-Kommunikation ausgerichtet ist. Da kämen dann ja "nur" die gelegentlichen Broadcasts in die Quere. Wenn da beide Seiten gleichzeitig senden, stört das die Heizung nicht, und der Pi bekommt im worst case keine oder eine Fehlermeldung zurück und kann dann noch einmal senden, das ist der Arduino-Umsetzung ja letztlich nicht ganz unähnlich. Je mehr Teilnehmer am Bus hängen, desto schwieriger würde so ein Ansatz natürlich, aber wie gesagt, das ist jetzt nur meine Vermutung, vielleicht ist das auch ganz anders umgesetzt.

Gruß,

F.
Alle Infos zur Anbindung von Heizungssystemen mit PPS-, LPB- bzw. BSB-Bus ans LAN gibt es hier:
https://github.com/fredlcore/bsb_lan

Alle Infos zum WLAN-Interface "Robotan" für Ambrogio/Stiga/Wolf und baugleiche Rasenmähroboter:
https://github.com/fredlcore/robotan

miwi

#992
Danke fuer die Antwort, Fredrik.

Anbei ein Bild einer I/F-Platine, die ich vor laengerer Zeit einmal entwickelt habe.  Man sieht links zwei parallel verbundene RJ12-Buchsen; es sind zwei Buchsen, um darueber das Kabel zwischen LP-Bus und dem OCI700 zu schleifen. An den seriellen Interfaces rechts steht dann der Datenstrom zum Mitlesen an.
Die weissen ICs sind Optokoppler, der schwarze Block darunter ein DC/DC-Wandler. Oben ist der Arduino micro, rechts je ein USB- und RS-232 Interface zu einem PC.   Das Projekt, die Platine im Formfaktor an den Raspi anzupassen und direkt steckbar ohne die jetzt noch vorhandene TTL-RS-232 Pegelwandlung zu gestalten, ist noch irgendwo auf der ToDo-Liste.  Schon mit diesem Entwurf erhalten mein Raspi (mit seiner eigenen RS-232 <=> 3.3V Pegelwandlung fuer das HW UART) oder ein PC ihre Daten vom Bus.

Die kleine Platine oben ersetzt mir uebrigens den Gang zur real existierenden Heizung, denn sie bildet am Labortisch einen LP- oder BS-Bus nach. Ueber den DB-9 connector kann ein Computer Telegramme auf diesen "Bus" modulieren, die ich frueher einmal mit diesem Interface abgegriffen und gespeichert habe.  Das ist oft recht praktisch, um Software zu testen.

s0me0ne

Zitat von: freetz am 17 September 2017, 20:58:23
Ich würde das Protokoll an sich gerne noch mit in BSB-LAN einbauen, bräuchte aber entweder eine QAA70 (am besten noch mit entsprechender Gegenstelle) oder jemanden, der eine solche Kombi sein Eigen nennt und als Beta-Tester bei der Analyse mithelfen kann/will.

Hallo Fredrik,

ich besitze eine Sieger TG11 mit Siegermatic s42DB wo eine RFD 40(QAA70) angeschlossen werden könnte. So bin ich auch auch den Thread gestoßen.
Wie kann ich unterstützen?

Schönen Abend
Florian

freetz

Hallo Florian,

danke für Dein Angebot - was ich bräuchte wären Mitschnitte von den Protokollen, die über die Schnittstelle zwischen der S 42 DB und der QAA70 gehen, wie das geht, ist in der FAQ erklärt. Dann könnte ich schauen, ob und wie sich die Telegramme in BSB_Lan einbauen lassen. Ich weiß aus Dokumenten im Netz bisher nur grob, dass vermutlich nur deutlich abgespeckte Funktionen in diesem älteren Protokoll abgebildet werden. Ob also z.B. nur ein Auslesen und kein Setzen der Werte möglich ist. Nichtsdestotrotz könntets Du vermutlich auch schon mit der jetzigen Software und einer Relaiskarte die Heizung zwischen Normal- und Absenkbetrieb wechseln lassen und das über FHEM anhand von externen Parametern (Uhrzeit, Außen- oder Innentemperatur) steuern.

Aber wie gesagt, wenn es Telegramm-Mitschnitte von den einzelnen Funktionen gibt, will ich gerne versuchen, das einzubauen.

Gruß,

F.
Alle Infos zur Anbindung von Heizungssystemen mit PPS-, LPB- bzw. BSB-Bus ans LAN gibt es hier:
https://github.com/fredlcore/bsb_lan

Alle Infos zum WLAN-Interface "Robotan" für Ambrogio/Stiga/Wolf und baugleiche Rasenmähroboter:
https://github.com/fredlcore/robotan

Schotty

Zitat von: s0me0ne am 23 Oktober 2017, 20:20:13
[...] Siegermatic s42DB wo eine RFD 40(QAA70) [...]

Hmmm, sieht für mich irgendwie aus wie eine Brötje Eurocontrol..?!
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

lynckmeister

Hallo Leute, kurze Frage zum Anschluss des Adapters,
ich habe einen Mega und den Adapter auf dem Breadboard... seit gestern gibt es ja eine neus Schaltbild das auch etwas verändert wurde... aber mir fehlt jetzt der zweite BC107 , aber ich nehme mal an nach dem alten Plan sollte es auch funktionieren... (oder??)

Also ich habe den Mega vor mir die Stromversorgung schliess ich wohl am VIN Pin und Ground an Ground an ... aber die RX und TX bin ich nicht sicher...
ist  68 und 69 A13 und A14 unten links?! Ich habe auch noch die Pins 0 und1 mit der Bezeichnung RC und TX Rechts unter der Shield Platine ...

Anbei mal mein MEGA... vielen dank für eure Hilfe..

babajun


Schotty

#998
Zitat von: lynckmeister am 02 November 2017, 23:14:20
Hallo Leute, kurze Frage zum Anschluss des Adapters,
ich habe einen Mega und den Adapter auf dem Breadboard... seit gestern gibt es ja eine neus Schaltbild das auch etwas verändert wurde... aber mir fehlt jetzt der zweite BC107 , aber ich nehme mal an nach dem alten Plan sollte es auch funktionieren... (oder??)
Ja, der Adapter laut 'altem' Schaltplan funktioniert natürlich nach wie vor! Der neue bezieht sich auf den aktuellen/neuen Adapter, der sowohl am Arduino als auch am Raspberry angeschlossen werden kann, siehe hier: https://forum.fhem.de/index.php/topic,29762.msg697267.html#msg697267

Zitat
Also ich habe den Mega vor mir die Stromversorgung schliess ich wohl am VIN Pin und Ground an Ground an ... aber die RX und TX bin ich nicht sicher...
ist  68 und 69 A13 und A14 unten links?! Ich habe auch noch die Pins 0 und1 mit der Bezeichnung RC und TX Rechts unter der Shield Platine ...
Den Adapter bitte an GND (Ground/-) und 5V (+) anschließen! Bei Vin (ist auf dem alten Schaltplan m.E. leider etwas missverständlich beschriftet) kann es m.E. eventuell Probleme geben, falls du bspw. ein 9V-Netzteil verwendest.
68 und 69 sind die Pins A14 (Rx) und A15 (Tx), nicht A13 und A14. Ist auch im HowTo zu finden: "BSB-Interface (...) Für diese Konfiguration wird Pin A14 (68) als RX, und Pin A15 (69) als TX genutzt" (s. "HOWTO_de.pdf", S.1/8). In der PDF-Version vom deutschen Readme bei GitHub sieht man derzeit auch noch die Bilder vom 'alten' Adapter, dort sind auch die Anschlüsse von A14, A15, GND und 5V bei der bestückten Platine gut zu erkennen.

Gruß
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

lynckmeister

Vielen Dank, damit ist es klar...
So ich habe übrigens eine Brötje L-UB 25 C .. genau diesen Typ habe ich nicht gefunden, aber ich hoffe , dass das Protokoll nicht alzu unterschiedlich ist von den anderen...
Jedenfalls hab ich jetzt vorn am Bedienteil CL+ und CL- an der Wartungsbuchse angeschlossen am Adapter. Die LED flackert ab und zu und ich erreiche das Webinterface. Allerdings kommt bei allen anfragen Query Failed...
wie gehe ich am besten vor um den Fehler zu finden.. habt ihr ein paar Vorschläge für mich ? Oder ist es am End doch die Heizung und der Sketch versteht nur Bahnhof?
Grüße
Filip

Schotty

Zitat von: lynckmeister am 04 November 2017, 09:25:36
(...)Brötje L-UB 25 C (...) Wartungsbuchse (...)
Welcher Kesselregler und welche Bedieneinheit sind verbaut? Schon ISR Plus oder noch Eurocontrol? Genauere Angaben und notfalls auch Fotos bitte..
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

freetz

Wenn die LED flackert, wenn Du eine Kategorie-Seite aufrufst (also da wo dann reihenweise "query failed" kommt), dann klappt das Senden, aber der Empfangsweg funktioniert nicht. Wenn die LED ohne Abruf von Parametern flackert, aber nicht, wenn Du die Kategorie-Seite aufrufst, dann klappt der Empfang, aber das Senden nicht. Dementsprechend kannst Du im Schaltplan die Verbindungen prüfen, notfalls mit einem Oszilloskop.
Wenn alle Stricke reißen, kannst Du Dich auch noch an der Sammelbestellung beteiligen.

Gruß,

F.
Alle Infos zur Anbindung von Heizungssystemen mit PPS-, LPB- bzw. BSB-Bus ans LAN gibt es hier:
https://github.com/fredlcore/bsb_lan

Alle Infos zum WLAN-Interface "Robotan" für Ambrogio/Stiga/Wolf und baugleiche Rasenmähroboter:
https://github.com/fredlcore/robotan

lynckmeister

also LED Flackert wenn ich ein Query auslöse über die Webseite und LED flackert auch von selbst ... ich glaube hier hiegt kein Problem vor...
Ich denke ich muss mal den Monitor aktivieren, habe aber noch nciht gesehen wo ich dann die Logausgaben sehe...

anbei ein Bild von der Bedienheinheit... und der ganzen Heizung.. sie ist von 2008 ich denke ISR Plus gab es noch nicht.
Wie erkenne ich den Kesselregler ?

Danke für eure Wochenendhilfe;))

Schotty

#1003
Die L-UB25C ist im Grunde der Vorgänger der SOB, nur eben ohne nachgeschalteten Wärmetauscher, was die SOB zum Brennwerter macht. ISR Plus ist bei dir verbaut. Kesselregler siehst du, wenn du die beiden Plastik'schrauben' links und rechts am Bedienteil aufdrehst (ca 90Grad nach links) und dann vorsichtig alles nach unten klappst, dann solltest du einen Blick auf den Kesselregler riskieren können (das Teil, wo die ganzen Kabel und Fühler etc angeschlossen sind).
ABER: Hast du bei der 'Wartungsbuchse' vorne die richtigen Anschlüsse genommen? Von oben gezählt (sind ja 4 Pins) ist der 2. v. oben CL+, und der 3. v. oben CL-.
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

freetz

Monitor mit /M1 als URL-Aufruf aktivieren, dann den Arduino mit USB an den Rechner anschließen und in der Arduino IDE den Seriellen Monitor starten und schauen, was passiert...
Alle Infos zur Anbindung von Heizungssystemen mit PPS-, LPB- bzw. BSB-Bus ans LAN gibt es hier:
https://github.com/fredlcore/bsb_lan

Alle Infos zum WLAN-Interface "Robotan" für Ambrogio/Stiga/Wolf und baugleiche Rasenmähroboter:
https://github.com/fredlcore/robotan