remotecontrol

Ich habe gerade ein Touch-Feld in Betrieb genommen: feine Sache , reagiert genau richtig. Und in Kombination mit dem Piezo Speaker, damit bei kurzem / langem Drücken unterschiedliche Töne als Feedback wiedergegeben werden, wirkt das noch besser. Das wäre auch noch eine Idee: ein Gehäuse-Seitenteil mit Touch-Feld oder schon mal vorbereitete Bohrungen für die Montage vorhandener Touch-Elemente. Ich werde das 3x4 Feld wohl rechts neben das Display schrauben. Sieht zwar nicht so toll aus beim klaren Gehäuse, dunkelt aber wenigstens die Master-LEDs ab. Aber jetzt wird's eng im Gehäuse, nachdem gerade die neue Firmware für den RemoteSwitch da ist ...

Hallo TF-Team, könnt Ihr eigentlich "tiefere" Seitenteile + Oberteil für das Gehäuse der Wetterstation herstellen? Damit könnte dann z. B. ein 3. Master ins Gehäuse und in Summe ist mehr Platz. Ich habe schon immer Probleme mit Tastenprellen und würde gerne das Multitouch nutzen anstelle der Tasten und diverse andere Dinge mit einbauen, aber dann brauche ich einen 3. Master und mehr Platz. Ich habe da auch noch einen Raspi drin, der das recht eng macht.

Von den Stack-Kontakten (links + rechts) sind meines Wissens nach in Summe 10 Leitungen für die Spannungsversorgung zuständig, die je 500mA leiten können, in Summe also 5A. D. h. prinzipiell kannst Du 2,8A durchleiten. Wie warm wird der DC Brick denn? Der sitzt ja unter der WLAN Extension und wird vermutlich nicht viel Luftzug abbekommen. Ich würde öfter prüfen, wie warm der wird. Ich glaube nicht, dass die Wärme durch die Leitungen entsteht, eher etwas Verlustleistung im DC und der Step-Down. Ich habe bei meinen DC- und Servo-Bricks die Spannungsversorgung aber auch an den zusätzlichen Eingang angeschlossen: der Motor kann beim Anlaufen auch mehr als den Nennstrom verbrauchen (je nach Beschleunigung und Last). Außerdem habe ich ab und zu auch 2 Bricks (Servo + DC) im Stack und dann wird es schon knapp mit den 5A.

Mit C# sollte es keine Probleme geben, dafür gibt es Bindings und Du hast auch richtig erkannt, dass Du auf dem MicroController keinen Brickd brauchst: Du spricht den Stack dann über die IP Adresse der Ethernet extension an. Wie das mit Visual Studio und dem Netduino zusammenspielt weiss ich allerdings nicht.

Das stimmt mich doch sehr zuversichtlich . Wenn ich die Bedienungsanleitung von Intertechno richtig verstanden habe, sind Sender untereinander kompatibel. Es stand in der Anleitung, dass mit dem Sender auch andere Intertechno Geräte mit bedient werden können. Außerdem geht die Anzahl möglicher Codes wohl weit über 512 hinaus ...

Hallo zusammen, hat schon mal jemand mit dem neuen Piezo Speaker kurze Morsecodes gesendet, z. B. ein 'i' == '..' (2 Punkte)? Ich bekomme immer 5 Töne, wenn ich einen Code sende, der kürzer als 5 ist. Ab 5 Beeps scheint es dann korrekt zu sein

Ich habe das gleiche "Problem", siehe http://www.tinkerunity.org/forum/index.php/topic,2008.0.html

Also die ersten "naiven" Versuche waren erfolglos: 1) Dose einstecken und in den ersten 5 Sekunden einen Code senden klappte nicht. Gut möglich, dass ich hier noch einen Fehler gemacht habe und die Dose, das nicht als gültigen Code erkannt hat. 2) Dose bereits angelernt und in einer Schleife mal alle House und Receivercodes von 0..63 durchprobiert (dabei immer gewartet bis der SWITCHING_DONE Callback gerufen wurde) Ich habe noch eine interessante Seite gefunden: http://www.fhemwiki.de/wiki/Intertechno_Code_Berechnung, mal sehen, ob mich das weiter bringt. Ist auch die Frage, ob der Code LJ4209 am Sender bzw. LJ4208 am der Dose was bedeutet.

