rtrbt

Moin, Nein, das ist mir absolut unklar. Die Zeitsteuerung läuft über einen Scheduler von openHAB, ich würde aber nicht erwarten, dass der das Problem ist. Teste mal folgendes: Aktiviere mal das Trace-Logging für alle involvierten Bindings, also mindestens Astro und Tinkerforge. Den Paketnamen des Astrobindings bekommst du über list -s | grep binding in der Karaf-Konsole raus. Dann kannst du das Trace-Logging mit log:set TRACE [binding-name] aktivieren. (Das kennst du ja schon für das Tinkerforge-Binding ) Ich hoffe, dass du dann nicht so sehr mit Ausgabe geflutet wirst, dass man das nicht die paar Stunden laufen lassen kann. Wenn du dann in dem Zustand bist, dass ein anderes Binding hängt, würde mich das Log interessieren (also openhab.log aus userdata/logs/), im Idealfall machst du das vor dem ganzen Test einmal leer. Außerdem kannst du, wenn das ganze hängt, in der Karaf-Konsole shell:threads ausführen und die Ausgabe mit schicken. Der Befehl gibt aus, was alle openHAB-Threads gerade tun. Eine Idee, was dein Problem ist hätte ich noch: Wenn du Regeln hast, die in bestimmten Umständen lange blockieren (eventuell auch nur bei seltsamen Zuständen wie dieser Kanaloptimierungsgeschichte der Fritz-Box), kannst du damit eventuell Teile von openHAB blockieren. Siehe hier. Falls wir das Problem bis dahin nicht raushaben, werde ich bei nächster Gelegenheit mal einen vergleichbaren Aufbau hier hinstellen, vielleicht bekomme ich das ja reproduziert. Ich habe hier zum testen der Bindings immer nur ein lokales openHAB auf dem PC laufen, es gibt aber ein paar Systeme von denen ich weiß, die seit Monaten problemlos laufen, das von meinem Kollegen auch mit dem Astro-Binding. Er hat seinen Stapel aber über Ethernet angebunden. Das ist im Moment noch so gewollt, die Bindings generieren für alle boolschen Channel SwitchTypes, die Contacts für boolsche Channel die nur lesbar sind kommen vermutlich mit der nächsten Beta.

Moin, Das stimmt, mit den neuen Bindings musst du außer den Rules selbst keine Textdateien mehr schreiben. Du kannst prinzipiell alles was du in .items, .cfg usw. schreiben würdest über die PaperUI machen. (Auf meiner TODO-Liste bevor die Bindings "fertig" sind steht aber noch rauszufinden, ob und wenn ja wie man die Variante des Konfigurierens über die Dateien unterstützen kann) Wenn du die Dimension weglässt sollte das nur den Effekt haben, dass du in der PaperUI oder einer eigenen Sitemap eben nur noch den Wert ohne Einheit bekommst. Du kannst aber alternativ den Item-Wert in deiner Rule in einen DecimalType konvertieren, dann sollte es auch mit Dimension gehen. Sieh dir mal den openHAB-Beta-Thread, insbesondere diesen Post an, da ist eine ziemlich lange Rule an deren Anfang du siehst, wie man an den Zustand eines Items als DecimalType kommt. Wenn du aus dem Beta-Thread noch mehr Informationen holst, musst du aber aufpassen, dass du die aktuellen Namen für die Geräte, Funktionen usw. benutzt, das musste ich leider ein paar mal Ändern, damit alles funktioniert.

Moin, Damit meinst du sowohl die Java- als auch die openHAB-Bindings aus diesem Thread? Wenn nicht, ignoriere den Rest des Posts Davon darfst du dich nicht verwirren lassen, die Dokumentation auf openHAB ist für das alte Binding. Die Dokumentation für die neuen Bindings ist hier. Die ganzen openHAB-Textdateien solltest du damit nicht brauchen, die Bindings kannst du komplett über die PaperUI verwenden. Die Rulesyntax ist leider etwas kompliziert, hier zwei Beispiele für das Industrial Dual Relay: Das ist die Variante, wenn du die Actions benutzt. Damit sprichst du im Endeffekt direkt mit den Java-Bindings, die openHAB-Bindings reichen nur durch. Damit hast du den Vorteil, dass du fast alle Funktionen der Bricks/Bricklets benutzen kannst (alle Actions), es ist aber etwas komplizierter. ("No7" musst du durch die UID deines Relays ersetzen, das ist die UID von dem was ich gerade auf dem Tisch liegen hatte) rule "Relay example" when System started then val relayActions = getActions("tinkerforge", "tinkerforge:brickletindustrialdualrelay:No7") relayActions.brickletIndustrialDualRelaySetMonoflop(0, true, 1500) val relayState = relayActions.brickletIndustrialDualRelayGetValue() logInfo("Example", "Channel 0: " + relayState.get("channel0") + " Channel 1: " + relayState.get("channel1")) end Alternativ kannst du auch Items für die Relays und deren Monoflops erstellen und die dann direkt benutzen. Das hat den Vorteil, dass die Rules deutlich einfacher werden, du kannst aber nur tun, was als Channel unterstützt wird. Hier musst du noch die Item-Namen, also No7_Relay0 und No7_MonoflopRelay1 durch deine Item-Namen ersetzen. rule "Relay example 2" when System started then No7_Relay0.send(OnOffType.ON) No7_MonoflopRelay1.sendCommand("blah") end Die Channel-Dokumentation schreibt, dass der Monoflop-Channel Commands verwendet, deshalb musst du sendCommand anstelle von send benutzen. Als Command-Liste ist "Accepts any string" angegeben. Das heißt, dass es nur ein Kommando gibt, in diesem Fall "löse das konfigurierte Monoflop aus" (die Konfiguration kannst du über die PaperUI ändern), und jeder String den du schickst dieses Kommando auslöst. Gruß, Erik

