rtrbt

Was es nicht alles gibt. Auf dem LCD ist dann auch nichts zu sehen? Soweit ich das sehe, (sind das diese Nodes?) sind die für Items, nicht für Actions. D.h. du müsstest irgendwie ein Item für den Text-Channel des LCDs anlegen und da dann einen String im Format "0,1,Hello World!" reinschreiben. Wenn du Node-RED benutzen willst kannst du aber alternativ zu den openHAB-Bindings auch die MQTT-Bindings verwenden, Node-RED kommt mit MQTT ziemlich gut klar.

Das ist eine gute Frage, ich habe das immer nur über die PaperUI gemacht. Da kannst du sowohl das Item anlegen (blau) als auch den Channel konfigurieren (rot). Wenn du das zwingend über die Textdateien machen willst: Ich habe beim danach suchen diesen Thread gefunden, das sieht so aus als könnte es funktionieren. Edit: Man sollte das Bild auch anhängen

Das macht der Brick Viewer für dich.

Moin, Hast du die tinkerforge-2.1.26.jar aus der Java-Bindings-Zip oder aus der openHAB-Bindings-Zip? Mir fällt gerade auf, dass die nicht die selben sind, zweitere sind ein Maven-Bundle. Ich editiere mal meinen Post oben, da linke ich auf die falsche Datei, sorry dafür. Führe in der Konsole mal sha256sum /usr/share/openhab2/addons/tinkerforge-2.1.26.jar aus. Korrekt ist die 22c9d235f1c62c29a4ec4c9d1feccccf0e6f8b33. Wenn du da etwas anderes rausbekommst, musst du die Datei durch die aus den openHAB-Bindings ersetzen.

Hi, By rebooting the Pi you mean power cycling it or just a software reboot? A software reboot does not restart the connected Master Brick, so this would indicate, that your problem is not the Brick or the Motion Bricklet. If this happens again, it would be interesting to see, if you can still connect to the Pi with Brick Viewer and if so, whether the Motion Bricklet is still working. Also the Brick Daemon log (/var/log/brickd.log) could be useful.

Moin, Das das Bricklet nach dem Reset nicht wieder auftaucht liegt vermutlich daran, dass dessen Enumerate-Paket verloren gegangen ist. Wenn du Reconnectest, löst das auch eine Enumerierung aus, dann taucht das Bricklet wieder auf. Bezüglich der hängenden Temperatur selbst: Teste mal bitte die angehangene Firmware, die I2C-Kommunikationsfehler subtil anders behandelt, eventuell löst das dein Problem. Ich habe meinen Aufbau hier auch darauf umgestellt. temperature-v2-bricklet-firmware.zbin

Moin, Das sieht aus als ob du das Programm nicht als Root startest. Die Root-Rechte brauchst du, damit du auf die SPI-Schnittstelle zugreifen darfst. Eventuell musst du erst set_configuration und dann die set_(continuous_)acceleration_callback_configuration aufrufen. Habe ich aber nicht getestet. Ich habe das hier mal getestet und komme auf 1850 Pakete pro Sekunde, also ~13900 Werte pro Sekunde und Bricklet (d.h. es würde für 16-Bit-Werte einer Achse mit 12800Hz reichen). Ich habe dabei die BRICKLET_STACK_SPI_CONFIG_MAX_SPEED_HZ in hal_linux.c auf 2000000 gesetzt, dann läuft die SPI-Kommunikation mit 2MHz, was das Maximum ist, das die Bricklets können und die Callback-Tick-Optimierung eingebaut, die ich erwähnt hatte. Ich habe dann mal mit dem Logic-Analyzer nachgesehen und festgestellt, dass selbst wenn ich das Programm "ideal" optimieren würde, man nicht die 25600 Hz bei 4 Bricklets schaffen wird: Der Linux-Kernel macht zwischen jedem Byte eine etwas längere Pause, die effektive Durchschnittsfrequenz liegt bei ~1.76 MHz. Mit der Frequenz kommt man dann auf 220 kByte/s unter der Annahme, ich könnte durchgängig Daten per SPI senden/empfangen. Ein Paket hat 60 Byte Payload, dazu 11 Byte Protokollheader usw. macht 71 Byte, ergibt ~3100 Pakete pro Sekunde, also 23250 Werte pro Sekunde und Bricklet. Durch den Overhead des Programms und weil ich auch auf das Bricklet warten muss, bis ein Acknowledgement kommt usw. verliert man dann nochmal einiges, auch deshalb, weil es vorkommt, dass aufgrund von Timing-Pech das Pi oder das Bricklet ein Paket neu senden muss. Falls du wirklich den vollen Durchsatz brauchst, sehe ich als Option nur noch, dass du einen ESP32 nimmst. Der ESP hat zwei benutzbare SPI-Einheiten, theoretisch könntest du einen HAL für jede SPI-Einheit anlegen und dann die HALs und deren zugeordnete Bricklets mit jeweils einem eigenen Thread auf einem der zwei Kerne des ESPs laufen lassen.

