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

[Schotty]

Hi DeejayT,
also wenn du ganz sicher gehen willst und nicht so auf die Kosten achten musst, dann empfehlen wir natürlich -wie auch im BSB-LAN-Handbuch beschrieben- die originalen Komponenten zu verwenden.
Anderenfalls kannst du i.d.R. jeden passenden Clone bestellen, beim Verkäufer deiner Wahl..
Achte nur drauf, dass die jeweiligen Beschreibungen passen, also Arduino Mega 2560 Rev3 und LAN-Shield mit W5100 oder W5500. Steht aber ebenfalls alles im Handbuch: https://1coderookie.github.io/BSB-LPB-LAN/kap12.html

Da es Anbieter wie Sand am Meer (samt etwaiger Qualitätsschwankungen) gibt und damit es hinterher nicht heißt "Ich habe Probleme mit dem Ardu/Shield, aber Ihr habt mir doch Verkäufer xyz empfohlen!?!", sehe ich von einer direkten Verkäufer-/Produktempfehlung mittlerweile ab. Ob du nun bei einem deutschen Händler, bei Ebay, Amazon oder direkt in China bestellst, bleibt dir überlassen..

Wenn du alles in Betrieb genommen hast, poste doch bitte deinen genauen Heizungstyp (Hersteller & genaue Modellbezeichnung) sowie die Ausgabe von /Q.

EDIT: Du kannst aber natürlich gerne (dann aber vielleicht lieber per PN) einen Link schicken und ich kann gucken, ob das -zumindest laut Beschreibung- so passt..

[miwi]

Nach der Diskussion ueber saubere Signalformen moechte ich an eine Moeglichkeit erinnern, mit der - abgestimmt auf die Spezifikationen des BS-Bus bzw. LP-Bus - mit einem Schmitt-Trigger ein sauberers Rechtecksignal fuer die Weiterverarbeitung erzeugt wird.  Fuer die Schaltschwellen sind die Widerstaende so bemessen, dass die Schaltung den Low- und High-Pegel des Busses sicher erkennt. Die Schaltung war ebenfalls schon einmal hier oder im Microcontroller Forum abgebildet. Siehe Bild.  Mit SMD-Bauteilen nimmt die Schaltung nur einen kleinen Raum auf der Platine ein, erst recht, wenn man einen Doppeltransistor verwendet.  Ich weiss, dass diese Teile nicht auf Gegenliebe stossen.

[freetz]

Ist irgendjemand in der Lage, mir jemand dieses Verhalten des Due erklären?

Wenn ich folgendes minimale Script auf dem Due laufen lasse:

Code Auswählen Erweitern

void setup() {
  Serial.begin(115200);
  Serial1.begin(115200);
  Serial2.begin(115200);
  Serial3.begin(115200);
}

Und im Anschluss die Pegel von RX0/TX0 bis RX3/TX3 messe, dann bekomme ich bei RX0/TX0 die erwarteten 3,3V Pegel für die logische Null. Wenn ich aber an RX1/TX1 bis RX3/TX3 messe, bekomme ich zwar bei den TX-Pins ebenfalls die 3,3V im Leerlauf, allerdings 0V bei den RX-Pins.
Zuerst dachte ich, dass ich da was beim Basteln zerschossen hätte, aber der der Empfang auf den Pins funktioniert einwandfrei, wenn ich diese loop()-Funktion hinten dran hänge und RX0 und RX1 direkt miteinander verbinde und dann etwas per USB über den Seriellen Monitor tippe:

Code Auswählen Erweitern

void loop() {
  while (Serial1.available()) {
    Serial.print("Got :");
    while (Serial1.available()) {
      Serial.print((char)Serial1.read());
    }
    Serial.println();
  }
}

Wenn das so wäre, wäre das schon extrem ärgerlich, denn dann müsste die Schaltung (nur) für den Due ja noch mal invertiert werden, denn beim Mega ist ja auch bei RX1 die Leerlaufspannung 3,3V. Oder die Schaltung wäre dann generell nur noch für den Due und man müsste für den Mega bei der jetzigen Schaltung bleiben.
Auf der anderen Seite dürfte ja eine direkte Koppelung von RX0 zu RX1 wie im eben genannten loop()-Beispiel dann ja eigentlich auch nicht funktionieren, wenn die Zustände für logisch 0/1 entgegengesetzt wären.

Interessant ist vielleicht noch, dass beim Drücken der Reset-Taste auf dem Due auch die RX1-3 Pins auf 3,3V gehen; erst mit dem Loslassen der Taste gehen sie auf 0V.

