Jump to content

Recommended Posts

Geschrieben

Hallo liebe Gemeinde,

 

mich würde es interessieren, ob es möglich ist von einer Wifi Extension 1.0 die Anzahl der aktuellen Verbindungen auszulesen. Weiß jemand eine Möglichkeit?

 

Hintergrund ist folgender: Ich steuere mit einer Android-App einen LED-Strip. Soweit so gut, aber nach ein paar Befehlen (ein System habe ich noch nicht ausmachen können), reagiert der Strip nicht mehr. In aller Regel ist die Wifi Extension noch pingbar, mit dem BrickV kann ich mich zwar verbinden aber es werden mir keine Module mehr angezeigt. Um das Problem einzugrenzen habe ich auch mit dem BrickV mehrere Befehle an den LED-Strip in schneller Folge gesendet, da funktioniert. Ebenfalls habe ich die APP im Simulator auf dem PC laufen lassen, funktioniert auch. Handy WLAN Verbindung besteht auch nachdem der Fehler aufgetreten ist.

Meine Vermutung ist es nun, dass die App in einem nebenläufigen Thread die Verbindung nicht richtig abbaut, deswegen würde ich gerne auslesen wie viele aktuelle Verbindungen die Wifi Extension hat.

 

Ich wäre sehr dankbar wenn mir jemand helfen kann :-)

  • Replies 81
  • Created
  • Letzte Antwort

Top Posters In This Topic

Geschrieben

Das kannst du so leider nicht abfragen.

 

Wenn sich Brick Viewer noch verbinden kann über WLAN, dann hast du noch nicht alle WLAN Verbindungen aufgebraucht. Denn sonst könnte sich Brick Viewer auch nicht mehr verbinden.

 

Wie setze du denn in deinem Programm die LEDs? Setzt du vielleicht ganze viele LEDs ohne Pause hintereinander weg? Vielleicht versucht du mehr Aufrufe pro Sekunde zu machen als die WIFI Extension schafft. Test mal ob es was bringt zwischen dein einzelnen setRGBValues() aufrufen ein paar Millisekunden zu warten.

 

Kannst du den Code vorzeigen, der das Setzen der LEDs macht?

Geschrieben

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)

  • 2 weeks later...
Geschrieben

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.

 

 

Geschrieben

Hallo Masder,

 

ich hab fuer uns noch eine Idee: Den Brickstack im Keller habe ich noch nicht mit FW 2.41 geflasht. Vielleicht schlaegt hier, bei laengerer Laufzeit, das 256 Byte FW Problem zu? Ausserdem werde ich bei allen Bicklets die FW auch neu ueberbuegeln.

 

Denn: Ich hatte eine Woche keinen AP zur Verfuehgung. Nun steht der alte AP wieder da, aber der Stack ist nicht erreichbar. Ich denke nur ein Powerreset im Keller direkt am Stack hilft.

 

 

Der Loetkolben

Geschrieben

Hallo Loetkolben,

 

also ich habe alle schon min. 1 mal neu geflasht. daran kann es also nicht Ligen.

das mit dem 256Byte Fehler habe ich gar nicht mit bekommen. aber ein guter tip.

werde das die tage mal ausprobieren.

 

mfg

Masder 

 

Geschrieben

Nur als Zwischeninfo:

 

FW 2.4.1 drauf und alle Bricklets neu geflasht.

AP musste ich von Kanal  7 auf 3 umstellen, damit ein Connect zwischen Keller und Wohnung zu stande kommt, obwohl "Gewinnantennen" drauf sind.

 

Der Ping geht mit 3-4 ms gut durch.

 

Mal sehen was die Tage bringen.

 

 

Der Loetkolben

Geschrieben

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).

Geschrieben

 

Mein WLAN-Stack hat nun die 2.4.1 und alle Bricklet druebergeflasht.

 

Gestern war es dann leider schon so weit.

Der Stack war ploetzlich ab 16:00h nicht mehr ansprechbar. Erst ein Powercycle konnte den Kontakt zum AP wieder herstellen. Ob das an der Entfernung liegt weiss ich nicht, aber ich vermute es.

 

Nun ist der Kontakt wieder "stabil". Fast jeder Ping wird mit 3-4 ms beantwortet.

 

Eine Reduzierung der WLAN Leistung ist ausgeschaltet.

 

 

Der Loetkolben

Geschrieben

Hallo,

 

 

ich habe gestern alle meine teile auf den aktuellen stand gebracht und auch neu geflasht, so wie auch die prick viewer alles neu auf dem pc gemacht.

 

leider ist die Verbindung schon nach nur 24 stunden wieder abgerissen.

Wlan Stack nicht mehr erreichbar. Nur nach power restet geht es wieder.

 

@Loetkolben, hatte schon so große Hoffnung das es besser wird :'(

ich vermute also das es bei dir nicht an der Entfernung liegt da bei mir nur ein paar meter überbrückt werden müssen.

 

Gruß

Masder

Geschrieben

Hallo!

 

Hier meine Beobachtung:

 

Ich betreibe 2 Stacks mit WIFI Master Extension (nicht 2.0) mit OpenHAB (1, nicht 2). Einen mit genau einem altem Masterbrick 1.0  (FW 2.4.1), den anderen mit genau einem neuerem Masterbrick 2.0 (FW 2.3.4).

 

Der Stack mit dem alten Master 1.0 ist irgendwann (irregulär) sicher nicht mehr erreichbar und muss dann hart resettet werden. Der andere Stack läuft und läuft und läuft.

 