Der Tick macht genau was du schreibst: Er blockiert für die übergebene Zeit und liefert Callbacks des Bricklets aus. Da auf einem Mikrocontroller kein Multitasking verfügbar sein muss, muss man das als Nutzer händisch machen. Hm, da hast du recht, für deinen Fall sind die 250µs wirklich sinnvoller. Noch ein Gedanke: Du willst ja eigentlich nicht die 250µs stehen, sondern falls innerhalb dieser Zeit ein Callback ankam weißt du ja, dass das nächste erst eine Millisekunde später kommen kann. Die Restzeit kannst du sinnvoller verwenden. D.h. ich baue in den Callback-Tick ein, dass du einen Timeout von 0 mitgeben kannst, das heißt dann "versuche ein Callback zu empfangen, falls gerade eins da ist, wenn nicht, brich sofort ab". Dann kannst du in deiner Loop alle Callbacks mit 0 als Timeout ticken und solltest damit nochmal deutlich effizienter sein. Du kannst ein ähnliches Verhalten testen, indem du TF_TFP_SLEEP_TIME_US in bindings/tfp.c auf z.b. 50 setzt und dann die Callback-Ticks mit z.B. 100µs aufrufst.

Hi Claudio, Die Demo sieht soweit gut aus, es kann aber sein, dass du den Callback-Tick pro Device etwas länger ziehen musst, auf dem Raspberry Pi kann es dir bei ungünstigem Scheduling sonst passieren, dass du auf einem Device garnicht tickst und auf einem anderen dafür mehr, ist ja kein Echtzeitsystem. Bei meinen Tests meine ich mich daran erinnern zu können, dass etwas im Bereich 500 oder 1000µs besser lief. Ob das Continuous Callback schneller läuft als mit dem Brick Daemon würde mich auf jeden Fall auch interessieren, poste da mal deine Ergebnisse, wenn du getestet hast. Ich benutze im Linux-HAL zwar den selben Code wie der Brick Daemon, aber es gibt ein paar Stellen an denen ich aggressiver mit den Timings sein kann (Zielplattform sind ja Mikrocontroller), da kann es gut sein, dass du etwas mehr Performance rausziehen kannst. Die drei Callbacks gibt es garnicht, Connect und Disconnect fallen weg weil kein Brick Daemon läuft, zu dem man sich verbinden kann, Enumerate fällt weg, weil die Bindings beim hal_init nachsehen, welche Devices angeschlossen sind, danach aber nur mit diesen Devices arbeiten. High-Level-Callbacks sind Callbacks, die High-Level-Funktionen sind. (So weit, so nichtssagend). High-Level-Funktionen sind alle die intern streamen, also einen Funktionsaufruf der Bindings, bestes Beispiel dafür ist write_pixels vom LCD 128x64, in mehrere Pakete aufteilen, weil der Payload (in diesem Fall bis zu 128*64 boolsche Werte) nicht in ein Paket passt. High-Level-Callbacks sind dann zum Beispiel die für die Thermal-Bilder vom Thermal Imaging Bricklet oder das Spektrum des Sound Pressure Level Bricklets. Edit: Alle High-Level-Funktionen (also auch die Callbacks) haben eine entsprechende Low-Level-Variante. Man kann die Funktionalität also trotzdem verwenden, muss sich aber das Streaming selbst implementieren. Ich habe die High-Level-Callbacks mit vorgegebener Streaming-Implementierung rausgenommen, da die Daten temporär gehalten werden müssen, sie aber definitiv zu groß für den RAM eines Mikrocontrollers sind. (z.B: 80*60*2 =9600 Byte für das Thermal-Bild) Wenn man als User jetzt seine eigene Streaming-Logik implementiert, kann man z.b. ohne dass man das ganze Thermal-Bild im RAM hält, die wärmste Stelle im Bild finden.

