[Java] Wifi Extension: Anzahl aktueller Verbindungen auslesen?

[reinweb]

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

[batti]

Ok, Danke!

[Masder]

Hallo batti,

 

Stack auf bau

 

Master 1

Master 2.0

Wifi Master 1

Master 2.1

Step-Down

 

angeschlossen habe ich an brick letzt Ambient Light/Temperature/Humidity/Linear Poti/

Multi Touch LCD 20x4 1.2 und ein LED Strip Bricklet.

 

der Stack habe ich schon über 2 Jahre oder länger so.

am Anfang über USB angeschlossen dann über Ethernet Master Extension

da gab es auch keine Probleme. erst als ich den Wifi Master eingesetzt habe

aufgehängte sich der Stack immer auf.

 

meine Code werde ich die tage auch gerne mall postet.

ich habe aber alles so wie in den beischpielen stack via. brotcast finden

alle zurück melden den Bricklets einen callback einrichten sie sollen so alle min wen sich was ändert antworten, auser Linear Poti /Multi Touch die sind deutlich schnell.

 

ausgeschlossen habe ich ihn da es ja mit dem Ethernet Master Extension

einwandfrei funktioniert hat.

 

wann genau der Fehler auftritt kann ich nicht sagen. bei mir ist es immer unterschiedlich.

 

ich werde die tage mall schauen ob ich mein Programm so erweitere das er mir eine Meldung auswirft wann er die Verbindung verloren hat vieleicht finde ich dann was genaueres raus.

 

 

was ich aber weis ist das der Stack sich oft aufhängt wen ich nichts mache also

wären ich schlafe oder auf arbeit bin.

 

 

mfg masder

 

 

 

 

 

 

 

 

 

 

 

[Loetkolben]

Hallo batti,

 

Stackaufbau

 

Master 1

Master 2.0

Wifi Master 1

Master 2.1

Step-Down

 

Kann es sein, dass der WLAN Master OBEN sein muss?

 

 

Der Loetkolben

[batti]

Hallo Loetkolben,

 

nein, das ist prinzipiell egal. Elektrisch ist das egal. Wir hatten mal einen Fall, wo es Probleme mit den Stapel-Kontakten gab, wo es einen Unterschied machte wo die Extension steckt.

[reinweb]

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

[batti]

Okay... Warten wir mal ab

[Masder]

Hallo batti,

 

 

heute kommt mein gewaltiger Code block.

 

