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

Schotty

@postman:
PRI 230V (Pin 1-2)
SEC1 13V 4,82VA (Pin 9-10)
SEC2 6V 0,18VA (Pin 6-7)
Allerdings scheinen von insg 7 Anschlusspins des Trafos, die auf der Unterseite der Platine wieder 'herauskommen' schonmal zwei nicht beim Platinenlayout nirgends Kontakt zu Leiterbahnen zu haben, die sitzen einfach so im 'Leeren'. Und von den beiden Spannungsreglern, nach denen frank am Anfang wg der Bezeichnunggefragt hatte, geht der Output-Pin vom LM2940 direkt an den Input-Pin vom 7805.

@frank: Danke fürs Nachsehen! Der RVS43.345 ist die aktuelle Reglergenration (der Nachfolger von meinem Regler) und wird bei den Ölern (Brötje BOB) verbaut. Da hatte ich mir zwar die Pläne angesehen, aber nicht die Specs..  ::) Sorry Leute, mein Fehler..  :-[
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

postman

Moin zusammen,
@Schotty, doppelseitige Platine? Falls ja, dann sind zwei eventuell auf der Oberseite angeschlossen. Also, wenn ich mir das Bild mit der Platine anschaue, finde ich unten in der Mitte 3 Lötpunkte, von denen der linke Lötpunkt Masse ist und zwei Lötpunkte, die wie Schotty schreibt inder "Luft"hängen, diese beiden werden auf der Oberseite verbunden sein.
Außerdem, man verbaut keinen Trafo mit mehreren Sekundärausgängen, wenn nur eine Spannung benötigt wird, das ist "zu teuer" (wenn auch nur ein paar Cent) für die Industrie  ;)
Gruß Uwe
Raspberry Pi Version 2 QUAD-CORE CPU und 1 GB RAM, CUL V3 868 MHz,  stapelbarer CC1101 (SCC) 433 MHz, Enocean-Stick,Jeelink-Stick, BSB-Lanadapter

Spruch eines Ausbilders: Theorie ist, wenn man alles weiss und nichts funktioniert; Praxis ist, wenn alles funktioniert und keiner weiss warum...

Schotty

@postman: Ja, das dachte ich mir auch, aber wenn ich sie gegen das Licht halte, dann scheints durch - naja, streng genommen könnte da eine Leiterbahn sein, da schimmert etwas ganz leicht - wird wohl auch der Fall sein, wär ja sonst wirklich Quatsch.. ;) 
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

frank

mahlzeit zusammen,

ich denke, ich habe mein frozen-lan-shield problem gelöst.

ob wirklich endgültig, wird erst ein langzeittest zeigen. aber die fehlerfreie zeit, von bisher maximal 15 stunden, ist nun nach ein paar tagen bereits um ein vielfaches überschritten. zusätzlich funktioniert nun auch ein automatischer start der mega-ethernet-kombi nach poweron, was noch viel entscheidender ist.  :)


mein clone shield entspricht dem shield vom eckstein clone, dessen link andres29 gepostet hat. https://eckstein-shop.de/HIMALAYA-basic-w5100-Ethernet-Shield-fuer-Arduino?curr=EUR&gclid=EAIaIQobChMIns_35ciK3wIV0KiaCh3pkAdVEAQYAyABEgL-f_D_BwE

auf diesen clones fehlt ein wichtiges ic, um den W5100 bei powerup und manuellen resets definiert zu resetten.
im schaltplan vom original arduino-lan-shield ist es ic1, ein CAT811. auf dem original shield findet man das 4-polige smd ic zwischen quarz und reset button.
schaltplan arduino-lan-shield: https://www.arduino.cc/en/uploads/Main/arduino-ethernet-shield-06-schematic.pdf
datenblatt cat811: https://www.onsemi.com/pub/Collateral/CAT811-D.PDF



als workaround/modifikation habe ich bisher 2 varianten gefunden:

1. rc-reihenschaltung zwischen RESET und GND einfügen

zb wie hier beschrieben: http://tigawd.blogspot.com/2015/05/arduino-uno-clone-and-w5100-ethernet.html