Moin, Nimm wie gesagt nur das NodeMCU mit dem HAT, der MEGA hat 5V Logikpegel, damit kannst du dir im schlimmsten Fall das HAT beschädigen. (Das HAT hat 3,3V Logikpegel, ich habe bei mir auf dem Tisch eins liegen, dass ich vermutlich genau mit diesem Fehler kaputt gemacht habe.) Es gibt 5 CS-Pins, weil das HAT Zero selbst einen Koprozessor hat. Aus Sicht der Bindings ist das HAT auch ein Brick, mit dem du Daten austauschen kannst. Im Sketch musst du die Pins auflisten, die du auf deiner Seite benutzt, also wenn du den MEGA weiter benutzt (mach das wie gesagt nicht!) wäre folgendes korrekt: TF_Port ports[5] = {{ .chip_select_pin=53, .port_name='A' }, { .chip_select_pin=49, .port_name='B' }, { .chip_select_pin=47, .port_name='C' }, { .chip_select_pin=45, .port_name='D' }, { .chip_select_pin=43, .port_name='I' }}; Ich vermute, dass deine Probleme mit dem Fehler -10 (errors.h sagt, das ist TF_E_DEVICE_NOT_FOUND) daher kommen, dass der MEGA die Antworten der Bricklets nicht versteht, weil ein 3,3V High nicht stark genug ist.

Hi, If you use ti.set_spotmeter_config([20,20,40,40]) it should work: set_spotmeter_config requires an array of 4 elements instead of passing the four parameters directly.

Moin, Hast du auf deinem Rechner auch eine statische IP konfiguriert? Auf der Extension läuft kein DHCP-Server. Folgende Einstellungen sollten beispielsweise funktionieren: Auf dem Rechner mit dem du dich auf die Extension verbinden willst: Adresse 10.0.0.2 Netzmaske 255.255.255.0 Gateway 10.0.0.1 Im Brick Viewer des Rechners musst du dann 10.0.0.1 als Host eintragen. Gruß, Erik

Das hängt davon ab was für ein Brick/Bricklet das ist, bei dem du den Button drückst. Wenn du einen Brick oder ein altes 10-Pol-Bricklet resettest, startet der ganze Stapel neu. Wenn es ein 7-Pol-Bricklet ist, dann nur das Bricklet selbst. Danke, ich baue das hier mal nach. Falls sich da was tut, melde ich mich nochmal.

Moin, Das stimmt, also wurde dein Callback nicht einfach durch einen Reset deaktiviert. Soweit ich das aus der Firmware des Bricklets sehe, gibt es zwei Möglichkeiten was da passiert: Der Sensor selbst bleibt auf einem Wert hängen und gibt diesen aus irgendeinem Grund immer zurück. (Halte ich für unwahrscheinlich) Die I2C-Kommunikation zwischen Sensor und Bricklet-Prozessor ist gestört und zwar so, dass die Fehlerbehandlung der Bricklet-Firmware das nicht wieder repariert bekommt. Eventuell ist ein Bug in der Firmware, der die Kommunikations-State-Machine so durcheinander bringt, dass das Bricklet in einer Reinitialisierungsschleife hängt o.Ä. Auf deiner Seite ist das vermutlich nur zu lösen, wenn du den Wert in deinem Programm überwachst und wenn er untypisch lange hängt das Bricklet resettest. Mir ist aber auch unklar, warum es bei dir zwei Resets braucht. Hast du eventuell nach dem ersten nicht lang genug gewartet? Ich stelle hier mal einen Aufbau mit einem Temperature Bricklet 2.0 hin, eventuell bekomme ich das Problem reproduziert. Welche Callback-Konfiguration benutzt du für das Bricklet?

Moin, Da geht es tatsächlich nur um die Geschwindigkeit, wenn du die Liste leer anlegst und immer neue Daten appendest, muss Python ziemlich oft intern eine neue (größere) Liste anlegen und die Daten kopieren. Das ist aber bei der relativ kleinen Problemgröße (und der Tatsache, dass auf das E-Paper zeichnen im Vergleich dazu ewig dauert) vermutlich egal. Die Formel benutze ich zur Umrechnung von (x,y)-Koordinaten in den eindimensionalen Index. Das hilft immer sich es als Bild vorzustellen, so wie hier zum Beispiel (Stride und Width sind bei unserem Bildformat identisch). Im Endeffekt überspringe ich y vollständige Bildzeilen mit y * WIDTH, dann bin ich bei der aktuelle Bildzeile, das + x ist dann in der aktuellen Zeile die Spalte die ich schreiben will. Weil mir das gerade noch aufgefallen ist: Du kannst die etwas verwirrende data[y,x] Vertauschung loswerden, wenn du die for-Schleifen-Indices umbenennst, x ist ja eigentlich die Spaltenkoordinate, y die Zeilenkoordinate.

