remotecontrol

I also though about a better way for the exception handling, because within the Android App a "printStackTrace()" is more or less lost. Currently I redirect stdout/stderr for testing onto the SD-Card, but I'm not satisfied with that solution. One idea was to use something similar like Thread.setDefaultUncaughtExceptionHandler(). the Tinkerforge API might offer something like IPConnection.setDefaultUncaughtExceptionHandler() This exception handler is populated as a callback by the Tinkerforge-implementation into every thread which is created by the API. within the catch-block the handler is called there is a default handler defined in the API, which is active by default, which just calls e.printStacktrace() It would be possible to have slightly different parameters in this exception handler, for example an enumeration value which gives information about the source of error. It would be easy for a client-application to react to the situation and either just log and continue or terminate the application. then the client application at least has a good chance to react of the exception if a way it is suitable for that kind of application The change in the API is not complicated and doesn't affect existing applications. If you think this might be helpful I can make an implementation and send it to you.

Schaut gut aus - meine Anwendung läuft damit flüssig und ich nutze wieder die Standard API. Vielen Dank

Sowas gibt es meines Wissens nach nicht: nach X ms einen weiteren Ausgang einschalten ohne einen weiteren Befehl zu senden. Nach X ms einen Ausgang wieder abschalten geht über die Monoflop-Funktionalität. Aber ansonsten können die Ausgänge alle zu einem Zeitpunkt geschaltet werden oder über separate Befehle. Mit den separaten Befehlen ist aber ein exaktes Timing im Millisekunden-Bereich kaum zu erreichen. Viele Grüße

Super - vielen Dank. Werde ich mal antesten.

Den Satz verstehe ich nicht so recht: Der Master bekommt Daten vom WIFI Modul, wenn der Master welche rausschickt? Das hat nichts zu tun mit API-Befehlen ohne Response - oder? Da wird ja nichts mehr zurück geschickt, dachte ich zumindest.

Hallo zusammen, ich habe mal refreshWifiStatus() und getWifiBufferInfo() aufgerufen und war überrascht, dass die lowWatermark nach einem Connect und getStackVoltage() noch bei 1500 steht und nach einigen Servo und Status-Befehlen bei 1493. Nur wenn ich sehr viel IO erzeuge geht es mal auf 1450 zurück. Werden die Commands inzwischen so schnell aus dem Puffer geholt oder interpretiere ich die Zahl falsch: 1500 würde ja bedeuten, dass nie wirklich was im Puffer steht. 1493 sind mal gerade 7 Bytes und die meisten Befehle nutzen 8 oder mehr Bytes.

Ich glaub ich hab' das Problem schon: meine Implementierung des enumerate() war nicht darauf vorbereitet, völlig "unkontrolliert" ein 2. mal aufgerufen zu werden, weil sich ein anderer Client connected und den enumerate() auslöst. Dadurch wird ein Device mit einer UID 2x in der IPConnection registriert. Der ipcon.devices.put(..) wirft aber die zuerst registrierte Instanz aus der Map der IPConnection. Aber genau diese Instanz wird von meiner Anwendung noch benutzt => das kann nicht klappen. Danke für den Denkanstoss.

Vielleicht noch eine Frage dazu: wenn der 2. Client den Enumerate startet wird das ja auch an den 1. Client gemeldet. Im 1. Client initialisiere ich meine Strukturen aber nicht neu und nutze weiter die vorhandenen Devices mit den bekannten UIDs. Kann das ein Problem sein?

Ich dachte eigentlich, dass ich nichts besonderes mache. Hier ein Beispiel, ist mir nicht damit aufgefallen, zeigt aber dennoch den Effekt. - in den Sourcen 1x die Main-Klasse mit der Option "ns" starten => liest nur noch Spannung aus, alle 2 Sekunden, 15x - das gleiche vom selben oder einem anderen Rechner nochmal starten Einer der Clients bekommt dann immer eine Timeoutexception. (Hinweis: fehlt die Option, wird noch ein Server angesteuert, das sollte tunlichst nur von einem Rechner passieren.) BrickTest.zip

Ich verbinde hier zwei Clients (von unterschiedlichen Quell-IPs) ausschließlich über WLAN. Der Stack hat keine USB-Connection und wird über Step-Down mit Strom versorgt. Beide Clients "pollen" alle 2 Sekunden Spannung/Strom vom Master und nachdem sich der 2. Client connected hat bekommt der Erste beim abfragen der Daten eine TimeoutException. Ich bediene nicht beide Schnittstellen (USB + WLAN) gleichzeitig.

