rtrbt

Moin, Das Outdoor Weather Bricklet wird soweit ich das sehe von dem Paket nicht unterstützt, zumindest laut diesem Issue. Du kannst aber alternativ die MQTT-Bindings benutzen und darüber die Daten in Node-RED bekommen. Gruß, Erik

Moin, Ich muss mal testen, ob das funktioniert, das schiebe ich diese Woche noch ein. Da gibt es bisher noch keine Updates, mein letzter Stand als ich das vor Monaten getestet hatte war, dass aus irgendeinem Grund Things dupliziert werden. Die Spannungsversorgung auf dem HAT schafft theoretisch 4A bei 5V, wird aber bei 3A Dauerlast schon ziemlich heiß. Die Raspberry Pi Foundation schreibt in den Spezifikationen Daraus könnte man jetzt abschätzen, dass sie für den Pi selbst mit 2A Peak-Strom rechnen. Die USB-Geräte können laut diesem Artikel bis zu 1,2A ziehen, dazu kommt dann noch was du am HAT selbst angeschlossen hast. Für die Bricks und Bricklets sollte jeweils der Stromverbrauch dokumentiert sein. D.h. du kannst dir das für deinen Aufbau durchrechnen, wenn du aber nicht gerade 5*4 + 8 Industrial Dual Relays verbaust und die alle schaltest, sollte das vermutlich gehen. Der Pi sollte wenn du darauf nur openHAB laufen lässt ja auch nicht gerade unter permanenter Volllast sein. Du solltest aber auf jeden Fall einen flachen Kühlkörper auf den Prozessor des Pis setzen und den ganzen Aufbau mit einem Lüfter kühlen, sonst brennt dir der Pi selbst schon ein Loch in den Tisch. Gruß, Erik

Den kann ich noch eine Weile laufen lassen, stört in der Ecke keinen. Das heißt hoffentlich, dass es jetzt kein I2C- sondern nur ein Reset-Problem ist. Damit kann man notfalls ja umgehen, wenn die Enumerations ankommen.

Moin, Die Sonderzeichen kannst du über die Hex-Escape-Sequenzen in Strings einfügen, z.b. mit oled.write_line(0, 0, '24.25\xF8C')

Moin, Hast du den 5.4er Kernel installiert? Dann hast du vermutlich dieses Problem. Du kannst also entweder nochmal auf den alten 4.19er Kernel wechseln, die HAT-Firmware aktualisieren und dann wieder auf den 5.4er Kernel gehen, oder du benutzt den dort angehangenen Brick Daemon zum flashen der neuen HAT-Firmware.

Das ist ein Framing-Error, das heißt das ein Paket entweder eine komplett ungültige Länge hatte (z.b. nur ein halber Header) oder dass die Länge im Header nicht zur echten Paketlänge gepasst hat. Das könnte eventuell das letzte Paket sein, das gerade halb gesendet wurde, als das Bricklet sich neu gestartet hat. Ich hätte eher die Hoffnung gehabt, dass da deutlich größere Zahlen stehen, dann hätte man in Richtung defektes Kabel o.Ä. gehen können. So ist das ein eher schwaches Indiz. Der steht seit Tagen hier rum und hat bisher maximal für 13 Sekunden die selbe Temperatur gemessen. Es scheint als bräuchte ich dein Dach hier.

Normalerweise nur wenn du es aus deinem Programm heraus machst. Wenn du aber z.b. Stromversorgungsprobleme oder sowas hast kann das auch sporadisch passieren. Die (Koprozessor-)Bricklets warten beim Boot eine Sekunde auf eine Enumerate-Anfrage, wenn die nicht kommt schicken sie von sich aus ein Enumerate mit connection_type=..._CONNECTED. Deshalb meinte ich, dass du bei deinem Enumerate-Handler darauf reagieren solltest.

Ja. Die Bricklet-Firmware generiert nur ein Callback-Paket wenn es voll wird, also wenn 30 bzw. 60 Samples im Ringbuffer des Bricklets liegen. Ich glaube, dass du die 300µs nicht kompensieren musst. Zumindest unter der Prämisse, dass du dir ein Signal auf die Accelerometer geben kannst zur Synchronisierung des Starts: Wenn du das kannst und danach die Callback-Pakete verarbeiten kannst, ohne dass die Ringbuffer der Bricklets sich füllen, dann verlierst du keine Messwerte, das heißt vom Startzeitpunkt aus hast du jeweils eine vollständige Messung. Die Messungen kannst du dann zueinander verschieben, sodass die Startzeitpunkte übereinander liegen und da der Sensor selbst mit einer festen Frequenz misst, ist ein leichter Jitter (also eine Latenzschwankung) auf dem Übertragungsweg egal. Die Übertragung ist ja über den Ringbuffer von der eigentlichen Datenerhebung entkoppelt.

