remotecontrol

Der Re-Compile sollte das Problem beheben, gibt mir bitte eine kurze Info, ob es geklappt hat. Wenn alles ok ist, sollte der brickv beim Start mit dem Beispiel 11 Bricklets an 3 Mastern anzeigen (wichtig: auf Port 4225 nicht 4223 wenn keine Optionen verwendet werden).

Das ist schon peinlich: Git ist bei mir nur ein Ableger meines Repos wo viel mehr Sourcen sind, darum habe ich ein "abgespecktes" Makefile im Git und zugegeben immer nur den Compile getestet (Unittests habe ich im anderen Baum) und der hatte beim Linken die Option "-c" ... Ich habe das Makefile aktualisiert, synchronisiere bitte nochmal Deinen lokalen Stand und baue es nach (make new).

Zurück .. brauchst nichts zu machen, sieht so aus, als sei das falsche Makefile da drin (ich habe ein eigenes für die GIT-Version).

Hallo Andreas, jetzt bin ich etwas irritiert ... hast Du ggf. einen Cross-Compiler auf dem System installiert? Normalerweise sollte der Compiler ja Code für die aktuelle Umgebung erzeugen, es sei denn, Du hast einen Cross-Compiler drauf. Was sagen die Befehle der Art uname -a g++ -v file /bin/bash falls die bash bei Dir wo anders stehen sollte, den "file" Befehl für ein anderes Binary aus /bin oder /usr/bin ausführen. Viele Grüße

