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

MoinMoin

Zitat von: Shortypower am 15 März 2021, 12:08:04
Ich habe irgendwo gelesen, dass jemand mit dem BSB LAn jetzt einen Raumtemperatursensor simuliert und diesen mit einbezieht in die Berechnung.
Sowas finde ich höchst interessant. Ich habe ja die Temperaturen aller meiner Räume zur Verfügung und könnte da problemlos (clever) einen "Mittelwert" übermitteln, als virtuellen Raumsensor.
Genau das mach ich. Wenn auch bei meiner sehr trägen Bodenheizung mit noch nicht perfektem Erfolg. Raumtemperaturen bringen der Heizung vor Allem etwas, wenn man Radiatoren hat, die schnell reagieren. Wenn meine Heizung beginnt zu heizen, kann der Effekt gut 2h gehen (dafür ist sie auch nach dem Ausschalten länger noch warm).

Deshalb versuch ich gerade noch, Wetter-Vorhersagen in die Berechnung reinzubringen. Wenn der Aussensensor um 10 Uhr morgens 5 Grad misst, aber am Nachmittag eine Kaltfront kommt mit 0 Grad, ist die Heizung zu langsam bei mir. Deshalb versuch ich die träge Heizung anhand der Vorhersage schon früh zu triggern, mehr zu heizen.

Ich mach das mit der BSB-Lan-Integration in IoBroker. Dort kann man auch Temperatur-Sensoren reinnehmen und dann anhand von kleinen Skripts (Javascript) etwas sinnvolles programmieren...

Jewe

Zitat von: Shortypower am 15 März 2021, 12:08:04
Ich habe irgendwo gelesen, dass jemand mit dem BSB LAn jetzt einen Raumtemperatursensor simuliert und diesen mit einbezieht in die Berechnung.
Sowas finde ich höchst interessant. Ich habe ja die Temperaturen aller meiner Räume zur Verfügung und könnte da problemlos (clever) einen "Mittelwert" übermitteln, als virtuellen Raumsensor.

Wokann man sich in so ein Thema am Besten mal einlsen? Habt ihr Tipps?

Servus,

das mache ich für meinen Heizkörper-Heizkreis. Ich mittele aus verschiedenen Räumen die Ist-Temperatur und übergebe diese an die Heizung über den BSB. Dabei hat sich ergeben, dass manche Räume dann zu wenig Wärme bekommen oder es keinen Einfluss auf die Vorlauftemperatur hat, weil dann alle Räume in der Mittelwertberechnung enthalten sind (habe Räume in denen die Heizung auch mal aus ist).

Das habe ich inzwischen so gelöst, dass ich die Ist-Temperatur der HM-RT´s an den Heizkörpern so auswerte, dass wenn die Ventilöffnung > 10 ist, diese dann in die Mittelwertberechnung miteinbezogen werden und sonst nicht. Desweiteren übermittele ich auch die Soll-Temperatur der Heizkörper die eingeschaltet (d.h. Ventilöffnung >10) an die Heizung als Raum Sollwert.

Da ich auch glücklicher Besitzer einer Solarthermie-Anlage bin, schaue ich morgen um 8 Uhr nach dem Wetter und würge dann ggf. die Heizung ab. Das spart dann auch ein paar Pellets :-)

Bei einer Fußbodenheizung die Raumtemperatur an die Regelung zu übermitteln ist sicherlich von nöten. Das Ein / Ausschalten der Fußbodenheizkreise macht meistens keinen Sinn.

Wenn Interesse besteht, kann ich das gerne hier mal posten.

Grüssle, Jens

PS. Bin immer noch sehr Glücklich mit meinem Mega und der "letzen" Version. :-)

freetz

Ich nehme mal ein Thema wieder auf, was wir vor gut einem/eineinhalb Jahr/en bei der Umstellung von Software- auf Hardware-Serial schon mal diskutiert haben, wobei mir aber jetzt etwas klar geworden ist:
Und zwar ging es um die Frage, warum Gero damals eigentlich SoftwareSerial genommen hat und nicht auf HardwareSerial gesetzt hat, wie andere Projekte auch. Ich hatte damals angenommen, dass es daran lag, dass HardwareSerial womöglich die etwas abweichende serielle Schnittstellekonfiguration 8O1 (statt 8N1) nicht unterstützt hatte.

