photron

Richtig, der Hostname wird permanent gespeichert, wie die anderen WIFI Einstellungen.

Deine Vermutung ist korrekt Bis dahin kannst du das aber schon über set_wifi_hostname setzen.

Bindings: C/C++ 2.0.3, C# 2.0.4, Delphi 2.0.5, Java 2.0.4, PHP 2.0.4, Python 2.0.4, Ruby 2.0.4 Reduce scope of request and socket mutex to improve concurrency [all, except PHP] Improve and unify code for response expected flag handling [all] Add get/set_wifi_hostname functions and callbacks for stack/USB voltage and stack current to Master Brick API [all] Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby

Bindings: C/C++ 2.0.3, C# 2.0.4, Delphi 2.0.5, Java 2.0.4, PHP 2.0.4, Python 2.0.4, Ruby 2.0.4 Geltungsbereich für Request und Socket Mutex veringert um Nebenläufigkeit zu verbessern [alle, außer PHP] Code für die Behandlung des Response Expected Flag vereinheitlicht und vereinfacht [alle] get/set_wifi_hostname Funktionen und Callbacks für Stack/USB Voltage und Stack Current zur Master Brick API hinzugefügt [alle] Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby

Die 0,1K ist als konservative Angabe für 0,06K zu sehen Die 0,06K Schritte sind das normale Verhalten.

Die Dokumentation spricht von 0,1°C Auflösung. Wo kommen die Angabe über 0,01°C her?

Richtig, getResponseExpected mach unnötige viele Funktionsaufrufe. Ich bin gerade dabei das in Java zu verbessern und schau mir dann auch noch alle anderen Bindings an.

Ah ich sehe was du meinst. Du beziehst dich auf den socketMutex. Der ist neu in v2 und führt dazu dass alle Setter/Getter Aufrufe aller Devices der selben IPConnection serialisiert werden. Das ist schlecht für die Performance mit mehreren Threads. Da haben wir nicht aufgepasst AuronX, du beziehst dich auf den requestMutex im Setter Fall. Wie im Pull Request schon gesagt sehe ich da keine Problem das zu ändern. In remotecontrols Fall über WLAN (nehme ich an) wo die Getter Roundtriptime höher ist ist der Gewinn einer solchen Änderung natürlich deutlich größer als über USB. Damit steht jetzt feineres Locking auf der TODO Liste für die nächste Release.

Das ist das alte Vorgehen aus v1 Zeiten. In v2 haben alle Devices addXYZListener(XYZListener listener) und removeXYZListener(XYZListener listener) pro Listenertype. Diese Umbau ist uns für die IPConnection durch die Lappen gegangen, sorry. In der nächsten Java Bindings Version wird das geändert sein.

Danke für den Hinweis, ist korrigiert.

Wir versuchen möglichst viel des Binding Codes zu generieren. IPConnection.java und Device.java sind handgeschrieben der Rest wird generiert. Daher ist es einfacher den Generator getIdentity() implementieren zu lassen.

The_Real_Black, hat das Flashen den geklappt im Sinne von Brick Viewer hat keine Fehler gemeldet? Oder kommt die Meldung mit Code 43 im Gerätemanager wenn der Brick im Bootloader ist?

Andu, das war ein Fehler in der USB Unplug Erkennung. Der hatte sich in 2.0.2 eingeschlichen. In Brick Daemon 2.0.3 ist das jetzt korrigiert. Nic, ist das ein neues Problem oder besteht das schon länger?

Brick Daemon 2.0.3 Fix USB unplug detection on Windows Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Brick Daemon 2.0.3 Fehler in USB Unplug Erkennung korrigiert auf Windows Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Mit Brick Daemon 2.0.2 ist jetzt auch eine Version released in der das Problem korrigiert ist.

Brick Daemon 2.0.2 kann jetzt auf Windows auch als normales Kommandozeilenprogramm gestartet werden.

Brick Daemon 2.0.2 An error during client peer name lookup doesn't abort the socket connection anymore Support running as normal console application on Windows Support MinGW as compiler on Windows Support running as non-root on Linux Improve --help output Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Brick Daemon 2.0.2 Fehler während des Client Peer Name Lookups brichtjetzt nicht mehr die Socketverbindung ab Support für Ausführung als normales Kommandozeilenprogramm auf Windows Support für MinGW als Compiler auf Windows Support für Ausführung als User auf Linux --help Ausgabe verbessert Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Richtig, das fehlte. Ist jetzt auch drin. Danke für den Hinweis.

Brick Viewer 2.0.2 Use smaller update rate for WIFI status refresh (may timeout otherwise) Check UID length before writing Fix initialization of IO16 Bricklet plugin Make Brick flashing error message more verbose Add support for long WPA key (up to 64 chars) to Master Brick plugin Downloads: Windows, Linux, Mac OS X

Brick Viewer 2.0.2 Geringere Updaterate für WIFI Status Refresh (geringere Wahrscheinlichkeit für Timeouts) Prüfe UID Länge vorm Schreiben Initialisierung des IO16 Bricklet Plugin korrigiert Detailliertere Meldungen für Brick Flashing Fehler Unterstützung für langen WPA Schlüssel (bis zu 64 Zeichen) zu Master Brick Plugin hinzugefügt Downloads: Windows, Linux, Mac OS X

Bindings: C/C++ 2.0.2, C# 2.0.3, Delphi 2.0.4, Java 2.0.3, PHP 2.0.3, Python 2.0.3, Ruby 2.0.3 Add get/set_long_wifi_key functions to Master Brick API [all] Ensure that exceptions in user code don't kill the callback thread silently [Delphi, Java] Use a shorter format for JavaDoc links [Java] Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby

Bindings: C/C++ 2.0.2, C# 2.0.3, Delphi 2.0.4, Java 2.0.3, PHP 2.0.3, Python 2.0.3, Ruby 2.0.3 get/set_long_wifi_key Funktionen zur Master Brick API hinzugefügt [alle] Exceptions in User Code brechen den Callback Thread nicht mehr unbemerkt ab [Delphi, Java] Kürzeres Linkformat in JavaDoc verwendet [Java] Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby

Brick Viewer ist in Python geschrieben und benutzt PyQt4 für das GUI. Das könnte potentiell auch auf Andriod funktionieren. Im Moment gibt es allerdings von uns keinen Brick Viewer passend für Android.