piwo2 Posted May 2, 2024 at 10:40 PM Posted May 2, 2024 at 10:40 PM (edited) folgende pip-warnung exisitert (schon länger) : DEPRECATION: Loading egg at /usr/local/lib/python3.12/site-packages/tinkerforge-2.1.31-py3.12.egg is deprecated. pip 23.3 will enforce this behaviour change. A possible replacement is to use pip for package installation.. könnt ihr euch das mal ansehen ? lg w Edited May 2, 2024 at 10:40 PM by piwo2 Quote
photron Posted May 3, 2024 at 08:29 AM Posted May 3, 2024 at 08:29 AM Die Lösung ist wie pip schon selbst schreibt: pip install Ich habe gerade alle Varianten durchprobiert die wir dokumentieren, um die Python Bindings zu installieren. Wir liefern das egg-info nicht direkt aus. Das veraltete egg Format wird durch "python setup.py install" erzeugt. Ich vermute du hast die Python Bindings darüber installiert. Laut Dokumentation, die ich dazu finden konnte, ist es deprecated setup.py direkt aufzurufen. Man soll stattdessen "pip install ." im Verzeichnis ausführen, in dem die setup.py Datei liegt. Das installiert die Bindings dann im aktuellen dist-info Format. Danke für den Hinweis. Quote
piwo2 Posted May 5, 2024 at 11:07 AM Author Posted May 5, 2024 at 11:07 AM die egg-deprecation warning des pip3.12 ist seit meinem (system-) umstieg auf python 3.12 penetrant geworden. installiert habe ich immer wie befohlen ;-) habs auch für die doku hier eher mehr geschrieben, was ja nun durch ist. Quote
piwo2 Posted May 5, 2024 at 11:27 AM Author Posted May 5, 2024 at 11:27 AM so nebenbei : könnte man nicht mal den brick-logger und den tinkerforge_mqtt verheiraten in ein lösung ? ob ich nun ein csv schreibe oder den pub-sub-zirkus veranstalte ist ja einigermassen egal ... es ist ganz praktisch, gleich im brickv sämtliche dinge zu konfigurieren, die man haben möchte und eine brick-logger config zu schreiben. kann auch sagen, wozu das gut ist : ich habe momentan im systemd jede menge Exec=tinkerforge_mqtt BindsTo=mosquitto laufen, da ich mich entschieden habe sämtliche tinkerforge-daten via mqtt laufen zu lassen das mit den jsons zu konfigurieren ist immer etwas zäh und ich fände es wirklich gut, wenn nach jahrzehnten endlich ein friktionsfreie möglichkeit bestünde, die daten von den bricklets endlich in eine halbwegs brauchbare form gebracht zu kriegen !!! lg w Quote
jedie Posted May 6, 2024 at 03:10 PM Posted May 6, 2024 at 03:10 PM Kannst ja mal ein Blick auf mein https://github.com/jedie/tinkerforge2mqtt werfen ;) Aber vollständig ist das noch lange nicht... Quote
piwo2 Posted May 7, 2024 at 10:45 AM Author Posted May 7, 2024 at 10:45 AM (edited) @tinkerforge wallboxen ist super, hab auch eine, aber ich würde mir da was von euch wünschen. vor allem nach dem openhab-desaster hier ... habe schon zig-mal versucht tinkerforge-code auf github zu "adaptieren" ... jaja alles gewachsener code und super strukturiert ... sorry, das stemmt keiner, der den moloch nicht in-und-auswendig kennt. und die mqtt-topics sind ja echt super. aber mit keinem standard für keine things verheiratbar. @jedie danke. ist eine sehr gute sache das mit ha. der standard wird wenigstens breit unterstützt "ha-kompatibel" ist ja gottseidank weiter verbreitet. spannend wirds halt immer, wenn man nicht so wie es die tinkerforge-philosophie vorsieht massiv mit einem generator für sämtliche bricks/bricklets drüberfahren kann. habe schon zig projekte gesehen, auch selber was begonnen. dann werden halt ein paar bricklets für den eigenbedarf codiert und der rest ist wunschdenken. ist oft gar nicht so leicht, wenn man sich im code nicht so gut auskennt vom design her, was ja nur der entwerfer wirklich gut kann ... bestes beispiel patrick baus mit einer tollen async-variante. kann ja jeder mal bei github suchen und mich prügeln, sollte das nicht stimmen. resumee : ich glaube, es gäbe - wie gesagt im sinne einer mqtt-isierung (vom brick-logger oder sonstwas) seitens tinkerforge echt handlungsbedarf. von einer unterstützung von projekten mit einem python-interface-code-generator ganz zu schweigen. p.s. github-code-suche : tinkerforge "async with" (respektive __aenter__, oder auch nur "async") : ausser bei p.baus findet man sowas ja auch schon bei tinkerforge/generators aber sonst : alles sehr sehr überschaubar ... detto for __enter__ __next__ __iter__ ... contextmanager ? generatoren ? die natürlichste sache der welt ? ergebnis noch überschaubarer ... habe mir da auch schon die finger gebrochen angesichts der low-level-api. machste mal für 2-3 bricklets, dann gibt man auf. ich blamier mich doch nicht auf github mit ein paar würstchen. da muss schon das ganze universum rein. und das stemmste nicht .... ich hab auch den code mit wonne gelöscht und die verplemperte zeit als "lessons learned" abgeschrieben. war das einzige vergnügen dabei ... Edited May 7, 2024 at 11:21 AM by piwo2 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.