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

[Schotty]

Danke fürs Testen!
Ein vielleicht ähnliches Problem hatte ich kürzlich, als ich BCs im 10 und 30Sek-Takt auf Karte geloggt habe und dann (ohne drüber nachzudenken  ) die Logdatei mit /D aufrufen wollte. Das war wohl der overkill für den Mega, danach ging nix mehr. Ich habe es aber dann auf das nicht-vorhandene Multitasking geschoben (aufgrund dessen ja eigtl auch keine zwei gleichzeitigen Abfragen möglich sind - wenn, dann arbeitet der Ardu/Hzgsregler immer alles nach einander ab), den Ardu stromlos gemacht und die Karte zum Auslesen entfernt (weil ich gerade nicht neu flashen wollte).

[freetz]

Hm, also ich habe ja ein Clone-Shield mit dem 511er Widerstandsarray und habe im normalen Ablauf auch mehrere Prozesse, die gleichzeitig auf den Shield zugreifen könnten (alle 5 Minuten Abfrage von ca. 10 Parametern, alle 5 Minuten Senden der Raumtemperatur, alle 60 Sekunden Abfrage der Relais-GPIOs). Hinzu kommen eben gerade die brute force Telegrammabfragen (ca. 1.6 Abfragen pro Sekunde), bei denen es also zwangsläufig Kollisionen geben müsste. Aber weder die periodischen FHEM-Abfragen, noch die brute force Abfragen leiden darunter, sondern warten jeweils brav, bis sie eine Antwort kriegen.

Anders verhält es sich bei dem Wemos Mega über WiFi, hier bricht die WiFiEsp Library Anfragen, die länger als 1 Sekunde in der Pipeline hängen, ab, was aber anscheinend nicht zum Browser durchdringt, sondern der bis zu seinem (langen) Timeout weiterrödelt. Da muss ich noch mal schauen, wie man das umgehen kann.

Mir scheint, dass es weniger ein Hardware-Problem ist, sondern ein Problem der Firmware des LAN-Shields. Möglicherweise gibt es hier unterscheidliche Versionen, die vielleicht auch mit bestimmten Baugruppen einher gehen, so dass diese Auffälligkeit zu Rückschlüssen verleitet. Und manche dieser Versionen laufen dann vermutlich (in)stabiler als andere. Das würde auch erklären, warum z.B. ein Reboot (der sich ja nur auf den Arduino auswirkt) oder ein delay in der setup() Routine (k)einen Einfluss auf das Verhalten haben.

[Schotty]

ein Reboot (der sich ja nur auf den Arduino auswirkt)

Hm, also zumindest bei mir wirkt sich der auch aufs LAN-Shield aus - LED erlöschen, Verbindung wird neu hergestellt, LEDs leuchten..

[freetz]

Ja, aber ob das Shield dadurch stromlos wird, ist damit nicht unbedingt gesagt. Es kommt glaube ich auch auf die Art an, wie der Reset-Button verdrahtet ist: Ob er den Reset des ATMega aktiviert oder eben einfach hart den Strom kappt.

Interessant(er) wäre (von meinen vorherigen Überlegungen ausgehend) (eher) ein Vergleich der Versionen des WizNet-Chips: Ich habe auf meinem Board die PH7T9-010 1435, in dem SparkFun Datasheet ist die P3319-011 0646 abgebildet, vielleicht ergibt sich daraus ja ein Muster. Denn ich kann mir wie gesagt nicht vorstellen, dass reine Hardware-Komponenten erst nach so langer Zeit zu solch seltsamem Verhalten führen. Für mich sieht das eher nach einem Software-(in diesem Falle: Firmware-)Problem aus, das sich, wenn nicht in der für alle geltenden Ethernet Library, wohl am ehesten in der Firmware des WizNet Chips verbergen könnte...

[Schotty]

Denn ich kann mir wie gesagt nicht vorstellen, dass reine Hardware-Komponenten erst nach so langer Zeit zu solch seltsamem Verhalten führen.

..geplante Obsoleszenz..?! 
..oder netter formuliert: Vielleicht 'altern' irgendwelche Komponenten.. ..wenn es denn wirklich erst nach längerer benutzung auftritt - man liest ja auch von Fällen, die direkt Probleme bereiten. Aber vermutlich werden wir das nie wirklich klären können..

[Scherheinz]

Das Ethernet Shield wird zwar nicht stromlos gemacht aber es wird doch ein "Reconnect" durchgeführt da die setup() die Verbindungsdaten neu verhandelt werden. Oder liege ich da falsch?

[freetz]