zur zeit nutze ich diese variante, da man zum testen einfach die rc-kombi in die buchsen der pinleiste stecken kann.
meine erfolgreiche kombination besteht aus einem 100uF kondensator und einem 2K7 ohm wiederstand. also eine resultierende zeitkonstante von ca 270ms, die deutlich grösser ist als 44ms aus dem link beispiel. mit einem etwas kleineren kondensator mit 68uF hat es schon nicht mehr funktioniert.

gut möglich, dass meine vorhandenen kondensatoren bereits einiges an kapazität im laufe der zeit verloren haben, da sie nicht mehr die jüngsten sind. allerdings finde ich, dass meine zeitkonstante mehr zum CAT811 passt.
etwas schlecht finde ich bei dieser variante momentan die ebenfalls recht lange entladung des kondensators. damit der poweron reset verlässlich funktioniert, muss ich die versorgungsspannung schon ein paar sekunden vor dem wiedereinschalten ausgeschaltet lassen. ausserdem sollen ja auch die netzteile selbst und die art der ankopplung an den arduino unterschiedlich auswirkungen haben.
.
hier muss ich auf jeden fall noch nacharbeiten, wahrscheinlich mit einer zusätzlichen diode. aber ersteinmal das langzeitverhalten abwarten.


2. das RESET signal durch einen freien output-pin des arduino erzeugen

Zitat2. Clip off the reset pin of the Ethernet shield, and connect it with a wire to an unused i/o of the Arduino. So the reset of the Ethernet shield is independent to the Arduino. Before calling the Ethernet library,  enable that output pin, pull it low for 100ms, and then switch the port back to input mode with pullups disabled.
https://www.hobbyist.co.nz/?q=taxonomy/term/2

diese variante hat den charme, dass man den W5100 auch über den sketch resetten kann.
auf alle fälle muss durch toggeln des genutzten output-pins in der setup() funktion der reset beim start ausgelöst werden. zusätzlich wäre natürlich auch später bei einem hänger des ethernet shields ein reset über den sketch möglich.

da man hier aber mindestens den pin der RESET verbindung zum arduino umbiegen müsste, habe ich diese variante noch nicht probiert. zumindestens wollte ich sie hier mal erwähnt haben.



ausserdem habe ich noch software erweiterungen getestet:

1. delay in der setup() funktion
diese massnahme habe ich natürlich als erstes probiert. hiermit funktionierte ein manueller reset manchmal gefühlt etwas besser. aber ohne funktionierenden hardware reset aus punkt 1. macht diese massnahme alleine nicht wirklich sinn. sie ist und bleibt natürlich eingebaut.

2. frozen sockets erkennen und killen
http://forum.arduino.cc/index.php?topic=291958.0

diesen von freetz verlinkten code habe ich natürlich auch eingebaut.
damit ich erkennen kann, ob ein zukünftiger ethernethänger eventuell auf diese frozen sockets zurückzuführen ist, habe ich aber zusätzlich einen counter eingebaut, der jeden erkannten frozen socket zählt. beim regelmässigen auslesen des bsb-adapters über fhem, lese ich nun auch den aktuellen zählerstand aus.

angeblich sollen ja port scans solche frozen socket auslösen können. ich konnte bisher noch keinen hänger reproduzierbar auslösen. auch durch unterschiedlichste port scans über nmap haben bisher keine auffälligkeiten ergeben.

3. timeout in der loop() funktion einbauen
ebenso sollen fehlende newline (\n) zeichen bei einer verbindungsanfrage, den server code in der loop() funktion zum hängen bringen können. das habe ich noch nicht eingebaut. auch zum testen ist mir noch nichts eingefallen.



@freetz

ich habe mir auch die letzten änderungen in deinem code angeschaut.
nach meinem verständnis solltest du:
1. das delay in setup() etwas weiter nach hinten schieben, direkt vor server.begin
2. das array unsigned long connectTime[MAX_SOCK_NUM] möglichst am ende von setup() initialisieren, damit auch der erste aufruf von checkSockStatus() einwandfrei funktioniert. siehe zb den neuen server sketch aus dem playground.

