rtrbt

Das kannst du höchstens über Tricks hinbekommen, hängt aber von deinem Anwendungsfall ab. Was versuchst du synchron zu messen? Von welchen Zeitskalen reden wir da? Das hängt davon ab, ob du alte Bricklets mit 10-Pol-Stecker verwendest, oder die neuen Koprozessor-Bricklets mit 7-Pol-Stecker: Bei den alten wird die Firmware vom Master Brick ausgeführt, der dann auch die Callbacks generiert. Bei den neuen läuft die Firmware direkt auf dem Koprozessor, der dann auch von sich aus Callbacks erzeugen kann.

Moin, Nein, es gibt keine Möglichkeit, die Abfragen zu synchronisieren. Ersteres, die Befehle werden vom RED-Brick nacheinander zu den anderen Bricks/Bricklets gesendet. Die Bricklets können Callbacks parallel auslösen. Der Brick fragt aber intern nacheinander ab. D.h. du kannst parallel erzeugte Callbacks nacheinander bekommen, hast aber keine Möglichkeit herauszufinden, ob sie wirklich gleichzeitig ausgelöst wurden. Sowohl, als auch: Du hast weniger Arbeit und es muss pro Messwert nur noch ein Paket vom Bricklet zum RED-Brick geschickt werden, das Paket mit der Anfrage vom RED-Brick zum Bricklet fällt weg.

Nein, das wird nicht unterstützt. Das kommt hin, ein Unterschied ist aber, dass du das Enumerate auch für Teile der Hardware bekommen kannst, du kannst ja zwei Stacks per USB angeschlossen haben und dann einen abziehen.

Moin, Du kannst die LEDs steuern, indem du die entsprechenden Dateien schreibst. Es gibt folgende Ordner: Rote LED: /sys/class/leds/red-brick:led:error/ Grüne LED: /sys/class/leds/red-brick:led:running/ Darin kannst du z.B. default-on in die trigger-Datei schreiben um eine LED anzuschalten. Du kannst dir, indem du die trigger-Datei liest (z.b. mit cat /sys/class/leds/red-brick:led:error/trigger) anzeigen, welche Trigger es gibt und welcher aktuell ausgewählt ist. Die Helligkeit scheint nur binär, also an/aus, steuerbar zu sein: Wenn du eine 0 in brightness schreibst geht die LED aus, bei 1 bis 255 geht sie an (wenn der Trigger passt), bleibt aber gleich hell. Mit Python funktioniert das ganze dann z.B. so: with open('/sys/class/leds/red-brick:led:error/trigger', 'w') as f: f.write('heartbeat') Achtung: Damit du die Dateien schreiben darfst, musst du root-Rechte haben. Wenn du nur eine bestimmte Konfiguration für die LEDs setzen willst, kannst du auch den Brick Viewer benutzen: Im RED Brick -> Settings -> Brick Daemon-Tab kannst du die LEDs persistent setzen.

Moin, Den Websocket-Port solltest du eigentlich nicht brauchen. Du kannst testen, ob die Jars geladen werden, indem du in der openHAB-Karaf-Konsole folgendes eingibst: bundle:list | grep Tinkerforge Bei mir sieht die Ausgabe dann so aus: 203 │ Active │ 80 │ 2.5.3.202005191321 │ openHAB Add-ons :: Bundles :: Tinkerforge Binding 211 │ Active │ 80 │ 2.1.26 │ Tinkerforge API Bindings Wenn das fehlt, hat openHAB die Jars aus irgendeinem Grund nicht geladen. Dann wäre es hilfreich, wenn du das openHAB-Log (die Datei logs/openhab.log im openHAB-Ordner) hier anhängst. Du kannst auch in der PaperUI nachsehen, ob das Binding installiert ist: Dann sollte es unter Configuration->Bindings aufgeführt sein. Wenn das alles klappt, solltest du über das Plus in der Inbox das Tinkerforge Binding und dann den Brick Daemon auswählen können. Da musst du dann für die Authentication auf Show More gehen, die Authentication aktivieren und das Passwort eingeben.

