[Java] Wifi Extension: Anzahl aktueller Verbindungen auslesen?

[Masder]

Hallo batti,

 

die Firmware 2.0.2 habe ich getestet, sie ist sehr Stabil bei mir.auch bei sehr vielen Nachrichten.

getestet habe ich mit Dem Brickviewer Moving Color, frame duration =50 speed =9

und es wurden 150 RGB-LED gesteuert. Ergebnis nach ca 30 Min funktioniert immer noch alles einwandfrei.(Langzeit test mit meiner Software läuft noch aber bis jetzt 4 tage bis jetzt ist nix aufgefallen)

Die Einstellungen beim Master 1.1 werden nicht gespeichert (habe ihr da zu was gefunden?).

 

FW: 2.0.3 werde ich die tage mal aufspielen.

 

mfg masder

[reinweb]

hej, DANKE :-) für 2.0.3 - ja, das könnte "mein Problem" sein!

gibt es eine Möglichkeit, diese Situation auch bei der WLAN-Extension der 1. Generation abzufangen? Diese hat mit der Möglichkeit der externen Antenne noch immer eine wichtigen Vorteil (weil ich üblicherweise geschirmte Gehäuse mit externer Antenne verwende).

lg, Reinhard

[batti]

Hallo Reinhard,

 

das mit dem response expected gilt für alle unsere Produkte unabhängig von Extensions. Du kannst das auch mit einer WIFI V1 nutzen.

[reinweb]

das mit dem SetResponseExpected praktiziere ich schon. Da bekomme ich dann im Fehlerfall eine Timeout-Exception auf die ich reagieren kann.

 

Aber für den Kniff mit dem SetResponseExpected braucht's ja keinen WLAN-Firmware-Update. Darum meine Frage: kann ich auch mit der WLAN-Extension V1 in den Genuss der Firmware-Verbesserungen kommen?

 

[batti]

Sorry Reinhard,

 

die WIFI Extensions Version 2 und Version 1 nutzen komplett unterschiedliche Software. Der gefundene Bug bezieht sich nur auf Version 2.

[reinweb]

... d.h. diese Situation/Bug:

In der Tat gab es noch einen "Bug", der auftreten konnte, wenn mehr Nachrichten aufgetauscht werden sollten, als die WIFI Extension schaffte.

 

Hier der Changelog zur Firmware:

 

    Ein-/Ausgangs-Buffergrößen vergrößert

    Halte TCP Transfers bevor die Buffer überlaufen (Nachrichten werden beim Sender gebuffert)

kann mit der WLAN-Extension 1 nicht vorkommen?

[batti]

Dieser Bug bezieht sich nur auf den Code der WIFI V2. WIFI V1 arbeitet intern komplett anders. Das Problem sollte bei der V1 nicht vorkommen.

[reinweb]

Danke!

im grunde merke ich mit V2.0.3 keinen Unterschied. Manchmal verliert der Stack die CallBacks, aber nach dem Re-Connect passt alles wieder.

[Quantasy]

Ich glaube, an der gleichen Stelle zu scheitern!

 

Wenn ich den brickv benutze und über eine WLAN-Extension 1 einen Stack (StepDown, Master(2)->LEDBricklet, WLAN, Master(2.1)->LEDBricklet, Master(2)->LEDBricklet) anspreche,

und 40LEDs, 160LEDs, 192LEDs mit 100ms ansteuere

