rtrbt

Du musst dir eine Callback-Funktion anlegen, die ausgeführt werden soll (im Beispiel cb_alarm) und die dann registrieren. Eigentlich kannst du als zweiten Parameter für register_callback direkt cb_alarm mitgeben, aber damit du im Callback Zugriff auf die LED hast habe ich das mit dem Lambda reinimprovisiert. (Achtung ungetesteter Code!) Das time.sleep ist nur dafür da, damit dein Programm nicht beendet während du noch auf das Callback wartest. import time def cb_alarm(led, year, month, day, hour, minute, second, centisecond, weekday, timestamp): led_green(led) def main(): ipcon =

Moin, @MiRo Das Problem ist mir neu. Versuche erstmal die Bindings 2.1.26 zu verwenden, ich versuche in den nächsten Tagen mal das hier nachzustellen. @StefanOHAN Dein RTC-Verhalten kommt daher, dass ich die in openHAB immer auf UTC stelle und die Zeitzone dann in openHAB darauf verrechne. Das ist typischerweise das Standardvorgehen bei sowas. Wenn du die Uhr aber händisch im Brick Viewer schon mit Zeitzone stellst, rechnet openHAB dann nochmal die Zeitzone drauf und du hast dieses Offset. (Funfact: Das selbe Problem bekommt man wenn man Windows und Linux per dual-boot auf einem PC h

Moin, Ein paar Ideen dazu: Du kannst mit subprocess.run den reboot-Befehl ausführen. Das darfst du als normaler User aber nicht, da müsstest du davor auf der RED-Brick-Konsole mit sudo su (root-passwort ist tf) EDITOR=nano visudo bzw einfach nur visudo wenn du mit vi umgehen kannst, dir die Erlaubnis geben, reboot ohne Passwort auszuführen, indem du die folgende Zeile einträgst: tf ALL=(ALL) NOPASSWD:/sbin/reboot Danach sollte folgendes klappen: import subprocess subprocess.run(["sudo", "reboot"]) Nur wenn du dann in einem Python-Script ö.Ä. a

Moin, Das kann viele Gründe haben, Ich hätte folgende Fragen dazu: Funktioniert das Voltage/Current-Bricklet wenn du es direkt an den Master Brick anschließt? Was passiert, wenn du das Isolator-Bricklet ohne das Voltage/Current an den Master anschließt? Hast du eventuell den Isolator falsch herum eingebaut? Darauf gibt es eine Beschriftung, welche Seite zum Brick und welche zum Bricklet soll. Machen die LEDs auf den Bricklets irgendetwas? Gruß, Erik

Moin, In Beta 7 war noch ein Bug, der dazu führte, dass Callbacks nach ~ 35 Minuten (2^31 Mikrosekunden) nicht mehr funktionierten. Der ist in Beta 8 gefixt, sonst gab es keine Änderungen

Das stimmt, das heißt das Kabel funktioniert wohl. Ich habe gerade nochmal einen Blick in die Firmware geworfen. Das du immer 0 zurückbekommst kann an folgendem liegen: Der Sensor des Bricklets wird per I²C ausgelesen, und zwar vom Master Brick über das ganze Kabel. Wenn du jetzt eine störende Umgebung hast, kann es passieren, dass nie gültige Daten vom Brick gelesen werden (Die Daten sind mit einer CRC versehen mit der der Brick die Daten prüfen kann). 0 ist der Default-Wert, der dann nie geändert wird, weil nie gültige Daten ankommen. Es wundert mich aber, dass sich das bei dir so

Moin, Die Step-Datei haben wir nicht, aber die Maße für den Motor findest du im Datenblatt.

Moin, Es gibt zwei Varianten wie du das Bricklet mit dem Pi verbinden kannst: Du kannst entweder einen Master Brick + USB-Kabel und ein 7-Pol-10-Pol Bricklet-Kabel (Länge nach Wahl) verwenden und den Master Brick per USB an den Pi anschließen. Alternativ kannst du ein HAT Brick oder HAT Zero Brick + das jeweilige Befestigungskit und ein 7-Pol-7-Pol Bricklet-Kabel verwenden. Welche Variante die geschicktere ist, hängt davon ab was du noch damit vor hast: Mit dem Master Brick kannst du einen Stapel bauen, also weitere Bricks aufstecken. Außerdem kannst du an einem Master auch die alte

Moin, Wenn du dir Items für die drei Beschleunigungswerte anlegst kannst du dann diese Rule benutzen: import java.lang.Math rule "calc pitch" when Item JpE_AccelerationX changed then val x = (JpE_AccelerationX.state as Number).doubleValue val y = (JpE_AccelerationY.state as Number).doubleValue val z = (JpE_AccelerationZ.state as Number).doubleValue val pitch = Math.round(Math.atan(x / Math.sqrt(y * y + z * z)) * 180 / Math.PI) val roll = Math.round(Math.atan(y / Math.sqrt(x * x + z * z)) * 180 / Math.PI) logInfo("calc pitch", "pitch: " + pitch + "°")

Moin, Beta 7 ist jetzt im Post oben. Die Bindings sind jetzt in einem Zustand den ich als "fertig" bezeichnen würde, die Beta lasse ich aber noch bis zum Release der Hardware offen. Ich freue mich wie immer über jedes Feedback, vorallem zur Dokumentation. Gruß, Erik

Bau im Zweifelsfall das was näher an deinem Produktivsystem sein wird. Ich habe hier auch noch einige Testaufbauten zu testen.

und Genau die beiden meine ich. Ich war wie gesagt erst verwirrt, weil in der zweiten Datei zwei der ThingHandler-Threads gerade dabei sind einen heartbeat auszuführen, hatte dann aber gesehen, dass es auch zwei Disconnect-Prober-Threads gibt (die werden jeweils von der IP-Connection zum Brick Daemon erzeugt). Daraus konnte ich dann schließen, dass du mindestens zwei Brick Daemons in openHAB hinzugefügt hast, weil zwei IP-Connections laufen und es deshalb nicht schlimm ist, dass auch zwei heartbeats gleichzeitig laufen. Wenn aus einem Brick Daemon heraus zwei ThingHandler-Thr

Moin, Das sieht soweit gut aus. In Nr2 sind die ThingHandler mit den Erreichbarkeits-Checks beschäftigt. Da war ich erst verwirrt, weil zwei Threads den Heartbeat ausführen, aber du hast ja mehrere Verbindungen zu Brick Daemons, deshalb ergibt das Sinn. Danke nochmal! Erik

Moin, Interessant wäre direkt nach dem Verbindungsverlust. Wie üblich danke für die Tests! Erik

Das klingt doch gut. Dann baue ich das in die nächste "offizielle" Beta ein. Falls du in nächster Zeit nochmal mitbekommst, dass der Master Brick gerade wieder reconnected, wäre ich nochmal an der shell:threads Ausgabe interessiert. Das ist nicht kritisch aber eventuell sehe ich da noch ein paar interessante Effekte.

Moin, Die shell:threads-Ausgabe ist sehr interessant, anscheinend passiert da folgendes: Ich habe einen Heartbeat-Mechanismus der alle 90 Sekunden prüft ob die Bricks und Bricklets noch erreichbar sind. Falls ein Timeout auftritt (z.b. weil dein WiFi-Stapel weg ist) ziehe ich den nächsten Heartbeat vor, damit er sofort prüft, was alles noch da ist. Das Vorziehen funktioniert aber so, dass ich den regelmäßigen Heartbeat abbreche und stattdessen dem Scheduler einen neuen gebe, der sofort los läuft (und dann wieder 90 Sekunden später). Jetzt kann es, wenn das Timing schlecht ist, p

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 geflut

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 i

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

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äus