borg

Die Bindings bieten aber ja wohl eine deutliche "angenehmere" API an. Und so ist es mit HTTP-Requests auch. Es ist doch einfacher einen simplen HTTP-Request abzusetzen (das kann man sogar komplett ohne Programmierung in jedem Browser) als sich die einzelnen Bits und Bytes für das TF-Protokoll zusammenzupfriemeln (das ich mir persönlich noch nicht einmal angeschaut habe). Das siehst du falsch. Der Master sieht sowas wie "FID=1, UID=xyz, length=20, data=[...]". Die Daten sind absolute Binärdaten, das könnte jetzt 20x uint8 sein, oder 5x uint32 oder nen string aus 20 Zeichen. Mehr Informationen sind nicht da. Natürlich könnte ich jetzt hergehen und die Daten in Base64 kodieren und als Antwort auf ein HTTP Get zurücksenden. Aber das wäre in keinster weise einfacher zu parsen als das was wir aktuell direkt auf den Sockets verschicken. Die Informationen die in den Bindings steckt, nämlich wie der Aufbau der Daten für eine gegebene FID ist, die hat der Master nicht.

Dieses "HTTP Request Protokoll" wäre dann aber nur unser ganz normales Protokoll mit mehr Boilerplate. Da sehe ich jetzt auch nicht den Vorteil. Jede Sprache die HTTP Requests absetzen kann, kann auch einen ganz normalen "TCP/IP Socket" nutzen.

Du hast die Entprellzeit für den Flankenzähler nicht eingestellt. Der Standardwert dafür ist 100ms, was 5Hz entspricht wenn die "high" und "low"-Zeiten je gleich lang sind. Streu mal an einer strategischen Stelle folgendes ein : // Eingang 0 (=bitmask 1), Steigende Flanke, Debounnce 5ms (max ~100Hz) idi4.setEdgeCountConfig(1, BrickletIndustrialDigitalIn4.EDGE_TYPE_RISING, (short)5); das "setDebouncePeriod" setzt nur die Entprellzeit für den InterruptListener.

12Hz sollte kein Problem sein, kannst du den Source Code den du benutzt um das auszulesen hier posten?

Um ganz ehrlich zu sein hatten wir das nicht richtig ausprobiert. Der Hersteller hat uns die angeboten und wir haben sie mit aufgenommen. Ich hatte einen kurzen 1m Strip durch einen der Schläuche (mit viel mühe) geschoben und es nie mit 5m probiert. Wir haben den Hersteller gefragt und er wusste auch nicht so recht wie das gehen soll . Wir haben jetzt vom Hersteller Silikonschläuche bekommen die bereits einen Faden durchgezogen haben. Ich würde jedem mit Problemen (also vermutlich jedem mit einem Strip > 2m) anbieten den neuen Silikonschlauch zu schicken. Dazu bitte eine Email mit Bestellnummer an olaf@tinkerforge.com schicken.

http://www.tinkerforge.com/de/doc/Low_Level_Protocols/TCPIP.html#disconnect_probe

Das gucke ich mir gerade an. Dafür müssten wir einen kleinen Webserver sowie das Websocket Handshaking implementieren. Das Handshaking nutzt HTTP als Protokoll (deswegen einen Webserver) und es muss leider über Hashes ein Globally Unique Identifier berechnet werden (Sec-WebSocket-Key). Dabei teilt der Client dem Server dann mit welches Protokoll er sprich (in unserem Fall tfp) und dann danach könnte dann ganz normal TCP/IP gesprochen werden. So ist aktuell mein Verständnis . Klar.

