rtrbt

Klingt gruselig Hast du eventuell ein anderes Programm laufen, dass die Segmente setzt? Das kannst du am einfachsten testen, indem du mit dem Brick Viewer die UID des Bricklets änderst. Andere Programme sollten dann ins Leere laufen, falls sie die UID hardgecoded haben. Alternativ könnte auch ein Programm laufen, dass die falsche UID verwendet und deshalb seine Nachrichten an das Segment Display schickt, statt an das richtige Bricklet. Erik

Ich habe mir gerade nochmal das Timing angesehen. Wie lange musst du beim Anlernen warten, vom Switch On senden bis die LED aufhört zu blinken? Die sollte, wenn es klappt, fast sofort aufhören zu leuchten und dann konstant an sein. Falls die Fassung nichts empfängt, hört sie 20 Sekunden nach dem Knopfdruck auf zu blinken. Ich vermute aber, weil du ja andere Dinge mit dem Bricklet steuern kannst, dass die Fassung hin ist. Hast du eine Fernbedienung oder irgendetwas anderes mit dem du die Fassung testen kannst? Wegen anderen Lampenfassungen kann ich dich nur auf die Kompatiblitätsliste verweisen. Da ist aber leider nicht aufgelistet, welche als Switch und welche als Dimmer arbeiten.

