rtrbt

Hi, Als erste Frage: Sind das Voltage/Current 1.0 oder 2.0?

Moin, Das ist normal und erwartet, openHAB fragt alle existierenden ChannelTypeProvider nach allen ChannelTypes bis einer sagt "den kenne ich". Dabei wird nicht darauf geachtet, welches Binding für welche ChannelTypen ist, deshalb fragt openHAB meinen Provider ob er den ChannelType kennt, was er nicht tut. Daher kommt auch die Log-Flut: Im events.log z.B. ab 2020-09-27 09:00:00 siehst du, dass die Hue-Lampen andauernd offline und online gehen. Anscheinend werden die Channel-Typen jedes Mal wenn eine Lampe wiederkommt neu angelegt und landen dann aber auch bei meinem ChannelTypeProvider, der dann meckert weil er die Typen nicht kennt. Ich muss mal einbauen, dass er auch die Debug-Meldung nur ausgibt wenn der ChannelType mit "tinkerforge:" anfängt, sorry dass ich dir das Log so zumülle. Das ist denke ich der interessante Teil. In deinem Brick Viewer Screenshot sehe ich Timeouts, werden das mit der Zeit mehr wenn du in dem Zustand bist? Fehlt in der example_interrupt-Ausgabe nicht eher die steigende Flanke? Ich sehe erst 0x44 und später 0xc4 0x44, da beim ersten Mal fehlt die Ausgabe die das höchste Bit gesetzt hat. Hat sich später wenn du die 0xc4 wieder bekomsmt das Problem von alleine gelöst oder hast du da das Callback neu konfiguriert o.Ä.? Im Log selbst habe ich im Fehlerfall nichts relevantes gefunden, den Spam vom ChannelTypeProvider konnte man zum Glück gut per Regex rauswerfen. Die Threadlisten usw. sehen soweit okay aus.

No you can't stack more than one RS485-Extension on a stack. However you can build a bus roughly like this: IMU Stack 1 Single Receiver Stack (Master + IMU + RS485) <---------->RS485(1) IMU Stack 2 | Master<---USB---->PC (Master + IMU + RS485) <------ IMU Stack 3 | (Master + IMU + RS485) <------ IMU Stack 4 | (Master + IMU + RS485) <------ IMU Stack 5 | (Master + IMU + RS485) <------ IMU Stack 6 | (Master + IMU + RS485) <------ This is documented here: https://www.tinkerforge.com/en/doc/Hardware/Master_Extensions/RS485_Extension.html#rs485-bus-assembly

I just meant, that you need to configure each RS485 Extension only once, as the configuration is saved in the extension's memory. For this you don't have to build the bus already, but can instead just plug in a stack like this: RS485 Master<--USB-->PC Then configure the RS485 Extension, unplug the stack, swap the extension and so on.

Moin, Du musst da an einigen Stellen vorsichtig sein: Die ±2% und ±0.2°C Angaben sind "typisch", was sich auf die Aussage aus dem Datenblatt bezieht. Auf Seite 7 siehst du die "Wahrheit". Die ±2% gehen da nur von 20% bis 60%, bei deinen ~70% bist du eher bei ±3%. Die MIN und MAX-Werte liegen weiter auseinander, da die vermutlich über deine ganze Kurve gehen, nach Augenmaß scheint es aber keinen Zeitpunkt zu geben, wo die ±3% tatsächlich gerissen werden. Ich passe das in der Dokumentation mal an, damit klarer ist, was mit typisch gemeint ist. Die ADC-Kalibrierung bringt dir nichts, das ist ein Feature, das sich nur auf sehr alte Bricklets auswirkt, die noch direkt vom Master Brick ausgelesen wurden. Die neueren Bricklets (mit 7-Pol-Stecker) haben alle einen eigenen Koprozessor und kommunizieren digital mit dem Master Brick. Im Fall des Humidity Bricklets 2.0 ist es sogar so, dass der ADC direkt im Sensor-Chip sitzt. Du kannst die Bricklets selbst nicht nachkalibrieren, aber da, wie in deinem Graph zu sehen ist, das ja nur ein konstantes Offset zwischen den Bricklets ist, kannst du diesen auch hinterher, also in deinem Programm ausbessern. Falls du keinen anderen Sensor zum Vergleichen zur Hand hast: Ich würde erwarten, dass der "echte" Wert Nahe der roten/blauen Kurve liegt. Wenn du also bei dem Bricklet mit der grünen Kurve immer 2 Prozentpunkte addierst und bei dem mit der gelben Kurve immer 3 abziehst, solltest du nahe der Wahrheit sein. Bei der Temperatur kannst du das ähnlich machen. Noch ein Tipp um die Messung genauer zu machen: Die Bricklets leiden unter einer Selbsterwärmung, wenn die Messfrequenz zu hoch ist. Je nachdem wie träge deine Umgebung ist, kann es sein, dass du deutlich seltener messen musst, dann lohnt es sich die set_samples_per_second-Funktion zu verwenden. Ich vermute, dass der kurze starke Temperaturanstieg, den du in den ersten ~200 Sekunden siehst, dieser Effekt ist.