Muss mal den alten Master austauschen und beobachten. Welche Version vom Masterbrick verwendet ihr in den Problemfällen?

 

Oder es gab doch mal eine Charge nicht ganz perfekter WIFI Extensions?

 

(Bricklets an Master 1.0 sind Temperature / Humidity / Voltage-Current / IO-4, Bricklets an Master 2.0 sind 3 Voltage-Current. An denen sollte es nicht liegen.)

 

Andere Stacks mit Master 2.0 und 2.1 mit Ethernet-Extension laufen rock-solid.

 

 

Gruß, Uwe

Geschrieben

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).

Geschrieben

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).

Geschrieben

Vielleicht hilft das zusammentragen von Informationen hier weiter und man etwas ausschliessen.

 

Ich habe bei dem WLAN Stack ein Master 1, da man nur mit ihm flashen kann wenn eine WLAN Extension drauf ist. (Bug: Master 2.0 und WLAN Extension muss vor dem flashen auseinander gebaut werden).

 

Ich arbeitet mit keinen Callbacks. Null.  ;)

 

Im Moment ist hier seit einigen Tages alles stabil.

 

 

Der Loetkolben

Geschrieben

Hallo reinweb,

 

das hat sich nicht rumgesprochen?  ;)

 

Ich frage den (Wetter-) Stack minuetlich oder ggf. stuendlich ab. Wie sollte man denn Callbacks per Shell programmieren?

 

Es begab sich zu einer Zeit als Tinkerforge mit der Protokollversion 1 und ein paar Bytes in der Lage war mit nur einer Zeile Shell die Temperaturwerte abzuholen. Shellbindings gab es noch nicht.

 

echo -n -e "\x$STACKID\x01\x04\00" | nc -w1 $HOST 4223

 

Seit der Protokollversion 2 muss man ein wenig mehr Coding machen, aber es geht immer noch prima in der Shell.

 

Auch das setzen von LEDs aus der Ferne ist im Prinzip mit einer Shellzeile getan. Die Ansprache der Tinkerforgestacks per Shell hat auch den Vorteil, dass man von kleinen Linuxsystemen mal eben einen Befehl abschicken oder abholen kann, ohne python oder andere Pakete installieren zu muessen. (Z.b. laeuft ein Script auf einem WD NAS ohne an der NAS FW etwas gebastelt zu haben.

 

Weiterhin kann ich Callbacks nicht wirklich auf den WAN Verbindungen gebrauchen, da dort auch mal die Verbindung zusammenbrechen kann und dann die erwartete Kommunikation nicht mehr funktioniert.

 

Wer den Stack im LAN oder per USB betreibt kommt mit Callbacks sicher gut klar.

 

 

Der Loetkolben

 

Geschrieben

@Tingerforge

@batti

@borg

@photron

 

Einer Reaktion zum Tema wäre echt nett.

bis jetzt war ich sehr glücklich mit meinen teilen.

Da wir hier schon länger mit unserem Problem kämpfen und keine Lösung finde,

würden wir uns sehr freuen.

 

@all

werde das auch noch mall via Mail schreiben.

Den es nervt mich mittlerweile so richtig jedes mall wen ich mein licht anmachen will geht es nicht da der stack schon wieder nicht reagiert.

 

hoffe sie sehen es dann mal und hinterlassen wenigstens ein hallo.

 

mfg masder

 

 

 

 

Geschrieben

Hallo zusammen,

 

Sorry, dass ihr von uns so lange nichts dazu gehört habt.

 

Mir ist momentan unklar wie wir euch helfen können, da hier mehrere Probleme verschiedener Nutzer behandelt werden. Alle mit anderen HW Konfigurationen, mit anderer Software usw. Es ist schwer da einen Überblick zu behalten.

 

Masder, bitte poste hier oder schicke uns mal Beispielcode mit dem du dein Problem erzeugen kannst (Wie von Matthias zuvor erbeten). Bitte nenne auch die dazugehörige Hardwarekonfiguration. Dann können wir testen.

 

VG,

 

Bastian

 

p.s.:

Allgemein würde es uns helfen, wenn Ihr die Informationen nicht über mehrere Posts verteilt. Ein Post mit allen Informationen (inkl. Fehlerbeschreibung, genutzte Hardware und Beispielcode) würde es uns sehr erleichtern Probleme nachzustellen.

Geschrieben

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

 

Geschrieben

Hallo Masder,

 

ich kann das morgen zusammen bauen und programmieren. Bin mir aber nicht sicher ob das sinnvoll ist. Wäre es nicht besser, wenn du uns deine Probleme nennst und wir versuchen diese nachzustellen?

 

VG

Geschrieben

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)

Geschrieben

Hallo reinweb,

 

jetzt habe ich dich auch erkannt. ;)

 

Besser wäre es, wenn du uns irgendein Beispiel nennst bei dem es sich bei dir halbwegs reproduzierbar aufhängt. Ich kann dir irgendein Beispiel programmieren, befürchte/glaube/hoffe aber, dass das durchlaufen wird. Dann sind wir genauso schlau wie vorher.

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).

 

Wie steht das im Verhältnis zu deinem Post? Ein LED Strip Bricklet ist bei deinem Wunschbeispiel ja nicht dabei. Deine Beschreibung von "1000 Varianten" hilft uns nicht dabei konkret eine Lösung zu finden.

 

Was bei der WIFI Extension Problematisch sein kann, ist wenn man das System sehr viele Callbacks generieren lässt, die die WIFI Extension in der Zeit nicht verschicken kann (z.B. wegen schlechter Verbindung).

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Gast
Reply to this topic...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.


×
×
  • Neu erstellen...