rtrbt

Bezüglich der Taktfrequenzen: Brick Daemon bis einschließlich 2.4.2 erwartet eine core-Clock von 250 MHz (die die du mit vcgencmd measure_clock core ausgelesen hast). Beim Pi Zero kannst du die Frequenz mit core_freq=250 in /boot/config.txt festlegen. Die Umbauarbeiten in 2.4.2 und 2.4.3 sind genau dafür da solche Probleme zu umgehen, der Pi skaliert nämlich die SPI-Clock mit der core_freq, d.h. wenn er auf 400 MHz läuft, läuft SPI so schnell, dass die Bricklets das nicht mehr verstehen. Das liegt vermutlich daran, dass der Brick Daemon für den Pi auch Stacks per USB unterstützt. Das ist keine spezielle gestrippte Version, die nur SPI kann. Das ist interessant, dazu muss ich @photron mal befragen. Das sollte kein Problem sein, du hast ja ein HAT Zero, das hat sowieso keine RTC an Bord. Nein, weil der Kernel nicht genug CS-Pins unterstützt. Meines Wissens nur zwei. Ab Brick Daemon 2.4.2 umgehen wir sowieso das ganze Kernel-Interface und sprechen direkt mit dem BCM2835.

Das geht prinzipiell, es gibt aber (noch) keine Micropython-Bindings für die Bricklets, die du an den ESP-Brick anschließen kannst. Ich habe noch auf meiner TODO-Liste stehen, zu untersuchen ob wir Micropython-Bindings anbieten wollen, bzw. wie viel Aufwand das wäre die zu generieren.

Das kommt ganz auf deine Paranoia an ;) Ich habe bei den openHAB-Bindings das gleiche Problem und bin da relativ aggressiv, lies ich konfiguriere immer alles neu, wenn ich mir nicht 100%ig sicher bin, dass alles passt. Ich versuche mal alle Komponenten aufzulisten, bei denen was schief gehen kann, frag nochmal wenn da irgendwelche Lücken sind. Es gibt: Einzelne Bricks/Bricklets: Die schicken beim Neustart ein Enumerate mit Connected. Das passiert z.b. wenn du die Firmware aktualisierst, oder aus anderen Gründen ein Brick(let) resettest. Den Stack, der neustartet wenn du USB abziehst und wieder dransteckst. Wenn alles andere noch läuft, solltest du im Moment des Stecker-ziehens ein Enumerate mit Disconnected für alle Bricks/Bricklets bekommen, auf jeden Fall bekommst du aber ein Enumerate mit Connected, wenn der Stack angeschlossen wird. Der Brick Daemon. Wenn der neustartet oder du aus anderen Gründen die Verbindung verlierst, kannst du das über das connected btw. disconnected Callback mitbekommen. Der MQTT-Broker. Das hängt etwas vom Broker ab, was passiert wenn du den neustartest. Bei mosquitto kannst du dich wie oben beschrieben auf $SYS/broker/version subscriben. (Achtung: In der Shell brauchst du Anführungszeichen oder musst das $ escapen, sonst wirds nichts) Die MQTT-Bindings. Wenn die Bindings sich sauber beenden siehst du das unter "tinkerforge/callback/bindings/shutdown", falls sie crashen (und deshalb diesen Publish nicht schaffen würden) siehst du stattdessen "tinkerforge/callback/bindings/last_will". Wenn die Bindings (neu)starten bekommst du "tinkerforge/callback/bindings/restart", auf allen diesen Topics ist der Payload einfach null, da geht es ja nur um das Signal selbst. Den last_will bekommst du übrigens auch wenn der Broker (sauber) beendet wird. Wenn jetzt irgendeine Komponente neustartet, musst du im worst-Case alle Callbacks neu registrieren und aktivieren und alle Konfiguration der Bricks/Bricklets neusetzen. Es kann dir nämlich passieren, das z.b. der MQTT-Broker abschmiert, während der weg ist, aber der Stack neustartet, weil jemand ungünstig ans USB-Kabel gekommen ist oder so. Das bekommst du jetzt aber nicht mehr mit, d.h. wenn der Broker wieder kommt weißt du nicht was in der Zwischenzeit passiert ist. Andererseits kannst du natürlich Glück haben und der Broker-Neustart hat sonst nichts beeinflusst, dann kommen deine Daten weiterhin durch. WIe gesagt, das hängt von der Paranoia/den Robustheitsansprüchen hab. Ich würde folgendes machen: Baue dir in einem z.b. Pythonscript eine Initialisierungsfunktion pro Brick/Bricklet, die die Callbacks registriert und aktiviert und alles konfiguriert. und "glaube" den Daten nur, wenn die erfolgreich durchgelaufen ist. Wenn du jetzt in der Kette irgendeinen Crash/Neustart detektierst, führst du die Funktionen alle neu aus. Du kannst dann natürlich optimieren und wenn du einen einzelnen Brick(let) neustart siehst nur das eine Gerät neu initialisieren.

