rtrbt

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.

Moin, ich habe das hier mal nachgebaut, bisher (seit gestern ~ 16 Uhr) hat es immer geklappt. Wie üblich: Ich gebe Bescheid wenn sich etwas tut.

Solange red green und blue (wie oben) Tupel sind, kannst du folgendes machen: if self.sw.get_color() not in [red, green, purple]: self.sw.set_color(*blue) (oder alternativ ohne das not wenn du vergleichen willst ob get_color() gleich einem Element der Liste ist)

Moin, Du kannst mit einem * Tupel o.Ä auf Parameter-Listen expandieren, z.b. so: self.sw.set_color(*red)

Moin, Im Moment eher nicht. Du kannst aber die MQTT-Bindings benutzen, mit einem init_file Callbacks für die Werte aktivieren die dich interessieren und dann mit der MQTT-Sensor-Integration die Werte in Home Assistant bekommen.

Das ist für mich das Zeichen, dass der Brick ein Hardware-Problem hat. Wir schicken dir einen neuen raus, bei dem ich gerade nochmal HDMI getestet habe (an einem Samsung S22D300HY). Gib dann bitte Bescheid ob es mit dem neuen Brick funktioniert. Ich baue dafür im Brick Viewer mal einen Hinweis ein. Gruß, Erik

Moin, HDMI ist leider recht kompliziert. Es gibt manche Monitore die am RED-Brick nur funktionieren, wenn du sie im laufenden Betrieb ansteckst, andere funktionieren nur wenn sie bereits vorher angeschlossen sind. Mit welchen Bildschirmen hast du es probiert? Eventuell findet sich da ja eine Gemeinsamkeit. Meintest du eher eine Step Down Power Supply? Die Einspeisung am DC-Brick versorgt nur angeschlossene Motoren mit Strom, nicht andere Bricks im Stapel. Eventuell hat deine serielle Konsole da die Ausgabe davor verschluckt. Tut sich etwas wenn du Enter drückst und dann irgendeinen Befehl schreibst?

Moin, Das steht schon seit längerem auf der Nice-to-have-Liste, bisher ist bei uns aber noch niemand dazu gekommen das im Brick Daemon zu implementieren. Gruß, Erik

Zu deinem Displayproblem: Ich fürchte das ist eine Inkompatibilität zwischen Display und Prozessor und Kernel des RED-Bricks. Erfahrungsgemäß gibt es manche Displays, die nie funktionieren, wenn man das Kabel nachträglich ansteckt, und andere die das zwingend brauchen. Vermutlich triffst du mit deinem Display den zweiten Fall. Wenn du nicht gerade ein anderes Display verwenden willst, wird man da nicht viel machen können, sorry.

Das sollte inzwischen gefixt sein, auf dem Download-Server lag eine falsche Test-Datei die dazu führte, dass der Update-Check durcheinander kam. Wie sieht das Farbenspiel genau aus? Mach am besten mal ein Foto. Was passiert wenn du den Desktop siehst und dann den RED-Brick z.B. über Brick Viewer rebootest (dabei aber nicht Display oder RED-Brick vom Strom trennst)?

Aus dem Log sehe ich folgendes: Dein Programm startet sehr schnell nachdem Brick Daemon und RED Brick API Daemon gestartet sind (das ist die Zeile mit "Added new client (N: 127.0.0.1..."). Der Brick Daemon resettet anscheinend erst danach den Master Brick, weshalb dieser "vergisst" dass die Bricklets angeschlossen sind und an allen Ports neu anfragt. Das Rotary Encoder Bricklet meldet sich dann ("Received enumerate-connected callback (uid: KcD)") was der Brick Daemon als "Das Bricklet wurde neu angesteckt, ich werfe alle alten Anfragen weg weil die jetzt keinen Sinn mehr ergeben" behandelt. Eine Anfrage (vermutlich die Callback-Konfiguration) wurde dann verworfen. Mich wundert allerdings, warum du dann trotzdem 0, also keinen Fehler zurückbekommst. Hast du da eventuell einen Bug in der Anzeige auf dem LCD? Mit der Zahl-zu-String-Konvertierung? Du kannst den Rückgabewert, wenn du ihm mit printf ausgibst dann mit dem Brick Viewer sehen: Wenn du die stdout.log anklickst solltest du die Ausgaben deines Programms sehen können. Als grundlegende Frage: Behebt sich dein Problem, wenn du in der main (bevor du irgendetwas anderes machst) ein paar Sekunden wartest?

Das hängt von den Bindings ab. Bei den Python-Bindings kannst du pro Device und Callback-ID nur ein Callback registrieren. Wenn du die Registrierung mehrfach ausführst, werden die älteren Registrierungen überschrieben.