dann bricht !irgendwann! (manchmal nach ein paar Sekunden, manchmal nach so ca. 120') die Kommunikation zusammen... Ich weiss nicht wann und warum; ein Muster konnte ich nicht erkennen.

 

Im brickv sehe ich dann noch die Volt-Angabe sich ändern, aber die LEDs können nicht mehr angesprochen werden. Ich denke, der frameRendered-callback kommt einfach nicht mehr.

 

Dann plötzlich wird die Sache dramatischer, denn brickv versucht einen 'Autoreconnect' o.ä. zu machen, was aber kläglich scheitert... der Stack ist nicht mehr erreichbar.

 

Ich nutze extra brickv, damit dies vom TF-Team auch nachgestellt werden kann!

 

Kann das TF-Team dieses Verhalten bestätigen, oder läuft bei euch... bei irgend jemandem in der TF-Welt ein ähnliches Setting seit Tagen stabil?

 

Da ist doch irgend so ein fieser Race-Condition-Bug im Spiel?! Das muss sich doch finden und eliminieren lassen!

 

Noch ein Hint zu diesem Problem:

Habe ein eigenes Programm geschrieben, welches die LEDs (Framerate 200ms) anschaltet, sobald ein MotionDetection-Bricklet (im gleichen Stack wie die LEDs) 'jemanden sieht'. Das läuft dann aber auch nach ein paar Stunden nicht mehr, weil das Event vom MotionDetection-Bricklet nicht mehr ankommt.

ABER: Wenn ich dann mit dem brickv auch noch auf diesen Stack zugreife... dann sehe ich die Wechselnden Zustände vom MotionDetector im brickv. Mein ursprüngliches Programm aber, wartet bis auf den St. Nimmerleinstag auf einen Event vom MotionDetection-Bricklet.

 

Ich denke, die FrameRendered-Callbacks 'abzuschalten' würden das Problem mindern, aber es löst es nicht.

 

Aber der Trick mit dem Disconnect/Connect kann doch nicht die offizielle Lösung sein?! So ein 'Watchdog', der immer mal wieder resettet, ist wohl eher ein 'Bill Gate-scher' Ansatz.

 

Bitte guckt euch die Sache nochmal an, da muss eine dreckige Race-Condition im Spiel sein!

[reinweb]

Quantasy, find ich gut wie du das aufgebaut hast. Auf diese Art ist es wirklich auch für TF reproduzierbar. Wenn du das WLAN Modul gegen ein LAN Modul austauscht, läuft es problemlos.

Das WLAN Modul reagiert unter "Überbelastung" nicht zuverlässig und gibt auf. Diese Überbelastung ist auch manchmal schon erreicht, wenn 2 Callbacks sehr knapp hintereinander daherkommen (und das kann man nicht verhindern).

Ich hab eine Routine, die das OLED Display mit writeLine beschreibt. Wenn man keine Pause macht dazwischen, hängt es sich auch auf.

[Quantasy]

Hey Reinweb, danke für die erste Aufklärung.

LAN kann bei mir aber nicht in Frage kommen, da ich an dieser Stelle keine Datenleitung habe und der WAF (der durch die häufigen 'Hänger' sowieso schon im <0.xx Bereich) in Richtung 1/unendlich zeigen würde.

 

Wenn das mit den Events, welche zu kurz hintereinander kommen schon die ausgemachte Ursache ist, dann müsste der Master-Brick die WLAN-Extension doch einfach davor schützen... Lieber stottert die Sache 'kurz', als dass sie abstürzt?!

Oder aber das verwendete (TCP) Protokoll von TF erlaubt ein Zusammenfassen von Callbacks, aber das wäre sehr tief unten angesetzt...

 

Die WLAN Extension V2 funktioniert denn die? Nach Deiner Aussage vom 02. November scheint ja auch die das nicht zu packen und der 'Watchdog' mit dem Disconnect/Connect Trick muss immer mal wieder ran?!

 

 

[Masder]

Hallo Quantasy,

 

Ich habe so zu sagen genau dein problemm.

habe 150LED die steuer ich über Wlan.

Mit dem Wlan 2.0 mit FW:2.0.3 habe ich mall test über 30 min gemacht da ist der Stack nicht mehr ausgefallen.

 

Test 150LEDs mit 50ms move color speed 9, natürlich mit Brickv

 

Master 2.0 Wifi 1 = Stack reagiert nach ca 2 min immer nicht mehr.

Stack steigt auch bei 100ms Frame oder 200ms aus, wen man auf 200 hoch geht daut es ein paar min länger.

 

Master 2.0 Wifi 2.0= Stack schaft 30 min ohne Ausfall.

 

 

 

Längeren test werde ich ab nächsten monnat noch mal angehe da ich gerade umziehe.

 

 

mfg masder

 

 

[reinweb]

ich denke, der Ansatz mit dem Brickviewer und dem LED-Bricklet ist eine hervorragende Überlegung für eine nachvollziehbare Laborumgebung zur Stabilitätsmessung.

zusätzlich hab ich jetzt mal das hier vorgeschlagen: Datalogger mit Callbacks und scrollende Oled Ausgabe http://www.tinkerunity.org/forum/index.php/topic,3893.0.html

weil ich hoffe, dass wir damit das Problem-Thema in Mulit-Bricklet Umgebungen reproduzierbar machen können.

 

[reinweb]

mir ist am WoE diese Funktion hier aufgefallen:

http://www.tinkerforge.com/de/doc/Software/Bricks/Master_Brick_PHP.html#BrickMaster::getWifiBufferInfo

was genau bedeudet das? und kann es einen Zusammenhang mit hier diskutierten Phänomen geben?

Nachdem das Phänomen immer(?) in Zusammenhang mit Callbacks auftritt, wird der Buffer ja von der anderen Seite (vom Stack) gefüllt.

lg, Reinhard

[batti]

Hallo zusammen,

 

hier hat sich ja wieder einiges angesammelt.

 

Ich versuche das ganze mal zusammenzufassen:

 

1) Mit WIFI 2.0 sind uns nach der Firmwareänderung keine weiteren Probleme mehr bekannt. Damit sollte alles wie gewünscht laufen.

 

