Tinkerforge Python Asyncio Bindings

[maat]

Die Sache mit den Tinkerforge Bindings und Asyncio wird ja alle Jahre wieder einmal durchgekaut (z.B. hier oder hier). Ich bin nicht besonders glücklich darüber gewesen wie es von @borg vorgeschlagen wurde die TF Bindings in einen Threadpool zu packen. Das macht die ganze Sache sehr, sehr unübersichtlich und man kann kaum erkennen was hier eigentlich noch passiert. Außerdem ist der Code der IP connection über die Jahre ein scheinbar immer mehr organisch gewachsen, so dass hier mehr und mehr Code rein gewandert ist, welcher eigentlich gar nichts mehr mit der IP connection zu tun (no offsense).

Da wir die Bricklets aber mit großer Freude im Labor zum Loggen einsetzen, und ich das neue Backend gerne komplett in asyncio haben will, habe ich mich dran gesetzt und einfach eine komplett neue Implementierung der API angefangen. Das Ganze ist auf Github zu finden:

https://github.com/PatrickBaus/TinkerforgeAsync

Ich habe bisher alle Bricklets implementiert, die ich in die Hände bekommen habe und ein paar Änderungen an der API vorgenommen, die mich entweder gestört haben oder, die nicht zu asyncio gepasst haben. Eine Übersicht der Änderungen ist auf der Github Seite. Die größte Änderung ist sicherlich, dass ich von den base58 codierten uids zu Integern gegangen bin. Hier bin ich aber noch am überlegen, ob ich nicht zumindest auf der Eingabeseite beides akzeptieren sollte.

Was die Codestruktur angeht, so habe ich versucht die IP connection extra simpel zu halten und das ganze Dekodieren (außer dem Header) in die bricks/bricklets auszulagern. Dadurch fällt zum einen diese komplett absurde Struktur der High-Level-Callbacks weg und zum anderen bleibt der Code auch schön lokal sichtbar und man wurschtelt nicht in der IP connection irgendwelche Spezialfälle durch.

Ich würde mich über Feedback freuen.

bearbeitet February 9, 2021 at 00:26 von maat
Fixed typos

[borg]

Cool!

Ein Hinweis dazu: Die Bindings (und Dokumentation und Beispiele) werden generiert und sind nicht handgeschrieben: https://github.com/Tinkerforge/generators/tree/master/python

Dadurch ist die Implementierung der API an einigen Stellen etwas umständlich/unübersichtlich. Ist aber die einzige Möglichkeit für uns das Kreuzprodukt aus 15 Programmiersprachen, 120 Produkten mit Dokumentation und je drei Beispielen langfristig zu warten.

[Testling]

Hallo maat,

 

kurze Frage zu deiner Implementierung:

Ist der Unterschied in der Ausführungsgeschwindigkeit zwischen deiner und der nativen Python Bindings groß?

ich würde gerne für eine Projektarbeit ein RPi 4B mit HAT Brick als Messrechner aufsetzen. Daher wäre die Frage für mich relevant.

 

Danke für deine Antwort.

 

Viele Grüße 

Testling 

 

bearbeitet October 2, 2022 at 14:29 von Testling

[maat]

Hallo Testling,

ich würde zunächst einmal sagen, dass es zumindest bei kleineren Installationen von sagen wir mal unter 100 oder 1000 bricks keinen großen Unterschied machen wird, was die Geschwindigkeit angeht.

Vielmehr ist es von Interesse mit welcher Architektur du arbeiten willst. Wenn du ohnehin schon überall Threads verbaut hast und damit auch die Callback Architektur übernommen hast, dann ist das original Binding sicherlich der bessere Weg.

Wenn du Callbacks vermeiden willst und lieber mit Generatoren arbeiten willst, dann empfehle ich dir die Asyncio Bindings. Das ist vornehmlich eine Frage des Geschmacks.

Ich bin damals auf Asyncio gewechselt, weil ich ein dynamisches System haben wollte, so dass ich Config Updates in Echtzeit einspielen kann. Nach etlichen Versuchen das über die Standardbindings zu machen habe ich aufgegeben. Bei Dutzenden von Sensoren wird das mit den Callback einfach nur noch ein Chaos. Du weißt nie wo sich gerade welche Information befindet, weil sich alle möglichen Callbacks untereinander aufrufen. Um das Programm dann übersichtlich zu gestalten bot sich eine Pipeline/Stream Architektur an. Siehe https://reactivex.io/. Durch die Streams ist der gesamte Informationsfluss sofort ersichtlich und klar. Seit dem sauge ich fleißig Daten aus grob 200 Sensoren in eine Datenbank und bereite das Ganze über Grafana auf.

[Testling]

@maat

danke für Information. Dann macht das für mich wahrscheinlich keinen Sinn. Denn meine Projektarbeit umfasst Max. 8 Bricks und einen HAT. 
Dann nutze ich erst einmal das Standardbinding und schaue dann. Danke :-)