Gibt es dafür eine Erklärung bzw. Lösung?

[Schotty]

Nur so ein Gedanke:
Hast du den Due via USB mit Strom gespeist und dann gemessen? Auf Serial_0 liegt doch die USB-Schnittstelle, wie bspw beim Mega und Uno auch, vielleicht kommt die Spannung daher?
https://www.arduino.cc/en/pmwiki.php?n=Reference/Serial
https://www.arduino.cc/reference/de/language/functions/communication/serial/

[Schotty]

Interessant ist vielleicht noch, dass beim Drücken der Reset-Taste auf dem Due auch die RX1-3 Pins auf 3,3V gehen; erst mit dem Loslassen der Taste gehen sie auf 0V.

Habe gerade das hier gefunden, evtl passt das zusammen..?
https://www.mikrocontroller.net/topic/437815#5186474

[freetz]

Zwar keine Erklärung, aber eine Lösung: Wenn ich mit pinMode(19, INPUT_PULLUP) den Pin hoch ziehe, klappt es. Jetzt konnte ich die Schaltung zumindest soweit testen, dass der Due grundsätzlich Telegramme senden und empfangen kann, alledings habe ich jetzt das Problem, dass bei den kurzzeitig aufeinander folgenden Telegrammen eins fast immer "verschluckt" wird, wenn ich den Bus belausche: Wenn z.B. das Display die Heizung nach der Außentemperatur fragt, wird manchmal das QUR-Telegramm und dann wieder das ANS-Telegramm im SerMo angezeigt. Mit dem Logik-Analyzer sehe ich aber, dass beide Telegramme an RX1 empfangen werden. Über den Buffer im UART dürfe da ja eigenlich nichts verloren gehen. Mich wundert, dass das bei quasi identischem Code bei einer sehr viel schnelleren Architektur wie dem ARM-Prozessor ein Problem sein könnte...

[loetmeister]

Hi,

ich verstehe das Problem grade gar nicht...

bekomme ich zwar bei den TX-Pins ebenfalls die 3,3V im Leerlauf, allerdings 0V bei den RX-Pins.

Ich vermute die Messung war ohne Adapterschaltung, also dem "nackten" Due?
TX ist als 'output', vermutlich mit einem pull-up (intern) konfiguriert? Bei meinem Mega habe ich auch HIGH level am TX pin (nach der Seriellen Initialisierung, da der Default aller (oder fast aller) Ports als Eingang konfiguriert sind. D.h. es dauert eine Sekunde nach dem Reset, bis der port auf 'input' 'output' gesetzt wird und HIGH anliegt).

RX ist bei mir ebenfalls LOW. Ist auch gut, da sonst der pull-down in der Schaltung gegen einen internen pull-up arbeiten müsste. Den RX pull-down direkt am Arduino Pin kann man sich in dem Fall sparen, wenn intern pull-down gesetzt ist. Zwei pull-down ist auch nicht optimal... sind aber beide ja relativ Hochohmig. Eventuell ist das beim Due anders herum? (pull-up statt pull-down?)
Mit Bus Adapter würde RX bei ruhigem Bus high sein, da der Optokoppler schaltet (der Grund warum ich zum testen ohne Heizung einfach Spannung auf den Busanschluss gegeben hatte (mit Strombegrenzung!!) - damit ein "idle" Bus erkannt wurde)


Gruß,
Thomas

[freetz]

Danke für die Hinweise - in der Tat war jetzt am Ende der Pullup auf dem RX-Pin nicht mehr nötig; ich hatte mich nur gewundert, dass die Schaltung bzw. der Arduino gar nichts senden wollte, auch nicht gleich zu Beginn, wenn er die Gerätefamilie abfragt. Ich dachte, dass es die Kollisionserkennung ist, die ich ja vor einiger Zeit erst implementiert hatte (vorher funktionierte die ja so gut wie gar nicht). Weil ich vormals beim Umstellen auf HardwareSerial da auch die umgekehrten Pegel berücksichtigen musste, hatte ich zuerst hier angesetzt und dann - wie Du richtig vermutest - beim "nackten" Due gemessen.
Gleichzeitig musste ich aber auch das Serial1.begin() aus der BSB-Klasse in die setup()-Routine verlegen, damit überhaupt auf Serial1 zugegriffen werden kann. Und das war der eigentliche Grund, warum nichts auf den Bus kam, und nicht die Kombination aus Beidem. Insofern gut, dass Du darauf hingewiesen hast, Pull-Down gegen Pull-Up ankämpfen zu lassen, wäre in der Tat dumm gewesen.