Moin, Am einfachsten ist es, wenn du dir eine weitere SD-Karte nimmst, darauf das Raspberry Pi OS frisch runterlädst (das Image selbst hat noch den 4.19er Kernel), dann Brick Daemon installierst und mit Brick Viewer die HAT-Firmware aktualisierst. Danach sollte es auch mit dem 5.4er Kernel wieder funktionieren.

Ja, die ist es. Die kannst du selbst nachlöten, das ist aber etwas anstrengend. Alternativ kannst du die IMU auch zurückschicken und wir tauschen sie dir aus. Dann müsstest du mal eine Mail an nicolai@tinkerforge.com schreiben.

Getting a concrete accuracy value is not easy, as the IMU Brick uses multiple sensors and a data fusion algorithm to generate it's measurements. We only specify a measurement resolution of 0.0625°, but no measurement accuracy. You can try to find more information in the sensor's datasheet. If you only want to measure the slope, you could also use an Accelerometer Bricklet, but then have to calculate the slope from the acceleration values yourself.

Moin, Taucht die IMU im Gerätemanager im Abschnitt für serielle Schnittstellen auf? (Der Name hängt davon ab welchen Treiber Windows läd, sollte etwas mit Bossa, Atmel oder SAM im Namen sein) Den Symptomen nach könnte es auch sein, dass dir das im Bild rot markierte Bauteil abgerissen ist. In der Hardware-Dokumentation gibt es noch ein paar Bilder aus verschiedenen Winkeln.

Repeater machen da gerne seltsame Probleme, gut möglich, dass das das Problem ist. Du müsstest dafür die 5V-Ader des Kabels auftrennen (die entspricht im Bild dem roten Draht) und das Relay dazwischen hängen, am einfachsten ist es, wenn du einen dieser Stecker nimmst, die beim Industrial Dual Relay mitgeliefert sind, dann musst du theoretisch nicht mal löten, sondern kannst die beiden Enden der Ader in den Stecker stecken.

Kannst du einen Graph des Tagesverlaufs, oder am besten über 48 Stunden aus den letzten Tagen anhängen? Eventuell ist auch ein 48-Stunden-Graph aus dem Mai interessant, falls du die Daten alle noch hast. Ich würde dann hier einen ähnlichen Aufbau hinstellen um Vergleichswerte zu bekommen. Benutzt du die PT100-Werte um den Wert des Bricklets nochmal zu kompensieren? Das CO2-Bricklet misst selbst die Temperatur und Luftfeuchte. Du darfst also nicht die ganze Zeit set_temperature_offset mit dem Wert des PT100 füttern, die Funktion ist dafür da, dass du den Aufbau in ein Gehäuse baust, die Aufheizung im Gehäuse einmal misst und darüber kompensierst. Wenn das dein Problem ist, wäre sehr logisch.

