remotecontrol

Der Callback muss static sein und den user_data Parameter kann man verwenden, um den this-Pointer zu übergeben. Damit sieht das dann in etwa so aus: static void cb_IP_Disconnect(uint8_t disconnect_reason, void *user_data); ... void dlg_Main::cb_IP_Disconnect(uint8_t disconnect_reason, void *user_data) { dlg_Main *object = (dlg_Main*) user_data; object->... ; } ... ipcon_register_callback(&IPCon, IPCON_CALLBACK_DISCONNECTED, (void *)cb_IP_Disconnect, this);

Did you read these instructions too? www.tinkerforge.com/en/doc/Embedded/Raspberry_Pi.html

Der RED Brick ist etwas teurer, aber die Größe ist einfach super kompakt (darum hatte ich auch für diese kleine Version gestimmt) und etwas mehr Leistung als beim Raspi hat man auch, plus vorkonfigurierte Software ... das kostet dann ein paar EUR mehr. Das finde ich OK, zumal das TF-Team ja auch von was leben muss . Stapelbare REDs wären aber nett: mit dem Cubieboard und Apache Hadoop haben die Cubie-Entwickler mal in einen "Cluster" aufgebaut ...

Bzgl. der SD-Karte: mein Raspi eine eine "normale", mein Cubieboard eine Micro-SD. Inzwischen ziehe ich die Micro-SD vor, da die am Cubieboard nicht übersteht und so oft wechsle ich die ja auch nicht.

Wie dicht ist der Stack an der Lüftungsanlage bzw. den Motoren? Bei mir wurde ein Stack (ohne Relais) schon gestört, wenn er in 20cm Entfernung von einem Motor positioniert wurde, der sichtbare Bürstenfunken erzeugt. Mit den Dual-Relais konnte problemlos über längere Zeit eine kleine Pumpe (12V, max 3A) ein/ausschalten, wenn ich ein 2m Brickletkabel (geschirmt) benutzt habe und die Pumpe auch weiter weg positioniert hatte. Das ging so lange gut, bis das Wasser alle war ...

Auf jeden Fall nicht zu sehr ärgen - Du bist nicht alleine ... http://www.tinkerunity.org/forum/index.php/topic,1542.msg10176.html

Wenn Du das Relais schalten willst müsste das mit einem Dual-Relais Bricklet gehen. Aber dann musst Du wohl alles in den Schaltschrank einbauen. Hast Du Dir dazu schon Gedanken gemacht? Ist da ausreichend Platz? Dazu würdest Du nur den PI (ggf. mit WLAN Stick), Masterbrick und Dual-Relais-Bricklet benötigen. Dann kannst Du schon 2 Eltako Relais (und damit die Lampen) schalten. Bei der 220V Verkabelung musst Du aber aufpassen! Kennst Du Dich mit sowas aus?

Ich hab mal Euren Wikipedia-Link angeschaut bzgl. der Allwinner CPU: der A10s und der A23 hätten die gleiche Größe von 14x14mm. Reicht das von den Anschlüssen her dennoch nicht oder ist diese (recht neue CPU), dann doch zu teuer?

Schade, aber wenn ich das vorher richtig gelesen habe ist die anvisierte singe-core CPU merklich schneller als die vom Raspi, das wäre auch schon ein Vorteil.

Schon viel passiert hier in dem Thread... Der Formfaktor war für mich immer ein plus von Tinkerforge, darum bin ich für Variante 1: klein und kompakt und vom Preis noch im Bastelrahmen. HDMI würde ich nicht brauchen. Variante 3 steht etwas in Konkurrenz zu anderen embedded boards, welche aufgrund hoher Stückzahlen günstiger verkauft werden. Für mein dual-core Cubieboard habe ich mit Versand 55€ bezahlt, da ist noch Luft für Master und Step-Down... Aber: ginge Variante 1 auch mit dual-core? Ich fasse für mich mal zusammen: * es ist ein ARM basiertes Linux, evtl. ist das Raspi Repo voll nutzbar * d.h. es kann fast jede Software verwendet werden, die dort verfügbar ist * die Kommunikation mit den Brick(lets) ist etwas schneller als per USB oder gar per Wifi-Extension (was ein weiterer Vorteil gegenüber anderen embedded boards wäre) * und passende Gehäuse mit Platz für viele Bricklets gibt es auch