Sorry, aber Du solltest wirklich etwas mehr Python lernen (ich kann's eigentlich auch nicht): die Einrückung ist extrem wichtig. Du hast die while-Schleife falsch eingerückt und der Import ist wohl überflüssig, da Du ihn ganz am Anfang ja schon drin hast. Also in etwa so (Du kannst ja mit den Uhrzeiten und Minuten mal spielen, dann siehst Du, ob das klappt): ... if sys.version_info < (3, 0): input = raw_input # Compatibility for Python 2.x while 1: ts = time.localtime() if ts.tm_hour == 22 and ts.tm_minute == 0: lcd.backlight_off() if ts.tm_hour == 6 and ts.tm_minute == 0: lcd.backlight_on() time.sleep(50) if weather_station.ipcon != None: ...

Auch zur Frage "wo" das eingebaut werden müsste, diese Zeile input('Press key to exit\n') müsstest Du durch die while-Schleife ersetzen, die endlos läuft und z.B. alle 30 Sekunden die Uhrzeit abfragt. Die Abfragen in meinem Beispiel würden um 22:00 (exakt 22 Uhr) das Licht ausschalten und genau um 6:00 wieder ein. Wenn das Skript zwischen 22 und 6 Uhr beendet und neu gestartet würde, würde es nicht schalten, das Licht bliebe unverändert.

Im Prinzip passt die "while" Schleife (die ich im anderen Thread erwähnt habe) gut, um jeweils die aktuelle Zeit zu prüfen, das würde dann grob so aussehen: import time while 1: ts = time.localtime() if ts.tm_hour == 22 and ts.tm_minute == 0: print "Light off" if ts.tm_hour == 6 and ts.tm_minute == 0: print "Light on" time.sleep(30) Den sleep-Wert kann Du noch optimieren. Hier würde das Skript ggf. 2x in einer Minute was machen. Ein "sleep(60)" könnte aber prinzipiell dazu führen, dass man eine Minute übersprungen wird. Anstelle des "print" musst Du dann das backlight steuern.

Das Problem ist, dass Du auf Benutzereingaben wartest, darum diese Fehlermeldung. EOFError: EOF when reading a line Das liegt daran, dass <stdin> bei cron und inittab nicht verfügbar sind, die Dateien sind per Default mit keinem Terminal verbunden. Du müsstest in Deinem Hauptprogramm eine Endlosschleife einbauen, sowas in der Art anstelle des "input()": import time while 1: time.sleep(10) Damit läuft das Skript endlos (wacht zwar alle 10 Sekunden auf, schläft dann aber wieder). Beenden kannst Du es dann aber nur noch mit einem "kill" bzw. wenn Du es von Hand startest mit Ctrl-C (so die Theorie, Python nutze ich sonst nicht).

Ändere den Startbefehl mal nach python /home/pi/tinkerforge/wetter.py >/tmp/wetter.log 2>&1 & Dann steht evtl. in /tmp/wetter.log etwas drin, wenn ein Fehler kommt. Schreibt Dein Skript Daten in eine Datei? Wenn ja: wie sprichst Du die an (absolut / relativ)? Beim Start eines Skriptes aus den root-crontab oder init.d ist zu beachten: - Environment-Variablen sind nicht gesetzt (auch kein $HOME) - Arbeitsverzeichnis ist in der Regel "/" (root-Verzeichnis)

Ja, das funktioniert echt einfach: jetzt zeigen alle 4 Kanäle zweier Bricklets bei meiner Referenzspannung ein max. Delta von nur 4mV über alle 4 Kanäle - echt gut.

Hmmm, so wie es aussieht werde ich wohl ums Schalten nicht drum herum kommen: wenn ich nur 2 Zellen angeschlossen habe und das 2. Bricklet eigentlich nichts misst, wirkt sich das auf die Messung des 1. Bricklets aus. Ziehe ich den Stecker vom zweiten Bricklet ab, verändert sich die Spannung am ersten Bricklet um ein paar mV. Dummerweise auch noch an einem Kanal etwas nach oben, am anderen etwas nach unten. Bei der Art Messung (zwei Zellen in Reihe) muss ich wohl auch immer von einem Kanal 5mV abziehen, beim anderen addieren. Das scheint schaltungsbedingt. Die Kanäle messen ansonsten bis auf 3mV identisch, wenn ich sie parallel dieselbe Spannung messen lasse.

Das sollte möglich sein, aber Du musst auf dem Handy eine App installiert haben, die auf die Tags reagiert. Zumindest die Android Handys machen erstmal "nichts" (ist auch sicherer so).

Hallo batti, danke fürs nachtesten. Dann werde ich mir wohl auch mal den Schaltplan vom Bricklet näher ansehen und mit einigen Widerständen experimentieren, ob ich ohne irgendwas zu schalten sicher erkennen kann, ob da ein Akku anliegt oder nicht. Zu genauen Messung könnte ich ggf. die Kontakte per Relais abklemmen, aber das soll das System dann wenigestens selber machen, wenn es erkannt hat, dass nichts anliegt. Viele Grüße

Hallo Loetkolben, ich will eben nicht je nach angeschlossenem Akku irgendwas umschalten müssen, sondern mit den Bricklets selber erkennen, ob ich 2,3 oder 4 Zellen angeschlossen habe. Das ist der Grund warum ich kein(e) zusätzlichen Relais will. Meine Hoffnung ist, dass es mit zusätzlicher Beschaltung mit Widerständen geht (natürlich nicht mit 0 Ohm). Oder reden wir gerade aneinander vorbei ? Viele Grüße

Die Schaltung soll ja "konstant" sein, egal welchen Akku ich anschliesse. D.h. der Schaltungsaufbau sollte so sein, dass es eqal ist, ob 2,3 oder 4 Zellen angeschlossen werden. Und am liebsten würde ich über die Spannung an den Eingängen auch erkennen wollen, welcher Akku-Typ angeschlossen ist. Ich kann nicht "zur Laufzeit", wenn ich gerade einen 3-Zellen-Akku habe, einen oder 2 Anschlüsse auf Masse ziehen. Dann müsste ich ja per Relais oder sowas reagieren. Darum mein Gedanke mit den Widerständen, die eine Masseverbindung haben.

Ich hab' mal einen Versuch von einem Schaltplan (bringt eine Foto mehr?). Die Bricklets sind an den Kontakten einer Balancer-Steckerleiste angeschlossen, in die der Balanceranschluß eines Lipo-Akkus gesteckt werden kann. Damit kann ich dann die Spannung der einzelnen Zellen messen. Wenn ich zwei oder 4 Akkuzellen habe ist alles gut. Habe ich aber ein Akku mit 3 Zellen, dann hängt N1+ vom 2. Bricklet quasi frei, aber N1- ist ja an einem Pol angeschlossen und dann zeigt das Bricklet eine Spannung an. Die ist leider so hoch, dass ich sie nicht "ignorieren" kann. Ich frage mich, ob ich in diesem Fall alle Mess-Eingänge mit einem Widerstand noch gegen Masse schalten muss (wenn ja, wie hoch müssten die sein)?

Hallo zusammen, ich habe noch ein Problemchen mit dem Dual Analog In: ich will die Spannung von 2-4 in Reihe geschalteten LiPo Zellen messen (2 Bricklets). Je nachdem wie viele Zellen der Akku hat kann es sein, dass N1- (Minus von Ch 1) noch am Akku angeschlossen ist, aber N1+ quasi in der Luft hängt (gar keinen Kontakt). Dann bekomme ich auf Kanal 1 eine Spannung von 1,3V angezeigt, obwohl ich eigentlich 0 habe. Zwischen N1- und N0-/+ ist aber eine Spannungsdifferenz, das scheint hier dazu zu führen, dass eine Spannung auf Kanal 1 angezeigt wird. Kann ich diesen Effekt durch Beschaltung mit weiteren Widerständen verhindern? Wie müsste sowas aussehen?

Ich verbaue gerade ein Dual Analog In. Im Leerlauf (nichts an den Anschlüssen) zeigt der eine Kanal 0,000 der andere 0,002 - soweit gut. Schließe ich aber eine Spannung an, so gehen die Kanäle auseinander, der eine zeigt 4,170 der andere 4,209 an. Drehe ich die Verpolung um bekomme ich -4,154 und -4,136. Sieht so aus, als wäre der 2. Kanal um den 0-Punkt um 0,02V verschoben tendenziell zu hohe Spannung gemessen wird. Lohnt sich da der Versuch einer neuen Kalibrierung oder ist das noch im Rahmen? Ich hätte gern die Kanäle auf die 2. Stelle nach dem Komma gleich - müsste das erreichbar sein?

Erste Frage: zeigt ein ls -l /lib/arm-linux-gnueabihf/libc.so.6 korrekt etwas an oder kommt eine Fehlermeldung? Ich hatte schon mal den Fall, dass je nach Distribution die libc an anderer Stelle steht und ein Symlink gesetzt werden musste. Was gibt ein objdump -x /lib/arm-linux-gnueabihf/libc.so.6 | grep GLIBC_ aus? Taucht da GLIBC_2.17 auf? Wenn nein ist die glibc zu alt, dann wird's schwer den neuen brickd zum Laufen zu bekommen.

Ich würde auch eine Version mit Anschluß für Akku-Versorgung befürworten. Aktuell würde ich aber zwei von diesen Dingern brauchen, um eben zwei Bricklets anzuschließen, d.h. dann bin gleich bei ca. 80€ (dicht an Master+WIFI) und doppeltem Stromverbrauch und mehr Verkabelung. Zwei Bricklet-Ports ähnlich wie beim Servo-Brick sollten es schon sein. Eine drahtlose nicht-wifi Variante würde ich aber noch interessanter finden, auch wenn ich dafür noch ein Gegenstück auf einem normalen Stack benötige.

Ich bin mir nicht sicher, aber es sieht so aus, als sei das Setzen des Passwortes ein spezielles Command, welches zum Tag gesendet und dann vom Tag-Controller verarbeitet wird. Dieses müsste aber erstmal von der TF-API & Firmware unterstützt werden, damit das funktioniert. Ich glaube nicht, dass das mit der aktuellen Firmware schon geht.

Hast Du in der Spezifikation gesehen, dass so ein Passwortschutz möglich ist? Ich habe nichts gefunden. Das müsste ja vom Controller des Tags unterstützt werden, konkret müsste man ja beim Schreibvorgang ein Passwort übergeben. Dazu habe ich nichts gesehen. Ansonsten kannst Du immer Lese- oder Schreibbefehle senden, solange bis Du das Tag auf read-only setzt. Dann geht aber nichts mehr in Richtung schreiben.

Welche Werte kommen denn beim Callback? Minimal kleiner oder größer als der vorige Wert? Die Potis haben ja mechanische Kontakte, Prinzipiell möglich, dass sich der Kontakt durch durch minimale Bewegung (Erschütterung, Luftzug, ..) ein klein wenig ändert und dadurch ein Callback ausgelöst wird. Wenn der Callbackwert aber völlig aus der Reihe tanzt kann es das nicht sein, sondern eher eine Störung.

Nachtrag: Du musst direkt die Motorkontakte an den Fahrtregler anschließen, also keinen weiteren Regler dazwischen. Ich kann dir bei Gelegenheit mal ein Bild dazu machen. Komme ich aber jetzt nicht dazu.

Also hier ist beschrieben, wie man Fahrtregler anschließen kann, auch mit Videotutorial bzgl. der Masseleitungen: http://www.tinkerforge.com/de/doc/Hardware/Bricks/Servo_Brick.html#brushless-motoren-mit-escs-verwenden Ich selber habe diese: http://www.conrad.de/ce/de/product/207369/Modelcraft-B4230-Carbon-Series-Fahrtregler-Belastbarkeit-54-A-35-A-25-A-Motorlimit-20-Turns-380er-Motoren?ref=searchDetail Habe damals aber für's Dreierpack nur 25EUR bezahlt. Da bin ich gerade überrascht, dass die so teuer geworden sind. Aber mit einem Regler müsstest Du zwei Motoren parallel schalten können, würde ich auch jeden Fall mal probieren. Falls Du eine Filiale in der Nähe hast: erstmal einen Kaufen, und einen Motor mit Servobrick steuern, dann den 2. Motor direkt zum ersten parallel schalten und testen (sollen ja in dieselbe Richtung laufen). Und wenn das alles tut, dann erst für die zweite Kette einen zweiten Regler besorgen.