rtrbt

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 verhält. Die Erwartungshaltung wäre bei Umgebungsstörungen eher, dass manchmal ein gültiges Paket durchkommen würde, vor allem da ja andere Bricklets am selben Kabel funktionieren. Und wenn jemals ein Paket durchkommt, würde die 0 überschrieben werden und du würdest von da an nur noch diesen Wert bekommen (bis der nächste ankommt)

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 alten 10-Pol-Bricklets verwenden. Außerdem kannst du mit einer Wifi- oder Ethernet-Extension den Brick auch über ein Netzwerk mit dem Pi verbinden. Mit dem HAT Brick hast du gleich 8 Anschlüsse für weitere Bricklets, außerdem eine Stromversorgung an der du flexibler einspeisen kannst, eine Real-Time-Clock (das ist vor allem praktisch wenn du Sensorwerte über eine längere Zeit aufzeichnen willst und nicht immer eine Internetverbindung gegeben ist), und kannst den Pi zeitgesteuert ausschalten. Das HAT Brick haben wir aktuell nicht auf Vorrat, Nachschub ist aber in Produktion und sollte hoffentlich in den nächsten Wochen hier ankommen. Mit dem HAT Zero Brick liegst du preislich am Besten, hast aber keine Zusatzfeatures und es sieht auf dem großen Pi etwas seltsam aus (passt aber). Das Vorgehen bei der Messung und Aufzeichnung hängt davon ab, was deine Anforderungen sind: Die einfachste Variante ist, auf dem Pi eine graphische Oberfläche zu verwenden, dann kannst du neben dem Brick Daemon auch den Brick Viewer installieren und den integrierten Data Logger zur Datenaufzeichnung verwenden. Der Data Logger schreibt dann eine .csv-Datei. Wenn du die Sensordaten per MQTT verschicken willst, kannst du die MQTT Bindings verwenden. Falls dein Plan eher in Richtung SmartHome geht, kannst du dir die openHAB-Bindings ansehen, die sind aber noch in Beta. Wenn du ein eigenes Auswertungsprogramm schreiben willst, kannst du die API Bindings für die unterstützten Programmiersprachen verwenden. Gruß, Erik

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 + "°") logInfo("calc pitch", "roll: " + roll + "°") end (JpE musst du durch die UID von deinem Bricklet ersetzen, wenn du die Standard-Itemnamen verwendest, wenn du eigene Itemnamen benutzt, dann musst du JpE_AccelerationX,Y und Z komplett ersetzen) Die Umrechnung habe ich aus dem Brick-Viewer-Quellcode entnommen, das ist ja aber bis auf Vorzeichen identisch zu dem C-Code den du gefunden hast. Die Regel schreibt den Pitch- und Roll-Wert in das Log, du kannst aber auch ein Item dafür anlegen und die logInfo-Zeile durch Pitch.setState(new DecimalType(pitch)) ersetzen (Pitch mit großem P ist der Item-Name)

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-Threads den heartbeat ausgeführt hätten, dann wäre mein Fix für das Problem das du hattest nicht gut genug gewesen, weil ich ja genau das verhindern muss (sonst starten irgendwann alle 5 ThingHandler-Threads den heartbeat und kein Thread ist frei um ihn tatsächlich abzuarbeiten)

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, passieren, dass ein Timeout passiert, einer der ThingHandler-Threads (davon scheint es 5 zu geben) den Heartbeat vorzieht, ihn ausführt und währenddessen der nächste ThingHandler-Thread auch einen Timeout behandelt. Dann laufen auf einmal zwei Heartbeats parallel. Das ganze kann noch öfter passieren und dann hast du alle 5 ThingHandler-Threads die den Heartbeat ausführen. Das ist an sich kein Problem, aber der Heartbeat funktioniert so, dass er für jeden Brick und jedes Bricklet dem Scheduler einen Task gibt der den Status prüft und dann wartet bis die alle durch sind. Der Scheduler hat jetzt aber keine Threads mehr übrig die diese Tasks ausführen können, weil ja alle bereits im Heartbeat stecken und auf "ihre" Status-Prüf-Tasks warten. Ab dem Punkt hängt dann die ganze Thing-Behandlung. Teste mal bitte die angehangene Version, die sicherstellen sollte, dass nur einer der Timeouts einen Heartbeat auslösen kann. Die Bindings nehmen immer an, dass sie volle Kontrolle über die Bricks und Bricklets haben, d.h. "offiziell supported" ist das nicht. In der Theorie sollte es aber funktionieren, wenn du die Konfiguration der Bricks und Bricklets in beiden openHAB-Instanzen synchron hältst, aber es ist gut möglich, dass dann trotzdem seltsame Effekte entstehen wenn beide openHAB-Instanzen versuchen ein Bricklet umzukonfigurieren o.Ä.. tinkerforge_openhab_bindings_2_0_0.zip

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.