void setup()
{
  Serial.begin(115200);

  // disable w5100 SPI while starting SD
  digitalWrite(10,HIGH);

#ifdef ServerDEBUG
  Serial.print(F("Starting SD.."));
#endif

  if(!SD.begin(4)) {
#ifdef ServerDEBUG
    Serial.println(F("failed"));
#endif
  }
  else {
#ifdef ServerDEBUG
    Serial.println(F("ok"));
#endif
  }

  Ethernet.begin(mac, ip, gateway, gateway, subnet);

  delay(2000);
  server.begin();

  unsigned long thisTime = millis();

  for(int i=0;i<MAX_SOCK_NUM;i++) {
    connectTime[i] = thisTime;
  }

#ifdef ServerDEBUG
  Serial.println(F("Ready"));
#endif
}
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Schotty

Suuper - ich bin gespannt, was deine (Langzeit-)Tests ergeben und was letztlich als Lösung dabei herauskommt.

Mein frommer Weihnachtswunsch: Steig doch bitte endlich mal auf BSB-LAN um, tut auch gar nicht weh ;D
Handbuch zur BSB-LAN Hard- & Software (Anbindung v. Heizungsreglern, u.a. von Brötje & Elco):
https://1coderookie.github.io/BSB-LPB-LAN/

postman

#2900
Hallo zusammen,
Ich habe Anfang des Monats (9.12.2018) die Variante von freetz installiert. Seitdem habe ich bis heute keine Aussetzer mehr gehabt. Bisher läuft es stabil. Was ich allerdings im SerMon gesehen habe ist, wenn ich den BSB direkt über den Webbrowser aufrufe und die Konfiguration auswähle, ein HexDump des EEPROMS ausgegeben wird und der SerMon für diese Zeit steht.
Die Webverbindung bleibt aber bestehen. Anscheinend löst das Laden in der Titelzeile des BrowserTabs (ein HTTP 1.1 Aufruf) dieses Phänomen aus.
Aber wie geschrieben, das Web funktioniert und auch FHEM meldet keine Aussetzer.
Und damit wir nicht von unterschiedlichen Shields sprechen, im Anhang ein Bild des von mir verwendeten Shields ;)
Gruß Uwe
Raspberry Pi Version 2 QUAD-CORE CPU und 1 GB RAM, CUL V3 868 MHz,  stapelbarer CC1101 (SCC) 433 MHz, Enocean-Stick,Jeelink-Stick, BSB-Lanadapter

Spruch eines Ausbilders: Theorie ist, wenn man alles weiss und nichts funktioniert; Praxis ist, wenn alles funktioniert und keiner weiss warum...

Andreas29

Hi,

@frank:
Drücke Dir die Daumen  :)

Ich hatte das verlinkte LAN-shield auf BSB-LAN und auf einem Arduino-Raumgerät "light" im Einsatz.

Die ersten paar Tage hatte ich nach ca. 12 Stunden ein Erreichbarkeitsproblem bei BSB-LAN. Das hing bei mir mit der SD-Karte und dem loggen zusammen. Eine kleinere SD-Karte schaffte Abhilfe, danach hatte ich dann nur noch ca. alle 3 Wochen einen Ausfall. In allen Fällen konnte ich durch einfaches Versorgungsspannung aus/an (Reset) die Combo wieder an´s laufen bringen.
Zwischenzeitlich habe ich mal probehalber (weil ich auch über ein Problem mit der Spannungsstabilisierung gelesen habe) einen Kondensator zw. +5V und GND gesteckt, habe aber keine Langzeiterfahrung ob dies eine evt. Verbesserung dargestellt hätte.

Derzeit verwende ich (weil ich zwischenzeitlich fälschlicherweise von einem defekten LAN-shield ausging) für BSB-LAN ein originales Shield V2. Langzeiterfahrung fehlt auch hier, bisher läufts und "Proberesets" verliefen problemlos  :)

Das LAN-Shield auf dem "Raumgerät" lief unauffällig.

Grüße

Andreas

frank

moin,

was ich eigentlich herausstellen wollte, war folgendes:

immer, wenn von den ethernet hängern berichtet wurde und gleichzeitig das design des benutzten shields beschrieben ist, handelt es sich um schaltungen, bei denen das reset-controler ic fehlt.

bei neueren berichten sind eigentlich nur noch clones betroffen. scheinbar sind durch die einführung des ic bei den originalen arduino shields die probleme behoben.

auch bei meinem originalen shield mit reset controler habe ich in 5-6 jahren null hänger gehabt.

der entscheidende unterschied bei der funktion mit reset-controler ist, dass zuerst alle anderen schaltungen ausser dem w5100 auf beiden boards resettet werden. erst zum schluss nach einem delay resettet der controler nur noch den w5100.

