rtrbt

Moin, Wie misst du das genau? Also in welchen Intervallen und wird der Graph erzeugt? Von der Anzahl der Messwerte sind das ja nicht Tagesmittel sondern eventuell alle 12 Stunden ein Messwert? Eventuell hast du Pech und es werden in den vergangenen Monaten eher niedrige Messwerte geplottet und später eher hohe. Am besten siehst du dir mal den Verlauf über 1 bis 3 Tage aus dem Mai und von jetzt an, da kann man belastbarere Aussagen machen. Vielleicht siehst du auch Effekte von Corona? Prinzipiell sind >600 ppm schon sehr hoch, mir ist aber spontan nicht klar, ob man "normale" Atmosphärenmessungen mit deinen vergleichen kann, das hängt ja stark davon ab wie das CO2 sich höhenmäßig verteilt.

Moin, Hatte ganz vergessen dir zu schreiben. Die Input-Channels auf Contact umzubiegen scheint prinzipiell zu funktionieren, das muss ich jetzt noch dem Generator für alle entsprechenden Bricklets beibringen. Mache ich im Zuge des großen "alle Konfigurationen der Bricklets durchgehen und dabei die deutsche Doku schreiben" gleich mit, wenn ich denn mal dazu komme. Mir ist aber aufgefallen, dass Contacts anscheinend in der PaperUI-Übersicht den aktuellen Zustand nicht anzeigen. Bezüglich der Kühlung: Du kannst dir ja einen openHAB-Channel für die CPU-Temperatur bauen, dafür habe ich spontan diese Anleitung gefunden. Ich würde aber erwarten, dass es mit dem Kühlkörper keine Probleme gibt.

Moin, Ich gehe mal die ganzen Posts durch Es reicht wenn du eine Variante davon machst, also entweder das Paket installieren oder die tinkerforge_mqtt händisch kopieren. Das ist etwas fies, die Beispiele, die wir auf der Seite angeben sind nicht das Format, das du als init-file benutzen kannst. Die musst du eher als Anleitung verstehen, was zu tun ist, die Beispiele geben ja auch z.b. an auf welche Topics du subscriben musst, das ergäbe in einem init-file aber keinen Sinn. Das ist interessant, ich würde erwarten, dass MQTT.fx wenn du keinen Payload angibst auch einen leeren String schickt, anscheinend kam da aber etwas anderes. Passiert das auch, wenn du als Payload {} verschickst? Da fehlen die Root-Rechte, das sollte mit sudo brickd nicht passieren. Wenn systemctl status brickd aber Active: active (running) liefert, brauchst du das nicht, der Brick Daemon läuft dann schon als Service. Hast du da im Topic /register/ anstelle von /request/ benutzt? Das sieht wieder nach kaputtem Payload aus. Ich teste bei mir mal mit MQTT.fx, eventuell liegt da das Problem.

Moin, Was passiert mit dem Binding genau, wenn du den Master resettest? Starte die Bindings am besten mal mit --debug, dann sieht man eventuell mehr. Benutzt du für die Temperaturabfrage Callbacks oder Getter?

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.

Hm das stimmt, ich hatte bei mir den core_freq-Eintrag drin. Ich schreibe mir mal auf die Liste, dass ich die core_freq zur Laufzeit abfrage und die SPI-Clock entsprechend kompensiere. Das klappt aber nur, wenn force_turbo=1 ist, sonst schwankt die core_freq zur Laufzeit und ich bekomme nie eine stabile Clock. Damit die Tests sinnvoll sind habe ich eine neue Speicherkarte mit dem aktuellen Raspberry Pi OS (vom 27.05., Kernel 4.9.118) genommen. Wenn die core_freq nicht gesetzt wird, ist sie auf 400 Mhz, dann führt meine Einstellung auf 1,4 MHz dazu, dass in Wirklichkeit 1,4/250*400 = 2,24 MHz anliegen, deshalb klappt die Kommunikation nicht Ich komme mit core_freq=250 auf ~1130 PPS mit dem alten hal_linux (1.4MHz), mit dem hal_raspberry_pi sind die Werte so wie ich sie dir geschrieben hatte, also 2000 bzw. 2650. Mit dem Kernel 5.4.51+ #1330 (den ich gerade über rpi-update geholt habe) sind die hal_raspberry_pi-Zahlen identisch, mit dem hal_linux komme ich gerade auf 990 PPS (1,4 MHz) bzw. 1170 PPS (1.95 MHz). Warum das bei dir nicht sauber funktioniert, wenn du die core_freq setzt ist mir noch unklar.

Im Demo-Programm sehe ich spontan, dass du den hal_raspberry_pi includest, aber noch tf_hal_linux_init aufrufst. Das musst du mal anpassen und vermutlich auch dein Makefile.

Das hängt vermutlich davon ab wie du die Callbacks tickst. Was benutzt du dafür im Moment? Abgesehen davon ist das vermutlich ein Effekt, den du nur beobachten kannst, weil das Programm praktisch permanent überlastet ist. Wenn du es schaffst alle Pakete die die Bricklets erzeugen zu verarbeiten, sollte das nicht mehr auftreten. Die Bricklets generieren Pakete ja mit einer festen Frequenz.

Der neue HAL ist jetzt als hal_raspberry_pi in Beta 5 enthalten. Da es jetzt etwas offizieller ist, habe ich den HAL umbenannt und den unnützen spidev-Parameter entfernt.

Dann starte den Brick Daemon mal von Hand mit "sudo brickd".

Poste mal das aktuelle brickd.log.