rtrbt

ACHTUNG: Arduinos mit AVR-Mikrocontroller (z.b. der Arduino Uno und Mega) haben einen Logikpegel von 5V und brauchen deshalb einen Pegelwandler zwischen dem Arduino und dem Bricklet. Bricklets haben einen Logikpegel von 3,3V. Edit: Hier die offizielle Dokumentation. Moin, Nachdem es in letzter Zeit häufiger Kundenanfragen danach gab, Bricklets direkt mit einem Mikrocontroller zu verwenden, habe ich die letzten Monate entsprechende Bindings entwicklet. Die erste Beta der C/C++ Bindings für Mikrocontroller, mit denen Koprozessor-Bricklets direkt von z.B. einem Arduino über SPI gesteuert werden können, finden sich im Anhang. Die Bindings sind in eine allgemeine Implementierung und einen Hardware Abstraction Layer (HAL) für konkrete Plattformen unterteilt. Es gibt zur Zeit einen HAL für Arduino-AVR-Boards, einen für ESP32-Boards wie das NodeMCU und einen für das Raspberry Pi (Zero) + HAT (Zero). Details zum Interface, zur Implementierung eigener HALs für andere Boards usw. finden sich in der Dokumentation. Künftig wird es von uns eigene Hardware für die Bindings geben, sowohl ein ESP32-basiertes Board auf dem Programme, die die Bindings verwenden geflasht werden können, als auch ein neues Breakout Board, mit dem Koprozessor-Bricklets direkt mit einem Mikrocontroller verbunden werden können. (hier ein Teaser) Gruß, Erik Edit: Beta 8 mit folgender Änderung: Bug gefixt wegen dem Callbacks nach ~ 35 Minuten nicht mehr funktionierten. tinkerforge_uc_bindings_2_0_0_beta_8.zip

Moin, ipcon.connect blockiert bis entweder die Verbindung aufgebaut ist oder ein Fehler auftritt. Folgende Dinge fallen mir am Code auf: Das "if __name__ == "__main__":" kannst du dir an der Stelle sparen, du bist da ja schon mitten im Programm. Wenn du dir die IPConnection weiter außen hältst, musst du nicht jedes Mal eine neue Verbindung aufbauen, wenn du einen Temperaturwert abfragen willst get_temperature() kann (wie fast alle anderen Funktionen der Bricks/Bricklets auch) Timeouts erzeugen, wenn aus irgendeinem Grund die Abfrage länger als (falls nicht umkonfiguriert) 2,5 Sekunden dauert. Je nachdem was sonst noch auf dem System passiert, kann das durchaus passieren. Am besten ist es, wenn du den Fehler fängst und behandelst, im einfachsten Fall probierst du es einfach nochmal, bis z.b. 5 Versuche nicht geklappt haben. Das kann z.b. so aussehen: from tinkerforge.ip_connection import Error # 3 Versuche, danach geben wir auf for i in range(3): try: temp = thermocouple.get_temperature() # Wenn der Aufruf geklappt hat, verlasse die Schleife break except Error as e: if e.value != Error.TIMEOUT: # Wenn der Fehler kein Timeout war wird er zum Aufrufer weitergegeben. raise e else: # Das else einer for-Schleife wird ausgeführt, wenn kein break in der Schleife getroffen wurde # Das heißt in diesem Fall, dass alle 3 Versuche Timeouts erzeugt haben print("Konnte Temperatur nicht abfragen") Damit du das nicht bei jedem Aufruf machen musst, kannst du dir das wie folgt in eine Funktion packen: from tinkerforge.ip_connection import Error def attempt_n_times(fn, name, attempts): for i in range(attempts): try: return fn() except Error as e: if e.value != Error.TIMEOUT: raise e print("Konnte {} nicht ausführen: {} Timeouts".format(name, attempts)) return None temp = attempt_n_times(thermocouple.get_temperature, "Temperaturabfrage", 3) attempt_n_times(lambda: thermocouple.set_configuration(16, 3, 0), "Thermocouple-Konfiguration", 3) Achtung: Das sind Codebeispiele für das Thermocouple Bricklet, das musst du noch auf das Temperature 2.0 oder PTC 2.0 Bricklet anpassen. Du scheinst ja beide zu benutzen. Warum die Timeouts bei dir manchmal gehäuft auftreten ist mir spontan nicht klar. Eventuell stört dein TK-Schrank die Signale? Gruß, Erik

Das ist eine gute Frage. Ich würde an deiner Stelle mal folgendes testen: Du stellst das Voltage-Callback bei beiden Bricklets auf 2ms Periode, value_has_to_change false. Dann solltest du von jedem Bricklet 500 Callbacks pro Sekunde bekommen (das solltest du nachmessen, nicht dass bei deinem Aufbau/Programm noch irgendetwas limitiert). Da du hinter einem Master Brick auf 1000 Nachrichten pro Sekunde limitiert bist, kannst du nicht bei beiden Bricklets auf 1ms Periode gehen. Danach kannst du auf die Bricklets ein Synchronisationssignal legen, z.b. eine Rechteckspannung. Du solltest dann auf den Daten von beiden Bricklets den ersten Sprung sehen und kannst damit die Messungen korrelieren, relativ zum ersten Sprung sollte die jeweils n-te Messung im schlimmsten Fall ~4ms auseinanderliegen. Das basiert aber auch auf der Annahme, dass die Clocks der Bricklets nicht driften, das würde ich also nicht über Stunden laufen lassen. Das nächste Problem ist dann, dass das Sampling selbst nicht synchron ist. Du siehst schon, dass das in Summe extrem schwierig ist, an sinnvoll synchrone Daten zu kommen. Bist du dir ganz sicher, dass du für Zellspannungen (Ich gehe mal davon aus von Batteriezellen?) so starke Zeitanforderungen hast? Ich würde eigentlich erwarten, dass die Messwerte relativ träge sind.

Hm, da wirst du glaube ich nicht glücklich mit den Bricklets. Intern laufen die Bricks und Bricklets mit einer Tickrate von 1000 Hz, der Master Brick kann also höchstens eine Messung pro Millisekunde wegtransportieren. Theoretisch könnten die Bricklets alle gleichzeitig messen und du hast den Zeitversatz nur in der Kommunikation, aber auf so kleinen Zeitskalen ist das praktisch unmöglich zu synchronisieren, sorry.

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