borg

Uhm... Wir planen aktuell damit alle Bricks (bis auf den Master Brick) auf Bricklets umzustellen. Diese neuen "Bricklet-Bricks" werden aber wahrscheinlich zusätzlich einen USB-Stecker haben, sodass man sie weiterhin einzeln per USB benutzen kann, zusätzlich aber z.B. über das neue RPi HAT per Bricklet Kabel oder auch am Master Brick im Stapel. Das ist allerdings noch reine Planung, wir haben noch keine Prototypen dafür hier. Wird also noch ein paar Monate dauern bis es ein "Silent Stepper Bricklet" gibt.

Ich konnte das Problem zwar nicht reproduzieren, aber ich denke ich hab etwas gefunden. Kannst du einmal deine OLED128x64-Firmware auf die neueste Version aktualisieren und nochmal testen?

Firmware: OLED 128x64 Bricklet 2.0 2.0.3 Fix drawing race condition in automatic-draw mode Download: OLED 128x64 Bricklet 2.0

Firmware: OLED 128x64 Bricklet 2.0 2.0.3 Fix drawing race condition in automatic-draw mode Download: OLED 128x64 Bricklet 2.0

Die Idee hatten wir natürlich auch bereits. Ich kann mir gut vorstellen das sowas auch mittelfristig von uns offiziell kommen wird. Anstatt dem "alten" Master Brick dafür Support beizubringen würde ich es allerdings eher vorziehen entweder dafür ein komplett neues Brick zu machen welches auch reichlich mehr Speicher hat und neben C vielleicht auch sowas wie Micropython ausführen kann. Alternativ könnte man jetzt mit den neuen Bricklets auch ein Arduino Shield mit den neuen Bricklet-Steckern und Bindings machen die sich in das Arduino-Ökosystem integrieren. Wir haben allerdings aktuell eine volle Roadmap mit neuem Kram. Eine "Embedded-API" wird es daher erst mittelfristig geben (nicht in den nächsten Monaten).

Hab das gerade ausprobiert, am einfachsten ist es wenn du PIL über die Debian Pakete installierst: Diese drei runterladen: * https://packages.debian.org/stretch/armhf/python-pil/download * https://packages.debian.org/stretch/armhf/python3-pil/download * https://packages.debian.org/stretch/armhf/libwebpdemux2/download Das ist PIL für Python 2 und 3 sowie eine Abhängigkeit von beiden. Auf dem RED Brick dann: sudo dpkg -i libwebpdemux2_0.5.2-1_armhf.deb python3-pil_4.0.0-4_armhf.deb python-pil_4.0.0-4_armhf.deb Sieht dann so aus: tf@red-brick:~/pil$ ls libwebpdemux2_0.5.2-1_armhf.deb python3-pil_4.0.0-4_armhf.deb python-pil_4.0.0-4_armhf.deb tf@red-brick:~/pil$ sudo dpkg -i libwebpdemux2_0.5.2-1_armhf.deb python3-pil_4.0.0-4_armhf.deb python-pil_4.0.0-4_armhf.deb Selecting previously unselected package libwebpdemux2:armhf. (Reading database ... 203093 files and directories currently installed.) Preparing to unpack libwebpdemux2_0.5.2-1_armhf.deb ... Unpacking libwebpdemux2:armhf (0.5.2-1) ... Selecting previously unselected package python3-pil:armhf. Preparing to unpack python3-pil_4.0.0-4_armhf.deb ... Unpacking python3-pil:armhf (4.0.0-4) ... Selecting previously unselected package python-pil:armhf. Preparing to unpack python-pil_4.0.0-4_armhf.deb ... Unpacking python-pil:armhf (4.0.0-4) ... Setting up libwebpdemux2:armhf (0.5.2-1) ... Setting up python3-pil:armhf (4.0.0-4) ... Setting up python-pil:armhf (4.0.0-4) ... Processing triggers for libc-bin (2.24-11+deb9u3) ... tf@red-brick:~/pil$

Die Wetterstation sendet mit 433MHz 1x pro Minute. Du kannst die anderen Bricklets draußen entweder mit der WIFI Extension oder mit der Ethernet Extension oder mit einem RPi/RED Brick mit anderem Funk-Standard betreiben. An die Wetterstation kann man nichts weiteres anschließen.

Die Wetterstation ist ein Sender und das Outdoor Weather Bricklet ist ein Empfänger. Das Outdoor Weather Bricklet kannst du an einen Brick anschließen. Die anderen Bricklets werden auch an einen Brick angeschlossen.