Doch, so sehe ich es auch, aber wenn die Firmware des Shields hängt oder sonst wie nicht normal reagiert, bringt ggf. auch eine Neuinitialisierung über die setup()-Routine wenig bzw. nichts. Und das würde das erratische Verhalten eher erklären, als Hardwarekomponenten, die zumindest bei mir seit Jahr und Tag problemlos funktionieren...

[Andreas29]

Hi,

ich habe zwei CloneShields und zwar diese hier: https://eckstein-shop.de/HIMALAYA-basic-w5100-Ethernet-Shield-fuer-Arduino?curr=EUR&gclid=EAIaIQobChMIns_35ciK3wIV0KiaCh3pkAdVEAQYAyABEgL-f_D_BwE

Diese haben auch einen WN5100er Chip und haben auch beide eine mit 510 bezeichnete Widerstandsbrücke.

Beide laufen eigentlich ziemlich stabil. Ich hatte beim BSB-LAN-Shield in den letzten 3 Monaten 5 Ausstiege. Jedesmal war mit einem Stromlos/Stroman die Combo wieder zu starten.

Ich hatte ein shield, das hatte thermische Probleme (der Chip wurde im Betrieb sehr warm) und das ist dann auch schnell endgültig abgeraucht. Wurde durch Händler anstandslos getauscht. Das neu zugesendete arbeitet unauffällig, hat bisher aber auch zwischenzeitlich ein paar Hänger gehabt aber auch hier war jedesmal ein kurzes Strom aus und dann an geeignet um die Combo wieder ans laufen zu bekommen.

Ich habe mir nun ein orig. shield kommen lassen um zu sehen ob´s damit besser ist.

Eigentlich wollte ich erst mal noch ein bisschen abwarten und testen, aber da die Diskussion gerade neu aufkocht:
Auf dem originalen Shields sind rings um den Spannungsregler drei Kondensatoren, auf den Clonen sind dort meist nur zwei.
Offenbar scheint mir die Spannungsstabilisierung bei den orig. Shield aufwändiger gestaltet als bei den Clonen.
Irgendwo im Netz habe ich dazu auch eine Diskussion gefunden, jedenfalls um´s kurz zu machen, es ist nicht auszuschliessen, dass im Betrieb und je nach Traffic es wohl zu kurzen Spannungsschwankungen kommen kann und so der Chip das hängen anfängt.
Ich habe bei BSB-LAN jetzt einfach mal einen Elektrolytkondensator (ich meine er hatte 10uF/16V) zw den +5V und den GND Pin auf dem Shield gesteckt. Keramikkondensator wär wohl besser (die können schneller die Ladung abgeben und aufnehmen) aber den v.g. hatte ich noch in der Grabbelkiste. Damit erweitere ich ganz einfach die Glättungskapazität auf der 5V Seite.
Mal sehen ob mit dieser einfachen und minimalen Modifikation die Stabilität zu steigern ist.
Dabei von Belang: Ich betreibe beide Arduinos und Shields an einem USB-Netzteil.

Grüße

Andreas

[freetz]

Da es jetzt nach der WLAN-Option doch noch mal einige Nachfragen nach Platinen gab und meine Restbestände vergeben sind, würde ich noch mal eine Sammelbestellung organisieren.
Damit die Platinen noch vor Weihnachten bei den Interessierten sein können, müsste ich bis zum 3. Advent die Bestellung aufgeben. Wer also Interesse hat, melde sich bis dahin bei mir unter bsb (ät) code-it.de

[freetz]

Bezüglich der nicht erreichbaren Ethernet-Shields habe ich hier nun noch einen Hinweis gefunden, dass es sich möglicherweise doch primär um ein Software-Problem handelt:
http://forum.arduino.cc/index.php?topic=291958.msg2040300#msg2040300

Ich habe diesen Code nun in BSB-LAN übernommen, er wird allerdings nur aktiv, wenn man in der _config.h die Zeile

Code Auswählen Erweitern