Moin, Ich habe dazu folgenden Satz Fragen: Was ist der komplette Aufbau? Also wie viele Stapel, sind die per USB, Ethernet oder Wifi angeschlossen, usw. Mach am besten mal einen Brick Viewer Screenshot Die anderen Bricklets, die noch funktionieren sind am selben Stapel? Siehst du etwas interessantes, wenn du das Logging hochdrehst? (mit log:set TRACE org.openhab.tinkerforge, dann bekommst du potentiell viel Ausgabe, aber lass das mal so laufen bis das Problem wieder auftritt) Durch deine Rule solltest du den Zeitpunkt, wann es kaputt ist ja finden, da würden mich die Log-Zeilen ab ~ 3 Minuten davor interessieren. Probiere außerdem mal folgende Dinge, wenn das System gerade in dem kaputten Zustand ist: Die Ausgabe von shell:threads (in der openHAB-Konsole) könnte interessant sein. Was passiert, wenn du eine Aktualisierung mit smarthome:send Item_Name REFRESH erzwingst? Siehst du dann den neuen Zustand? Wenn du ein C-Programm nimmst, das sich auf das Input-Callback des IO16v2 registriert, aber das Aktivieren des Callbacks weglässt, kommen dann Callbacks an? (Du kannst z.b. das Interrupt-Beispiel nehmen, aber musst die Zeile mit io16_v2_set_input_value_callback_configuration weglassen): Ich gehe im Moment davon aus, dass die Callback-Aktivierung aus irgendeinem Grund verloren gegangen ist, wenn das Testprogramm jetzt die Callbacks wieder aktiviert, sehen wir nicht mehr ob das das Problem war.

Hi, One receiver stack should be enough. You can assign a unique slave address to each of the IMU stacks via Brick Viewer, as per this guide. For the configuration, connect the IMU stacks via USB, configure them and then build the RS485 bus, the configuration is saved persistently on the extensions. This also means that you can plug the RS485 extensions on the receiver stack (one after another; a stack with two RS485 extensions will not work) and configure them there.

Hi, The RS485 Extension only works with a Master Brick (that's why it's called Master Extension ;) ). So at least two Master Bricks, two RS485 Extensions and one IMU Brick are required. The Master Bricks have to be bottom most in the stack, for example RS485<---------->RS485 IMU Master<-->PC Master should work.

Currently the Bindings only work with PaperUI. I've tried implementing support for the text files, but using them causes strange behaviour where things and channels are duplicated. I'm not sure if this can be fixed easily, as I'm assuming this is a problem with the dynamic thing and channel creation.

Hi, The bindings are still in beta, but everything should be working, there is only some polishing missing, but I've been occupied with other projects for the last few months. There will be some changes to the modeling of some Bricklets, for example input pins of the IO Bricklets are currently OnOffTypes but will be changed to OpenClosedTypes. We actually have documentation available here: https://www.tinkerforge.com/en/doc/Software/API_Bindings_openHAB.html#api-bindings-openhab

Moin, Schlecht, dieses Jahr sind wir gut ausgelastet. Leider steht Julia auf der Liste der Sprachen, für die man Unterstützung hinzufügen könnte immer noch weit unten auf der Liste. Julia kann aber Bibliotheken aus diversen anderen Sprachen importieren, ich habe das (wegen der einfachen API) gerade mit den Python-Bindings ausprobiert, folgendes funktioniert bei mir: using PyCall ip_connection = pyimport("tinkerforge.ip_connection") bricklet_gps_v2 = pyimport("tinkerforge.bricklet_gps_v2") ipcon = ip_connection.IPConnection() ipcon.connect("localhost", 4223) gps = bricklet_gps_v2.BrickletGPSV2("Pvy", ipcon) println(gps.get_coordinates()) ipcon.disconnect() Wenn es eigene Julia-Bindings gäbe, würden die vermutlich nicht groß anders aussehen. Gruß, Erik

Moin, (Disclaimer: Bin kein JavaScript-Experte) Das Problem ist sogar noch etwas komplizierter, da du ja nicht weißt, wie viele Bricks/Bricklets vorhanden sind, das heißt rein technisch weißt du nicht, wann du fertig bist mit dem Warten auf die enumerate-Callbacks. Du kannst aber so Kriterien wie "ich weiß es sind genau X Bricks/Bricklets" oder "wenn nach 0.5 Sekunden kein neues Callback kam bin ich fertig" oder einfach "Ich warte eine Sekunde auf Callbacks" o.Ä. verwenden, das ist typischerweise gut genug. Ein Ansatz der dein Problem löst wäre, wenn das Auslösen mit .enumerate() und die Callback-Verarbeitung zwar nebenläufig ist, du aber mit await darauf warten kannst. Es würde sich also anbieten, wenn du eine Funktion schreibst, die das Array anlegt, das Callback registriert, enumerate auslöst, nach deinen Kriterien auf Antworten wartet und dann das Array zurückgibt. Diese Funktion machst du async, dann kannst du im Hauptprogramm das ganze anschieben und wenn du das Ergebnis brauchst es per await abholen. Gruß, Erik

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