2) Mit WIFI 1.0 kann es Probleme geben. Wir sind da zur Zeit bei.

 

Zur Frage von Reinhard:

http://www.tinkerforge.com/de/doc/Software/Bricks/Master_Brick_PHP.html#BrickMaster::getWifiBufferInfo

was genau bedeudet das? und kann es einen Zusammenhang mit hier diskutierten Phänomen geben?

Die Methode gibt wie beschrieben Informationen zum Zustand des Buffers (Überläufe etc.).

 

Zu der Wifi 1.0 Geschichte melde ich mich noch.

[reinweb]

Zur Frage von Reinhard:

Zitat

 

    http://www.tinkerforge.com/de/doc/Software/Bricks/Master_Brick_PHP.html#BrickMaster::getWifiBufferInfo

    was genau bedeudet das? und kann es einen Zusammenhang mit hier diskutierten Phänomen geben?

 

Die Methode gibt wie beschrieben Informationen zum Zustand des Buffers (Überläufe etc.).

 

Soweit so gut, aber wie interpretiere ich dies Info bzw. gibt es eine

If Bufferzustand == xx {dann....}

Logik?

[batti]

Das zurückgegebene Array enthält die Keys overflow, low_watermark und used.

 

overflow gibt dir an ob es seit dem Start jemals ein "overflow" gab, "low_watermark" die größte Ausnutzung des Puffers, und "used" wieviel Bytes vom Puffer aktuell benutzt werden.

 

Dafür gibt es keine vorhergesehende Logik. Das ist erst einmal nur eine Statusinformation.

 

btw.

Ich habe jetzt hier seit über einer Stunde einen Aufbau mit WIFI 1.0 Extension und LED Strip Bricklet am laufen und lasse einen "Moving Color Gradient" mit 100ms Frame duration und 150 LEDs laufen. Bisher kein Neustart oder irgendwelche anderen Problem. Teste weiter...

[Masder]

Hallo batti,

 

danke für das Update, Mit welchem Master testest du?

ich muss das bei mir noch mall test aber bei mir gab es da auf jeden Fall einen absturz mach 2 min.

 

weis aber nicht mehr mit welchem ich getestet habe, Master 1.1 oder 2.0. (glaube mit Master 1.1)

 

mfg masder.

[batti]

Ich teste aktuell mit einem Stapel aus drei Master Bricks 2.0 (hatte ich gerade zur Hand)

[batti]

Der Test mit den drei Master Bricks ist über Nacht durchgelaufen. Ich hatte nur einen angezeigten Timeout im Brick Viewer. Kein Neustart o.ä.

 

Habe den Test jetzt umgebaut (von unten nach oben):

Step Down Power Supply

Master Brick 2.0

WIFI 1.0

an Port D über 15cm Kabel angeschlossenes LED Strip Bricklet

 

Chip Typ WS2801, 10ms Frame Duration, 150 LEDs und dann "Show Moving Color Gradient".

 

Das Läuft aktuell auch bereits wieder über eine Stunde ohne Probleme. Teste ich noch falsch? Kann es sein, dass bei euch der WLAN Empfang sehr schlecht ist o.ä.? (Access-Point ist bei mir 10m Luftlinie entfernt mit einer Holzdecke dazwischen)

[Masder]

Hallo batti,

 

auf bau ist gleich bis auf Master da glaube ich eben den 1.1 benutzt zu haben

oder einen Stack mit Master 2.0 und Master 1.1.

 

ich werde das bei mir noch mal test die tage.

 

Empfang sollte kein Problem sein bei mir sind es gerade mal 1-2m zwischen Stack und Router

 

was noch anderst bei mir ist ich benutze eine  WS2812 LED-strip

 

 

mfg masder

[Quantasy]

Langsam glaube ich an Sonnenflecke!

 

Motiviert von den neusten Tests habe ich erneut einen Aufbau gemacht:

brickv2.3.6 steuert folgendes an (von unten nach oben):

