borg

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

Plugins: Distance US Bricklet 2.0.2 Elemente im BrickContext neu sortiert um die 256 Byte Größenbeschränkung einzuhalten Download: Distance US Bricklet

Das Distance US Bricklet hat in der Tat über seine BrickletContext grenzen hinweg geschrieben. Das lag einfach am vom Compiler eingefügten Padding, ließ sich ganz einfach mit einem Umsortieren des structs fixen. Mit Version 2.0.2 sollte das Problem jetzt nicht mehr auftreten (einfach im Brick Viewer updaten).

Ich kann das Problem reproduzieren wenn ich Remote Switch and Port C und Distance US an Port D anschließe (nicht umgekehrt). Das ist andersrum als ichs vermutet hätte, ich werde den Code von beiden Bricklets jetzt mit Debug-Ausgaben versehen, ich bin gespannt was da los ist...

Der Treiber IC auf dem LCD (KS0066U) kann leider keinen einzelnen Pixel setzen, daher ist das technisch nicht möglich. https://github.com/Tinkerforge/lcd-20x4-bricklet/raw/master/datasheets/KS0066u.pdf

Per Email hast du mir einen Traceback geschickt: LCD 20x4 initialized Exception in thread "main" java.lang.NullPointerException at WeatherStation.main(WeatherStation.java:185) Barometer initialized Ist bei dir Zeile 185 auch System.console().readLine("Press key to exit\n"); ? Falls ja, welche Java Version verwendest du?

Mh, ich wollte mir gerade ein Tevion Set bei Amazon bestellen, kann aber keinen Verkäufer finden. Kann es sein das die nicht mehr neu verkauft werden? Bei TEVION selbst steht es auch auf "Derzeit nicht verfügbar": http://www.amazon.de/Funksteckdose-Funksteckdosen-Schalter-Fernbedienung-Set/dp/B002VWIQBU

Oh, das ist ja komisch. Also wenn ihr A+B tauscht bleibt das Problem auch? Klint ja so als würde eins der Plugins im BrickletContext von dem anderen Plugin rumschreiben. Wenn das so ist dürfte das Problem aber nur in einer Reihenfolge auftreten? Ich kann es am Wochenende nicht testen, ich versuche das dann am Montag zu reproduzieren.

Die Stromversorgung der LED Streifen oder Pixel sollte nicht komplett über das Bricklet laufen, da bei sowas wie 10A Stromverbrauch an den Klemmen zuviel Spannung abfällt. Die sind dafür leider nicht ausgelegt. Du musst "-" verbinden, da sonst für die CLOCK und DATA Leitungen keine Referenz da ist. Wenn eine Spannungsmessung durchgeführt werden soll musst du auch "+" anschließen. Es sollte dann aber zusätzlich die eigentliche Stromversorgung der LEDs parallel dazu stattfinden.

Tevion Funkschalter haben wir noch nicht getestet. Gibt es dann da eine Aussage wozu die kompatibel sein sollen? Oder sprechen die ihr eigenes Protokoll?