reinweb

Die Verbindung (und damit das WLAN) zum Stapel funktioniert einwandfrei - weil ich in einer Schleife im Sekundentakt auf das OLED Display die Uhrzeit ausgebe und das funktioniert auch in dem Zustand wo keine Callbacks mehr daherkommen. Meine Software läuft übrigens auf einem Raspi der mit LAN verbunden ist (keine auffälligen Packet-Drops etc) Mein Teststapel läuft seit gestern morgen stabil mit sehr häufigen Callbacks (Sensoren & Ledstrip-Frames). Dreimal wurde das DISCONNECT - CONNECT Szenario ausgelöst (zuletzt gestern ca 13:00) - seither läuft der Stapel echt stabil. Ich würde sagen, so stabil wie noch nie (mit solch schnellen & vielen Callbacks). ich lass das jetzt mal Laufen - erst wenn es wieder stürzt bau ich diese Setter-Getter Checks ein. DANKE Batti & TF - wenn wir meine Stapel mit WLAN verlässlich zu Laufen bringen, ist das eine Meilenstein für mich und meine Anwendungen! Das hat mich bisher gebremst, TF großflächiger und systemkritischer einzusetzen.

Programm umgebaut. Wenn 10 Sekunden lang kein Callback aufgerufen wird, rufe ich $ipcon->enumerate() an. Intressant ist, dass die hinterlegte Enumeration Funktion nicht aufgerufen wird. Sieht also so aus, als würde gar kein Callback mehr ausgelöst werden. Nach 10 erfolglosen $ipcon->enumerate() Aufrufen mache ich ein $ipcon->disconnect; sleep(3); $ipcon->connect($ip, $port); sleep(3); $ipcpon->enumerate(); ich setze also beim Connect den Enumeration Callback nicht mehr! Und siehe da, die Callbacks des Stacks laufen wieder für ein paar Stunden. Nach ein paar Stunden (unregelmässig) wiederholt sich das wieder. Grundsätzlich bringt uns diese Erkenntnis hoffentlich einen ordentlichen Schritt weiter!

Hallo Batti,danke für deine Antworten. d.h. mit void BrickMaster::reset() egal auf welchem BrickMaster (wenn der Stapel mehrere Master haben sollte) kann ich den Stapel so zurücksetzen, dass die Anzahl der Wifi Verbindungen wieder bei 0 beginnen --> danach würde ich wieder einen Connect aufbauen und Enummerieren (+ callbacks setzen) Guter Hinweis - DANKE, das mache ich!

kann man alle Verbindungen löschen (auch die Zombies) wenn man den Master per Software resetted? Oder durch welche Aktion kann man alle Verbindungen löschen (z.B. disconnect und connect)?? wobei ich nicht so sehr das Problem hab, dass der Stack nicht mehr erreichbar ist - sondern dass keine Callbacks mehr ausgelöst werden (der Stapel aber erreichbar bleibt). Beispiel: HumidityBricklet löst keinen Callback mehr aus - aber das Programm kann weiterhin auf dem OledBricklet die aktuelle Zeit anzeigen. Manchmal ist es nicht notwendig, den Stapel stromlos zu machen - es geht einfach wieder, wenn ich das Programm kille und neu starte.

mein Code ist sehr ähnlich aufgebaut (in PHP). Wobei ich bei den Gebern (z.B. LinearPoti) langsamere CallBack Periodes hab und auch beim LedStrip. Am WoE hat mein LedStrip irgendwann begonnen, keine Callbacks mehr zu generieren. Der Rest läuft noch. Ich werde heut abend meinen PHP Code posten. Meine Vermutung ist, dass es nicht am Code liegt, sondern irgendwo im Queuing oder Buffering. Dass es irgendwann zu einer Konstellation kommt (z.B. mehrere Callbacks zur exakt gleichen Zeit und anderer Zugriff auf den Stack) und dann hängt sich intern irgendwas auf??!?!

"Blöderweise" funktioniert es jetzt wieder mal seit ein paar Tagen - wobei ich dazusagen muss, dass ich die CallbackPerioden runtergesetzt habe (und zeitlich versetzt ein wenig habe). mal sehen....

ok, ich liefere dir so einen Beispielaufbau, der sich bei mir regelmässig aufhängt. gib mir noch ein paar Tage Zeit dafür. den LED Strip hab ich vorher gar nicht erwähnt, weil der immer alles gleich ruiniert (der wird aber diesmal dabei sein).

