borg

Do you have any idea for a project or specific interest? Something easy to start with is always the weather stations. You can start with calling getters to get the measurements from the sensors and print then to the console. From there you can go anywhere (store data in a database, draw graphs, etc).

Das Air Quality Bricklet nutzt die 5V nicht, da kann nichts passieren. Du könntest versuchen die Firmware nochmal neu drauf zu spielen, ich wüsste aber nicht warum das etwas bringen soll. Damit ich das richtig verstanden hab: Wenn du das Bricklet vom Strom trennst und wieder ansteckst liest es immernoch Nullen? Oder hatte es nur einmal kurzfristig nur Nullen gelesen?

Schwer zu sagen, kannst du dein Python-Programm hier posten? Vielleicht lässt sich da ja noch etwas optimieren.

Wenn du in diesem Fehlerfall bist, bekommst du dann denn irgendwelche Callbacks? Ich würde erwarten dass das Bricklet dann vielleicht irgendwelche Klicks sieht die gar nicht da sind o.ä.?

Woran scheitert es denn? Hast du vielleicht Code der schon etwas tut aber nicht ganz funktioniert oder etwas ähnliches?

Steckt das Kabel richtig drin? Vielleicht auch einmal das Kabel am Brick und Bricklet abmachen und schauen ob alle Pins noch gerade sind oder ob etwas verbogen ist etc.

Ein E-Paper Bricklet ist bereits in der Entwicklung: https://github.com/Tinkerforge/e-paper-296x128-bricklet

Wenn du die Auflösung von 16bit auf 8bit umstellst, bekommst du in der tat die Einheit 256/10000g anstatt 1/10000g zurück (die 8 niedrigsten Bits werden einfach abgeschnitten). Das ist nicht hinreichend gut dokumentiert, kümmere ich mich drum! Die Skalierung und Datenrate solltest du allerdings ändern können ohne das sich die Einheit ändert. Edit: Hier sind die Änderungen die ich an der Doku vorgenommen hab um das klarer zu machen: https://github.com/Tinkerforge/generators/commit/fcd32651d873a40a16322866ef3515a45415f7ab

Wir können ein Beispiel machen welches diese Funktion implementiert. Das kann aber nicht teil der API sein. Die APIs die wir für die ganzen Programmiersprachen anbieten sind komplett auto-generiert. Wir haben ~120 Produkte und ~17 Programmiersprachen mit je ~3 Beispielen. Wenn du da das Kreuzprodukt draus bildest siehst du wie viel Code das ist. Es wäre unmöglich für uns das per Hand zu schreiben. Alle APIs, die Dokumentationen für die APIs und die meisten Beispiele sind auto-generiert. Der Generator nutzt fürs LCD128x64 diese Config: https://github.com/Tinkerforge/generators/blob/master/configs/bricklet_lcd_128x64_config.py Das sind also alle Informationen die zur Verfügung stehen die API, Beispiele und Dokumentation zu generieren.

Die Firmware inklusive der Schrift und GUI ist aktuell 22kb groß. Wir haben in Summe 32kb zur Verfügung, davon werden 8kb immer vom Booloader belegt. Es sind also aktuell noch 2kb frei. Eine Bitmap-Schriftart in der Größe ist mehrere hunderte Kilobyte groß. Das wird also nichts . Und nein, ein TrueType-Renderer oder sowas passt auch nicht auf den Mikrocontroller. Aber für hübsche große Schriftarten kann man ja PIL oder ähnliches nutzen!

Kommt mit dem nächsten Bindings-Release. Die Veröffentlichungen der Bindings und der Firmwares sind aktuell mehr oder weniger asynchron. Eine neue Firmware veröffentlichen dauert nur ein paar Sekunden, neue Bindings veröffentlichen ist mehr Aufwand. Daher gibt es neue Bindings meist nur alle paar Wochen.

Meine Vermutung dazu: Du hast irgendwo im Code sowas stehen wie t1 = float_value und überschreibst damit ausversehen das "t1" Temperature Bricklet-Objekt. Vielleicht ist in Python2 der Scope von der Variable irgendwo leicht anders als in Python3 und dadurch tritt das jetzt erst auf?

Schon wieder der Kühlkörper abgefallen? Normalerweise sollte der absolut Bombenfest sitzen. Der Kleber den wir da verwenden ist genau dafür gedacht. Wir gehen Montag den Lagerbestand durch und schauen ob wir weitere Kühlkörper abbrechen können. Anrauen sollte mit dem Kleber den wir verwenden soweit ich weiß nicht notwendig sein. Eventuell waren ein paar der Kühlkörper etwas "fettig" und wir hätten erst einmal mit IPA drüberwischen sollen? Wir werden das untersuchen. Wenn du den defekten Silent Stepper Brick zurück schickst können wir schauen was dort der Grund für die verlorenen Nachrichten ist. Es reicht wenn du den Brick einfach per Post in einem Luftpolsterumschlag oder so verschickt. Muss nicht schnell gehen.

Wenn du sagst du bekommst keine Rückgabewerte, was bekommst du denn dann? Eine Exception oder falsche Werte? Welche Exception bzw welche falschen Werte bekommst du? Und zu Python 2 vs 3: Mit Python 2 funktioniert es mit allen Bricklets aber mit Python 3 funktioniert es nicht mit allen Bricklets? Hab ich das richtig verstanden?

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.