Nun wird mir aus einem anderen Zusammenhang aber klar(er), dass es vermutlich eher daran lag, dass man bei Verwendung von HardwareSerial die auf dem Bus verwendete Kollisionserkennung CSMA/CD nicht umsetzen kann, zumindest nicht in der damals angedachten Art und Weise. Denn bei HardwareSerial übergibt man die Daten ja byteweise dem UART, der sie dann in einen Puffer schreibt und dann ausgibt. Nur über SoftwareSerial ließe sich das bitweise machen.

So wie ich den Code (der ja auch immer noch in der bsb.cpp für die Mega-User mit Platine V2 und kleier enthalten ist) aber schon seit einiger Zeit verstehe, ist dieses bitweise Senden nie passiert, weil immer ein ganzes Byte an BSBSoftwareSerial::write übergeben wurde, also im Endeffekt das Gleiche wie jetzt auch. Vielleicht war das damals auch noch auf ToDo und ist einfach noch nicht (vollständig) umgesetzt worden.

So verhält sich BSB-LAN nun nicht gerade "sozial" auf dem Bus, aber wenn sich letztlich alle an die Regeln halten und nur einer nicht, dann funktioniert die Kollisionserkennung am Ende trotzdem. Ich wollte es hier aber trotzdem noch einmal zur Klärung einbringen. Falls jemand eine Idee hat, wie man CSMA/CD mit HardwareSerial umsetzen kann, freue ich mich über jeden Hinweis. Vielleicht reicht ja schon vor dem Senden den Empfangspuffer mit available() abzufragen und ggf. gerade auflaufende Daten abzuwarten oder etwas in der Art. Von HardwareSerial wieder abzugehen ist in meinen Augen aber keine Option, weil die Stabilitäts- und Geschwindigkeitszuwächse (ersteres insbesondere bei PPS-Usern) einfach zu eindeutig sind.
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

loetmeister

Hi feetz,

war das nicht in bsb.cpp drin? (so halbwegs? - programmatisch mit den Schleifen nicht so schön gelöst... da es alles andere blockiert...)
Den RX pin eine gewisse Zeit zu beobachten wäre ja ok, wenn man sich an das Timing vom Bus hält. Also nicht senden, wenn der Bus innerhalb einer bestimmten Zeit nicht frei war. Statt eine Pegeländerung am Bus zu beobachten könnte man auch einen Zeitstempel vom Empfanspuffer mitführen. Also immer die letzte Sendezeit zu prüfen wann irgendein ein Byte  empfangen wurde - erst wenn eine min. Pausendauer vergangen ist, dann senden.
Das wäre jetzt erst mal nur alles Kollisionsvermeidung... zur Kollisionserkennung müsstest man verm. jedes gesendete Byte mit dem grade empfangenen vergleichen - wenns übereinstimmt, dann hat verm. niemand anderes dazwischen gequatscht...

Da der Bus ja rel. langsam ist (4800 Baud) wäre es bestimmt schön die ganzen "delay", "while" Schleifen und sonstige Wartezeit aus dem Code zu werfen und dem Prozessor zu erlauben die Zeit sinnvoll zu nutzen....  ;) Das würde aber verm. einem Neuaufbau gleichkommen...
(z.B. den framePointer static zu machen und immer wieder aus der Empfangsfunktion (GetMessage?) heraus zu gehen, wenn grade keine Daten im Puffer sind. Der "main" Code müsste das natürlich beachten, dass die Funktion nicht immer eine Nachricht liefert - bzw. nur bei Rückgabewert "true")

Gruß,
Thomas

freetz

Wie gesagt, grundsätzlich ist das im Code wohl so angelegt, aber die Schleifen gehen eben byte- und nicht bitweise durch die zu sendende Message, und wenn dann ein ganzes Byte an die write Funktion übergeben wird, die selber wiederum nichts anderes macht, als ungestört dieses Byte bitweise auf den Bus zu geben, dann bringt das ja nichts. Im Anschluss daran wird dann zwar der RX-Pin überprüft, aber das sagt mir ja nichts, wenn sich bei den 10 zuvor gesendeten Bits ein etwaig anderes Gerät schon wieder zurückgezogen hat. Oder habe ich da jetzt was übersehen/missverstanden?

