reinweb

ja, gute Idee. Zusätzlich zum Bohrplan.

Vermutlich denkst du an das LCD Bricklet, der Doc aber an das hier: HDMI Display 12,7cm (5", 800x480 mit Touchscreen) https://www.tinkerforge.com/de/shop/featured/hdmi-display-5-inch.html

Wieder aufgetreten. Manchmal enthält das $packet "2" - manchmal auch "" (also nix). Wenn es auftritt, dann immer mehrmals (2-3x) hintereinander. Vielleicht sollte ich einfach einen längeren Sleep einbauen.

hej, ich glaube, du solltest googlen nach "Linux Debian write to framebuffer" damit kannst du auf den Screen am HDMI Ausgang direkt schreiben. Selber noch nicht gemacht - vielleicht ist es ein Ansatz für dich.... lg, Reinhard

Nun ist es wieder passiert. Diesmal war aber $packet nicht leer - sondern der Inhalt war "2"!?!? Aufgetreten ist es wieder im Rahmen eines erneuten Enummerierungs-Callbacks. Ist 2x hintereinander vorgekommen und dann nach einiger Zeit nochmals. Durch meine Source-Änderung im IpConnection wurde die TinkerforgeException geworfen und mein Programm ist einwandfrei weitergelaufen (d.h. es sind danach wieder ordentliche Packets gekommen...) lg, Reinhard

also, der Inhalt der $packet Variable ist leer - drum gibt es auch nix zum "unpack" und den "unknown Index" Fehler. Aufgetreten ist der Fehler zuletzt im Zusammenhang mit Enummerierung nach einem ReConnect aufgetreten ist. Also zuerst kommt eine "did not respond in time" Exception. Dann mach ich ein Disconnect und ein Connect. Im Connect-Callback wird die Enumeration ausgelöst. Und der nächste DispatchCallback bringt dann leere $packets. Ich hab jetzt in der IpConnection.php die Zeile 1110 folgendermassen verändert: private function handleResponse($packet, $directCallbackDispatch) {if (strlen($packet)<4) {debug("REINWEB_TF_DEBUG");debug($packet);sleep(2);throw new TinkerforgeException("Empty Packet Received");} Ich wollte die Zeilenanzahl nicht verändern, drum hab ich alle Commands so grauslich in die Zeile 1110 gepackt. Es wird wohl wieder ein paar Stunden dauern, bis der Fehler wieder auftritt. Anmerken möcht ich noch, dass ich den Stack als solches nicht reseten oder power-cyclen musste. Einfach das PHP Programm neu starten und es hat wieder ordentliche "$packet" gegeben. lg, Reinhard

@photron: Anhang dabei... ich teste heute abend mit einem modifizierten IpConnection Modul...

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

Servus Batti, Ich hab einen Stack mit 2x Master, Barometer, TempIR, Dust, CO2, SoundIntensity, AmbientLight, WLAN Extension 2 alle liefern Callbacks. (Software in PHP) zwischen 10 und 11 Uhr heute wurden insg. 14.000 Callbacks ausgelöst (das sind ca 3,9 pro Sekunde). Jeder Callback schreibt was auf's OLED (den aktuellen Wert). Da bekam ich 151x einen Oled->writeline Timeout (did not respond in time). zwischen 14 und 15 Uhr heute wurden insg. 17.000 Callbacks ausgelöst (das sind ca 4,7 pro Sekunde). Jeder Callback schreibt was auf's OLED (den aktuellen Wert). Da bekam ich 1x einen Oled->writeline Timeout (did not respond in time). der WLAN AP steht 3 Meter in Sichtweite. Sonst läuft eigentlich nix am WLAN (nobody @home). Nach jedem Oled->writeline Timeout mach ich ein ReConnect (also Disconnect & Connect). Ebenso wenn 100 Sekunden lang kein einziger Callback ausgelöst wird. Ich glaube, dass irgendwelche unkontrollierbaren Gleichzeitigekeiten dafür sorgen, dass sich die Callbacks aufhängen bzw. diese OLED-Timeouts erzeugen. Wenn ihr ein Referenzprogramm (Datenlogger) mit Callbacks und OLED Support zur Verfügung stellt, könnt ich das dort mal laufen lassen. Das Phänomen tritt bei komplexen Stapel häufiger auf (mehrere Master, mehrere Bricklets mit Callbacks). Und nur bei WLAN lg, Reinhard

Soweit so gut, aber wie interpretiere ich dies Info bzw. gibt es eine If Bufferzustand == xx {dann....} Logik?

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

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.

hallo - eine Frage zum DataLogger:: soweit ich den Source durchschaut habe, arbeitet der DataLogger nicht mit Callbacks sondern mit aktiven GET-Abfragen (je nach Bricklet Typ). Ich wäre dankbar, wenn ihr eine Referenzimplementierung bereitstellt - die ähnlich wie der DataLogger ist, aber mit Callbacks arbeitet und die Ergebnisse in einem OLED oder LCD Bricklet mitscrollen lässt. Das wäre echt super und ist vermutlich auch nicht übermässig viel Arbeit für euch...

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.

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.

... d.h. diese Situation/Bug: kann mit der WLAN-Extension 1 nicht vorkommen?

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?

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

aktueller Zwischenstand: Der Trick funktioniert. Mindestens 1x verliert jeder Stapel seine Callbacks - mit einem Disconnect & Connect läuft dann alles wieder gut. Warum das so ist und ob sonst niemand diese Troubles hat ist mir mittlerweile sekundär. Es läuft stabil und damit passt es für mich. Danke TF-Team für den Hinweis.

Klasse & Danke für die Rückmeldung!

Erfolgsmeldung - zurück auf 2.0.0 und dann auf 2.0.1 hat funktioniert! DANKE!

hallo Proton, danke für deine Hilfe & für deinen 2000 Post! probier ich dann gleich aus!

Zwischenstand: Mein WLAN Stapel läuft jetzt im Stresstest seit 2016-10-12 23:03:26 insg. 14x sind die Callbacks verloren gegangen. Wie in einem vorigen Post beschrieben, wird (wenn 10 Sekunden kein Callback aufgerufen wurde) $ipcon->enumerate() aufgerufen. Wenn das die Callbacks nicht reaktiviert folgt ein $ipcon->disconnect & $ipcon->connect (war bisher immer notwendig um wieder Callbacks zu bekommen) Ist bis jetzt 14x (unregelmässig) aufgetreten. Der Stapel läuft mit diesem Trick einwandfrei. So stabil wie noch nie zuvor! :-)

zusatzinfo: nutze zum flashen den BrickViewer für OSX. Brick neu geflasht und dann die Wifi Extension - nutzt auch nix Wifi Firmware neu runtergeladen & geflasht - negativ intressant ist, dass die BrickViewer Seite zum Flashen die aktuelle Version nicht erkennt (Vergleich siehe Anhänge) irgendwie schaut es so aus, als ob das Flashen nicht gefunkt hätte - wobei ich nach dem Wifi2.0.1 flashen die Success Meldung bekomme....

hallo, nach dem Einspielen der neuen WLAN Firmware kann ich keine neue WLAN Konfig (dhcp, client mode) abspeichern "Could not save Configuration" Master 2.1, neueste Firmware, neuester BrickViewer. Klarerweise Rest, PowerOff & Co alles probiert. derselbe Brick und ein Wlan 2.0 mit Auslieferungsfirmware funktioniert einwandfrei Kämpft noch wer?