Moin, Das stimmt, mein Satz klingt etwas verwirrend, ich meinte "neben" im Sinne von "Im Ordner daneben liegend" nicht "neben den openHAB-Bindings Version 2.1.26....". Beta 23 ist die aktuelle openHAB-Bindings-Version.

Moin, Die aktuelle Beta braucht neben den openHAB-Bindings auch die Java-Bindings in Version 2.1.26 (findest du hier). Die Jar kannst du einfach neben die der openHAB-Bindings selbst legen, dann sollte es funktionieren. Gruß, Erik Edit: Die Java-Bindings aus der Zip und die aus den openHAB-Bindings unterscheiden sich subtil. In den openHAB-Bindings liegt die korrekte Version, die ein Maven-Bundle ist.

Moin, Die API des E-Paper-Bricklets erwartet nicht, dass du die Pixel in ints packst. Du kannst direkt ein Array von boolschen Werten übergeben, den Rest machen die Bindings. So sollte es funktionieren: pixel_matrix = [False] * WIDTH * HEIGHT for x in range(WIDTH): for y in range(HEIGHT): pixel_matrix[y * WIDTH + x] = data[x, y] == 1 epaper.write_black_white(0, 0, WIDTH - 1, HEIGHT - 1, pixel_matrix) eppaper.draw() Gruß, Erik

Da würde ich zusammengefasst sagen "Nimm nur das NodeMCU und kauf dir ein HAT Zero Brick ". Das hat die korrekten Trenner/Buffer-Chips und du kannst 4 Bricklets anschließen ohne dass du Breakout Bricklets brauchst. Das HAT hat auch 3,3V Logikpegel, also sollte es am NodeMCU funktionieren. Wenn du das am Arduino machen willst, musst du dann doch etwas basteln: Wir benutzen den 74AHC244 als Trenner-Chip, damit kann man zwei Ports auf einmal verschalten. Der 74AHC125 scheint das Äquivalent dafür zu sein, wenn du nur einen Port brauchst. Du kannst dir die Schaltung vom bald erscheinenden Breakout Bricklet 2.0 ansehen, den ich angehangen habe. Die Schaltung oben links mit dem LD1117 und den CONN_01X03 Jumper kannst du weglassen, wenn du direkt 3,3V und 5V vom Arduino bekommst, für das Breakout Bricklet haben wir das eingebaut, damit man nur 5V einspeisen muss. Die 82Ω Widerstände und die 220pF Kondensatoren brauchst du auch nicht unbedingt. Der Rest sollte auf einem Breadboard aufbaubar sein. Nein. (Bzw. nur ein Isolator Bricklet und dahinter ein anderes) Die Ports sind nicht an die Bricklets gekoppelt: Du musst nur deklarieren, welche Ports es gibt und welcher Pin der zugehörige Chip-Select-Pin ist. Die HAL-Initialisierung fragt dann einmal an allen Ports ab, welche Bricklets angeschlossen sind. Nein, weil du pro Port mehr als ein Bricklet angeschlossen haben kannst. (Im Moment z.B. wenn du ein Isolator Bricklet benutzt) breakout-V2.pdf

Sehr gut, ich habe den Fix mal in Beta 2 gepackt. Der hal_arduino_avr heißt jetzt hal_arduino. Ich habe den HAL hier auch mit einem Teensy (der hat einen ARM-Prozessor) getestet, deshalb die Namensänderung. Das hatte ich übrigens nur so gebaut, damit ich die selbe Demo-Implementierung für die Linux-Demo benutzen kann, der Arduino-Compiler läuft in Linkerprobleme wenn man ein normales Include benutzt weil die demo eine .c, keine .cpp ist.

Teste bitte mal die Version der Bindings im Anhang. Ich glaube ich habe das Problem gefunden. Außerdem habe ich die io4ledbtn.c leicht verändert angehangen, die Signatur deines Callbacks passte nicht ganz: Der erste Parameter ist entgegen der Dokumentation ein Zeiger auf das Device von dem das Callback kam. Das muss ich mal ins README schreiben. Außerdem benutze ich da jetzt den callback_tick und gebe eventuelle Fehler aus. (Nur den Return Code, für die Fehlerbeschreibungen ist der RAM des Unos zu klein) PS: Ich habe gerade keinen Button zur Hand und deshalb nur mit einem Kabel Pin 1 der IO-4 auf Masse gezogen, ist das beabsichtigt, dass man immer zweimal drücken muss, damit die LED an oder aus geht? io4ledbtn.c tinkerforge_uc_bindings_2_0_0_rwblinn.zip