Hi, Sorry this will take another few months. I've got a (slowly shrinking) heap of tasks with higher priority, and once that is done, I will port the binding to OH3 and finish it.

Moin, @Martin Du suchst vermutlich diese Seite: https://www.tinkerforge.com/en/doc/Software/API_Bindings_openHAB.html (Der Download-Link darauf bringt dich nicht weiter, aber die ganze Dokumentation sollte hilfreich sein.) Die funktionieren bei mir beide. Nimm im Zweifel eher den zweiten, also den Anhang im Forum. Warst du eventuell nicht eingeloggt, als du versucht hast den runterzuladen? Das sollte eigentlich ohne Login gehen, aber vielleicht ist die Forensoftware da falsch konfiguriert. 2.1.26. Mir ist absolut unklar, was bei der Installation von skober19 dazu führt, dass die Version nicht funktioniert. Das bringt dich nicht weiter, du musst die Java-Bindings-Jar direkt mit in den addons-Ordner von openHAB ablegen. Das ist langfristig das Ziel, dafür muss das Binding nur erst "fertig" werden. Auch für die anderen im Thread: Ich weiß, dass sich das schon lange verschleppt, ich kann als schlechte Ausrede aber nur anbieten, dass ich halt als einziger daran entwickle und der Aufgabenhaufen mit höherer Priorität (Mikrocontroller-Bindings, ESP32-Brick-Firmware, Wallbox-Firmware) langsam aber sicher kleiner wird.

Hi, You are correct, this is a bug in the unpack logic of multiple boolean arrays. Can you please test the attached version? Erik tinkerforge_ruby_bindings_2_1_27.zip

Moin, Sorry für die späte Antwort, Weihnachtsurlaub und so. Das ist tatsächlich kein Bug im eigentlichen Sinne: post_connect wird nur einmal ausgeführt und zwar nachdem die Verbindung zum Brick Daemon steht (die wird nach der Verbindung zum Broker aufgebaut). Auf meiner "Nice-to-have"-Liste steht tatsächlich noch "configure" o.Ä. einzuführen, was dann nach jeder Neuverbindung zum Broker oder Brick Daemon ausgeführt werden würde, für genau solche Fälle. Das kann aber noch etwas dauern, bis ich dazu komme. Du kannst Mosquitto-Neustarts aber mitbekommen, indem du dich auf "$SYS/broker/version" registrierst, da gibt Mosquitto beim (Neu)Start die Versionsnummer aus.

Moin, Ja, Port E ist der vom HAT selbst. Das Problem, dass du da hast scheint ein Bug in der aktuellen Version von Brick Daemon zu sein, ist z.B. hier schon mal aufgetaucht. @photron ist noch im Weihnachtsurlaub, aber in den nächsten Wochen fixen wir das. Edit: Als Work-Around kannst du auch probieren, ob Brick Daemon 2.4.1 bei dir das Problem nicht erzeugt. Der braucht aber udev oder ähnliches.

Moin, Über die Reihenfolge hast du, wenn du Callbacks benutzt, keine Kontrolle, da die Bricklets asynchron zueinander laufen. Du kannst aber über das Topic gehen: Die Callbacks tauchen ja auf tinkerforge/callback/outdoor_weather_bricklet/SvZ/station_data bzw. tinkerforge/callback/outdoor_weather_bricklet/SvZ/sensor_data auf. D.h. du könntest mit jeweils einem Shellscript eins der Topics subscriben.

Moin, Das ist interessant. Hat das Tab-Wechseln visuell noch funktioniert? Also dass der berührte Tab dann aktiv war, auch wenn dessen GUI vermutlich gefehlt hat, weil ja das Callback fehlte. Damit könnte man gut diagnostizieren, wo das schief gelaufen ist. Das kenne ich, da bin ich aber noch nicht hinterher gestiegen, man kommt hier ja zu nichts :D Nein, weil das bisher von meiner Seite aus "ungetestet" ist. Als nächstes steht sowieso der Wechsel zu openHAB 3 an, da muss ich das dann in Ruhe ausprobieren, wie das mit den Files ist. Bisher "unterstützt" ist nur die Konfiguration per PaperUI. Leider nein. Ich bin wie gesagt noch mit der Wallbox beschäftigt, aber optimistisch im Winter noch etwas Zeit in openHAB stecken zu können. Frohe Weihnachten an alle! Erik