hi, ich bin's der "reinweb" ;-) weisst du, ich hab schon so viele Versuche in 1000 Varianten gemacht - und immer wieder hängt sich der Stack auf. Reproduzierbar ist nur, dass sich der Stack aufhängt, aber nicht wann und warum. Manchmal hatte ich den Verdacht dass es gehäuft passiert, wenn sich ein anderer WLAN Client anmeldet (z.b. wenn ich nachhause komm und mein Handy sich ins wlan einklinkt). - aber alles eben nicht reproduzierbar. Eines ist allerdings gewiss:: wenn ich die WLAN Extension gegen die LAN Extension tausche, lauft der Stack monatelang ohne irgendeinen Rülpser. Daher liegt die Vermutung nahe, dass sich der Stack ev. dann aufhängt, wenn alle 15 Verbindungen tot sind (also der WLAN 15 "Leben" hat)

hallo Bastian, mir wäre geholfen, wenn ihr einen Referenzaufbau mit Software (Python oder PHP) posten könntet, der bei euch dauerhaft funktioniert. in etwa so: 2 Master, Wifi Extension, 2 Sensoren (z.B. Ambient, Ir-Temp), 2 Geber (z.b. Rotary-Encoder und Linear-Poti) mit Callbacks, 1x Oled 128x64 zur Ausgabe der aktuellen Zeit und der Messwerte. Dann bau ich den exakt nach und prüfe mal bei mir

alles klar, danke Lötkolben fdI

hej Lötkolben, wenn du keine Callbacks verwendest fragst du vermutlich zyklisch ab. In welcher Frequenz? Warum hast du dich gegen Callbacks entschieden?

an das TF Team:: sosehr ich euch schätze und großen Respekt für eure Arbeit habe, so sehr vermisse ich bei diesem Thema eine Reaktion. Vielleicht könnt ihr einen Referenzaufbau (z.B. 2 Master, 1x LedStrip, 1x Oled und dann Bricklets mit häufigeren Callbacks (Ambient, Rotary, Poti) Einfache Software dazu (Lauflicht, Ausgabe der Callback-Werte auf dem Display).

ich hab schon alle Varianten ausprobiert. Mit 1 bzw 2 Masterbrick in einem Stack. mit Master V1 und V2 (und auch gemischt). Wifi Extension 1 & 2. Meine Erfahrung ist, dass es stark mit den Callbacks zusammenhängt. Wenn du schnelle Callbacks (z.B. LedStrip) verwendest, hängt sich der Stack ziemlich schnell auf. Auch, wenn du mehrere Bricklets mit Callbacks hast. Oft ist der Stack noch erreichbar - aber es reagieren keinerlei Callbacks mehr (also auch nicht der Connected und der Enumeration CB).

also ich kann bisher nur äusserst POSITIVES berichten. Einzig mit dem LED-Strip Bricklet in Verbindung mit sehr kurzen FrameCallbacks (20ms) hatte ich noch einen Hänger - musste aber nur die App restarten und nicht den Stack resetten (wie früher).

inspiriert durch einen anderen Post ("teilweise unvollständige Auslieferungsfirmware") habe ich jeden einzelnen Brick & Bricklet neu drübergeflasht. Seither laufen meine Programme problemlos. Es hängt sich kein Callback auf, der Oled verliert keine Verbindung mehr usw.

Seit vielen Monaten habe ich ähnliche Probleme (mit Python und PHP) Meine Erkenntnis: die Wifi Extension ist sehr langsam/träge und empfindlich. Wenn man mehrere Bricklets in dem Stack betreibt mit Callbacks, dann hängen sich diese Callbacks irgendwann mal komplett auf und kommen nicht mehr. Abhilfe hab ich keine gefunden (es hilft auch nichts, die Callbacks regelmässig neu zu konfigurieren). Je kürzer die Callback Intervalle, desto häufiger tritt dies auf. mit den Getter Funktionen sind die Bricklet Werte aber weiterhin abfragbar. Eventuell hängt sich die Wifi Extension auf, wenn 2 Callbacks gleichzeitig auslösen oder sehr viele Callbacks in kurzer Zeit daherkommen. Die Wifi2 Extension scheint hier noch anfälliger zu sein! wenn man 1:1 auf die Ethernet Extension umstellt, läuft es monatelang einwandfrei. Alles in Allem bin ich deshalb mit der Wifi Extension sehr unglücklich, weil so die Verwendungsmöglichkeiten ganz stark einschränken. ich habe es aber auch noch nicht geschafft, jemanden vom TF-Team zu motivieren, einen Stack nachzubauen und den einfach mal laufen zu lassen um zu sehen, wann sich die Callbacks aufhängen Maik, wenn du mir ein Destillat des Sources bereitstellst, schau ich mir das gern an (vor allem mit dem WLAN & RGB Strip hab ich lang gekämpft bevor ich aufgegeben hab)

bin ein wenig weitergekommen:: Der WLAN-Brick ist einfach langsam und schnell überfordert. Resultat bei Überforderung ist einfach sehr unorthodoxes Verhalten oder komplette und dauerhafte Unerreichbarkeit des Stapels. Ich hab in meiner While(true) Schleife jetzt einen sleep von 500ms Sekunden eingebaut. Callbacks kommen in einer Frequez von 1,5 Sekunden. Dann funktioniert es auch mit einem komplexeren Stapel mit mehreren Mastern Instabil wird es scheinbar recht schnell in der Kombination LEDSTRIP-Bricklet und WLAN-Brick. Vielleicht helfen hier höhere Werte in der FrameDuration.

ich sehe 2 Möglichkeiten:: mit RS485 Bricks du belegst einfach 2 USB-Ports vom Raspberry Pi es hängt ein wenig davon ab, wie der "restliche" Stapel aussehen soll

hast du mehr als 1 Master im WLAN Stapel? und Callbacks? würd mich intressieren....

sehr interessant - bei mir haben solche Tests mit multi Apple-APs funktioniert (gleiche SSID, WLAN-Extender). Hat sich brav neu verbunden. Es kann sein, dass die Fritzbox ev. (gleichzeitig) sowas wie einen Kanalwechsel macht - darum hab ich überall "Auto-Kanal" ausgeschalten.. Ich bin ab überlegen, ob ich mir sowas wie einen Auto-Reboot machen soll - also wenn der Stack weg ist, ein automatischer Power-Cycle der Stapel-Stromversorgung erfolgt. Vereinfacht mit einem NE555 Timer, der nach einer bestimmten Zeit einen Relaiskontakt öffnet. Soweit ich gesehen habe, gibt es am NE555 nämlich die Möglichkeit, den Timer wieder rückzustellen (das soll der Stack erledigen). Wenn der Stack das nicht mehr erledigen kann, dann Relais mit Power-Cycle. So ungefähr der Plan aber noch nicht zu Ende gedacht... Das würde dein Problem lösen, meines aber nicht wirklich... Man braucht dafür wohl etwas Elektronik-Hardware- aber vor allem wohl ein zusätzliches Bricklet (kostet Geld und Anschluss). Alternative wäre eine LED "abzufragen", die normalerweise blinkt und beim Leuchten den Timer-Reset zieht. Vielleicht gehe ich aber in die Richtung Raspberry (Zero) und schliesse die Stapel per USB an. Gefällt mir fast besser - und löst meine Probleme auf jeden Fall.

@Lötkolben:: wo sind deine WLAN&TF Troubles?

ja, das habe ich gemeint - eigene SSID, anderer Kanal usw. (Überbelegung mit anderen existierenden WLANs ausgeschlossen) den TP-Link habe ich versuchsweise auch schon auf 11b gestellt mit 1MBit Bandbreite. der einzige WLAN Client ist der TF-Stapel Es macht ein wenig den Eindruck, als wäre bei 2 Mastern die interne Kommunikation im Stapel nicht schnell genug, und das erzeugt Timeouts. nächste Versuche:: 1.) ich versuche mal ein Testprogramm in python zusammenzukopieren. Vielleicht verhält es sich da anders... 2.) ich mach mal ausschließlich mit Gettern und gar keine Callbacks