Wenn du das weglässt, konfigurierst du auch alles, wenn du eine Enumerierung mit ENUMERATION_TYPE_DISCONNECTED bekommst, da sollte aber der Code auf keinen Fall laufen. Ansonsten gebe ich dir recht, wenn du eine Enumeration bei einem Reconnect auslöst, brauchst du sonst keine Spezialbehandlung.

Wenn das Bricklet die Enumeration (mit -Type Connected) schickt, sollte es im Initialzustand sein, alles andere wäre ein Firmware-Bug. D.h. wenn du danach deine Abweichungen zum Initialzustand konfiguriest sollte das reichen. Bei einem Reconnect der IP-Connection kann es im worst-case natürlich sein, dass während du nicht verbunden warst, eins der Bricklets neugestartet wurde, um maximal robust zu sein musst du da also auch alles was du brauchst neu konfigurieren. Wenn sich jemand anderes per Brick Viewer verbindet und Konfiguration verstellt hast du verloren, das bekommst du nur in den Griff, wenn du die Bricklets resettest und danach neu konfigurierst. Da würde ich lieber die Authentication anschalten

Du solltest übrigens prinzipiell darüber nachdenken, wenn ein _CONNECTED kommt, die Konfiguration des Bricklets (Callback-Registrierungen, Sample-Rates usw.) wiederherzustellen. Das ist ziemlich robust, habe ich z.B. in den openHAB-Bindings so gebaut.

Moin, Das kann eigentlich nur passieren, wenn du entweder einen Code-Pfad hast, der das Callback deaktiviert, oder wenn das Bricklet aus irgendwelchen Gründen beschlossen hat, sich zu resetten. Hast du eventuell ein sporadisches Enumerate vom Bricklet gesehen, bevor keine Daten mehr kamen? Wenn das Bricklet ein Enumerate mit dem Enumeration-Type ENUMERATION_TYPE_CONNECTED (=1) schickt, dann hat es sich neugestartet. Erik

Moin, Spontan sehe ich da zwei Probleme: Die openHAB-Bindings hängen im Moment noch von der Version 2.1.26 der Java-Bindings ab. Die 2.1.27 wird von den openHAB-Bindings ignoriert. Danach musst du erst über die Inbox manuell den Brick Daemon als Thing hinzufügen, danach sollten die angeschlossenen Bricks und Bricklets automatisch gefunden werden.

Hi, This will not work out of the box. You have to write some kind of object detection to find the tracked object in the thermal image.

Du bist noch in openHAB unterwegs? Dann kannst du dir diesen Post mal ansehen.

Moin Florian, Die Wetterstation misst nur den absoluten Wert, das ist soweit korrekt. Es gibt vom Outdoor Weather Bricklet keinen Kommunikationsrückkanal zur Wetterstation, deshalb kann das Bricklet den Wert nicht zurücksetzen. Relative Werte wie "Regen in den letzten 24h" o.Ä. musst du also selbst implementieren. Gruß, Erik

The relevant error message in your brickd.log is You have to enable the SPI device by running sudo raspi-config and then selecting "Interfacing Options" and "SPI" and answering yes. brickd --check-config does not work, because you are not running it with sudo, so it tries to check the non-existing user specific config file.

The default content is the same as if the brickd.conf file was empty. So to be sure, that nothing is misconfigured, you can replace everything.

The log looks okay so far. If the Brick Viewer can't connect to the Pi, you should get a message box indicating the error. If no error is reported, then the connection succeeds but the Brick Daemon running on the Pi does not see any hardware. To verify this, you can stop the Brick Daemon with sudo systemctl stop brickd and then start a non-daemonized instance with debug logging: sudo brickd --debug -all,+bricklet.c If the HAT is detected, you will get output like this: 2020-06-08 14:27:57.143360 <D> <bricklet.c:182> Found product_id "0x085d" in device tree, using pre-configured HAT Zero Brick setup 2020-06-08 14:27:57.144827 <D> <bricklet.c:220> Bricklet found: spidev /dev/spidev0.0, driver 1, name gpio27 (num 27) If this output is missing, the HAT is not detected.

