photron

In Java Bindings 1.0.7 gibts keine unnötigen addListener Methoden mehr.

In C# Bindings Version 1.1.1 gibt es jetzt XML Dokumentation. Auch die anderen Bindings haben jetzt Inline Dokumentation.

Im Moment bin ich mit generellem Aufräumen beschäftigt. Die nächsten Bindings werden für Ruby. Also keine Sorge, dass wir da morgen fertige Delphi Bindings präsentieren. Sind deine Delphi Bindings bisher von Hand programmiert oder hast du auch schon einen Generator gebaut? Am liebsten wäre es mir natürlich wenn ich für die zukünftigen offiziellen Delphi Bindings auf deine bisherige Arbeit aufsetzen könnte

Ich hab die addListener/registerCallback Methoden entfernt für Devices die keine Callbacks haben. Die Callbacks für den Master sind eine gute Idee.

Die TCP/IP Dokumentation ist schon fertig. Hier der generelle Teil http://www.tinkerforge.com/doc/Software/IPConnection_TCPIP.html#ipcon-tcpip und hier z.B. die für das Linear Poti Bricklet http://www.tinkerforge.com/doc/Software/Bricklets/LinearPoti_Bricklet_TCPIP.html#linear-poti-bricklet-tcpip Wenn dir da was fehlt, was nicht verständlich oder detailliert genug ist oder sonstige Probleme damit sind dann sag Bescheid oder frag.

In C# Bindings Version 1.1.0 geben jetzt u.a. Methoden mit nur einem Ausgabewert diesen per return zurück. Die alten Versionen der Methoden mit einem out-Parmeter sind weiterhin verfügbar und als obsolete markiert. Bei mehr als einem Ausgabewerten werden weiterhin all per out-Parameter zurückgegeben. Dank an AuronX, der diese Änderung beigesteuert hat

In Java Bindings Version 1.0.6 ist die Device Klasse jetzt public und abstract.

Es gibt noch kein removeListener Funktion, aber du hast recht so etwas fehlt noch. Bis ich das eingebaut habe funktioniert der Workaround den AuronX beschreibt.

Loetkolben, wie gesagt ist das kein Fehler und die Meldung daher keine Fehlermeldung Zu der 20 Frage: $ python -c 'print str(20.00)' 20.0 Wenn du da ein spezielles Ausgabeformat brauchst dann kannst du einfach das Python Script anpassen. Da du eh schon aus print('Temperature: ' + str(temperature) + ' °C') den Text entfernt hast kannst du das Beispiel ja auch noch weiter anpassen. Immer 2 Nachkommastellen bekommst du so: print('%.2f' % temperature)

Ich werde die Meldung entfernen, den sie hat keinen Mehrwert und stiftet nur Verwirrung wie dieser Thread beweist Außerdem werden Callbacks/Antworten mit unbekannter Function ID eh schon stillschweigend ignoriert.

Du musst da nichts "adden", UID ändern und Beispiel muss funktionieren, tut es ja auch Die Meldung deutet nicht auf ein Problem oder Fehler hin, sondern nur das die IPConnection etwas unerwartetes empfangen hat und es ignoriert hat.

Die Meldung bedeutet, dass die IPConnection eine Nachricht mit Function ID 8 (das ist der Temperature.CALLBACK_TEMPERATURE) vom Stackteilnehmer 2 (das wird wohl das Temperature Bricklet sein) erhalten hat. Aber es kennt keinen Stackteilnehmer 2, daher "unknown Stack ID". Hast du den Brick Viewer auf und den Tab für das Temperature Bricklet aktiv? Dann hat der Brick Viewer den Temperature.CALLBACK_TEMPERATURE Callback für das Bricklet aktiviert und es sendet Callbacks. Wenn du nun dein Script startest dann gibt es ein kleines Zeitfenster zwischen der Erzeugung der IPConnection und dem add_device Aufruf. In dieser Zeit empfängt die IPConnection schon eingehende Nachrichten kennt aber das Temperature Bricklet noch nicht. Du kannst diese Meldung vermeiden indem du brickv oder wer auch immer den Temperature.CALLBACK_TEMPERATURE Callback aktiviert hat schliesst. Oder du kannst die Schleife in das Python Script einbauen, so dass du nicht immer die IPConnection neu erstellst. Aber eigentlich könnte ich diese Meldung auch aus allen Bindings entfernen. Callbacks/Antworten von unbekannten Devices werden eh ignoriert.

Ja, das Problem von Short Reads ist mir auch schon aufgefallen. Es steht auch auf meiner TODO Liste. Und ja im Moment arbeiten alle Bindings so.

Es wird dann auch ein usleep(0) tun. Der Punkt ist dann nicht das Warten an sich sondern, dass das usleep() dazu führt dass der Scheduler einen anderen Prozess dran nimmt. Warum auch immer das einen Unterschied macht. Du sprichst von einem embedded Gerät. Testest du das Programm auch gerade dort, oder auf einem normalen Desktop Rechner? Du hast noch nicht gesagt welche C Bindings Version du verwendest und ob das Problem auch mit der aktuellen Version 1.0.5 auftritt.