Die Frage mit der Umrechnung der Bits habe ich mir beim Lesen der Doku auch gestellt. Vor allem: dezimal 42 == binär 101010 => 6 Bits Ist das ein typisches Beispiel? In der Beschreibung wird von 5 DIPs gesprochen, aber 42 kann ich mit 5 DIPs nicht ansprechen - oder? Das würde nur passen, wenn es sich um einen anderen Sender/Empfänger handelt, der eben mehr als diese 5 Bits verarbeitet; oder das 6. Bit wird zwar gesendet, aber vom Empfänger schlichtweg ignoriert.

Ich habe schon eine Versandmitteilung für die Bricklets bekommen , d.h. am Wochenende werde ich was ausprobieren können: ich berichte dann mal ...

D.h. ist muss in den 5 Sekunden nach dem Einstecken einen Code senden - Danke, werde ich mal probieren, wenn die Bricklets da sind. Inzwischen habe ich die Dose auch aufbekommen: mit einer langen Spitzzange bekommt man die Schrauben gedreht (bringt dann natürlich nichts, die Dinger aufzumachen).

Hallo, ich bin zwar noch kein Besitzer der Remote Switch Bricklets, habe aber bereits zwei bestellt ... Die Steckdosen sind bereits da: Intertechno IT-1500 (Verkaufsbezeichnung IT-1500, auf der Dose steht ITR-1500, auf dem Sender ITT-1500). Aber: die Dose lassen sich mit handelsüblichem Werkzeug nicht öffnen, da sind spezielle Schraubenköpfe und ich frage mich, ob jemand diese Dosen schon mal geöffnet hat, um die Codes ablesen zu können, ohne größere Schäden anzurichten?

Ein remote "weather bricklet" wäre super, das fehlt in der Wetterstation noch ...

Sieht gut aus . Muss ich bei Gelegenheit ausprobieren ...

Bei mir hat das mit WEP funktioniert, Client ist ein Tablet. * Access Point mit Static IP, z. B. 192.168.100.1 * Subnet Mask 255.255.255.0 * Gateway 192.168.100.1 * Key in Hex Notation, z. B. Zeichenfolge "abcde" == Hex "6162636465" und speicher, Reboot des Stack * Ich musste im Tablet dann auch diese Hex-Folge eingeben 6162636465, eben nicht "abcde" * Beim Einrichten des Clients muss auch eine statische IP vergeben werden, also z. B. 192.168.100.2 Dann sollte es eigentlich gehen.

Hallo Loetkolben, danke für diesen Link. Das beantwortet meine Frage schon: die Pakete werden aktuell nicht einfach ignoriert, sondern es kann zu Fehlverhalten kommen. Dann muss ich vorerst einen Versionscheck einbauen.

Hallo Admins, wäre es möglich, in die LCD Firmware eine getText() Funktion aufzunehmen (immer 1 ganze Zeile auslesen, analog wie "getDefaultText()") ? Aktuell kann man den Status aller Bricks / Bricklets nach einem Connect auslesen. Für fast alles gibt es eine get-Funktion, nur für den LCD-Text nicht. Hintergrund: Ich habe auch einen Stack-Emulator auf Protokollebene entwickelt, den ich für Unittests nutze. Der unterstützt 13 verschiedene Devices mit Callbacks. Jetzt wäre es noch hübsch, den Status aller Devices bei Bedarf über die TF-Client-API abzufragen und zu visualisieren. Aber beim LCD scheitert das mangels "getText()".

Hallo TF-Team, ich hatte hier noch einen Stack mit nicht aktueller Firmware (Master 2.0.5, Servo 2.0.0). In meiner Anwendung verwende ich schon Bindings, welche den Position-Reached-Callback explizit deaktivieren, was in der Servo-Firmware 2.0.0 noch nicht drin ist. Der Effekt war: das Servobrick hat nach der Initialisierung keine Befehle mehr ausgeführt (Servos bewegen sich nicht). Was passiert eigentlich in Fällen, wo der Function-Code eines Paketes für das Bricklet/Brick unbekannt ist? Wird das Paket einfach ignoriert oder ist das Verhalten je nach Art der Funktion/Firmware eher undefiniert?