ipcon2.addEnumerateListener(new IPConnection.EnumerateListener() {
		public void enumerate(String uid, String connectedUid,
				char position, short[] hardwareVersion,
				short[] firmwareVersion, int deviceIdentifier,
				short enumeerationType) {
//				Stack2
			if(enumeerationType == IPConnection.ENUMERATION_TYPE_CONNECTED ||enumeerationType == IPConnection.ENUMERATION_TYPE_AVAILABLE ){
				if(deviceIdentifier == BrickletLCD20x4.DEVICE_IDENTIFIER){
					lcd = new BrickletLCD20x4(UID2, ipcon2);
			        lcd.addButtonPressedListener(new BrickletLCD20x4.ButtonPressedListener() {
			            public void buttonPressed(short button) {
							if (button == 2) {									



							}
							if (button == 0) {

							}
			            	
			            }
			        });
			        // Add button released listener
			        lcd.addButtonReleasedListener(new BrickletLCD20x4.ButtonReleasedListener() {
			            public void buttonReleased(short button) {
			            	
			                if (button ==2){

			                }
			                        
			            	
			            }
			        });
					try {		
						lcd.setConfig(false, false);
						lcd.clearDisplay();


					} catch (Exception e) {
						e.printStackTrace();
						log(" lcd: Enumerate");
						log(e.getMessage());
						log(" ");
					}

				}
				if(deviceIdentifier == BrickletHumidity.DEVICE_IDENTIFIER){
					hum = new BrickletHumidity(UID3, ipcon2);	
					try {
						hum.setHumidityCallbackPeriod(20000);
						huml = (new BrickletHumidity.HumidityListener() {
							public void humidity(int humidity) {
								RH = humidity;
								xml.setHR(humidity);
							}
						});
						hum.addHumidityListener(huml);
					} catch (Exception e) {
						// TODO Auto-generated catch block
						e.printStackTrace();
						log(" :Humidity  Enumerate");
					}
				}
				if(deviceIdentifier == BrickletAmbientLight.DEVICE_IDENTIFIER){
					al = new BrickletAmbientLight(UID4, ipcon2);
					try {
						al.setIlluminanceCallbackPeriod(20000);
						all = (new BrickletAmbientLight.IlluminanceListener() {

							public void illuminance(int illuminance) {
								Lux = illuminance;
								xml.setLux(illuminance);
							}
						});
						al.addIlluminanceListener(all);
					} catch (Exception e) {
						// TODO Auto-generated catch block
						e.printStackTrace();
						log(" :AmbientLight Enumerate");
					}
				}
				if(deviceIdentifier == BrickletRemoteSwitch.DEVICE_IDENTIFIER){
					rs = new BrickletRemoteSwitch(UID5, ipcon2);
				}
				if(deviceIdentifier == BrickletMultiTouch.DEVICE_IDENTIFIER){
					Touch = new BrickletMultiTouch(UID7, ipcon2);
					try {
						Touch.setElectrodeConfig((int) (0b0111111111111));
						Touch.setElectrodeSensitivity((short) (80));
						Touchi = (new BrickletMultiTouch.TouchStateListener() {
							public void touchState(int touchState) {
								if ((touchState & 1 << 0) == 1) {//taste:1
									Menu(10);

								}
								if ((touchState & 1 << 1) != 0) {//taste:2
									Menu(11);
								}
//

							}
						});
						Touch.addTouchStateListener(Touchi);

					} catch (Exception e) {
						// TODO Auto-generated catch block
						e.printStackTrace();
						log(" :MultiTouch Enumerate");
					}

				}
				if(deviceIdentifier == BrickletLinearPoti.DEVICE_IDENTIFIER){
					fyM = new BrickletLinearPoti(UID8, ipcon2);
					try {
						fyM.setPositionCallbackPeriod(10);
						Lith2=fyM.getPosition();
						liht = (short) ((255 / 100) * fyM.getPosition());
						fyM.addPositionListener(new BrickletLinearPoti.PositionListener() {			
							public void position(int position) {
				            	
//

							}
						});
					} catch (Exception e) {
						// TODO Auto-generated catch block
						e.printStackTrace();
						log(" :LinearPoti Enumerate");
					}

				}
				if(deviceIdentifier == BrickletPiezoSpeaker.DEVICE_IDENTIFIER){
					ps = new BrickletPiezoSpeaker(UID11, ipcon2);
				}
				if(deviceIdentifier == BrickletTemperature.DEVICE_IDENTIFIER){
					temp = new BrickletTemperature(UID1, ipcon2);
					try {
						temp.setTemperatureCallbackPeriod(10000);
						T = temp.getTemperature();
						templ = (new BrickletTemperature.TemperatureListener() {
							public void temperature(short temperature) {
								int i = T;
								if (i-6 <= temperature && i+6 >= temperature){
									T = temperature;
									xml.settemp(temperature);
								}

							}
						});
						temp.addTemperatureListener(templ);
					} catch (Exception e) {
						// TODO Auto-generated catch block
						e.printStackTrace();
						log(" :Temperature Enumerate");
					}
				}
				if(deviceIdentifier == BrickletLEDStrip.DEVICE_IDENTIFIER){
					ledStrip = new BrickletLEDStrip(UID9, ipcon2);
					try {
						ledStrip.setFrameDuration(50);
						ledStrip.setChipType(2812);
						ledStrip.addFrameRenderedListener(new BrickletLEDStrip.FrameRenderedListener() {
							public void frameRendered(int length) {

//
							}
						});
					} catch (Exception e) {
						// TODO Auto-generated catch block
						e.printStackTrace();
						log(" :LEDStrip Enumerate");
					}						
					ledchange = 1;
					setLED();
				}
				}				
			}
		});

 

 

ich habe ein paar Sachen raus genommen damit es nicht zu viel wird.

und da es meistens nur verweise auf mein program waren.

hoffe ich habe nix wichtige raus gelöscht

 

 

mfg masder

[batti]

Hallo Masder,

 