Ich habe das nicht getestet, aber folgende Dinge fallen mir auf: Da musst du anders auf den konkreten Wert aus img_color zugreifen: Du willst ja den Pixel x,y, also Spalte x, Zeile y. Damit du in dem eindimensionalen Array den korrekten Pixel auswählst, musst du also y Zeilen überspringen (die sind jeweils 80 Pixel lang) und dann den x-ten Pixel auswählen. Das sollte so funtionieren: myBitmap.SetPixel(x, y, img_color(y * 80 + x)) Hier legst du als Farbe immer eine an, die einen Alpha-Wert von 0 (also vollständig transparent) hat. Das erzeugt bei dir dann kein Problem, weil du das Bild als jpg speicherst, was keine Transparenz kann, aber wenn du z.B. eine PNG anlegen würdest, oder das Bild direkt in eine GUI zeichnen, dann würdest du nichts mehr sehen. So sollte es klappen: img_color(i) = Color.FromArgb(255, img(i), 0, img(i)) 'RGB(255, 0, 0) Alternativ kannst du den Alpha-Wert auch weglassen: img_color(i) = Color.FromArgb(img(i), 0, img(i)) 'RGB(255, 0, 0)

Hi, When you connect to the Pi with Brick Viewer, can you see the HAT Zero Brick in the setup tab? Is the brick viewer able to connect to the Pi at all? In any case it could be useful, if you post the Brick Daemon log file (/var/log/brickd.log) here.

Moin, Am einfachsten ist es vermutlich, wenn du deinen Code postest, dann kann man darin den Fehler suchen.

Moin, Das klingt gut Die Java-Bindings 2.1.27 haben neue API für das Industrial Dual Analog In 2.0 Bricklet und das Barometer Bricklet hinzugefügt. Die openhab-Bindings benutzen die API aber noch nicht, deshalb habe ich die Abhängigkeit noch nicht aktualisiert. Gruß, Erik

Moin, Ich habe hier auf einer frischen VM nochmal getestet und diverse weitere Probleme mit dem Script gefunden. Ich komme aber erst am Montag dazu, das Script fertig zu reparieren. Wenn du die Dokumentation bauen willst, empfehle ich dir aber Docker zu verwenden. Aus Altlast-Gründen verwenden wir da eine gepatchte ältere Sphinx-Version, die aufzusetzen ist etwas kompliziert. Mit Docker geht das automatisch. Zum Installieren musst du folgendes machen: sudo apt install docker.io sudo usermod -a -G docker $USER # Aus und einloggen oder alternativ: newgrp docker docker pull tinkerforge/build_environment_full Danach kannst du im doc-Git mit ./make_with_docker html die Dokumentation bauen. Perspektivisch werde ich das build_environment_setup.sh mal so umbauen, dass es Docker und das Image mitinstalliert. Gruß, Erik

Firmware: LCD 128x64 Bricklet 2.0.9 Improve draw performance Download: LCD 128x64

Firmware: LCD 128x64 Bricklet 2.0.9 Performance des Zeichnens verbessert Download: LCD 128x64

Moin, Hier ist kein anderer kompatibler Sensor bekannt. Das Outdoor Weather Bricklet implementiert nur genau die Kommunikation mit der Weather Station und dem TH-6148.

Moin, Hat build_environment_setup.sh etwas interessantes ausgegeben? generate_tables.py setzt das generators-Git in seinen Import-Path und verlässt sich darauf, das darin device_infos.py erstellt wurde. Das sollte das Shellscript eigentlich gemacht haben, weil darin, bevor die Doku gebaut wird, generate_all.py in generators ausgeführt wird.