Was das Ersetzen des RX-Pulldowns angeht: Das würde doch nur bei den Arduinos gehen, beim Raspberry geht das m.W. nicht, oder?

[freetz]

Eine weitere Anomalie ist mir im Vergleich Mega/Due noch aufgefallen (beides HardwareSerial):
Beim Due scheint die Kollisionserkennung nicht so (gut) zu funktionieren, wie auf dem Mega. Ich konnte das daran beobachten, dass beim Abruf von einer Kategorie die Auflistung ca. alle 10 Sekunden stockt und im SerMo-Log dann ein "query failed" mit dem Debug-Hinweis kommt, dass keine Antwort auf das gesendete Telegramm empfangen wurde. Wenn ich die gleiche Schaltung an den Mega hänge, tritt das Problem nicht auf. Es tritt darüber hinaus auch nicht auf, wenn ich den Adapter an das gleiche Gerät via LPB anschließe.

Meine Vermutung: Auf dem BSB kommen ca. alle 10 Sekunden die Anfragen des Displays an die Heizung über den Draht. Die Kollisionserkennung scheint auf dem Mega zu funktionieren, denn da wird dann entsprechend nur Millisekunden gewartet und dann die Anfrage erneut verschickt. Auf dem Due scheint das nicht (so gut) zu funktionieren, denn dort wird anscheinend die Busaktivität nicht erkannt, das Telegramm gesendet, und dann die drei Sekunden Timeout abgewartet, bevor die Anfrage dann erneut (und dann bisher immer erfolgreich) abgesetzt wurde.

Ich vermute mal nicht, dass es hier an den Widerstandsgrößen bei 3,3V und 5V liegen wird, denn dafür treten die Pausen zu regelmäßig und nur beim BSB auf. Die Funktion rx_pin_read(), die die Aktivität auf dem Bus erkennen soll, gibt es zwar nur bei SoftwareSerial, aber die Funktion läuft letztlich auch bei HardwareSerial (bsb.cpp ganz am Ende) - auch auf dem Due. Interessanterweise ist jedoch der Rückgabewert beim Mega 0 oder 1, wohingegen er beim Due 0 oder 1024 ist, was eigentlich eher bei analogen Eingängen Sinn machen würde.

Die gute Nachricht ist, dass die Kollisionserkennung (bzw. -vermeidung) an sich so gut umgesetzt ist, dass Kollisionen wirksam vermieden werden - auf dem Mega zumindest. Wenn jemand noch eine Idee hat, warum das auf dem Due nicht (so) funktioniert oder wie ich das dort alternativ lösen kann, wäre ich einen guten Schritt weiter.

[Jewe]

Hallo,

ich übertrage die gemittelte Raumtemperatur mehrerer Räume an die Heizung Heizkreis 2. So wie es im Handbuch "8.2.1 Raumtemperatur übermitteln" auch beschrieben ist. Dabei stelle ich fest, dass des öfteren (regelmässig) der value auf "0" springt und dann natürlich auch an die Heizung kein Wert übertragen wird. Ich kann mir das verhalten nicht erklären bzw. verstehe es nicht.

Hatte von Euch auch schon jemand das Problem ?

Mit dem Doif wird die Temperatur bei Änderung an das Device BROETETEMP geschrieben:

Code Auswählen Erweitern

defmod BROETJETEMP HTTPMOD http://192.168.6.23/2201/8700 180
attr BROETJETEMP userattr reading0Name reading0Regex set0Name set0URL
attr BROETJETEMP enableControlSet 1
attr BROETJETEMP event-on-change-reading .*
attr BROETJETEMP reading0Name Aussentemperatur
attr BROETJETEMP reading0Regex 8700 .*:[ \t]+([-]?[\d\.]+)
attr BROETJETEMP room Heizung,x_Test
attr BROETJETEMP set0Name Raumtemperatur_HK2
attr BROETJETEMP set0URL http://192.168.6.23/2201/I10001=$val
attr BROETJETEMP stateFormat {sprintf("Aussentemperatur: %.1f °C | HK2 Raumtemperatur: %.1f °C", ReadingsVal($name,"Aussentemperatur",1), \
InternalVal("BROETJETEMP","value", 21))}
attr BROETJETEMP timeout 5
attr BROETJETEMP verbose 0