Danke für den Code. Das sieht ja alles sehr harmlos aus (bzgl. Callback Perioden etc.). Mit diesem Code kannst du bei dir Probleme erzeugen?

 

Wie sehen diese aus?

Womit muss ich testen (HW aufbau)?

[reinweb]

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??!?!

[Masder]

hallo batti,

 

ja damit erzeuge ich den Fehler.

ich hatte die tage auch mall den Fall das der Stack sich aufgehängt hatte als ich mit dem brickviewer zusätzlich mich verbunden haben.

 

mir fällt da aber noch was ein.

ich benutze die Funktion ConnectedListener() nicht das dass ein Problemm verursacht nach mehr maligen verbinungs auf bau oder so ?

 

Stack poste ich heute Abend weis es nicht auswendig

 

MFG masder

[batti]

Masder, bitte schicke mir doch einmal deinen vollständigen (=lauffähigen) Code mit dem du testest.

[batti]

Noch ein Nachtrag zu dem Connection kram. Im Gegensatz zu dem Brick Daemon, der prinzipiell unendlich viele Verbindungen halten kann, haben Ethernet Extension und WIFI Extension nur begrenzt viele Verbindungen. D.h. wenn euer Code mehr Verbindungen aufmachen will als möglich, werden irgendwann Verbindungen geblockt. Symptom ist dann, dass der Stapel nicht mehr "erreichbar" ist.

[Masder]

hallo batti,

Programm schick ich dir gerne heute Abend.

 

wie viel Verbindungen gehen den maximal ?

gibt es den eine Möglichkeit bei deinem neu verbinden die alten Verbindungen zu beenden so das man nicht an die maximale anzahl kommt.

 

 

mfg masder

[reinweb]

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.

[batti]

wie viel Verbindungen gehen den maximal ?

Zitat aus der Dokumentation (Tabelle):

"Maximale Anzahl gleichzeitiger Verbindungen 10"

 

gibt es den eine Möglichkeit bei deinem neu verbinden die alten Verbindungen zu beenden so das man nicht an die maximale anzahl kommt.

"ipcon.disconnect();"

 

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

Reset des Master Bricks, der die WIFI Extension nutzt führt dazu, dass die WIFI Extension neu initialisiert wird. Dabei werden alle zuvor bestehenden Verbindungen "gelöscht". Dies ist auch die einzige Möglichkeit alle Verbindungen zu löschen. Richtige Vorgehensweise ist jede Verbindung auch irgendwann zu schließen.

 

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.

 

Sind die Callbacks denn noch konfiguriert? Am besten du schreibst dir ein kleines Programm, was den Zustand der Callbacks abruft. Dieses Programm rufst du auf, wenn der Stack wieder in diesem Zustand ist.

Dann gibt es zwei Möglichkeiten:

 

1) Die Callbacks sind noch wie gewünscht konfiguriert.

Wäre sehr komisch, kann ich mir nicht so recht vorstellen.

 

2) Die Callbacks sind nicht mehr konfiguriert.

Hier wird es interessant. Entweder ein anderes Programm hat die Callbacks umkonfiguriert (deaktiviert) oder der Stapel wurde/hat sich neu gestartet.

 

Masder dein Programm versuche ich gleich hier mal laufen zu lassen.

[reinweb]

Hallo Batti,danke für deine Antworten.

Reset des Master Bricks, der die WIFI Extension nutzt führt dazu, dass die WIFI Extension neu initialisiert wird. Dabei werden alle zuvor bestehenden Verbindungen "gelöscht". Dies ist auch die einzige Möglichkeit alle Verbindungen zu löschen. Richtige Vorgehensweise ist jede Verbindung auch irgendwann zu schließen.

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)

 

 

Sind die Callbacks denn noch konfiguriert? Am besten du schreibst dir ein kleines Programm, was den Zustand der Callbacks abruft.

Guter Hinweis - DANKE, das mache ich!

[batti]

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

Korrekt

[Masder]

batti,

 

 

ich habe mir gearde die docku vom wifi 2.0 durch gelesen.

da gibt es eine web seite die anzeigt wie viele verbindungen offen sind.

kann man das irgend wie auslessen? beim wifi 1.0.

 

wen möglich könnte ich ja dann immer den stack reseten wen 8-9 verbindungen offen sind.

 