Das mit der Gesamt-Zeit ist völlig korrekt: das spart nur 0.x% der Gesamtzeit ein. Ich hatte 100.000 Aurufe. edit: reale Performance-Verbesserung bringt das nicht - stimme ich zu. Bei Tablets gilt aber: CPU-Verbrauch kostet Akku. Darum suche ich gerade nach Optimierungen. Der Garbage-Collektor hat bei mir auch viel zu tun, wegen den Byte-Buffern ... edit: der Garbage-Collector bringt kleine Aussetzer rein und läuft bei mir schon alle 10 Sekunden. Noch eine Anmerkung zur IO bei Servos: Requests mit Response brauchen per WLAN bei mir ca. 5-6ms. Servo-Requests ohne Response liegen aber weit unter 1ms, auch per WLAN (so meine Messung). Real sende ich gut 100-120 Requests pro Sekunde, wenn ich mit je einem Finger in einem Kreuzfeld jeweils 2 Servos bewege (in Summe also 4 Servos quasi gleichzeitig).

Ein kleiner Test mit Aufrufen von getResponseExpected() in alter und neuer Variante hat bei mir OLD: 26163us NEW: 21645us ausgegeben, also gut 15%.

Hallo, sollte es eigentlich möglich sein, von mehr als einem Client gleichzeitig per WLAN auf einen Stack zuzugreifen oder ist das eigentlich nicht vorgesehen (weil's per USB auch keinen rechten Sinn macht)? Aktuell habe ich folgendes Verhalten: - 1. PC connected ruft enumerate auf => OK - 2. PC connected und ruft enumerate auf => an beide Clients scheinen die enumerate-Events gesendet zu werden. - der 1. PC ruft danach BrickMaster.getStackVoltage() auf und bekommt eine TimeoutException. - der 2. arbeitet normal und kann die Stack-Voltage auslesen - vom 1. kann ich immernoch den ServoBrick ansteuern (ohne Response) Wenn's eh nicht vorgehesen ist, parallel mehrere Clients zu haben, ist alles OK.

Hallo Admins, ich habe bei mir zwei Methoden der Device-Klasse wie folgt umgestellt: public boolean getResponseExpected(byte functionId) { // IPConnection.unsignedByte creates values from 0..255 only byte value = responseExpected[iPConnection.unsignedByte(functionId)]; if(value != RESPONSE_EXPECTED_FLAG_INVALID_FUNCTION_ID) { return value == RESPONSE_EXPECTED_FLAG_ALWAYS_TRUE || value == RESPONSE_EXPECTED_FLAG_TRUE; } throw new IllegalArgumentException("Invalid function ID " + functionId); } public void setResponseExpected(byte functionId, boolean responseExpected) { // IPConnection.unsignedByte creates values from 0..255 only int index = IPConnection.unsignedByte(functionId); byte value = this.responseExpected[index]; if(value == RESPONSE_EXPECTED_FLAG_INVALID_FUNCTION_ID) { throw new IllegalArgumentException("Invalid function ID " + functionId); } if(value == RESPONSE_EXPECTED_FLAG_ALWAYS_TRUE || value == RESPONSE_EXPECTED_FLAG_ALWAYS_FALSE) { throw new IllegalArgumentException("Response Expected flag cannot be changed for function ID " + functionId); } if(responseExpected) { this.responseExpected[index] = RESPONSE_EXPECTED_FLAG_TRUE; } else { this.responseExpected[index] = RESPONSE_EXPECTED_FLAG_FALSE; } } Hintergrund: IPConnection.unsignedByte() liefert korrekt nur 0..255 zurück (kein Range-Check notwendig) der Range-Check in Java erfolgte auf Basis der functionId und nicht anhand des berechneten Index und nachdem schon einmal ins Array zugegriffen wurde => bringt leider eh nichts IPConnection.unsignedByte() ist ein echter Funktionsaufruf, darum speichere ich den Wert zwischen, damit die Funktion nicht zu oft aufgerufen wird. Gerade bei der Ansteuerung von Servos erfolgt viel Kommunikation und die Funktion getResponseExpected wird zig-tausendfach aufgerufen. In Summe bringt das ein paar % bei den Servoaufrufen. Auf CPU-schwächeren Systemen kann das hilfreich sein. Vielleicht übernehmt Ihr die Anpassung ins API.

Ich habe bei mir die Device.sendRequestExpectResponse und sendRequestNoResponse mal so umgebaut: synchronized(requestMutex) { if (ipcon.getConnectionState() != IPConnection.CONNECTION_STATE_CONNECTED) { throw new NotConnectedException(); } ... Also den 2. synchronized Block entfernt und IPConnection.write sieht dann so aus: void write(byte[] data) { try { synchronized(socketMutex) { out.write(data); } } catch(java.io.IOException e) { e.printStackTrace(); } } Damit läuft meine Steuerung deutlich flüssiger, weil Statusabfragen, wie Ambilight-Sensor oder Spannung/Strom auslesen andere Requests ohne Response nicht mehr vollständig blockieren. Ob das so "gut" ist oder eher Probleme im Master bereiten kann (wegen Parallelität) kann ich so nicht sagen.

Bei mir klappt der Aufruf von getIdentity() auch für den Master, auch während des enumerate(). Passiert das bei einem Master oder einem anderen Brick?

Bei meiner Fritzbox kommt nur 1x die Anmeldung im Log. Allerdings hatte ich gerade was Ähnliches 2x kurz nacheinander (aber leider auch nicht immer reproduzierbar): wenn ich ca. 8-10x: Verbindung herstelle, ein paar Befehle sende und Verbindung trenne, dann war der Stack über WLAN nicht mehr erreichbar und ich muss neu starten. Mit ist es auch schon passiert, dass ich das Servo noch bewegen konnte, aber das Auslesen der Spannung einen Timeout bekommen hat und danach nicht mehr funktioniert hat. Wenn ich dann die Verbindung trenne, geht kein neuer Connect mehr.

Hört sich danach an, aber so recht erklärbar ist das noch nicht. Ich werde morgen mal meinen 2. Stack einige Zeit "idle" stehen lassen. Mal sehen, was passiert.

Ich hab's nochmal probiert: Connect klappt auch nach ca. 40 Minuten noch (FritzBox 7270). Hast Du noch einen anderen Rechner im Netz, der über WLAN ansprechbar ist? Wenn der WLAN Connect nicht mehr funktioniert: zeigt die FritzBox noch die korrekte MAC-Adresse des Bricks an?

Einen Versuch hät' ich noch: - den Stack zusätzlich per USB anschließen - Mit brickv 1x über WLAN direkt connecten und 1x über USB/localhost (sollte ja beides gehen nach Neustart) - dann warten bis der Connect über WLAN nicht mehr geht - geht dann ein Connect über USB/localhost+brickd ? Mein Akku ist jetzt leer , ich hab's mit Verbindungen nach 10, 20 und ca. 30 Minuten versucht: hat bei mir geklappt; über 30 Minuten habe ich noch nicht versucht.

Hallo zusammen, im der Methode Device.sendRequestExpectResponse wird die ganze Zeit der Socket-Mutex der IPConnection gehalten, in der Art (Java Beispiel): synchronized(requestMutex) { synchronized(ipcon.socketMutex) { Ist das notwendig? Das bewirkt, dass bis die Response zurück ist keinerlei andere Commands gesendet werden können, auch keine, die keine Response erwarten. In API Version 1 wurde nur der IPConnection.write synchronisiert. Damit war es möglich, dass ein anderes Device schon früher wieder ein Command senden konnte. Verarbeitet der Master-Brick eh alles seriell oder könnte man theoretisch weitere Commands senden? Dann würde es sich lohnen, sich die Synchronisierung genau anzusehen.

Hmm, bei mir geht's - habs gerade nochmal versucht. In der Fritzbox gibt's auf der WLAN-Seite eine Checkbox der Art "Die angezeigten WLAN-Geräte dürfen untereinander kommunizieren" Ist die gesetzt? Bei mir ist die Option aktiv. Hast Du mit der Zeit variiert? Wenn Du nach 2-3 Minuten neu verbindest geht es noch, nach 10 auch noch, aber ab ca. 30 Minuten dann nicht mehr?

Ich hab's bei mir mal ausprobiert: - Stack mit Step-Down, Master, WLAN, Servo-Brick und ein paar Bricklets - Einschalten, Connect OK - ca. 30 Minuten warten => Connect geht noch, reagiert normal Allerdings arbeitet mein Stack mit DHCP gegen eine Fritzbox, die bei Bedarf Sendeleistung bei Bedarf reduziert (also auch das klappt bei mir). Meine IP ist aber sicher nicht anderweitig nochmal vergeben.

Ist sicher gestellt, dass kein zweites Gerät diese IP verwendet, z.B. per DHCP? Ist der IP-Bereich des DHCP-Servers jenseits dessen, was für statische IPs verwendet wird? Wenn sich nach Einschalten des Stacks ein anderes Gerät mit derselben IP im Netz anmeldet ist der Stack nicht mehr erreichbar, der ping klappt dann noch, da er zum anderen Gerät geht.

Ein kleiner Hinweis bei den Extensions, dass diese über dem Master stecken müssen wäre hilfreich. Ich habe das so in der Doku nicht gefunden. Vielen Dank.