Die Wetterstation kann nur mit dem Outdoor Weather Bricklet ausgelesen werden. Dieses kannst du dann aber mit einem Master Brick mit einer Ethernet Extension verbinden um die Wetterstation per LAN auszulesen. Wenn du den Luftdruck haben möchtest lohnt es sich . Das gute beim Luftdruck ist, dass du das Bricklet auch innen anbringen kannst. Der Luftdruck ist unter normalen Umständen innen und außen der gleiche. Das Dust Detector Bricklet ist so eine Art Rauchdetektor. Sowas wie Zigarettenrauch kann damit gut erkannt werden. Für jedes Bricklet brauchst du ein Bricklet-Kabel (das gibt es auf der Shop-Seite direkt als Option mit zur Auswahl). Dann brauchst du für je vier Bricklets einen Master Brick, ein USB Kabel für den Master Brick und einen PC (oder RPi oder RED Brick o.ä.) an dem du den Brick anschließen kannst. Das ist soweit erstmal die Minimalanforderung. Bei jedem Brick/Bricklet gibt es im Shop auch noch ein Befestigungskit, damit kannst du die Teile festschrauben oder auch aneinanderschreiben. Zusätzlich würden wahrscheinlich 2-3 Montageplatten Sinn machen. Wenn das ganze per LAN ausgelsen werden soll benötigst du auch noch eine Ethernet Extension. Als Stromversorgung reicht ein USB-Netzteil. Gehäuse für ganze aufbauten habe wir aktuell leider noch nicht im Shop.

Am einfachsten ist es wenn du den RED Brick dafür kurz ins Internet bringst, z.B. mit einem WIFI USB Stick. Ansonsten gibt es hier eine ganz gute Antwort darauf: https://stackoverflow.com/questions/36725843/installing-python-packages-without-internet-and-using-source-code-as-tar-gz-and

Mit Bindings meine ich die API, die Library. Das wo die "write_line"-Funktion drin steckt. Du hast da einen Order "tinkerforge_python_bindings_2_1_21". Ich nehme an du hast den "tinkerforge"-Order der da drin ist einfach auf das gleiche Level im Dateisystem wie die Beispiele gelegt? Das wäre OK. Ich versuche das nochmal zusammenzufassen: Deine ganzen Probleme sind denke ich alle das gleiche Problem (Nachrichten gehen verloren). Das ist hier definitiv der Fall und die Exception in dem "image_data[0,0]"-Thread ist ja auch wieder eine TimeoutException. Genauso wie die Exception beim Stepper Brick. Die Hardware scheint zu funktionieren (Du kannst z.B. Zeile 0 mit dem Brick Viewer setzen). Es funktioniert mit deinem Programm auch nicht wenn du das Bricklet an einen anderen Brick anschließt (d.h. es liegt höchstwahrscheinlich auch nicht an einem defekten Brick). Die Bindings haben die aktuellste Version. Ich hab im Moment keine gute Idee mehr. Kannst du mir vielleicht deinen ganzen Order zippen und schicken in dem das OLED-Beispiel ist welches das Problem erzeugt? Inklusive dem "tinkerforge"-Ordner. Dann schaue ich ob ich es damit reproduzieren kann.

Das Bricklet ist nicht defekt (es funktioniert mit dem Brick Viewer) und dein Program ist OK. Es muss also an den Bindings liegen die du verwendest? Gibt ja keine andere Möglichkeit . Hast du die bei uns von der Homepage geladen und händisch installiert? Oder per pip? Welche Version?

Der Aufbau mit RED Brick ist im Vergleich zum anderen Aufbau leider schwerer zu debuggen. Das hat auch mehr Komplexität (SD Karte, CPU Last bei dem "While-True"-Programm auf dem RED Brick etc). Eine andere Frage: Du bekommst jedes mal eine TimeoutException, richtig? Per Default haben wir einen 2,5 Sekunden Timeout im System. D.h. wenn es auf eine Anfrage an den Brick für 2,5 Sekunden keine Antwort gibt, fliegt die Exception. Du könntest diesen Timeout einmal testweise erhöhen (set_timeout auf der IPConnection aufrufen): https://www.tinkerforge.com/en/doc/Software/IPConnection_Python.html Am besten auf 30 Sekunden oder so stellen, damit wir ganz sicher sein können das auch wirklich eine Nachricht verloren geht und nicht nur für eine längere Zeit irgendwo stecken bleibt. Weitere Frage: Wenn die TimeoutException auftritt, kannst du danach dein Programm wieder starten und es läuft erst normal weiter?

Probier es mal so: image = Image.new('1', (128,64)) image_data = image.load() pixel = image_data[column, row] > 0

Der Aufbau lief bei mir über 9 Stunden durch. Übers Wochenende hab ich es jetzt aber nicht laufen lassen, aber ich kann es dann am Montag wieder starten. Mh, eher ist was mit dem Master Brick nicht in Ordnung oder? Der Stepper Brick alleine funktioniert ja. Kannst du einmal überprüfen ob vielleicht ein Pin im Bricklet-Stecker krumm ist und einen Kurzschluss macht o.ä. (in einem der Bricks oder Bricklets)? Ist irgendetwas im Stapel-Stecker was dazu führt das der Kontakt nicht gut ist? Aber das alles würde nicht erklären warum du Zeile 0-2 im OLED nicht setzen kannst... Vielleicht einen anderen USB-Port am PC oder ein anderes USB-Kabel? Dein Aufbau ist ja eigentlich recht simpel, dass muss absolut stabil laufen.