ohne controler wird der w5100 zusammen mit allem anderen  resettet. sowohl bei poweron als auch über die reset buttons. mein einfügen der rc-kombination zwischen reset und ground verzögert ja eigentlich nur den reset. weiterhin sind aber noch alle schaltungen, die den reset verarbeiten, gleichzeitig betroffen.

das so geänderte verhalten während des resets, hat nun aber scheinbar auch extreme auswirkungen auf die weitere stabilität der lanverbindung. also je besser die startprozedur, desto länger keine probleme.

um die funktionsweise mit controler ic annähernd zu implementieren, müsste man eigentlich nur den reset des w5100 verlängern/verschieben.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

freetz

@frank: Danke für die sehr hilfreichen Erklärungen und Erkenntnisse!
Bei einigen Punkten bin ich mir aber nicht ganz im Klaren, ob ich da seitens BSB-LAN noch etwas tun kann (z.B. was den späteren Reset etc. angeht) oder ob das wenn dann auf tieferer Ebene (oder eben über Hardware) realisiert werden müsste. Die 3 Sekunden Pause habe ich nun jedenfalls vor server.begin gestellt und das connectTime Array in der setup() initialisiert.
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

frank

Zitat von: freetz am 18 Dezember 2018, 17:22:11
@frank: Danke für die sehr hilfreichen Erklärungen und Erkenntnisse!
Bei einigen Punkten bin ich mir aber nicht ganz im Klaren, ob ich da seitens BSB-LAN noch etwas tun kann (z.B. was den späteren Reset etc. angeht) oder ob das wenn dann auf tieferer Ebene (oder eben über Hardware) realisiert werden müsste.
zur zeit fällt mir nur der 3. punkt meiner softwaretests ein, falls es nicht doch schon eingebaut ist. in deinem link zu den frozen sockets schrieb surfertim:

ZitatThe entire server example is here. It also includes a timeout feature if the client sends a few characters, but doesn't send a '\n' (newline) character. That will also cause a lockup (only takes once to lock up your sketch). Look at the second (old) server code at the bottom of the page for that timeout. The loopCount variable controls the timeout.
http://playground.arduino.cc/Code/WebServerST

scheinbar ein notausstieg/timeout der while schleifen, falls bei einem request vom client die daten korrupt sind.

FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

freetz

Äh, sehr gut, danke, das hatte ich übersehen...
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

freetz

So, habe die Stabilitätsvorschläge jetzt auch auf GitHub eingespielt. Bei dem Timeout frage ich mich allerdings, ob das für unsere Fälle relevant ist, denn das scheint ja nur ein totales Hängen des Arduino zu verhindern; in den Fällen hier lief ja soweit ich das erinnere die Ausgabe auf dem SerMo weiter, dann lag es zumindest in den Fällen nicht an einer Endlosschleife. Aber schaden tut's natürlich nicht und vielleicht bringt es ja doch noch zumindest etwas mehr Stabilität...
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

frank

ZitatBei dem Timeout frage ich mich allerdings, ob das für unsere Fälle relevant ist, denn das scheint ja nur ein totales Hängen des Arduino zu verhindern;
so verstehe ich das auch.

sollte dann auch hardware unabhängig sein. da mein original shield bis zum wechsel auf den clone min 5 jahre keine aussetzer hatte, schliesse ich das auch bei mir aus.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

freetz

Und noch eine (letzte?) Frage dazu: Das verzögerte Resetten des Shields kann ich nicht per Software beeinflussen, oder?
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

Scherheinz

#2909
Nur wenn du den Reset Pin vom Shield abschneidest und oben eine Brücke zu einem freien Arduino Pin machst. Dann kannst du jederzeit nach Lust und Laune das Shield resetten, nur dran denken im setup() den Pin noch vor der Ethernet Geschichte und dem evtl Delay() auf High zu setzen.  Das hatte ich auch schonmal bei einer anderen Bastelei gestestet. Zum Testen muss man den Draht ja nicht gleich abschneiden sondern ihn einfach etwas zur Seite biegen  so das er beim Aufstecken auf den Arduino an der Buchse vorbei geht. Optisch nicht schön aber zum Testen ok und kann wieder rückgängig gemacht werden ;)

Gruß