Nein. Der RecvLoop liest alles was auf dem Socket ankommt und ruft damit HandleMessage() auf. HandleMessage() unterscheidet dann verschiedene Messages: - AddDevice Antworten werden ausgewertet und das entsprechende Device aktualisiert mit den Informationen über Name, Stack ID etc. - Callback Antworten werden in die callbackQueue gesteckt - Andere Nachrichten für bekannte Devices werden in deren entsprechenden answerQueues gesteckt Der CallbackLoop nimmt Callback Antworten aus der callbackQueue und ruft die entsprechenden Callback Funktionen auf, falls solch eine vom Benutzer registriert wurde. Getter Aufrufe für Devices warten maximal 2,5 sec bis in ihrer answerQueue etwas angekommen ist.

Beide Threads laufen durch. RecvLoopFlag ist normalerweise True und wird beim destroy auf False gesetzt, damit man die Threads sauber abbrechen kann. Also steht da im Normalbetrieb ein while(True). Dass du im Debugger da nur was passieren siehst wenn du Devices ansteckst ist erwartet. Beim Anstecken schickt dir brickd eine Enumerate Message. Der socketStream.Read() Aufruf blockiert bis Daten zu lesen sind. Also steht der Thread die meiste Zeit in der Read() Methode wenn keine Daten übertragen werden.

Es muss auch ohne die sleeps funktionieren und das tut es hier auch. Ich hatte das vorgeschlagen weil jemand ein ähnliches Problem hatte und ihm sleeps geholfen haben. Das war allerdings vor meiner Zeit. Tritt das Problem auf Linux, Windows oder Mac OS auf? Tritt das Problem auch mit der aktuelle Version 1.0.5 der C Bindings auf? Nur wenn ich das Problem reproduzieren kann kann ich es auch beheben

Der RecvLoop läuft dauerhaft, liest alles was am Socket ankommt und behandelt es passend. Der CallbackLoop ist dafür da die Callbacks auszuführen, so dass man aus Callbacks heraus auch noch Getter der Devices aufrufen kann. Würden der RecvLoop die Callbacks ausführen würde dieser ja in der Zeit keine eingehenden Packages mehr annehmen können und wir hätten ein Deadlock, da die Antwort des Devices auf den Getter Aufruf nicht gelesen würde. Das ganze kommuniziert miteinander über thread-sichere Queues.

Das wäre in der Tat eine Möglichkeit Javascript Bindings zu machen. Aber warum so kompliziert? Wenn ich in Javascript schon WebSocket habe dann kann ich auch gleich von Javascript aus direkt mit brickd reden.

Das Problem ist jetzt auch in Version 1.0.5 der C Bindings behoben.

Änder mal private Device lcd; in private BrickletLCD20x4 lcd;

Wenn du WebSockets verwendest hast du aber auch ein PHP Programm auf dem Server das dauerhaft (zumindest länger) läuft und dann kannst du in der Schleife die die Clients bedient auch zwischendurch mal dispatchCallbacks() aufrufen und alles ist gut

Du meinst, dass das erste ipcon_add_device für das TemperatureIR funktioniert die nachfolgenden aber fehlschlagen? Ich hab das hier gerade mal getestet und bei mir funktioniert das ohne Probleme unter Linux mit den C Bindings in Version 1.0.5 (von gestern: http://download.tinkerforge.com/bindings/c/tinkerforge_c_bindings_1_0_5.zip). Hast du das Problem unter Windows oder mit einer alten Version der C Bindings? Hilft es wenn du zwischen den ipcon_add_device Aufrufen ein sleep von 1 sec einbaust?

Die Bindings prüfen im Moment noch nicht, ob das antwortende Brick von dem Type ist das die Bindings gerade erwarten. Es steht schon auf meiner TODO Liste das zu verbessern. Und wie ArcaneDraconum schon sagt UIDs haben keine feste Länge. Zufälligerweise sind im Moment die UIDs der Bricklets im Auslieferungszustand immer 3-stellig.

Iangillan, ich habe mir gerade mal Scratch angeschaut. So einfach ist die Anbindung zu Tinkerforge dann auch nicht, denke ich. Wie es aussieht kann man nicht so einfach neue Blöcke hinzufügen, ausser man erstellt eine Scratch Modification: http://wiki.scratch.mit.edu/wiki/Scratch_Modification Das ist dann ein eigenständiges Programm das nicht mehr Scratch heißen darf. Das Problem daran ist, dass Scratch in Squeak programmiert ist. Ein einfachere Variante wäre es wohl das Remote Sensors Protocol für Tinkerforge zu implementieren (z.B. in Form eines Proxies zwischen Brick Daemon und Scratch): http://wiki.scratch.mit.edu/wiki/Remote_Sensors_Protocol So weit ich das verstehe könnte man damit die Ausgabewerte der Tinkerforge Sensoren in Scrach per Sensor Block verfügbar machen und in Scratch darauf reagieren. Die Rückrichtung für Aktoren könnte man wohl über Broadcasts bauen. Ob das im Endeffekt ordentlich funktioniert und wie viel Arbeit das ist kann ich gerade nicht einschätzen.