Equinox hat das gut zusammengefasst. Ich hab mal ein bisschen rumgebastelt und folgendes gebaut: Einen kleinen Websocket-Server mit libwebsocket (http://libwebsockets.org/trac/libwebsockets) der ein Enumerate auf einem Brick aufrufen kann Eine kleine Webseite die Code beinhaltet die mit Websockets (per JavaScript) auf auf den Server zugreift und das Enumerate aufruft und die Rückgabe ausgibt. Das funktioniert einwandfrei. Mein Gedanke ist folgender: Brickd könnte auf einem weiteren Port einen Websocket öffnen auf dem über Websockets unser ganz normales Protokoll gesprochen wird. Dazu könnte man dann "echte" JavaScript Bindings machen. Dann könnten wir einen Online Brick Viewer anbieten den ihr aufrufen könntet der dann eine Webseite bei uns vom Server holt die sich lokal mit dem Brickd verbindet. Dabei liefern wir nur das HTML/JavaScript, wir kriegen nichts von den Daten mit, die bleiben komplett auf eurem Rechner. Damit hätten wir dann einen brickv den man nicht installieren muss der auf Handys/Tablets etc läuft. Was meint ihr, macht das Sinn?

Du hast das schon richtig verstanden. Node.js/JavaScript wäre ein weiteres Binding, genauso wie PHP.

das Disconnect schließt nicht die Verbindung des Brick Viewer. Allerdings kannst du z.B. mit deinem Programm die Callbacks umkonfigurieren, was dann auch den Brick Viewer beeinflusst. Oder umgekehrt wenn du den Brick Viewer beendest stellt er alle Callbacks aus was dein Programm beeinflussen kann.

Die IP die du beim Brick Viewer eingetragen hast ist aber zeigt aber auch auf einen Rechner an dem der Master Brick angeschlossen ist, ja?

Das Programmiermodell in node.js ist absolut asynchron. Dadurch sieht das JavaScript dort ganz anders aus als man es für den Browser schreiben würde. Hinzu kommt das die Bindings für node.js auf dem net package basieren (http://nodejs.org/api/net.html) müssen, welches im Browser nicht existiert. Da wird man also zumindest nicht den kompletten Code wiederverwenden können, evtl aber einen Teil. Dazu müsste ich mir das aber erst genauer angucken und einen Mockup schreiben.

Node.js ist ein Webserver den man mit JavaScript programmieren kann. Node.js läuft nicht im Browser, ein Großteil von Node.js ist in C++ geschrieben...

Genau, geschickter als JavaScript direkt zu nutzen. Also die Anwendung ist doch einen eigenen Webserver im eigenen LAN zu besitzen der Webseiten anzeigt? Ja aber gerade dieser Use Case ist doch schon perfekt abgedeckt? Wenn ich doch einen Webserver im eigenen LAN hab dann schließe ich da doch einfach die Bricks via USB oder Ethernet an, lese die Daten mit einer Programmiersprache meiner Wahl aus und zeige sie auf der Webseite an. Es macht doch nur Sinn den Code im Client (also im Browser) auszuführen wenn der Server selbst keinen Zugriff auf die Bricks hat. Ich handel mir doch sonst nur Probleme ein. Wenn ich mit meinem Handy von extern die Webseite aufrufe und der Code im Browser läuft dann muss ich die IP von mir zuhause kennen, der Port muss freigeschaltet sein, da gibt es offensichtliche Sicherheitsprobleme etc. Wenn die Bricks/Bricklets aber vom Server abgefragt werden und die Daten einfach auf der Webseite angezeigt werden kann ich von überall drauf zugreifen ohne auch nur irgendwelche Probleme zu erwarten. Oder nicht?

Mh. Vielleicht kenne ich mich bei den Webtechnologien einfach nicht gut genug aus um das zu verstehen . Ist es nicht viel geschickter die Verbindung zum Brick/Bricklet auf der Server Seite mit Python/Ruby/PHP aufzubauen und die eigentlichen Daten über REST/Websockets mit HTML5/JavaScript auf der Client Seite abzufragen? Wenn jeder Aufrufer einer Webseite selbst eine Verbindung zum Brick herstellt ist doch die USB Bandbreite super schnell aufgebraucht. Was ich sehen kann ist folgendes: Angenommen man würde Bindings für JavaScript mit den Chrome Sockets machen (http://developer.chrome.com/apps/socket.html), dann könnte man einen Online Brick Viewer entwerfen und man müsste keine Anwendung mehr installieren sondern könnte einfach eine Webseite (mit Chrome) bei uns aufrufen um sich seine lokalen Bricks/Bricklets anzusehen. Das hat aber natürlich den Nachteil das der Brick Viewer nur noch funktioniert wenn man auch Zugriff zum Internet hat, das ist auch komisch .

OK . Welche Sprache würdest du denn denn verwenden wollen um das JSON o.ä. auszulesen und in welcher Umgebung?

Ich verstehe die Logik nicht . Angenommen ein Master Brick könnte eine JSON API anbieten, wie würde dann etwas Standalone auf dem Brick laufen? Oder meinst du einfach das man direkt über TCP/IP mit dem Brick kommunizieren kann? Dafür haben wir doch schon die Ethernet Extension!

In der Tat, da war ein copy&paste Fehler . https://github.com/Tinkerforge/brickv/commit/e54131739309c076d1c18d4eb87ec44d34050b29 Ist dann im nächsten brickv Release gefixt.

Der Master selbst ist ja erstmal per USB an einem PC angeschlossen und kann somit auch kein JSON o.ä. anbieten da er kein TCP/IP spricht. Einen kleinen Daemon zu schreiben der eine JSON oder RPC/XML oder was auch immer API anbietet ist natürlich kein Problem, das tun wir ja z.B. schon für netio: http://www.tinkerforge.com/de/doc/Software/NetIO_Setup.html Ich verstehe das aber nicht so ganz. Ihr wollt dann z.B. per Java auf die Schnittstelle zugreifen? Warum dann nicht sofort die Java Bindings nehmen? Also mit welcher Programmiersprache die wir aktuell noch nicht unterstützen wollt ihr das JSON o.ä. verwerten?

WebSockets sind keine "normalen" Sockets, damit können wir nicht unser Protokoll sprechen. Node.js kann normale Sockets, man könnte also Node.js Bindings machen die genauso funktionieren wie unsere anderen Bindings auch. Zum testen hab ich ein schnelles Node.js Programm geschrieben das ein Enumerate macht: var s = require('net').Socket(); s.connect(4223, 'localhost'); buf = new Buffer(new Array(0, 0, 0, 0, 8, 254, 48, 0)); s.write(buf); s.on('data', function(d){ console.log(d); }); Funktioniert problemlos.

Kannst du mal ein Foto von deinem Aufbau machen, damit man sehen kann was du wo angeschlossen hast?

Da haben wir noch keine so richtige Aussage zu. Wir haben einen Prototyp des Giant Game Pads hier, allerdings sind wir uns noch nicht schlüssig darüber ob wir das so verkaufen können. Wir würden da erst gerne noch ein paar Usability-Tests machen, die wir gut machen können wenn das Blinkenlights Kit fertig ist (dafür ist es auch gutes Zubehör wenn es so funktioniert wie wir uns das vorstellen). Daher wird sich das noch ein wenig verzögern bis da wirklich was im Shop ist oder es Fotos o.ä. gibt.

Wir werden vermutlich am nächsten Montag die Perl Bindings veröffentlichen. Wir würden gerne direkt eine weitere Sprache hinterherschieben. Für welche Programmiersprache würdet ihr gerne als nächstes Bindings haben?

Die chipTemperature des Master Bricks ist nur als Temperatur-Indikator zu gebrauchen. D.h. mit steigender Temperatur steigt der Wert und mit fallender Temperatur sinkt er.

Plugins: Distance US Bricklet 2.0.2 Reorder elements in BrickContext to satisfy 256 byte size limit Download: Distance US Bricklet