Moin, Ich habe mal getestet, die Fassung will tatsächlich als B-Switch angesprochen werden. Folgendes funktioniert bei mir: [*]Lampenfassung alle Pairings vergessen lassen [*]Im Brick Viewer das Remote Switch Bricklet 2.0 auf B Switch, irgendeine Adresse (z.B: 12345678) und irgendein Unit (z.b. 5) konfigurieren [*]Lampenfassung in den Pairingmodus schicken [*]Im Brick Viewer einmal Switch On senden [*]Warten bis die LED an der Lampe aufgehört hat zu blinken Dann reagiert die Lampe auf Switch On und Switch Off. Dimmen startet, wenn die Lampe an ist und nochmal Switch On gesendet wird. Nochmal Switch On hält die Dimmstufe. Was mir beim Testen aufgefallen ist, ist dass der Empfang je nach Position des Bricklets schlecht sein kann, falls die Lampenfassung in einen Metallschirm geschraubt ist (z.B in diesen hier: https://www.ikea.com/de/de/p/tertial-arbeitsleuchte-weiss-70355455/).

Dabei auch darauf achten, dass der Master- unter dem Stepper-Brick sein muss.

Moin, Die Fassung steht deshalb auf der Kompatibilitätsliste, weil wir eine Funksteckdose, die das selbe Protokoll sprechen sollte, getestet haben. Wir bestellen gerade mal genau diese Fassung zum Testen. Eine erste Theorie die ich habe ist, dass die Fassung eventuell als B-Switch, nicht als B-Dimmer arbeitet und das Dimmen durch zwei An-Signale ausgelöst wird. Ich teste das mit der Fassung sobald sie hier eintrifft und melde mich nochmal. Erik

Hi, Das kann entweder ein Problem mit der Karte oder dem Brick sein. Hast du eine zweite Karte auf die du das Image flashen kannst? Falls ja, probiere das mal, wenn es mit einer anderen Karte auch nicht geht, sollte das Problem der Brick sein. Erik

In Brick Viewer 2.4.3 the 3D rendering is working with OpenGLES (i.e. on the Raspberry Pi).

Hi, can you please try the attached version of Brick Viewer? The problem seems to be, that the IMU 2.0 3D rendering uses the (very old) immediate mode, which is only supported by OpenGL, not OpenGLES. The Raspberry Pi does not support OpenGL, so we can't render the 3D model, which was not handled. I will rewrite the rendering to use more modern OpenGL capabilities, which are also supported by OpenGLES. But for now, you can use the attached version, which disables the 3D rendering if only OpenGLES is available. Thanks for reporting the bug, Erik brickv-2.4.2_all_opengl_fix.deb

Hi, You can distinguish multiple sensors and stations with the identifier field. If another sensor starts sending, it should change from 164 to another value.

Moin, Laut Schaltplan braucht das Bricklet alle 10 Pins. Im Schaltplan ist der Bricklet-Stecker P1 oben links.

Dann verwendet Qt bei dir vermutlich immer den Fusion Style. Der ist der Standard wenn Qt nicht sieht, dass du KDE oder etwas Gtk-basiertes laufen hast. (Siehe hier)

Moin, das ist korrekt. Der Brick Viewer hängt ab Version 2.4.0 von Python 3 und PyQt5 ab, die aber im RED Brick Image noch nicht enthalten sind, deshalb der Hinweis. Die kommende Version 1.14 liefert die Abhängigkeiten nach.

The scripts are just pseudocode, so you have to translate them to your favorite language, for example Python with the Paho library.

Der Fix ist in der Version 2.0.4 der Bindings enthalten, falls du wieder auf eine "offizielle" Version wechseln willst.

Bindings: MQTT 2.0.4 Bugfix for handling of list parameters Download: MQTT

Bindings: MQTT 2.0.4 Bugfix für Listenparameter Download: MQTT

Hm vielleicht hingen da noch Pakete im Buffer vom Brick Daemon. Im Normalbetrieb sollte das nicht passieren, es sei denn du versuchst mehr als 1000 Nachrichten pro Sekunde an die Bricklets zu schicken. Z.B. wenn du den Counter vom Segment Display auf 1ms konfigurierst und parallel noch andere Sachen machst.

Dass die Verzögerungen weg sind, kann ich dir spontan nicht erklären, vielleicht ist das Netzwerk weniger ausgelastet? Bist du dir sicher, dass du die Version ausführst, die ich angehangen habe? Diese Fehlermeldung kann von der neuen Version eigentlich nicht erzeugt werden, weil die Codezeilen, die ausgegeben werden, so nicht mehr vorkommen. In der neuen Version der tinkerforge_mqtt-Datei steht in Zeile 23 from collections.abc import Hashable Wenn das fehlt, hast du die falsche.

Bezüglich des Zeichenproblems: Sieht die Antwort auch so aus wenn du sie mit mosquitto_sub -t 'tinkerforge/#' -h 192.168.1.18 abholst?

Moin, die Bindings sollten eigentlich, abgesehen von der Netzwerklatenz, nicht langsam sein. Sind die Reaktionen auch verzögert, wenn du das ganze lokal testest? {"red": "{", "green": "\"", "blue": "r"} Das sieht kaputt aus. Die Zahlen sollten nicht als Zeichen interpretiert werden. Ist das Ausgabe von MQTT.fx? Das falsche (oder richtige, je nach dem ) Beispiel habe ich mal repariert, es dauert aber noch etwas bis es sichtbar wird. Bezüglich des 4x7 Displays, teste bitte mal ob das mit der angehangenen Variante der Bindings auch auftritt. Gruß und schönes Wochenende, Erik Edit: Du kannst übrigens testen ob die Bindings deine Nachrichten verstehen, indem du den --show-payload Parameter beim Starten mitgibst. Wenn die Bindings dann keine Fehlermeldungen mit dem Payload als string ausgeben, haben sie dich verstanden, wenn es dann nicht klappt, sind die Bindings kaputt. tinkerforge_mqtt_bindings_2_0_3.zip

Your init file looks good, I've tested it here and got callback responses. You could run the bindings with the --debug parameter and check if there are the following lines in the output: <DEBUG> MQTT bindings: Calling function set_station_callback_configuration for device Es8 of type outdoor_weather_bricklet. <DEBUG> MQTT bindings: Calling function set_station_callback_configuration for device Es8 of type outdoor_weather_bricklet succedded. <DEBUG> MQTT bindings: Registered callback station_data for device Es8 of type outdoor_weather_bricklet. Will publish messages to tinkerforge/callback/outdoor_weather_bricklet/Es8/station_data. If these are printed, the bindings should publish a message under the callback topic when there is new data (can take about 45 seconds). The get_status_led_config request works here, but maybe there are some hints in your debug output.

You don't have to configure the callbacky by hand. Instead you can use an init file, as described here. You could write a systemd service file. This is explained here. You should definitely use init-files then, or else you would have to reconfigure everything after a reboot.

Bindings: MQTT 2.0.3 Crash beim Start ohne init-File behoben Unnötige Callbackmeldungen entfernt Behandlung von Timeouts verbessert Symbole von Callbackantworten werden jetzt übersetzt Download: MQTT

Bindings: MQTT 2.0.3 Fix crash on start without init-file Remove unnecessary callback error message Fix handling of timeouts Translate symbols in callback responses Download: MQTT

The official version 2.0.3 is now available here.