Nicht unbedingt, die Bricklets haben eine Tick-Rate von 1000Hz, es kann also nur ein Paket pro Millisekunde generiert werden. Das funktioniert im Bricklet folgendermaßen: Es hat einen Ringbuffer für 256 16-Bit-Werte, der vom Sensor über einen Interrupt befüllt wird. Wenn der Ringbuffer voll ist, werden die ältesten Werte überschrieben. Das Callback wird im normalen Bricklet-Tick, also jede Millisekunde generiert, dabei wird nachgesehen, ob ein älteres Callback-Paket noch nicht verschickt werden konnte, falls ja wird es nicht überschrieben. Du bekommst also, wenn du nicht mit den 1000 PPS des Bricklets schritthalten kannst, ältere Werte, aber nur soweit wie der Ringbuffer sie noch hat. Im Normalfall hast du noch mehr Buffer im Master Brick und Brick Daemon, aber wenn du die Mikrocontroller-Bindings mit dem HAT benutzt fallen die alle weg. Die Bindings selbst haben nur einen Buffer in den ein Paket passt, da bekommst du also nicht noch mehr Latenz. Ich denke, das musst du dann folgendermaßen machen: Du musst erstmal anhand der Durchsatztests eine Datenrate finden, bei der du die Callbacks alle verarbeitet bekommst. Dann kannst du die Callbacks aktivieren und erstmal alle weglesen, damit die Ringbuffer möglichst leer sind. Danach kannst du die Daten aufzeichnen und dabei durch händisches Schedulen der Callback-Ticks der einzelnen Bricklets (also tf_accelerometer_v2_callback_tick im Gegensatz zu tf_hal_callback_tick) sicherstellen, dass die Messungen nicht auseinanderlaufen. Vermutlich musst du dann noch einen Synchronisierungspunkt erzeugen, indem du einen definierten Impuls auf die Accelerometer gibst. Edit: die 300µs Übertragungszeit musst du nicht kompensieren, das Accelerometer misst währendessen ja weiter.

Das ist für mich ein sehr starker Indikator dafür, dass das Bricklet sich resettet. Mir ist nur unklar warum das so oft passiert und warum du die Enumerations nicht siehst, wenn es wieder kommt.

Aus dem Stehgreif würde ich sagen der Grund ist folgender: Bei 1,95MHz brauchst du im Idealfall ~ 300µs um ein (volles) Paket zu übertragen. Das Callback-Polling funktioniert intern so, dass die Bindings vom Bricklet ein Byte Daten abfragen, wenn das 0 ist, dann hat es gerade keine Daten zu senden. Dann wird das nächste Bricklet gepollt. Wenn du jetzt pech hast und Bricklet X hat sein Paket gerade noch nicht bereit, dann werden erst die drei anderen Bricklets abgefragt, bevor es wieder dran kommt. Das kostet im schlimmsten Fall (wenn alle anderen Bricklets Pakete bereit haben) ~900µs, also fast eine Millisekunde, also ist Bricklet X selbst wenn jetzt alles perfekt läuft aus dem Takt und hängt immer ein Paket hinterher. Ich vermute, dass du, wenn du da noch das letzte Paket rausquetschen willst (und vor allem im Takt bleiben), dann musst du die einzelnen Bricklets von Hand ticken, und zwar so, dass du erst wieder alle vier Bricklets tickst, wenn du alle vier Pakete der letzten Runde hast.

Bevor du mit dem Brick-Viewer drauf gehst frag mal (mit einem Python-Script oder sowas) die Callback-Konfiguration und die aktuelle Temperatur ab (jeweils mit dem Getter, nicht die Temperatur per Callback abfragen).

Nein die Nachricht geht nur an das Bricklet, nicht an den Sensor selbst. Am Code fallen mir spontan zwei Dinge auf: Da deine Callbacks value_has_to_change=true haben, ist nicht so richtig unterscheidbar, ob die Temperatur gleich ist oder das Bricklet nicht mehr kommuniziert. Würde der Rest deiner Software das überstehen, da false mitzugeben? Dann kannst du auch viel strikter das Bricklet resetten, wenn z.b. 10 Sekunden lang kein Wert mehr kam. Du reagierst nur auf IPCON_ENUMERATION_TYPE_AVAILABLE, wenn das Bricklet sich neu startet (warum auch immer) bekommst du aber _CONNECTED. Da musst du auch die Callbacks neu registrieren usw. Hast du in deinem Log die Unhandled enumeration Meldung bekommen?

Moin, Der Fehler war auch wieder, dass du über Minuten zwar Callbacks bekommen hast, aber die immer den selben Wert hatten? (Im Gegensatz zu du hast keine Callbacks mehr bekommen) Was macht dein Daemon mit dem Bricklet wenn ein Enumerate kommt? Nur Callbacks registrieren oder einen Reset oder den Heater an oder sowas? Das allein eine Enumerierung und ein Callback-Neuregistrieren eine eventuell hängendes I2C wiederbelebt ergäbe keinen Sinn, dann müssten wir die These wohl zu Grabe tragen. Gruß, Erik

Für die Nachwelt: Wir haben telefonisch rausgefunden, dass es ein Hardwareproblem mit doppelt belegten GPIOs ist. Im HAT-Schaltplan kann nachgesehen werden, welche GPIOs vom HAT verwendet werden.