Wir wär's damit: - der Callback gibt die Temperatur auf der Console und dem LCD aus - der String darf aber nicht länger als 20 Zeichen sein - das LCD Sonderzeichen 0xDF habe ich als printf-Paremeter übergeben, weil der gcc sonst meckert, dass der Hexcode zu lang ist (weil ein 'C' direkt danach folgt). Achtung: wenn die Anzahl Stellen der Temperatur sich ändert, überschreibt der String nicht immer alles vom vorigen Wert. #include <stdio.h> #include "ip_connection.h" #include "bricklet_ptc.h" #include "bricklet_lcd_20x4.h" #define HOST "192.168.2.105" #define PORT 4223 #define UID_LCD20x4 "d4w" // UID vom LCD20x4 #define UID_PTC "fmJ" // UID vom PTC /////////////////////////////////////////////////////////////////////////// // Callback function for temperature callback (parameter has unit °C/100) void cb_temperature(int32_t temperature, void *user_data) { LCD20x4 *lcd = (LCD20x4*) user_data; printf("Temperature: %f °C\n", temperature/100.0); // Write "Temperatur" to LCD char line[21]; // 20 Zeichen + NUL-Terminator snprintf(line, sizeof(line), "Temp: %.2f %cC", temperature/100.0, 0xDF); line[20] = 0; lcd_20x4_write_line(lcd, 0, 0, line); } int main() { // Create IP connection IPConnection ipcon; ipcon_create(&ipcon); // Create device object PTC ptc; ptc_create(&ptc, UID_PTC, &ipcon); // Create device object LCD20x4 LCD20x4 lcd; lcd_20x4_create(&lcd, UID_LCD20x4, &ipcon); // Connect to brickd if(ipcon_connect(&ipcon, HOST, PORT) < 0) { fprintf(stderr, "Could not connect\n"); exit(1); } // Don't use device before ipcon is connected // Set Period for temperature callback to 1s (1000ms) // Note: The callback is only called every second if the // temperature has changed since the last call! ptc_set_temperature_callback_period(&ptc, 1000); // Register temperature callback to function cb_temperature ptc_register_callback(&ptc, PTC_CALLBACK_TEMPERATURE, (void *)cb_temperature, &lcd); // Turn backlight on lcd_20x4_backlight_on(&lcd); printf("Press key to exit\n"); getchar(); lcd_20x4_backlight_off(&lcd); // Turn backlight off ipcon_destroy(&ipcon); // Calls ipcon_disconnect internally }

Ich kann das Argument prinzipiell nachvollziehen, das bedeutet aber im Umkehrschluss, dass Vereinheitlichungen nicht möglich sind. Echte C-Programme merken die Änderung nicht, weil die Parameterleiste binär-kompatibel ist (bleibt 1 Byte Wert). C++ Programm sind hier schnell umgestellt, weil es Compile-Fehler geben würde. Diese Funktionen gehören zudem zu den eher weniger benutzten Funktionen, nicht gerade jene Funktionen, die jeder benutzen muss. Ich habe keinen Überblick, wie das in den anderen Bindings aussieht. In Java wäre wohl nichts zur ändern.

Über den enumerate-Mechnismus bekommt man alle Bricks und Bricklets aufgelistet mit den Informationen, welches Bricklet an welchem Port eines Bricks hängt (A,B,C,D) bzw. wo im Stack sich die Bricks befinden (Position 0..6). Es gibt keine API des Masterbricks, um direkt abzufragen, welche Bricklets an ihm angeschlossen sind. Aber der enumerate liefert diese Informationen indirekt mit.

Hallo Admins, In den C/C++ Bindings liefern die API-Funktionen int servo_is_position_reached_callback_enabled(Servo *servo, uint8_t *ret_enabled); int servo_is_velocity_reached_callback_enabled(Servo *servo, uint8_t *ret_enabled); jeweils einen uint8_t zurück, andere Funktionen liefern einen "bool" (z.B. is_enabled). Kann man das noch vereinheitlichen und überall einen bool verwenden? In der Datenübertragung sollte das ja keinen Unterschied machen.

