reinweb Geschrieben April 8, 2016 at 12:59 Geschrieben April 8, 2016 at 12:59 seit Wochen beschäftige ich mich erfolglos mit folgendem Problem: ich habe mittlerweile 5 verschiedene Stacks die alle mit WLAN angebunden sind. Egal wie und was ich probiere... (unterschiedliche Bausteine, USB oder Step-Down Versorgung, wenig Bricklets, viele Bricklet, Bricklet-Callbacks selten oder häufig, unterschiedliche WLAN-Accesspoints, fix IP, DHCP, Stapel komplett zerlegen und nur Master neu flashen, unterschiedliche Aufstellungsorte, ...) also alles was ich probiere - die Stapel sind irgendwann (ein paar Stunden bis längstens ein paar Tage) nicht mehr vom Raspberry ansprechbar (auch nicht mehr Pingbar, vom Brickviewer auch nicht ansprechber). Fehlermeldung meist:: "no route to host". Natürlich (sonst wäre es ja einfach) nicht alle Stapel gleichzeitig unerreichbar sondern alle stark unterschiedlich. Nach einem Stapel-Reset oder Stapel-Power-Cycle läuft alles wieder ordnungsgemäß an (Reconnect, Enumerate & Co). Wie lange laufen bei euch die WLAN-Extension Stapel (im Echtbetrieb mit Callbacks & Co) durch? Was kann die Ursache sein? Eine Vermutung ist, dass durch (aus welchem Grund auch immer) unsauberer Verbindungsabbruch die (in anderen Threads erwähnten) maximalen 15 Verbindungen (der WLAN-Extension) ausgeschöpft sind und daher der Stapel nicht mehr reagiert? Werden diese "Verbindungs-Zombies" gelöscht/entfernt, wenn ich den Masterbrick via Software resette? Oder nur bei einem Hardreset/Power-Cycle? Ein anderer Stapel mit PoE Brick läuft seit vielen vielen Tagen ohne irgendwelche Problem! Bitte um euche fachgerechte Hilfe! Zitieren
reinweb Geschrieben April 12, 2016 at 08:30 Autor Geschrieben April 12, 2016 at 08:30 Hmm, --- keine Reaktionen - ich bin nachdenklich. Entweder ist meine Erklärung zu wirr, das Problem zu simpel / zu komplex / nicht praxisrelevant, ........ meine aktuellen Versuche:: Ich hab mittlerweile mal die Wifi Extension 1:1 gegen die Ethernet Extension getauscht und das Programm läuft total reibungslos Reduktion auf 1 Master im Stapel:: das erhöht die Stabilität enorm. Ich bin fast geneigt zu sagen, es ist weg (damit warte ich aber noch...) --> ich brauch aber mehr als 1 Master im Stapel. identer Stapel:: ich habe einen exakt gleichen Stapel gebaut, die Verbindungsabbrüche fehler sind dort ebenfalls vorhanden. Es kann also nicht an einzelnen Bauteilen liegen. Zitieren
reinweb Geschrieben April 13, 2016 at 11:30 Autor Geschrieben April 13, 2016 at 11:30 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. Zitieren
borg Geschrieben April 13, 2016 at 13:53 Geschrieben April 13, 2016 at 13:53 Du hast in der Tat einen Bug im Brick Logger gefunden, hab das entsprechend gefixt: https://github.com/Tinkerforge/brickv/commit/40689d2b0b6641f91bc30e669601dca3c21e7854 Damit solltest du jetzt definitiv alle Bricks/Bricklets angezeigt bekommen. Du kannst die Bricks/Bricklets allerdings auch in der aktuellen Version schon händisch hinzufügen. Wenn das mit dem Logger dann auch nicht stabil läuft, kannst du uns die Brick Logger Konfiguration mitteilen? Dann können wir das hier parallel laufen lassen. Historisch konnten wir WIFI Extension Stabilitätsprobleme hier leider nie richtig nachstellen . Zitieren
Loetkolben Geschrieben April 13, 2016 at 14:42 Geschrieben April 13, 2016 at 14:42 Hallo. Ein paar Fragen dazu: Wie viele Accesspoints/Repeater hast du? Wenn die WLAN Extension sich an einem (ersten) AP anmeldet und dann auf eine andere MAC umswitcht (gleiche SSID) weil das Signal des ersten AP zu schwach ist, kann es zu Problemen kommen?! Welchen AP hast du? Wenn es eine FritzBox ist, schreib mal das Modell und die FW Version. Mit Wlan habe ich auch, aber andere, Probleme. Vielleicht kann man da aber Zusammenhaenge erkennen. Der Loetkolben Zitieren
reinweb Geschrieben April 13, 2016 at 14:48 Autor Geschrieben April 13, 2016 at 14:48 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 Zitieren
reinweb Geschrieben April 13, 2016 at 16:37 Autor Geschrieben April 13, 2016 at 16:37 ... der TP-LINK und der APPLE erzeugen jeweils ein separates WLAN... Zitieren
Loetkolben Geschrieben April 13, 2016 at 22:43 Geschrieben April 13, 2016 at 22:43 ... der TP-LINK und der APPLE erzeugen jeweils ein separates WLAN... Also mit eigener SSID (Namen) ? Ich kann deiner Theorie folgen und finde die auch schluessig, aber ich wollte nur einen Seiteneffekt ausschliessen. Der Loetkolben Zitieren
reinweb Geschrieben April 14, 2016 at 07:26 Autor Geschrieben April 14, 2016 at 07:26 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 Zitieren
reinweb Geschrieben April 14, 2016 at 07:27 Autor Geschrieben April 14, 2016 at 07:27 @Lötkolben:: wo sind deine WLAN&TF Troubles? Zitieren
Loetkolben Geschrieben April 14, 2016 at 13:04 Geschrieben April 14, 2016 at 13:04 Hallo reinweb, meine Probleme sind zum einen, dass bei einem Multi-AP System, wo man eine SSID und mehrere AP hat, der Tinkerforge Stack Probleme macht, wenn der staerkste (damit ist er verbunden) AP ausfaellt und er sich mit gleicher SSID an einen anderen AP mit andere MAC verbinden soll. Das klappt (bei mir) nicht. Soll heissen: Der Stack im Keller hat eine Verbindung zu AP im Erdgeschoss. Faellt der Erdgeschoss AP aus (Wartung), versucht sich der Stack mit dem AP im 1. OG zu verbinden. Das ist zwar das gleiche WLAN Netz (SSID), aber andere MAC Adresse. Das geht (bei mir) dann leider nicht. (Empfangsstaerke passt). Ich muss erst den Stack per Power-Reset durchbooten. Das andere Problem ist, was ich auch hier schon beschrieben habe, dass die neue Fritzboxsoftware auf 11.b gestellt werden muss, da der (bisherige) Stack nicht mehr als 11.g kommunizieren kann. Das ist meine Probleme. :-) Der Loetkolben Zitieren
reinweb Geschrieben April 14, 2016 at 13:53 Autor Geschrieben April 14, 2016 at 13:53 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. Zitieren
Loetkolben Geschrieben April 14, 2016 at 17:48 Geschrieben April 14, 2016 at 17:48 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. Darum wurde damals auch in den Stack ein bisschen Software eingebaut, dass das WLAN Modul nach 30 Sekunden im Stack resettet wird, wenn die Verbindung weg ist. Also quasi schon ein Watchdog. Du kannst es ja mal beobachten und testen. Man sieht es an der LED des WLAN Moduls. Somit sollte es eigentlich kein Probleme bei Multi AP oder beim Kanalwechsel geben. Da ich meine Multi AP Probleme nicht zu 100% eingrenzen kann und wollte deshalb ein paar Infos von deinen Problemen haben. :-) Das Problem mit der der neuen Fritzboxfirmware, dass die auch 11b enabled haben MUSS ist aber auf jeden Fall reproduzierbar. Der Loetkolben Zitieren
reinweb Geschrieben April 14, 2016 at 20:01 Autor Geschrieben April 14, 2016 at 20:01 hast du mehr als 1 Master im WLAN Stapel? und Callbacks? würd mich intressieren.... Zitieren
Loetkolben Geschrieben April 15, 2016 at 20:22 Geschrieben April 15, 2016 at 20:22 Nein. Maximal (immer) nur ein Master und ich arbeitet ohne Callbacks. Der Loetkolben Zitieren
reinweb Geschrieben April 18, 2016 at 20:25 Autor Geschrieben April 18, 2016 at 20:25 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. Zitieren
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.