rtrbt

Vermutlich ist die Netzwerkfirewall da zu aggressiv: Die Requests die der Brick Viewer sendet, sehen nicht aus, als kämen sie von einem Browser. Deshalb werden die wohl blockiert.

Als work-around kannst du die Firmwares von Hand runterladen und im Flashing-Fenster per Custom flashen.

Moin,

Sieh mal nach, ob die Firewall von Windows den Brick Viewer blockiert hat.

Mit dem Explorer komm ich aber problemlos drauf.

heißt, du kommst mit einem Browser auf http://download.tinkerforge.com/ ?

Erik

Wenn ich nochmal darüber nachdenke: Das Verhalten, was du siehst, ließe sich erklären, wenn du bei beiden Beispielen statt der UID des jeweiligen Bricklets die des Master Bricks eingetragen hast.

Moin,

hast du daran gedacht, die UIDs in den Beispielen zu ändern? Das übersieht man gerne. Die Logs kannst du mal anhängen, eventuell findet sich da ja was.

Erik

Suspend kann zwar der Linux-Kernel, aber auf dem RED-Brick funktioniert er hardwareseitig nicht.

Du könntest dir mit einem per USB angeschlossenen Master-Brick und einem Relay-Bricklet etwas basteln, das hat aber folgende Nachteile:

• Das Timing wird sehr ungenau (im Bereich von einer Minute pro Stunde, das hängt vom Quartz auf dem Master Brick ab).
  
• Der Master Brick braucht eine Stromversorgung, da brauchst du entweder eine Step-Down-Power-Supply oder musst dir ein USB-Kabel zurecht bauen.
  
• Der RED-Brick würde sich selbst die Stromversorgung (sofort) wegnehmen, also kann das Linux nicht sauber herunterfahren.
  

Hängt also von deinem Einsatzzweck ab, ob das sinnvoll ist.

Bei den Relaymodulen von Amazon musst du mal sehen, ob du mit dem Timing hinkommst. Das erste scheint auf maximal 999 Minuten (16 Stunden 39 Minuten) konfigurierbar zu sein.

Payload was: b'{"register": true}'

 

Steht das b für Byte oder ist das Bestandteil des Payloads?

Das b steht für Byte. Dass der Payload an der Stelle des Codes noch (nicht dekodierte) Bytes sind, ist ein Bug in den Bindings. Ich habe mal eine Version mit Bugfix angehangen.

Ich hatte in der Mosquitto-Doku übrigens schon vor meinem ersten Posting geschaut, inwiefern man beeinflussen kann, ob String oder Byte als Datentyp verwendet wird, aber nichts dazu gefunden. Weiß diesbezüglich jemand was?

Du kannst mosquitto_pub mit -s beliebige Dinge auf der Standardeingabe füttern, die Bindings verstehen aber nur UTF-8 kodiertes JSON.

Bei Node-Red habe ich sowohl String als auch JSON als Payload-Typ ausprobiert. Auch hier wird die Payload vom Binding, wie oben, mit dem vorangestellten b angegeben.

Das sollte auch an dem Bug in den Bindings liegen.

tinkerforge_mqtt

Moin,

Das scheint ein seltsames Problem zu sein. Wenn ich die Befehle copy-paste und die UID anpasse, funktioniert es bei mir. Du kannst mal versuchen, die Bindings mit --debug --show-payload starten. Dann sollte in der Fehlermeldung die du bekommst hinten der Payload stehen, wie ihn die Bindings empfangen haben.

Erik

Habe dir nochmal eine neue Firmware angehangen, da war noch ein Rundungsfehler in dem Fall den du getroffen hattest, der u.U. dazu führt, dass doch zwei Callbacks (das erste eins größer als das zweite) zugestellt werden. Die angehangene Firmware ist identisch zur offiziellen 2.0.3.

rotary-poti-bricklet.bin

Moin,

Frage 1: Beim IPCON_ENUMERATION_TYPE_DISCONNECTED wird dem Callback zwar die uid des nicht mehr vorhandenen RotaryPoti übergeben, aber nicht der device_identifier, der immer 0 ist.

 

Warum?

Dass nur UID (und enumeration type) gültig sind, liegt daran, dass der Brick Daemon nur diese Werte zwischenspeichert, um sie mit dem Callback rauszugeben. Das ist absichtlich so, da es Fälle gibt, wo nicht mehr Informationen verfügbar sind.

Frage 2: Warum wird mein Callback doppelt aufgerufen? Und dann auch noch beim ersten Mal mit einem ungültigen Poti-Wert 150?

Das war in der Firmware kaputt. Das Problem ist, dass dein Programm, weil in C, so schnell ist, dass das Callback schon registriert und aktiviert ist, wenn der erste Wert abgefragt wird. Weil die Firmware da die Reihenfolge falsch hatte, wurde erst der (geglättete) Positionswert aus nicht vorhandenen Daten berechnet und danach der erste echte Wert vom Poti gelesen. Teste mal bitte die angehangene Firmware, die löst das Problem bei mir.

Erik

rotary-poti-bricklet.bin

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