StepDown (5V kommt rein... ist ein wenig knapp!)

Master2.0 B -> LEDBricklet -> 120xWS2811

          D -> LEDBricklet -> 120xWS2811

WiFiExt 1.0

Master 2.1 A -> RotaryEncoder

          D -> MotionDetector

 

10ms Frame Duration. Eine LED-Leiste mit 'Moving Color Dot', die andere mit 'Moving Color Gradient'

Das läuft seit mehr als 5 Stunden super... habe zwar über 3000 Timeouts aber läuft.

Ich verwende eine WiFi-Extension, welche ich auch beim anderen Stack benutzt hatte und welche dort garantiert den Dienst nach wenigen Minuten versagte. Das benutzte Netz ist das selbe wie beim Stapel, der 'zusammenbricht'.

 

Unterschiede zu meinem anderen Aufbau, der fast sofort zusammenbricht:

-LEDBricklets sind nun an einem einzigen Master Brick.

-LEDs sind von der selben Art.

-Andere 'Instanzen' der Master Bricks. (Habe beide Stapel parallel aufgebaut).

 

 

 

Warum läuft der? (Sollte ja eigentlich glücklich sein... aber irgendwie ist das ganze spooky)

 

Problem am Rande: Durch den BrickV weiss ich nicht, ob die Events des Rotary bzw. des MotionDetectors noch durchkommen... BrickV polled ja.

 

[Quantasy]

Nein.

Nach ca 34h  Online war's dann doch wieder so weit. Der Stack hat sich 'aufgehängt'.

Der Motion-Detector leuchtet dann ständig (als hätte er einen MotionDetectCycle am laufen), die blaue LED des Masters flackert zwar noch, aber der Stack ist nicht mehr zu erreichen.

 

Ich habe extra darauf geachtet, ob die FritzBox vielleicht einen Kanalwechsel im bgn-Netz vorgenommen hätte. Nein. War stets auf Kanal 11.

 

[reinweb]

Hallo,

 

Im Stresstest verhält sich mein Stapel (Wifi 2.0 mit Callbacks für LED Strip (40ms) und Sound Intensity (500ms) und Ambient Light (500ms)) nun mittlerweile ziemlich stabil, jedoch passiert nach einiger Zeit  folgendes:

 

Notice Error: Undefined index: sequenceNumberAndOptions in [/var/www/html/raspix350/vendor/Tinkerforge/IPConnection.php, line 1115]

Warning Error: unpack(): Type C: not enough input, need 1, have 0 in [/var/www/html/raspix350/vendor/Tinkerforge/IPConnection.php, line 1111]

Notice Error: Undefined index: functionID in [/var/www/html/raspix350/vendor/Tinkerforge/IPConnection.php, line 1114]

 

Das Detail-Log hab ich im Anhang bereitgestellt. Was isn das für ein Problem? Was könnte die Ursache sein? Meiner Einschätzung kann es nicht an meinem Code liegen, weil der läuft viele Stunden / einige Tage durch.

 

Ich werde mir den IpConnection Code anpassen, sodass eine "TinkerforgeException" geworfen wird, wenn die Funktion "IpConnection->handleResponse" fehlschlägt. Das fliegt dann natürlich beim Update raus. Vielleicht könnt auch ihr den PHP Code an dieser Stelle etwas robuster machen.

 

Danke vorab. Reinhard

Aktualisierung 24.11: Anhang jetzt dabei

currentProb.txt

[photron]

reinweb, du hast keine Datei an deinen Post angehängt.

 

Kannst du was über den zeitlichen Zusammenhang dieser 3 Zeilen sagen?

 

Alle 3 Zeilen hängen mit dem Entpacken des Packet Headers zusammen. Alle drei sehen so aus als ob sie einen zu kurzen Header behandeln.

 

Die receive Funktion ruft aber die handleResponse Funktion nur auf, wenn die komplettes Packet mit vollständigem Header empfangen wurde.

 

Die einzige Möglichkeit die ich im Moment für diese Fehler sehe, ist, dass ein kaputtes Packet empfangen wurde in dem das Längen Feld im Header einen ungültigen Wert (kleiner 8 Bytes) enthalten hat. Das wird momentan noch nicht geprüft, steht aber auf der Todo Liste, dass in allen Bindings zu verbessern.

 

Die Frage ist jetzt wo dies kaputtes Packet hergekommen ist.

 

Interessant wäre es den Inhalt der $packet Variable zu sehen, wenn diese Fehler auftreten.