Ich wär mir nicht sicher, ob sich der brickd so einfach mit dem Android NDK übersetzen lässt und dann auch noch die USB-Dependencies vorhanden sind. Ich kann auch nur empfehlen, zuerst mal den Stack per WIFI anzubinden oder Ethernet und dazu die passende App auf dem Handy zu schreiben. Das ist noch überschaubar. Und danach kann man ja einen brickd in Java für Android schreiben . OTG hat auch noch den Nachteil, dass das Handy zu der Zeit nicht geladen wird -> für Dauerbetrieb nicht so gut geeignet.

Auch wenn ich keine Ahnung von GIT habe, scheint es funktioniert zu haben: https://github.com/PlayWithIt/TFStubserver

Hallo zusammen, wenn ich im brickv die "Temperate Average Length" fürs Barometer Bricklet ändere scheint das keinen Effekt zu haben: nach Neustart des Brickv (nicht Neustart des Stacks) wird immer der alte Wert angezeigt. Die beiden anderen Werte werden korrekt übernommen. Bei meinen Stubserver kann ich sehen, dass der 3. Wert der Funktion BAROMETER_FUNCTION_SET_AVERAGING immer jener ist, den der Brickv beim Start ausgelesen hat, nicht der Wert, der in der GUI neu eingestellt wurde.

8-9 Grad halte ich nicht für normal, 30 passt da schon eher (etwas höher als die Umgebungstemperatur), so ist es zumindest bei mir.

Wenn Du diesen Mustercode meinst: https://github.com/Tinkerforge/weather-station/blob/master/write_to_lcd/java/WeatherStation.java Da brauchst Du keine UIDs einzustellen: im "enumerate" werden hier explizit die Bricklet-Typen geprüft und initialisiert. Die "Warteschleife" ist dort letztendlich dieser Befehl: System.console().readLine("Press key to exit\n"); Der darauf wartet, dass Du <enter> drückst. Wenn's jetzt geht: viel Spaß beim Experimentieren.

Welcher Beispielcode ist es? In der Dokumentation gibt es einige Fragmente bei der Wetterstation? Folgendes würde ich prüfen: * die IDs müssen stimmen (im Brickviewer ablesen und im Code anpassen) * nicht gleichzeitig Brickviewer und Anwendung laufen lassen * je nach Beispielcode muss dass Programm noch eine Warteschleife haben, sonst beendet es sich ja wieder sofort und aktualisiert nichts. Darum die Frage nach dem Beispielcode.

Ich kann den Effekt nachvollziehen: wenn ich Remote-Switch + Distance US dran habe, dann kommt der Switching-Done Callback nicht. D. h. auch im Brickviewer bleiben die Buttons zum Schalten (Switch On/Off) dauerhaft inaktiv/gesperrt. Die Steckdose reagiert meist nicht. Ist das Distance-US weg, geht eh problemlos und die Steckdose reagiert immer. Dabei war es unabhängig vom Port, d. h. mit A+B bzw. C+D gab es dasselbe Verhalten. => Die Bricklets scheinen sich zu beeinflussen. Edit: per USB bekommt man 500mA was völlig ausreichend ist für beide Bricklets (40 für Remote Switch + 8 für Distance US + Master ...)

Ich will den Code noch etwas aufräumen und den Piezo-Emulator mit Tönen versehen, dann kann ich das mal separat veröffentlichen. Das wird aber eher 2014 werden Einen guten Rutsch.

Hallo zusammen, ich möchte hier kurz vorstellen, wie ich aktuell meine Software teste: Ich habe eine kleine Wetterstation mit Zeitschaltuhr und Timern http://www.tinkerunity.org/wiki/index.php/DE/Projekte/Wetterstation_mit_Zeitschaltuhr_und_Android_App, bei der ich einen Großteil der Zeit für die Tastensteuerung benötigt habe (zuletzt nochmal umgestellt und Multi-Touch). Kleine Änderungen an der Wetterstation auf dem PI zu installieren und zu testen, ist recht zäh: Build auf dem PI braucht schon 17 Minuten, auf PC <10 Sekunden . Ich hatte zwischenzeitlich schon einen Stackemulator entwickelt, der mir alle Brick/Bricklets mit Callbacks emuliert, die ich benötige http://www.tinkerunity.org/wiki/index.php/DE/Projekte/Stackemulator_%28stubserver%29 (und noch ein paar mehr), aber der Test von neuen Bedienschritten ist damit nicht möglich und den LCD-Inhalt sieht man auch nicht. Darum habe ich das Ganze nun noch um eine Android-App erweitert: per App kann ich Tasten-Eingaben übers WLAN an die Wetterstation senden und diese damit steuern. Ebenso zeigt die App immer den aktuellen Inhalt des LCD an. Die App hat somit zwei Funktionen: zum Einen ist es die Methode, über ich die Software mit der simulierten Hardware komplett manuell testen kann. Zum Anderen kann ich damit jederzeit auch im Normalbetrieb meine Wetterstation abfragen und steuern (zusätzlich zur Steuerung direkt über das Bedienfeld). Die App ist allerdings anwendungsspezifisch, der Emulator nicht. Die Entwicklung von App und Emulator hat sich für mich schon gelohnt, da ich inzwischen deutlich schneller was ausprobieren kann, als mit realer Hardware: auch mal Bricklets 'entfernen' und nur einem Teil der Hardware testen oder Temperaturstürze simulieren ...