Moin, Prinzipiell sollte das natürlich nicht passieren. Ist das Problem, dass dein Gerät, dass mit der Wifi-Extension verbunden sein sollte, nicht mal eine Wifi-Verbindung hinbekommt oder kannst du dich mit dem Wifi verbinden, kannst dann aber keine TCP-Verbindung aufbauen? (Das kannst du z.b. mit einem Ping testen) Die Wifi-Extension kann prinzipiell nur 15 Verbindungen aufbauen, je nachdem wie dein Programm funktioniert und ob du mit deinem Gerät immer mal die Empfangsreichweite verlässt, kann es passieren, dass du Verbindungen leakst, also sie auf deiner Seite geschlossen sind, die Extension das aber nie mitbekommt. Die Verbindung bleibt dann für immer "offen" und du kannst nur noch eine weniger öffnen. Wenn das eine Weile so geht, wäre es durchaus möglich, dass alle 15 Verbindungen geleakt sind. Da Wifi-Probleme typischerweise schwer zu debuggen sind kannst du versuchen das einfach zu umgehen, aber sowas: kann der Master Brick nicht. Du kannst aber alternativ folgendes machen: Wenn du die Stromversorgung (Da du eine WiFi-Extension benutzt nehme ich an, dass du eine Step-Down-Power-Supply benutzt, ansonsten musst du dir ein USB-Kabel schlachten) über ein Industrial Dual Relay Bricklet führst, kannst du den Stapel, wenn die WiFi-Verbindung weg ist, resetten Der Trick an dem Aufbau ist, das die Stromversorgung über den Relay-Pfad geht, der bei nicht angezogenem Relay durchgeschaltet ist. Das Relay ist wenn das Bricklet startet nicht angezogen. Du kannst dann mit der API des Bricklets einen Monoflop auf "aus" über z.B. 5 Minuten starten, das Relay bleibt dann die nächsten 5 Minuten auch nicht angezogen. Wenn die Zeit abläuft, zieht das Bricklet das Relay an, der Stapel verliert die Stromversorgung, der Energieverbrauch des Relays zieht den Reststrom, und lässt dann wieder los. Dann ist die Stromversorgung wiederhergestellt und der Stapel startet neu. Du kannst dann den 5-Minuten-Monoflop jede Minute neu setzen, dann verlängert sich der Monoflop um eine Minute, du hast dann also einen simplen Watchdog, der anspringt, wenn 5 Minuten lang kein Monoflop-Befehl ankam, was, wenn dein Programm durch läuft nur der Fall ist, wenn die Verbindung abreißt. Die ganzen Zeiten usw. kannst du dir natürlich auf deinen Anwendungsfall anpassen.

Das klingt gut. Damit meinst du einen Restart des Raspberry Pis? Es sollte in /etc/ die Datei tinkerforge_mqtt.cmdline geben. Darin ist Zeile 98 ein auskommentierter init-file-Parameter. Wenn du also #--init-file INIT_FILE durch --init-file /home/dein_username/dein_initfile.txt ersetzt, sollten die Bindings das init-file beim Start lesen. Prinzipiell funktioniert die .cmdline-Datei genauso wie die Kommandozeilenparameter, das heißt wenn du noch andere Parameter hast, die du beim händischen Starten mitgibst, kannst du sie auch da eintragen. Das soll dir nur mitteilen, dass sich die Bindings beenden. Beim Start der Bindings kommt eine äquivalente Nachricht, nur auf dem /restart anstelle von dem /shutdown Topic.

Nein, das bringt dich vermutlich auch nicht weiter. Mach mal folgendes: Sicherstellen dass der Brick Daemon läuft: systemctl status brickd ausführen, dann muss Active: active (running) kommen Mit dem Brick Viewer verbinden und prüfen, ob das Outdoor Weather Bricklet auftaucht. (Schreib dir mal gleich die UID auf) Die MQTT-Bindings hast du ja schon installiert. Im Anhang ist ein init-file, das funktionieren sollte. Leg dir das mal in dein Home-Verzeichnis. Du musst noch die UID ändern von Fax auf die von deinem Bricklet (vier Mal). Die Bindings kannst du dann mit tinkerforge_mqtt --init-file ~/mqtt_outdoor_weather_init.txt --debug starten. Dabei darauf achten, dass folgende Zeilen ausgegeben werden: <DEBUG> MQTT bindings: Connected to mqtt broker. <DEBUG> MQTT bindings: Connected to brickd at ... In Node-RED kannst du dann mit dem Flow den ich angehängten habe die Daten auslesen. Du musst aber folgende Dinge im Flow ändern: Die Broker-IP anpassen, das geht durch Doppelklick auf den MQTT-Knoten (mit tinkerforge/callback/...), dann bei Server auf den Editieren-Button mit dem Stift und die IP ändern Im Topic des MQTT-Knotens selbst musst du auch Fax durch deine UID ersetzen Wenn dabei irgendetwas schief geht, schicke mal die Ausgabe von dem tinkerforge_mqtt-Befehl aus 2.3. mqtt_outdoor_weather_init.txt flows.json

Moin, Ich habe das hier gerade getestet und es funktioniert. Ist das Quad Relay ein 1.0? Falls ja (oder du ein anderes 10-Pol-Bricklet zur Hand hast), häng das mal an das 2m-Kabel. Alternativ kannst du das auch mit einem Multimeter durchmessen. Das Verhalten des Temperatur IR-Bricklets könnte man erklären, wenn das Kabel einen Defekt an Pin 7 hat. Wenn das das Problem ist, kann das Quad Relay, wenn du es an das 2m-Kabel hängst eins der Relays nicht mehr schalten.

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.