Ich bin ratlos. Das macht keinerlei Sinn. Der Brick Viewer nutzt wie gesagt die ganz normalen Python Bindings die wir auch veröffentlicht haben.

Du hast gar nichts geändert an deinem Aufbau und keine Software aktualisiert o.ä.? Ich wüsste nicht warum dann auf einmal die Callbacks nicht mehr funktionieren sollten . Kannst du vielleicht einmal eines der Minimalbeispiele testen die es in der API-Dokumentation gibt? Funktionieren diese auch nicht?

Temperaturmessung ist ein erstaunlich schwieriges Problem. Wenn ein Sensor eine Genauigkeit von +-0,1°C angibt (z.B.) ist das unter Laborbedingungen sicherlich korrekt. Die Ungenauigkeiten entstehen dann durch "self-heating" (der Temperatursensor selbst wird warm wenn er benutzt wird) oder durch eine leicht warme Leiterplatte (auf Grund eines Prozessors der neben dem Temperatursensor sitzt z.B.). Manchmal ist auch die direkte Umgebungsluft wärmer als die eigentliche Raumluft. Eventuell weil sich Hitze in einem Gehäuse staut. Der RPi 3 gibt natürlich auch eine Menge wärme von sich. Daher muss die Temperatur in so einem Aufbau fast immer zusätzlich einmal Kalibriert werden wenn sie auf ein paar Zehntel Grad genau sein soll. Wir bieten aktuell leider keinerlei Wasserdichte Gehäuse. Wenn WLAN nicht in Frage kommt bieten wir aktuell in unserem System nur LAN und natürlich die Outdoor Weather Station mit dem passenden Bricklet dazu (das wäre 433MHz Funk). Wir haben so ziemlich alle Möglichkeiten Sensoren auszulesen im System (digitale Eingänge, 0-10V, 4-20mA, RS232, RS485, etc). Sollte also möglich sein . Ja, der PC ist auch für das Display alleine schon notwendig denke ich. Wenn du nur Daten auf dem Display anzeigen möchtest würde ich mir eine hübsche Graph-Library suchen und die nutzen, OpenHAB brauchst du dafür nicht. Natürlich macht das Vorhaben mit Tinkerforge Sinn. Eine andere Antwort kannst du hier im Forum jetzt aber auch nicht erwarten . Ganz grob: Wenn der Weg Das Ziel ist (d.h. es geht dir darum Löten zu lernen oder zu lernen wie man low-level einen Treiber für einen Sensor schreibt oder so) ist Tinkerforge wahrscheinlich nicht die beste Wahl. Wenn das Ziel das Ziel ist (du möchtest am Ende ein funktionierende Wetterstation nach deinen Vorstellungen haben) ist Tinkerforge genau richtig.

Bezüglich der Geschmeidigkeit der Kurve: Wie schnell war denn die Reaktionszeit und wie hoch die Updaterate? Weil mit der aktuell veröffentlichen Version von BSEC kriegen wir Daten nur mit einer Frequenz von maximal 0.33Hz.

Ich hab das jetzt eine ganze Weile am laufen hier (im Stapel mit Master Brick), bisher kann ich es leider noch nicht reproduzieren . Der Aufbau mit nur Rotary Encoder und Silent Stepper Brick lief die ganze Nacht duch.

Hab gerade kurz in den Code geschaut, es gibt zwei Checks in der Funktion: Der zweite Check ist hier wahrscheinlich das Problem. Die Funktion geht hier davon aus, dass der Kanal zuvor bereits auf Input konfiguriert wurde. Das scheint mir ein wenig strikt zu sein, ich bin mir gerade nicht sicher ob das notwendig ist. Muss ich mir im Detail anschauen.

Das kann ich nicht reproduzieren. Wenn du per Brick Viewer oben Text sendest (line 0, pos 0), funktioniert das? Das ist auch in Python geschrieben und nutzt intern auch write_line.

Die API hat auch einen Callback dafür: https://www.tinkerforge.com/de/doc/Software/Bricks/SilentStepper_Brick_Python.html#BrickSilentStepper.CALLBACK_UNDER_VOLTAGE

Hab das jetzt (inklusive Rotary Encoder) hier aufgebaut und gestartet. Bisher läuft es durch. Das erste was mir bei dem Script auffällt: Du rufst get_count() des Rotary Encoders und get_current_velocity() des Stepper Bricks mehr oder weniger in einer "While-True-Schleife" auf. Du könntest an der Stelle entweder ein sleep von 50ms oder so einbauen um das ganze ein bisschen zu entlasten oder sogar den Count per Callback holen und in der Schleife nur drauf reagieren wenn der Count sich ändert. So wie es gebaut ist lastet das den Stepper Brick und Rotary Encoder voll aus. Deswegen sollte das natürlich nicht abstürzen, nur als Hinweis.

OK, ich werde versuchen das hier zu reproduzieren. D.h. der Minimalaufbau mit dem ich das nachstellen kann wäre ein Silent Stepper Brick mit Schrittmotor und externer Stromversorgung per USB am PC und dazu dein Python-Programm ausführen, richtig?