#define WATCH_SOCKETS
hinzufügt.
Diese Bedingung ist notwendig, weil dieser Code anscheinend nicht mit der aktuellen Version der Ethernet-Library läuft. Man muss also unter Sketch / Bibliothek einbinden / Bibliotheken verwalten die Ethernet Library auswählen und dort in dem DropDown die Version 1.1.2 auswählen (falls man die nicht eh' noch hat). Dann wird alle 60 Sekunden auf dem SerMo die Anzahl der verwendeten Sockets ausgegeben und ein eingefrorener Socket zum Schließen gezwungen, wenn dieser länger als 30 Sekunden in diesem Zustand war. Wenn BSB-LAN also nicht erreichbar ist, sollte damit nach spätestens nach ein paar Minuten dieser wieder einsatzbereit sein - zumindest nach der Theorie.

Da ich selber mit meinem Shield keine Probleme habe und Schotty und Andreas29 ebenfalls nicht, ist für uns das Problem nicht reproduzierbar. Von daher wäre die Bitte an diejenigen, bei denen das Problem regelmäßiger auftritt, es einmal mit dieser Konfiguration zu probieren. Wenn möglich den SerMo dabei laufen lassen; dort steht dann auch immer, wenn ein eingefrorener Socket geschlossen wird.

Wenn damit das Problem gelöst sein sollte, würde dies auf einen Bug in der Firmware einer bestimmten Charge der Netzwerk-Chips hindeuten, die eben das Schließen eingefrorener Sockets nicht von alleine hinbekommen, weil sie sich möglicherweise anderweitig "verrannt" haben (was die unterschiedliche Dauer erklären würde, bis zu der es dann zu dem Problem kommt).

[Scherheinz]

Danke für die Information, das war mit gänzlich neu. 

[postman]

Moin freetz,
ich habe das so, wie beschrieben, installiert.
Ich bekomme diese Rückmeldung im SerMon:

Code Auswählen Erweitern

Socket#0:0x0 80 D:192.168.222.17(52223)
Socket#1:0x14 80 D:192.168.222.17(52221)
Socket#2:0x0 80 D:192.168.222.17(52208)
Socket#3:0x0 0 D:0.0.0.0(0)

was mich stutzig macht, ist die letzte Zeile, die nur Nullen ausgibt. Ansonsten sieht das so ja scheinbar gut aus.

Gibt es eine Möglichkeit, das Ganze in einer Log zuspeichern oder über einen HTTPMod abzufragen?

Gruß Uwe

[freetz]

Moin Uwe,

so wie ich das verstehe, sind bei Dir dann nur drei Sockets in Benutzung (reicht ja auch, denn da BSB-LAN nicht mehrere Anfragen gleichzeitig bearbeiten kann, sollten 1-2 Sockets eigentlich reichen.
Wichtig ist auf eine Meldung "Socket frozen" zu achten - da wäre dann ein Problem, was die neue Funktion dann beseitigt hätte.
Loggen und per HTTP ausgeben geht leider nicht - dafür, dass die Funktion jetzt nur zum Testen da ist, wäre das für mich zu viel Aufwand, das noch in das Logging mit einzubauen, jedenfalls dann nicht, wenn wir die Lösung des Problems nicht in absehbarer Zeit damit verifizieren können...

[postman]

Hallo freetz,
ok, allerdings wird es jetzt eine ganze Weile dauern, bis klar ist, ob es das war. Bei meinem BSB-Lan tritt dieser Fehler immer nur sporadisch in unregelmäßigen Abständen auftrittIch habe auch mal gesucht, ob es möglich ist, im Shield die Firmware zu ändern; leider Fehlanzeige. Auf der Herstellerseite gibt es für den Chip zwar eine Library, die aber sicher auch nur den Arduino programiert.

Nachtrag:
Noch etwas ist mir aufgefallen: Es wird beim Mitlesen im SerMon ein EEPROM dump mit lauter "00" mit GET /favicon.ini HTTP/1.1 ausgegeben. Dabei hängt dann der SerMon. Das geschieht immer dann, wenn ich das Web direkt im Browser aufrufe, allerdings funktioniert das Web weiterhin. Das geschieht jedesmal, wenn ich im Browser die Konfiguration aufrufe. Scheinbar ist der Auslöser ein GET /C HTTP/1.1

Vielleicht hilft das ja.

Gruß Uwe

[freetz]

Mal eine Frage an die Elektr(on)iker hier in der Runde:
Mir kam die Idee, ob man die Stromversorgung des Arduino nicht auch über den BSB abwickeln könnte. Schließlich ist dabei ja auch vorgesehen, dass ein Raumgerät darüber gespeist wird, wo ja auch ein Display und Microcontroller zu versorgen sind. Laut Specs sind das ja ca. 15 Volt im Leerlauf, die man dann entsprechend heruntertransformieren müsste, würde da ein Spannungsteiler mit Widerständen funktionieren, auch wenn die Widerstände dann ja quasi "auf dem Bus" säßen?
Und wäre eine galvanische Trennung über Oktokoppler dann überhaupt noch nötig, weil es dann ja keine zwei Stromkreise gäbe?
Vor dem Hintergrund einer WLAN-Option wäre es ja schon interessant, dann BSB-LAN ganz autark betreiben zu können und den Arduino einfach an/in/unter/auf die Heizung zu klemmen...