Moin, Ich vermute, dass das nicht klappen wird: Diese Tierchips scheinen laut diesem Artikel alle auf einem Frequenzband von ungefähr 130 kHz zu laufen. Das NFC Bricklet arbeitet aber auf 13,56 MHz, weil die ganzen NFC-Standards auf der Frequenz liegen.

Another thought: Does this happen if you downgrade to Brick Daemon 2.4.1? This version is too old to be available in the APT repository, however you can download it here: https://download.tinkerforge.com/tools/brickd/linux/brickd-2.4.1_armhf.deb

I've just tried the same thing here and could reproduce the bug. I will report back when we know more. (Probably next year)

Moin, Das kannst du unter Configuration -> Things -> das IO-16-Bricklet einstellen. Da gibt es über den Namen einen blauen Button, mit dem du die Thing-Einstellungen öffnen kannst. Darin kannst du, genau wie mit Brick Viewer, die Ports konfigurieren. Das liegt daran, dass die Bindings sich nicht darauf verlassen, dass die Konfiguration unverändert ist, wenn das Bricklet neu auftaucht oder openHAB neustartet o.Ä. und deshalb alles neu setzt. Das ist noch auf der Agenda. Ich bin leider immer noch mit einem anderen Projekt beschäftigt *hust*. Wenn da der Release-Stress etwas abgeklungen ist, geht es mit den Bindings aber auf jeden Fall weiter. Gruß, Erik

Hi, Are you using Brick Daemon 2.4.3? There have been some changes to fix problems with the dynamic clock rate of newer Raspberry Pis in this version. Unfortunately you can't. Brick Daemon itself does not have any API to query for these errors.

Aktualisiere trotzdem erstmal dem Brick Daemon auf 2.4.3. Es gibt Änderungen bezüglich der Geschwindigkeit mit der das HAT mit den Bricklets SPI spricht, leider ist das sowohl Hardware- als auch Lastabhängig, wann da Fehler auftreten. Es ist also gut möglich, dass es mit einem Thermal Imaging Bricklet klappt, aber mit einem anderen nicht. In 2.4.3 haben wir das gefixt. Noch eine Frage: Hast du einen Master Brick oder ein anderes HAT zur Hand mit dem du testen könntest, ob das neue Bricklet prinzipiell kaputt ist?

Hi, Folgende Fragen dazu: Hat der Aufbau schon mal funktioniert? Ist der Brick Daemon auf dem Pi aktuell? (Version 2.4.3) Steckt der Thermal-Sensor richtig? Die rutschen leider recht leicht aus dem Sockel. Gehen die Timeouts gleichmäßig hoch, oder hattest du das Bricklet nur kurz testweise abgezogen, aber seit dem es wieder angeschlossen ist, bleibt die Timeout-Zahl gleich? Die Kommunikation mit dem Bricklet (aber nicht unbedingt dem Sensor) muss ja schonmal funktioniert haben, sonst wäre die "Region of Interest"-Konfiguration auch leer.

Moin, Vielleicht bekommst du mehr Informationen, wenn du den ganzen Stapel per PoE startest, wartest bis der RED Brick gestartet ist (das erkennst du gut daran, dass dann der Master Brick nochmal sein LED-Lauflicht macht, der RED-Brick resettet den Stapel) und dann den Stapel zusätzlich per USB an deinen Rechner steckst. Dann solltest du mit dem Brick Viewer den RED Brick sehen können. Dann wäre interessant, ob der Brick die Ethernet Extension gefunden hat und was der Netzwerkstatus ist.

Moin, Das stimmt. Tut es. Es reicht also, wenn du das Offset einmal setzt. Wie gehst du bisher mit dem Offset um? Die beste Erklärung für das Verhalten wäre, wenn du das Offset alle ~2 Sekunden setzt und zwar immer auf einen größeren Wert. Was mich zudem noch wundert: Die UID des Bricklets sieht so aus als hätte es sich die selbst erwürfelt. Eigentlich setzen wir hier beim ersten Flashen und Testen eine UID die zur Zeit dreistellig ist. Vielleicht ist da etwas schief gelaufen. Ich würde deshalb auf Verdacht vorschlagen, dass du die Firmware nochmal neu flasht, nur um sicherzugehen. (Die UID bleibt dann aber die gleiche)