Ein Warten bringt ja auch nur bedingt was, denn auch da kann es ja sein, dass genau in dem Moment ein anderes Gerät anfängt zu senden. Auch in dem Fall würden meine 11 Bit (Start+8+Parity+Stop) ja unabhängig davon auf den Bus gehen, bis ich etwaig etwas erkennen würde, oder? Wenn etwas an Daten eingeht und GetMessage das erkennt, wird ja sowieso so lange gelesen, bis das Telegramm vollständig empfangen ist. Da der Arduino so lange eh' nichts anderes macht, hat man dadurch schon eine sichere zeitliche Distanz zu einem vorhergehenden Telegramm.

Das Vergleichen des gesendeten Bytes mit dem empfangenen Byte könnte aber ein Ansatzpunkt sein, das wäre dann zwar kein Zurückziehen beim ersten ungleichen Bit, aber womöglich immer noch besser als der jetzige Status, nämlich nichts zu machen ;)...

Danke auf jeden Fall für die schnelle und hilfreiche Rückmeldung!
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

Shortypower

Hallo
Danke erst mal für die vielen Infos und Anregungen.
Ich bin inzwischen einen Schritt weiter und berechne nach diversen Kriterien eine Raumtemperatur und möchte diese an BSB übermitteln.
Nun habe ich mehrfach gelesen und auch von einem hilfreichen User per PN noch mal erfahren, dass der Wert wohl an Parameter 10000 übertagen werden soll.
Bei mir ist der Parameter aber not supportet.
Kann man alternativ den Paramter
8742 Diagnose Verbraucher - Raumtemperatur 1 Modell
benutzen?


Jewe

Hey,

schau mal im Handbuch nach. Den Parameter 10000 findest Du nicht direkt in der Heizung als Parameter. Ist aber der richtige.
https://1coderookie.github.io/BSB-LPB-LAN/kap08.html#821-raumtemperatur-%C3%BCbermitteln

In diesem Parameter siehtst Du ob es auch angekommen ist: 8740 Diagnose Verbraucher - Raumtemperatur 1

Jens

freetz

Der Parameter ist ein write-only Parameter, deswegen bekommst Du da auch beim Auslesen die entsprechende Fehlermeldung. Schreibe einfach die Temperatur an Parameter 10000 und schau' in der Diagnose-Seite, ob die Raumtemperatur entsprechend übernommen wird.
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: Jewe am 22 März 2021, 11:18:12
https://1coderookie.github.io/BSB-LPB-LAN/kap08.html#821-raumtemperatur-%C3%BCbermitteln
Danke, den Hinweis aufs Handbuch wollte ich auch gerade schreiben (bzw. hatte ich gerade, hab's aber wieder gelöscht ;) ). Aber:
Der von dir genannte Link funktioniert seit der Umstruktierung nicht mehr (Hinweis gab's hier: https://forum.fhem.de/index.php/topic,29762.msg1139674.html#msg1139674), der korrekte Link lautet: https://1coderookie.github.io/BSB-LPB-LAN/kap06.html#63-raumtemperatur-%C3%BCbermitteln
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

Shortypower

Super vielen Dank!

Reicht es diesen zu setzen, wenn er sich ändert, oder muss man das, reglmäßig tun ?

Schotty

..hast du das Kapitel gelesen..?
Zitat: "Die Raumtemperatur muss regelmäßig in relativ kurzen Intervallen übermittelt werden, bspw. alle ein oder zwei Minuten."
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

Shortypower

Hallo, sorry, habe ich gelesen un dauch umgesetzt!

Den Parameter 10000 kann ich nicht setzten.
192.168.1.226/S10000=22 führt zu 'FEHLER: Setzen fehlgeschlagen!'

Schreibzugriff ist komplett gesetzt!



Schotty

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

Shortypower

Raumeinfluss ist auf 70 % eingestellt

750 Heizkreis 1 - Raumeinfluss: 70 %

Schotty

Hmm, dann sollte es da eigtl schonmal passen. Den Schreibzugriff hast du via Webinterface gesetzt und dann auch abgespeichert?
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/