setstate BROETJETEMP Aussentemperatur: 8.3 °C | HK2 Raumtemperatur: 20.5 °C

Code Auswählen Erweitern

defmod di_average DOIF ([SELF:state])(set BROETJETEMP Raumtemperatur_HK2 [$SELF:state])
attr di_average DbLogExclude .*
attr di_average do always
attr di_average room x_Test
attr di_average state {([KZ_Thermostat_Weather:temperature]+[KZ_Heizung_Weather:measured-temp]+[SP_Heizung_Weather:measured-temp]+[BA_Heizung_Weather:measured-temp])/4}
attr di_average stateFormat {sprintf("%.2f °C", ReadingsVal($name,"state",1))}

setstate di_average 20.15 °C

[loetmeister]

Hi,

Danke für die Erklärungen.

Bzgl. der Kollisionserkennung. Du könntest die Funktion "boolean" zurück geben lassen?
uint8_t BSB::rx_pin_read() {
Wobei da kommt ja ein pointer zurück? Wäre aber auch egal.. Wenn kein Wert bei low pegel kommt...
Was sprach nochmal dagegen digitalRead() zu nutzen? Der Aufbau des aktuell genutzten pin_read war so indwr softwareserial drin, aber digitalread wäre die sicherere Funktion.

Z.b. In der eigenen Funktion, statt portInputRegister, return digitalread(rx_pin) ^ hwSerial;? Dann sparst man sich auch die zusätzlichen Bedingungen im "if" bei der Kollisionserkennung.

Gruß,
Thomas

[freetz]

Ja, das mit dem Pointer ist mir auch nicht so ganz klar, so sieht die Funktion im Original bei SoftwareSerial aus:

Code Auswählen Erweitern

uint8_t SoftwareSerial::rx_pin_read()
{
  return *_receivePortRegister & _receiveBitMask;
}

Ich dachte, dass da der Inhalt der Speicherstelle, die für den GPIO-Pin zuständig ist, zurück gegeben wird?

DigitalRead hatte ich nicht genommen, weil ich gelesen habe, dass der sehr viel(?) länger in der Ausführung benötigt, als wenn man das Register direkt abfragt. Aber werde ich auch noch mal probieren, genau so wie das boolean - danke!

[freetz]

Schade, beides gerade probiert, sowohl mit boolean als auch mit digitalRead kommt trotzdem ca. alle 10 Sekunden ein "query failed" nach 3sekündiger Pause...

[freetz]

@loetmeister: Ich jetzt noch mal ganz am Anfang der setup()-Funktion eine Schleife gesetzt, die immer dann, wenn digitalRead() oder portInputRegister() auf Null gehen, die entsprechenden Werte ausgibt. Dann habe ich die Schaltung an den PPS-Bus gehängt, der ja ca. alle 500ms ein Telegramm auf den Bus schickt.
Ergebnis:
Ohne pinmode(19, INPUT_PULLUP) bekomme ich bei beiden Funktionen dauerhaft eine Null zurückgeliefert. Wenn ich aber pinmode(19, INPUT_PULLUP) hinzufüge, bekomme ich schön regelmäßig etwa alle 500ms eine Reihen von Nullen angezeigt, die signalisieren, dass auf dem Bus etwas los ist, dann wieder 500ms Pause usw.
Dabei hat sich auch gezeigt, dass portInputRegister() häufiger eine Null zurück liefert, als digitalRead(), eine von beiden Funktionen ist also träger. "Sicherer" wäre da also portInputRegister.

Und nach dem Herausnehmen der Schleife und Wechsel zurück auf BSB scheint nun auch im gesamten Programm die Kollisionserkennung zu funktionieren. Ich kann jetzt eine lange Kategorie aufrufen und bekomme nicht mehr ca. alle 10 Sekunden diese Aussetzer.

Meine Frage wäre jetzt, wie "schädlich" dieses Ankämpfen von Pull-Up und Pull-Down ist, und/oder ob man da dann schaltungstechnisch doch noch etwas berücksichtigen sollte?

[freetz]

@Jewe: Da helfen nur die betreffenden Log-Dateien und am besten auch die entsprechenden Einträge aus dem Event-Monitor. Wenn das regelmäßig passiert, muss man vielleicht nicht allzu lange warten und kann den richtigen Moment abpassen? Bei mir passiert sowas übrigens manchmal, wenn ich von den MAX-Thermostaten Werte wie "on" oder "off" gemeldet bekomme, die dann eben in einer 0 enden...