... der TP-LINK und der APPLE erzeugen jeweils ein separates WLAN...

Hej, ein AP ist ein TP-LINK (ohne Repeater) - Stapel steht 2,5m daneben. zweiter AP ist ein Apple TimeCapsule/Airport Extreme. Den Airport-Express-Repeater habe ich versuchshalber schon abgedreht (macht aber keinen Unterschied). Wenn der Stapel nur 1 Master hat, dann läuft alles sauber - das spricht ein wenig gegen das WLAN als eigentliche Haupt-Ursache. Ich fürchte/vermute es ist die WLAN-spezifische Firmware (im Masterbrick) bzw. dass der zweite Master sich auch WLAN-wichtig macht

nächster Versuch mit dem Datalogger (vom aktuellsten Brickviewer auf IOS):: Scheint immer in Zusammenhang mit mehreren Master in einem Stapel zu stehen... Der Datalogger erkennt im WLAN-Stapel (mit mehreren Master-Bricks) nicht alle Bricklets wenn ich auf "Add Device" drücke - auch nach mehrmaligem Refresh. Mit Ethernet Extension (oder per USB )geht es einwandfrei Der Brickviewer erkennt den gesamten Stapel immer vollständig... weiters ist mir aufgefallen, dass die Connect-Callback-Enumerung sich mit WLAN anders verhält als mit Ethernet. Bei Ethernet melden sich alle Bricks und Bricklets sofort. Beim WIFI nicht - da muss nochmals manuell ein ipConnection->enumerate() aufgerufen werden, damit sich Alle zumindest einmal gemeldet haben (mit unterschiedlichsten Stapeln ausprobiert) es ist nicht ganz auszuschliessen, dass es sich auch um ein Problem der Firmware handelt. Ich habe einen ältern grossen Stapel ausgebaut. Die vollständige automatische Erkennung im Datalogger hat damit sofort funktioniert.