rtrbt

Moin, Du musst die Parameternamen mitgeben, in deinem Fall sollte das wie folgt sein: mosquitto_pub -t tinkerforge/request/industrial_dual_relay_bricklet/FLg/set_selected_value -m '{"channel": 0, "value": true}'

Das Flashen musst du über den Brick Viewer machen, siehe hier: https://www.tinkerforge.com/de/doc/Software/Brickv.html#mit-brick-viewer Der Brick Viewer läd die Firmware auch selbst runter, d.h. du musst nicht über die Downloadseite gehen.

Die Bilder sehen soweit gut aus, da ist also kein offensichtlicher Hardware-Defekt drauf. Welche Bricklets hast du außerdem Barometer noch zum Testen genommen? Nur um sicher zu gehen: Auf dem Master Brick ist die aktuelle Firmware, also die 2.4.10? Wenn nicht, musst du die auf jeden Fall mal aktualisieren, der Master Brick unterstützt erst seit 2.4.4 die 7-Pol-Bricklets. Wenn du einen halbwegs aktuellen Brick Viewer verwendest (> 2.4.0) zeigt er übrigens verfügbare Firmware-Updates an.

Man soll ja nichts versprechen, aber ich bin mal optimistisch und behaupte dieses Jahr noch.

Ist er, du hast aber zwei Probleme. 1. Die Signale zum RED-Brick zu bekommen, aber wenn du mit den GPIOs schon mal was gemacht hast sollte das gehen (Hast du dann Drähte angelötet oder wie kommst du da ran?) 2. Ist die Frage wie du Interrupts bekommst, da musst du vermutlich einen Kernel-Treiber schreiben o.Ä. Das Linux auf dem RED-Brick ist allgemein eher langsam, im User-Space bist du da von "Echtzeit-Fähigkeit" weit weg. Damit du nicht unnütz viel Zeit investierst: Es wird in den nächsten Monaten einen ESP32-basierten Brick geben, an dem neben den Bricklet-Ports noch ein paar GPIOs rausgeführt werden. Wenn dein Anwendungsfall einfach ist dieses Signal zu lesen und noch ein paar Bricklets daneben zu verwenden, kannst du auf den ESP32-Brick warten, dann kannst du deine Implementierung weiterverwenden.

Hm, da wirst du ohne größere Hacks kein Bricklet finden, das das kann. Du müsstest ja nach Nyquist-Shannon mit 2 kHz abtasten. Das höchste was du mit einem Bricklet hinbekommen würdest (und das ist aber eher ineffizient) wäre ein IO4 2.0, damit kannst du theoretisch mit 1 kHz sampeln also 500 Hz messen, aber da bin ich mir nicht sicher, ob das im Bricklet so implementiert ist, das man das tatsächlich schafft. Ich fürchte da bleibt dir nur, einen Mikrocontroller o.Ä. zu nehmen, damit das Signal auszuwerten und das dann irgendwie anders zu kommunizieren. Wenn du Lust auf Firmware-Programmierung hast und im Tinkerforge-Universum bleiben willst, kannst du ein XMC-Breakout Bricklet nehmen. Alternativ: (Da ich gerade deinen Post aus dem Oktober gesehen habe) Wenn du das ganze auf einem ESP32 zum Laufen gebracht hast könntest du auch von da die Informationen per WiFi an den RED-Brick oder Raspberry Pi kommunizieren.

Moin, Wenn du mit dekodieren meinst Duty-Cycle, Frequenz usw. zu bestimmen und die Flanken zu zählen, kannst du das Industrial Counter Bricklet verwenden. Gruß, Erik

Moin, Hot-Plug von Bricklets wird von uns nicht unterstützt, du musst also immer erst den Brick abziehen, dann die Bricklets an/abstecken und dann den Brick wieder anschließen. Das sollte (inoffiziell ;) ) in diesen Fall aber eigentlich funktionieren. Hier der nächste Satz Fragen: Daraus schließe ich mal, dass noch andere Bricklets, eben mit 10-Pol-Port vorhanden sind? Funktionieren die an dem Master Brick? Falls nicht würde ich davon ausgehen, dass der Master Brick defekt ist. Achtung: Die 10-Pol-Bricklets sind nicht mal inoffiziell Hot-Plug-fähig Hat der Master Brick schon mal funktioniert? Hilft es den Master Brick mit dem Brick Viewer neu zu flashen? Wenn möglich hätte ich gerne (hoch-auflösende) Bilder von beiden Seiten des Bricks und der Bricklets, eventuell sieht man da einen Schaden oder ein fehlendes Bauteil. Gruß, Erik

Moin, Nach deiner Beschreibung sollte der Aufbau funktionieren. Du hast da anscheinend ein Hardware-Problem. Der nächste Satz Fragen: Passiert das auch wenn du den RED-Brick außen vor lässt und den Master direkt per USB anschließt? Sind eventuell an den Bricklet-Ports Pins verbogen? Das passiert bei den alten 10-Pol-Kabeln leider relativ einfach. Sähe z.B. dann so aus: Hast du ein anderes Kabel und oder einen anderen Brick mit Bricklet-Ports zur Hand? Falls ja teste die mal Passiert das an allen Ports des Master Bricks oder nur an bestimmmten? Wie lang sind deine Kabel? Hast du eventuell ein Problem mit Störstrahlung? (Das halte ich für unwahrscheinlich, weil wirklich garnichts am Brick anzukommen scheint)

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 = IPConnection() rtc = BrickletRealTimeClockV2(UID_Clock, ipcon) led = BrickletRGBLEDV2(UID_Led, ipcon) ipcon.connect(HOST, PORT) led_green(led) time.sleep(1) led_red(led) rtc.register_callback(rtc.CALLBACK_ALARM, lambda *args: cb_alarm(led, *args)) rtc.set_alarm(-1, -1, -1, -1, -1, -1, 5) time.sleep(10) ipcon.disconnect()

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 hat, Windows stellt die RTC auf localtime, Linux auf UTC) Gruß, Erik

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 ö.Ä. auf den Alarm reagierst und den reboot so auslöst. Das geht mit etwas Bastelei. Du könntest zum Beispiel diesen Aufbau nachbauen und dann auf dem RED-Brick ein Script laufen lassen, der den Monoflop immer setzt.

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