Laut dem Log hat dein händisches Konfigurieren funktioniert. Wenn du das HAT und angeschlossene Bricklets also immer noch nicht erreichst, ist es wohl wirklich ein Schaden am Pi oder HAT. Ich bin gespannt was bei deinem Test mit einem anderen Pi herauskommt.

Vermutlich. Wenn das HAT konstant blau leuchtet hat es eine funktionierende Firmware. Das heißt wir haben es hier geflasht und getestet und es hat zumindest vor dem Versand funktioniert. Ich halte einen Transportschaden für eher unwahrscheinlich. Falls du entweder ein anderes HAT (muss keins von uns sein) zur Hand hast oder alternativ noch einen Pi (mit der selben Speicherkarte) könnte man das entgültig testen. Eine Alternative kannst du noch testen: Du kannst den laufenden Brick Daemon mit sudo systemctl stop brickd anhalten und danach händisch mit Debugausgabe in der Konsole starten: sudo brickd --debug Eventuell bekommen wir da noch ein paar Informationen.

Hm das klingt als ob der Pi das HAT überhaupt nicht findet. Was macht die Status-LED des HATs (ganz rechts etwas unter der Mitte)? Eventuell steckt dein HAT im Bootloader-Modus fest, dann blinkt die Status-LED. Du kannst auf jeden Fall mal folgendes testen: Aktiviere mit sudo raspi-config das SPI-Interface (unter Interfacing Options -> SPI -> Ja). Danach kannst du die HAT-Pins händisch konfigurieren, wie das in der HAT-Dokumentation steht (den ganzen Block einfach ans Ende von /etc/brickd.conf packen). Danach (mit HAT) neustarten. Du solltest dann zwar immer noch nicht /proc/device-tree/hat/ haben, aber trotzdem mit dem Brick Viewer das HAT, sowie angeschlossene Bricklets, sehen und flashen können.

Moin, Hänge mal bitte die Rules an mit denen du den Test machst, also die mit der du den Pin setzt und die mit der du auf die ChangeEvents wartest und die (Fehler)-Zähler setzt usw. Dann kann ich das hier mal genauso nachbauen wie du das hast. Mein Aufbau läuft übrigens immer noch. Der funktioniert aber anders, da ich die IO16s selbst benutze um einen Pin zu setzen.

Moin, Gibt der Aufruf von rotary_encoder_v2_set_count_callback_configuration([...]) einen Fehlercode (also etwas anderes als 0) zurück? Gib den am besten mal aus und sieh dir hinterher mit dem Brick Viewer das Ausgabe-Log an.

Moin, Du hast vermutlich den Kernel 5.4 laufen (kannst du mit uname -r prüfen). Da gab es Änderungen in der Standardkonfiguration der GPIO-Leiste mit denen das HAT nicht zurechtkommt. Mich wundert es allerdings, dass nicht noch mehr Fehlermeldungen kommen. Du kannst testweise mal die Brick Daemon-Variante aus diesem Post installieren, die das Problem umgeht. Danach kannst du dich mit dem Brick Viewer zum Pi verbinden und die HAT-Firmware auf 2.0.2 aktualisieren, danach sollte es auch mit der normalen Brick Daemon-Version funktionieren. Falls das nicht hilft, melde dich nochmal, dann hast du ein anderes Problem. Gruß, Erik

Moin, Die Callbacks werden intern den Devices zugeordnet. Du kannst also z.B. folgendes machen: def cb_1(channel, changed, value): print("1") def cb_2(channel, changed, value): print("2") io = BrickletIO16V2("UID1", ipcon) io2 = BrickletIO16V2("UID2", ipcon) io.register_callback(io.CALLBACK_INPUT_VALUE, cb_1) io2.register_callback(io.CALLBACK_INPUT_VALUE, cb_2) Dann wird dir eine 1 ausgegeben, wenn das erste IO-Bricklet das Callback ausgelöst hat, und eine 2 wenn es das zweite war. Du kannst dann noch cleverer sein und dir bei der Registrierung des Callbacks mitgeben, welches Device das ist, indem du einen Lambda-Ausdruck benutzt, z.b. so: def cb(device, channel, changed, value): print("Ich bin {}".format(device)) print(channel, changed, value) io = BrickletIO16V2("UID1", ipcon) io2 = BrickletIO16V2("UID2", ipcon) io.register_callback(io.CALLBACK_INPUT_VALUE, lambda *args: cb("UID1", *args)) io2.register_callback(io.CALLBACK_INPUT_VALUE, lambda *args: cb("UID2", *args)) Das ganze kannst du soweit führen, dass du dir statt der UID gleich das Device-Objekt in das Callback reingibst, falls du direkt mit dem Bricklet etwas machen willst (z.B. wenn Pin 1 sich ändert Pin 2 auch ändern o.Ä.)

Hi, I'm currently still occupied with other projects, but the openHAB binding development will continue sooner or later. As per the feedback in the german thread, I will probably target openHAB 3 for the "finished" release of the bindings.