Wenn ich das richtig sehe, dürfte sich Deine Anzeige derzeit nur aktualisieren, wenn Du ENTER drückst - korrekt? getchar() liest stdin immer "buffered", d. h. die Anwendung bekommt immer nur eine ganze Zeile, die dann zeichenweise gelesen werden kann. Um das zu umgehen musst Du stdin in einen unbuffered mode versetzen und dann kannst Du prüfen, ob überhaupt ein Zeichen getippt wurde, siehe z:b. http://stackoverflow.com/questions/5616092/non-blocking-call-for-reading-descriptor. Zum warten gibt es z. B. usleep oder besser noch die C++ Varianten davon, siehe z: B. http://stackoverflow.com/questions/4184468/sleep-for-milliseconds. Du könntest also immer etwas warten, prüfen ob eine Taste gedrückt wurde und die Anzeige aktualisieren. Alternativ geht es nur mit 2 Threads (dann wird es aber auch gleich komplizierter): einer wartet auf Tastatureingabe, die kann dann auch gepuffert sein, und der andere aktualisiert die Anzeige. Die Threads müssen sich dann aber noch synchronisieren ...

Hallo Equinox, die IPConnection hat eine Callback-Queue, die in einem eigenen Thread abgearbeitet wird. Aus dieser Queue wird immer ein Callback nach dem anderen aufgerufen. Wenn also mehrere Bricklets Callbacks senden werden die in eine Queue gepackt (und damit indirekt serialisiert), aber asynchron zu Deiner Anwendung aufgerufen. Um die Queue nicht zu lange zu blockieren solltest Du länger laufende Aktionen in einem eigenen Thread auslagern. Auch muss man aufpassen, wenn im Listener Aktionen aufgerufen werden, die wieder auf den Aufruf eines Callbacks/Listeners warten: das kann zum Deadlock führen ...

Hallo Unexpected, StackCurrent und StackVoltage, die über die API des MasterBrick ausgelesen werden können, sind die Eingangswerte der Step-Down Power Supply (wenn also 12V, 300mA gemessen wird, verbraucht der Stack 3,6 Watt, also 720mA auf Basis der 5V intern). Die Werte kannst Du über die API gezielt auslesen (master_get_stack_voltage / ...current) oder eben Listener setzen, dann werden Callbacks aufgerufen, wenn sich die Werte ändern. Die Werte sind nicht so genau, wie bei VoltageBricklet, aber dennoch schon recht gut. Ich habe vielleicht 0,1-0,2 Volt Toleranz bei der Spannung. Nachtrag: ohne Step-Down liefern die Funktionen 0 zurück, d. h. Spannung/Strom kann nicht gemessen werden, wenn der Stack über USB mit Strom versorgt wird.

Auf einem Android Tablet (== Chrome Browser) hatte ich auch schon mal eine falsche Reihenfolge, mit Firefox ist mir das noch nie passiert. Also doch eher ein Browser-Bug.

Meine ITR-1500 (3er Set) arbeiten nun auch . Nur das Anlernen scheint noch etwas "Glückssache" zu sein bzw. etwas schwieriger als mit der Fernbedienung: 2 Dosen liessen sich relativ schnell anlernen (2-3 Versuche), bei der 3. habe ich gut 30 Versuche benötigt. Zwischenzeitliche Anlernversuche mit der Fernbedienung klappten immer auf Anhieb. Den Repeat-Code zwischen 3 und 10 variieren hat keinen merklichen Unterschied gemacht (letztendlich hat es mit "3" dann geklappt), aber anlernen muss man ja nicht so oft. Beim Schalten habe ich keinerlei Aussetzer / Verzögerungen: klappt immer einwandfrei, wenn der Repeat-Count >= 2 ist.

Weihnachten ist gerettet ... Ich werd's die Tage ausprobieren, bin ja selber schon gespannt. Vielen Dank für Euer Engagement in der Sache!