Hm ich teste das hier gerade auch, habe aber noch nicht gefunden, was genau kaputt ist. Ich melde mich morgen nochmal mit mehr Informationen.

Das hängt vom Bricklet ab. Manche brauchen die 5V, aber bei vielen ist das einfach auf Brickletseite nicht verbunden, weil sie mit 3,3V auskommen. Die Kurzfassung ist du kannst in deinem Buttonbeispiel anstelle von dem tf_io4_v2_get_value(&io, io_ret_value); in der io4ledbtn_loop-Funktion folgendes machen: tf_io4_v2_callback_tick(&io, 250); Das blockiert für 250µs und holt Callbacks ab, ohne dass du unnütz den Getter ausführst. Im Callback selbst hast du // <TODO> This function is not triggered - need to explore why // tf_io4_v2_set_selected_value(&io, 0, led_state); Die Funktion würde nicht ausgeführt werden, weil prinzipiell keine Ausführung von Device-Funktionen in Callbacks erlaubt ist. D.h. das richtige Vorgehen ist, wie du es auch gemacht hast, im Callback nur Informationen zu ändern, die du dann in der Loop benutzt.

ATTENTION: Arduinos with an AVR microcontroller (for example the Arduino Uno or Mega) use a logic level of 5V. Bricklets use a logic level of 3.3V. A level shifter is required between the Arduino and any bricklet. Edit: Here's the official documentation. Hi, After multiple customer requests to be able to control Bricklets directly with a microcontroller, I've spent the last months creating bindings to be able to do so. The first beta version of the C/C++ bindings for microcontrollers are attached to this post. With them you can control Co-processor bricklets using for example an Arduino over SPI. The bindings are separated in a common implementation and Hardware Abstraction Layers (HALs) for the specific platforms. At this time a HAL for Arduino AVR and ESP32 boards and a HAL for the Raspberry Pi (Zero) with a Hat (Zero) Brick are available. Further information about the interface of the bindings, and on how to implement custom HALs for other boards can be found in the documentation. In the future there will be additional hardware for the bindings: An ESP32 based board on that programs using the bindings can be executed, as well as a new Breakout board that allows connecting multiple Bricklets to a micro controller. Cheers, Erik Edit: Beta 8 with the following change: Fixed a bug where callbacks stopped working after 35 minutes This will probably be the last beta version. However the beta phase will continue until the hardware for the bindings is released. tinkerforge_uc_bindings_2_0_0_beta_8.zip

Moin, Erstmal danke für die Tests! Es überrascht mich etwas, dass der Aufbau funktioniert: Der Arduino Uno hat ein Logik-Pegel von 5V, das Bricklet ist 5V kompatibel, schickt selbst aber nur 3,3V über die MOSI-Leitung. Du hast anscheinend das Glück, dass dein Arduino die 3,3V High-Signale versteht, bei meinem hat das nicht funktioniert. Falls du mit irgendeinem Bricklet keine Antworten bekommst, liegt es vermutlich daran. Zu dem TODO bei deinem Push-Button-Test: Die Callbacks kommennur, wenn du eine Funktion aufrufst, da sonst keine Kommunikation mit dem Bricklet stattfindet. Es gibt aber pro Device eine Callback-Tick-Funktion, z.B. int tf_io4_v2_callback_tick(TF_IO4V2 *io4_v2, uint32_t timeout_us); Die Funktion blockiert für die übergebene Zeit (in Mikrosekunden) und liefert Callbacks aus die reingekommen sind. D.h. wenn du in deiner Loop noch Zeit übrig hast ist es sinnvoll bei allen Bricklets bei denen du Callbacks benutzt die Funktion aufzurufen. Wenn du die ganze Zeit mit dem Bricklet kommunizierst, z.b. bei dir mit get_value, werden die Callbacks dann ausgeliefert, wenn sie während des getters reinkommen. Die Tick-Funktion werde ich mal im Readme dokumentieren. Eventuell kommt noch eine allgemeinere Tick-Funktion, die alle Bricklets mit registrierten Callbacks tickt. Gruß, Erik Edit: Was mir noch aufgefallen ist: In deinem Callback-Handler hast du einen auskommentierten Funktionsaufruf auf dem IO4 Bricklet. Die Bindings unterstützen es aber nicht, aus einem Callback heraus wieder Funktionen aufzurufen, da ein Callback auch mitten in einem anderen Funktionsaufruf ankommen kann.