borg

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?

Die Vorgehensweise die ich dafür vorschlagen würde ist folgende (Pseudocode): beep 1s/1khz, 2s/2kh, 5s/1khz, 1s/2khz beep(10000, 1000) pause(1000) beep(10000, 2000) pause(2000) beep(10000, 1000) pause(5000) beep(1000, 1000) Also du lässt ihn einfach lange beepen und überschreibst dann nach der Zeit die du eigentlich einhalten möchtest. Eine blockende Methode die einen Wert zwischenspeichert klingt aber auch gut, ich hab es mir mal aufgeschrieben .

Mh, da müssen wir mal gucken. Methoden um etwas erweitern würde die API brechen, das machen wir eigentlich nicht. Deswegen können wir die beiden Vorschläge nicht so ohne weiteres implementieren.

Mh, ich befürchte das wir die Delphi Bindings nur unter Windows und Linux (fpc) getestet haben. Das müssen wir uns genauer angucken, da muss für MacOS X vermutlich eine andere Socket-Implementierung her.

Die "Selection Mask" ist eine Binärmaske. D.h. wenn du den Flankenzähler nur für Pin 1 aktivieren möchtest musst du eine 1 setzen. Pin 0 = 1 = 20 Pin 1 = 2 = 21 Pin 2 = 4 = 22 Pin 3 = 8 = 23 Pin 1+3 = 10 = 21 + 23 usw.

Ishraqs Bindings are already generated!

Hier hat mal jemand einen Reichweitentest gemacht mit dem Sender den wir benutzen: http://lowpowerlab.com/forum/index.php?topic=114.0 (RFM69HW, grün im Bild)

Ich glaube wir haben eine Instanz dieses Chromium Bugs: https://code.google.com/p/chromium/issues/detail?id=322936 @AuronX: Opera benutzt ja mittlerweile auch Chromium zum rendern, das würde also passen .

Ein kurzer Druck auf die Taste der Fernbedienung erzeugt immer so ca. 7-9 Repeats. Nach meinen Tests reichen aber 5 Repeats fast immer . Warum das anlernen der dritten Dose nicht geklappt hat auf Anhieb kann ich nicht sagen.

So, die neue Firmware ist jetzt veröffentlicht. Es werden jetzt 3 unterschiedliche Protokolle unterstützt. Mehr dazu in der Dokumentation: http://www.tinkerforge.com/de/doc/Hardware/Bricklets/Remote_Switch.html Die Kompatibilitätsliste ist noch nicht vollständig. Da kommen bei Intertechno nochmal so ~20 hinzu und bei ELRO Home Easy nochmal ~40. Müssen wir nur noch Stück für Stück überprüfen welches Protokoll gesprochen wird. Wir haben auf jeden Fall exemplarisch unterschiedliche Steckdosen, Dimmer, 12/24V Schalter, Jalousie-/Garangentoröffner und Gongs von Intertechno und ELRO Home Easy getestet und konnten mit der neuen Firmware alles benutzen . Über Feedback würden wir uns freuen! Ein Frage dazu hätte ich dazu noch: Würdet ihr Interesse daran haben auch die Fernbedienungen von ELRO/Intertechno und Co auslesen zu können? Anwendungsszenarien wären sowas wie mit der Funksteckdosen-Fernbedienung die Lautstärke vom PC zu verändern oder vergleichbares.