In /etc/init.d habe ich eine Start-Datei, die bei mir so aussieht: #!/bin/sh ### BEGIN INIT INFO # Provides: homestation # Required-Start: $all # Required-Stop: # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: homestation # Description: Home Station ### END INIT INFO PATH=/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin DAEMON=/usr/local/bin/homestation NAME=homestation PIDFILE=/var/run/$NAME.pid DESC="Home Station" # options for the main program OPTIONS="--fork --pid $PIDFILE" test -f $DAEMON || exit 0 set -e case "$1" in start) echo -n "Starting $DESC: " # echo start-stop-daemon --verbose -d /home/pi/HomeStation --pidfile $PIDFILE --exec $DAEMON --start -- $OPTIONS start-stop-daemon --verbose -d /home/pi/HomeStation --pidfile $PIDFILE --exec $DAEMON --start -- $OPTIONS ;; stop) echo -n "Stopping $DESC: " start-stop-daemon --verbose --pidfile $PIDFILE --stop ;; restart|force-reload) echo "Restarting $DESC: " start-stop-daemon --verbose --pidfile $PIDFILE --stop sleep 3 start-stop-daemon --verbose -d /home/pi/HomeStation --pidfile $PIDFILE --exec $DAEMON --start -- $OPTIONS ;; status) echo -n "Status of $DESC: " if [ -n "${PIDFILE:-}" -a -r "$PIDFILE" ]; then PID=`cat "$PIDFILE"` if [ -n "${PID:-}" ]; then if $(kill -0 "${PID:-}" 2> /dev/null); then echo "running (pid $PID)" elif ps "${PID:-}" > /dev/null 2>&1; then echo "running (pid $PID)" else echo "stopped" fi else echo "stopped" fi else echo "stopped" fi ;; *) N=/etc/init.d/$NAME echo "Usage: $N {start|stop|restart|force-reload|status}" >&2 exit 1 ;; esac exit 0 Über den Befehl "insserv" kann dieser Dienst dann in den entsprechenden Runleveln eingetragen und damit automatisch gestartet gestartet werden. Aber Achtung: so wie hier gezeigt ist der User der "root" nicht "pi". Du musst den Start noch etwas ändern, wenn der User anders sein soll. Und das Programm muss natürlich die Argumente verarbeiten (z. B. fork + pid-file schreiben) und ggf. auf den SIGTERM reagieren um einen normalen Shutdown zu machen und ggf. auch zu protokollieren, dass er beendet wurde. Das geht prinzipiell auch alles ohne PID-File und SIGTERM-Handling.

Hallo TF-Team, um die Genauigkeit des Barometersensors zu erhöhen, verfügt dieser über einen zusätzlichen Temperatursensor und der lässt sich über API auslesen. Der Humiditysensor muss auch einen Temperatursensor haben (zumindest intern), da die Luftfeuchte ja immer relativ zur Umgebungstemperatur ist. Dummerweise lässt sich gerade dieser Wert nicht auslesen. Ginge das prinzipiell oder bräuchte man dafür ein neue Hardwareversion des Humiditysensors? Hintergrund: wenn man die Wetterstation mit Gehäuse und verbautem Raspi betreibt, dann wärmt sich der Innenraum merklich auf (auch wenn das WLAN-Modul drin ist). Das verfälscht die Luftfeuchte-Messung erheblich. Aktuell "löse" ich das Problem dadurch, dass ich die Temperatur des Barometer-Bricklets für eine Korrekturberechnung der Luftfeuchte hernehme. Die Zieltemperatur ist dabei ein außerhalb des Gehäuses befestigter separater Temperatursensor. Das klappt recht gut, aber eigentlich wäre es sinnvoll/hilfreich, wenn die Temperatur des Humidity-Bricklet auch auslesbar wäre.

Ich habe den Raspi an die Step-Down angeschlossen und den Stack an einen der USB-Anschlüsse des Raspi. Das klappt ohne Probleme, Du musst Dir aber ein USB-Kabel "zurecht basteln". Auch der Bootvorgang läuft so problemlos: beim Einschalten booten Stack + Raspi, der brickd startet automatisch und erkennt sofort den Stack. Eine Anwendung startet nach brickd über die init-Sequenz.