Korrekt, alles was du irgendwie an den Pi anschließt (also per HAT oder Brick) kannst du vom Pi aus benutzen.

Moin Christian, Das wird nicht so einfach funktionieren. Der Brick Daemon auf einem Raspberry Pi kommuniziert über das HAT und das 7-Pol-Kabel mit den Koprozessoren auf den Bricklets, nicht direkt mit den Sensoren. Dabei verwenden wir ein eigenes Protokoll basierend auf SPI. Du kannst aber alternativ folgendes machen (sortiert nach Aufwand): Du kannst statt dem HAT einen oder mehrere Master Bricks per USB an den Pi anschließen und daran die Bricklets Das HAT verwendet nicht alle Pins der GPIO-Leiste des Pis. Du könntest also mit einer längeren Stiftleiste o.Ä. die anderen Pins abgreifen, die du brauchst. Da musst du aber extrem aufpassen, dass du nicht einen der Pins des HATs erwischt. Am besten siehst du dafür im Schaltplan des HATs bzw. HAT Zeros nach. Im Laufe der nächsten Monate werden wir ein Breakout Bricklet veröffentlichen. Damit kannst du Bricklets direkt an die Stiftleiste anschließen, das sieht dann ungefähr aus wie in diesem Video. Das Breakout Bricklet ist notwendig, da du Bricklets nicht direkt an die Stiftleiste des Pis hängen kannst. Ich zitiere mal aus der Doku der (noch in Beta befindlichen) Bindings für Mikrocontroller: "Aufgrund eines Bugs des auf den Bricklets verwendeten XMC-Mikrocontrollers von Infineon trennt das Bricklets sich nicht korrekt vom SPI-Bus, wenn das Chip-Select-Signal deaktiviert wird. Es treibt dann weiterhin auf MISO einen Wert, was dazu führt, dass sich mehrere Bricklets am selben SPI-Bus gegenseitig stören. Falls mehrere Bricklets eingesetzt werden sollen, müssen deshalb vom Chip-Select-Signal kontrollierte Trenner-Chips eingesetzt werden." Wenn du es super eilig hast und diesen Weg gehen willst, müsstest du also selbst eine Schaltung mit Trenner-Chips aufbauen. Gruß, Erik

Moin, Es wundert mich, dass das funktioniert hat. Hattest du die 2.1.26 auch im Addons-Ordner liegen? Zusätzlich zu dem was Stefan schreibt: Hast du den Browser-Cache geleert? Mir passiert es überraschend oft mit der PaperUI, dass Einträge fehlen weil der Cache veraltet ist. Mach, wenn du auf das + in der Inbox geklickt hast, mal ein Strg+F5. Falls das nicht hilft kannst du in der openHAB-Konsole mit log:set TRACE org.openhab.tinkerforge das Debug-Log aktivieren, dann openHAB neustarten und dann würde mich das openHAB-Log interessieren. Erik

Habe mir das gerade mal angesehen und musste feststellen, dass das nicht klappt. Die Umbenennungen von org.eclipse.smarthome nach org.openhab sind in openHAB 2 nur halb gemacht, aber in openHAB 3 komplett. Das heißt, dass ich bestimmte Pakete nicht einheitlich importieren kann. Der nächste Schritt wird dann wohl sein, noch eine letzte openHAB 2 kompatible Beta zu bauen, mit den kleineren Änderungen die so aufgelaufen sind, und danach auf openHAB 3 zu wechseln. Das wird wie gesagt aber noch etwas dauern, sorry.

Ich habe leider keine grobe Timeline, wann ich überhaupt wieder für openHAB Zeit habe. Ich sehe mal zu, dass ich im Dezember noch ein paar Tage zwischendurch investieren kann. Wenn es sich ergibt, teste ich diese Woche mal, ob ich das Binding zumindest erstmal so bauen kann, dass es mit openHAB 2 und 3 kompatibel ist.

Moin, Korrekt, das Bricklet kann nur die Spannung einer externen Versorgung messen, wenn du den Input-Klemmenblock verwendest. Das geht. Z.B. die unterstützten WS2815-LEDs brauchen 12 Volt. Da sollte eigentlich jeder funktionieren, solange der Treiber einer der hier aufgeführten ist.