mfg masder

 

 

[reinweb]

Sind die Callbacks denn noch konfiguriert? Am besten du schreibst dir ein kleines Programm, was den Zustand der Callbacks abruft. Dieses Programm rufst du auf, wenn der Stack wieder in diesem Zustand ist.

Dann gibt es zwei Möglichkeiten:

 

1) Die Callbacks sind noch wie gewünscht konfiguriert.

Wäre sehr komisch, kann ich mir nicht so recht vorstellen.

 

2) Die Callbacks sind nicht mehr konfiguriert.

Hier wird es interessant. Entweder ein anderes Programm hat die Callbacks umkonfiguriert (deaktiviert) oder der Stapel wurde/hat sich neu gestartet.

 

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!

[batti]

Masder:

 

Die Anzahl der Verbindungen auszulesen ist wirklich nur über die Webseite möglich. So etwas hat die 1.0er Version nicht.

 

Bin heute noch nicht dazu gekommen deinen Code mal laufen zu lassen. Sah auf dem ersten Blick nichts böses im Code. Baue das morgen mal auf.

 

 

 

Reinweb:

Das ist interessant. Die einfachste Erklärung ist, dass die Verbindung tot ist. Der Frage ist warum.

 

Könnte daran liegen, dass das WLAN gestört ist (außer Reichweite o.ä.) und dass das auto-reconnect nicht funktioniert. Alternativ hat sich der Stapel neugestartet.

 

Mach mal bitte folgendes:

 

1. Kurz vorm disconnect ruf mal ein getter auf. Ich würde vermuten, dass dieser ein Timeout bekommt. Wenn ja ist die Verbindung tot.

 

2. Ruf mal bei der Initialisierung einen Setter auf und setze irgendwas auf einen nicht default Wert. Rufe diesen Wert nach dem neuen connect mal ab. Ist dieser wieder auf default -> neugestartet. Ist dieser auf dem alten Wert -> nicht neugestartet.

 

 

p.s.: Wir hätten diesen Thread für euch beide mal spalten sollen. Ich glaube ihr habt sehr unterschiedliche Probleme.

[reinweb]

Reinweb:

Das ist interessant. Die einfachste Erklärung ist, dass die Verbindung tot ist. Der Frage ist warum.

Könnte daran liegen, dass das WLAN gestört ist (außer Reichweite o.ä.) und dass das auto-reconnect nicht funktioniert. Alternativ hat sich der Stapel neugestartet.

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.

[reinweb]

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! :-)

[reinweb]

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.

[batti]

Ebenfalls eine Neuigkeit von uns dazu. Wir haben eben die WIFI 2.0 Firmware in Version 2.0.3 veröffentlicht. 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)
  

 

Testet bitte ab jetzt mit der neuen Firmware.

 

Es sieht momentan danach aus, als ober das Masder Programm genau diesen Fehler auslösen konnte. In dem Programm wurden sehr viele Nachrichten zum Stellen von RGB LEDs (LED Strip Bricklet) generiert.

 

Das Reinweb Problem könnte ähnlich sein.

 

Bei WIFI kann die Empfangs/Sendequalität stark schwanken, so dass mal mehr und mal weniger Nachrichten durchgehen. Da der Bug nun hoffentlich gefixt ist sollte es so sein, dass auf Anwendercode-Seite die noch nicht verschickten Nachrichten (Funktiosaufrufe) gespeichert werden und nach und nach verschickt werden. Dadurch stauen sich Nachrichten auf. Das Problem der aufstauenden Nachrichten kann eigentlich nur durch "Set'ter" erzeugt werden, da diese keine Antwort erwarten. Es können also prinzipiell beliebig viele Set'ter pro Sekunde aufgerufen werden, was das System überfordert. Die Nachrichten sammeln sich dann im TCP Buffer.

 

Das Problem lösen kann man durch den "set response expected" Mechanismus, bei dem jeder Setter auch eine Antwort vom System erwartet. Dann bekommt man auch mit (über Timeout), wenn eine Nachricht nicht beim System angekommen ist.

 

Es werden dann aber auch doppelt so viele Nachrichten ausgetauscht (Set-Nachricht hin, Antwort zurück).