borg

Das hast du komplett richtig erklärt. Alle Werte des Bricklets kommen über die API der Bosch Software. Die Bosch Software steuert unter anderem einen Heater, der die Luft in dem Sensor in regelmäßigen Intervallen auf >100°C erhitzt. Das wird gemacht um den IAQ-Index zu bestimmen. Damit man gleichzeitig aber noch die korrekte Temperatur und Luftfeuchte usw auslesen kann muss die Bosch Software diese aber natürlich wenn der Heater an ist entsprechend justieren. Wenn die Bosch Software läuft und wir nebenher einfach selbst die Temperatur auslesen würden (was wir könnten) würden wir regelmäßig sowas wie 100°C messen. Was wir machen könnten ist die Bosch Software komplett runter schmeißen und den Heater ignorieren. Dann könnten wir Temperatur, Luftfeuchte und Luftdruck messen, aber keinen IAQ. Der kommt erst durch diese Steuerung des Heaters und des Auslesens der "Gas Resistance" zustande. Den Algorithmus dafür oder auch nur eine Erklärung wie das im Detail funktioniert gibt es aber von Bosch leider nicht...

Ich hab deinen letzten Post wie folgt verstanden: Du möchtest so etwas ähnliches wie Brick Viewer oder Brick Daemon bauen und dir fehlen die Tools dafür. Meine Antwort darauf ist: Brick Viewer/Daemon basieren auf den Tools die wir veröffentlicht haben. Ich weiß nicht welche Tools dir fehlen um etwas ähnliches zu bauen. Wenn das nicht gut genug ist als Antwort versuch doch bitte einmal deine Gedanken zu sortieren und eine konkrete und verständliche Frage zu stellen.

Es gibt ein Stück proprietäre Software namens BSEC. Dieses Stück Software kommt von Bosch und es ist für uns eine Blackbox. Diese Blackbox hat (unter anderem) die API bsec_get_state() und bsec_set_state(). Bei einem Aufruf von bsec_get_state() wird der aktuelle "State" des Algorithmus inklusive der ganzen Kalibrierungsdaten usw zurück gegeben. Durch einen Aufruf von bsec_set_state() kann dieser State wieder gesetzt werden. Das Bricklet ruft alle 12 Stunden bsec_get_state() auf und speichert die zurückgegebenen Daten inklusive einer CRC in den Flash. Wenn das Bricklet gestartet wird, schaut es ob gespeicherte Daten im Flash liegen und ob die CRC passt. Falls dies der Fall ist lädt es diese Daten und setzt sie per bsec_set_state(). Das ist bereits die komplette Logik aus Sicht des Bricklets. Entweder die Funktion bsec_set_state() oder bsec_get_state() hat in der aktuellen Version von BSEC einen Bug welcher dazu führt dass die Kalibrierungsdaten (die Teil des States sind) korrupt werden.

Das macht das Update automatisch. Da musst du nichts machen, einfach mit Strom verbinden. Das passiert alles intern.

Das Problem bei 2.0.3 ist, dass wenn du das Bricklet neustartest (und es vorher mindestens 12 Stunden gelaufen hat) die gespeicherte Kalibrierung wieder geladen wird. Dieser Ladevorgang korrumpiert manchmal die Kalibrierungsdaten. Wenn das passiert fängt der IAQ-Wert an zwischen absolut unrealistischen Werten hin- und herzuspringen. Wenn du einmal in dem Zustand bist, bin ich mir nicht sicher ob man da überhaupt wieder raus kommt ohne die Kalibrierung einmal zu löschen. Ich hatte es jetzt ~10 Tage laufen lassen in dem Zustand ohne Besserung...

Bei Bosch hat sich leider bisher noch nichts getan bezüglich des "load/save state"-Bugs. Ich hab jetzt erst eine Firmware (2.0.4) gebaut welche die automatische Kalibrierung nicht alle 12 Stunden speichert oder diese beim Neustart lädt. Ich hab zusätzlich auch die Doku zur IAQ-Genauigkeit nochmal überarbeitet mit allen Informationen die ich von Bosch dazu bekommen hab: https://www.tinkerforge.com/de/doc/Hardware/Bricklets/Air_Quality.html#iaq-index-genauigkeit Wenn ihr die neue Firmware flasht ist die Erwartung, dass der IAQ-Wert erst eine Zeitlang bei 25 steht (bei accuracy=0) und dann für mehrere Minuten auf 0 springt und dort bleibt (bei accuracy=1). Dann fängt der Wert irgendwann an sich zu bewegen und nach ein paar Stunden sollte dann die Genauigkeit auf 2 springen. In der aktuellen Firmware, wenn ihr das Bricklet dann neustartet fängt das Prozedere wieder von vorne an.

Dass der Kühlkörper abbricht ist ja so schonmal nicht gedacht. Normalerweise sollte der absolut fest sitzen und nicht so ohne weiteres abbrechen können. Ich würde vorschlagen wir schicken dir erstmal einen neuen Master Brick und einen neuen Silent Stepper Brick. Dann hast du einen Ersatz für den Silent Stepper Brick mit dem abgebrochenen Kühlkörper und wir können schauen ob deinen Timeouts ein Hardwareproblem zugrunde liegt oder nicht.

Ich hab das Test-Script was du zuvor gepostet hattest für 2x je ~8 Stunden am Stück laufen lassen ohne Probleme. Die Exception bedeutet das du auf einen Getter (get_current_velocity in diesem Fall) keine Antwort bekommen hast. Das heißt entweder die Anfrage ist verloren gegangen oder die Antwort auf die Anfrage. Ich würde erwarten das du auch mit einem while True: ss.get_current_velocity() ohne den ganzen anderen Code das Problem erzeugen kannst? Wenn die Kommunikation einmal gestört war, bleibt Sie gestört und du musst erst das Brick vom Strom trennen damit es wieder funktioniert. Am einfachsten wäre es ja noch wenn irgendein Hardwaredefekt vorliegen würde, aber mir fällt nichts ein was diese Symptome erzeugen könnte.

Ich muss noch die ganzen LC128x64 draw_*()-Funktionen auf das OLED 128x64 portieren. Siehe hier: https://www.tinkerforge.com/de/doc/Software/Bricklets/LCD128x64_Bricklet_Python.html#BrickletLCD128x64.draw_text Das steht schon auf der TODO-Liste.

Hier hast du mich abgehängt. Der Brick Viewer nutzt die ganz normalen Python-Bindings ohne Änderungen. Die Komponenten dafür stehen also zur Verfügung. Der Brick Daemon nimmt Pakete über USB entgegen und sendet sie per TCP/IP wieder raus (und umgekehrt). Da gibt es keinerlei Magie. Die MQTT-Bindings werden genauso generiert wie die anderen Bindings auch. Da stecken nicht mehr und nicht weniger Information oder Abstraktion drin wie in den anderen Bindings. Die MQTT-Bindings (und auch der obsolete MQTT-Proxy) vereinen auch nicht den Brick Daemon mit irgendetwas. Den Wandler von USB nach TCP/IP benötigst du ach noch wenn du die MQTT-Bindings einsetzt. Welche Komponenten nutzen wir im Brick Viewer/Daemon und in den MQTT-Bindings die dir nicht zur Verfügung stehen?

Zeitsynchronisation zwischen zwei Microcontrollern ist nicht so einfach. Du könntest versuchen sowas wie NTP/PTP über SPI zu implementieren oder einen Sync Ein-/Ausgang bei den Bricklets haben. Wenn einer der Stepper den zieht führt der andere den letzten Befehl aus den er bekommen hat.

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