piwo2

@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 ...

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

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.

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

gibt es irgendwann trixie ode bleibt es bei bookworm ? danke & lg w p.s. .gpg ist deprecated statt wget https://download.tinkerforge.com/apt/$(. /etc/os-release; echo $ID)/tinkerforge.gpg -q -O - | sudo tee /etc/apt/trusted.gpg.d/tinkerforge.gpg > /dev/null konvertieren in .asc wget -qO /tmp/tinkerforge.gpg https://download.tinkerforge.com/apt/debian/tinkerforge.gpg gpg --keyring /tmp/temp.gpg --no-default-keyring --import /tmp/tinkerforge.gpg gpg --keyring /tmp/temp.gpg --no-default-keyring --export -a | sudo tee /etc/apt/trusted.gpg.d/tinkerforge.asc >/dev/null rm -f /tmp/tinkerforge.gpg /tmp/temp.gpg ... oder als intelligenter einzeiler falls das möglich ist, was ich nicht glaube ... oder gleich zusätzlich ein tinkerforge.asc deployen ?

dies wird beim installationsprozess automatisch gemacht, wenn man den "normalen" user als admin deklariert ... mag heissen, member von dialout ist der fall ... [rotten@vlap-wp ~]$ grep dialout /etc/group dialout:x:18:rotten der /dev/ACM1 (oder wie er auch immer heisst, nagel mich nicht fest) der das flash-device unter fedora ist, spielt offensichtlich beim dialout nicht mit tty* schon ... genügt das ?

... schon mal versucht einen brick zu flashen OHNE sudo/root ? das serial-device wird dir was pfeifen ...

ok. funkt. kleine frage noch : ich sehe schon länger, dass ein "sudo brickv" offensichtlich eine andere gui erzeugt als "brickv". die fehlende XDG_RUNTIME_DIR mittels "sudo XDG_RUNTIME_DIR=/run/user/0 brickv" zu spezifizieren ändert nichts .... darüber hinaus wirft "brickv" bei mir folgenden fehler : "qt.qpa.qgnomeplatform.theme: The desktop style for QtQuick Controls 2 applications is not available on the system (qqc2-desktop-style). The application may look broken." ..... und so sieht es auch aus : vollkommen unleserlich .... würde mich nur grundsätzlich interessieren, wie beides zustande kommt, bzw. ob da mit fedora-37 (cinnamon desktop) was zu tun ist. lg wolfgang

no deal - meckert jetzt anders ... building Debian package dpkg-buildpackage: info: source package tinkerforge-brickv dpkg-buildpackage: info: source version 2.4.25 dpkg-buildpackage: info: source distribution stable dpkg-buildpackage: info: source changed by Matthias Bolte <matthias@tinkerforge.com> dpkg-buildpackage: info: host architecture amd64 dpkg-source --before-build . dpkg-checkbuilddeps: error: Unmet build dependencies: debhelper (>= 10) dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting dpkg-buildpackage: warning: (Use -d flag to override.) Traceback (most recent call last): File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg.py", line 264, in <module> exit_code = main() ^^^^^^ File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg.py", line 252, in main build_linux_pkg() File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg.py", line 141, in build_linux_pkg utils.build_debian_pkg() File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg_utils.py", line 206, in build_debian_pkg system(['dpkg-buildpackage', '-us', '-uc'], cwd=self.build_data_dest_path) File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg_utils.py", line 33, in system subprocess.check_call(command, **kwargs) File "/usr/lib64/python3.11/subprocess.py", line 413, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['dpkg-buildpackage', '-us', '-uc']' returned non-zero exit status 3. ==================== patch build_pkg_utils.py <<EOFEOF 206c206 < system(['dpkg-buildpackage', '-us', '-uc'], cwd=self.build_data_dest_path) --- > system(['dpkg-buildpackage', '-d', '-us', '-uc'], cwd=self.build_data_dest_path) EOFEOF d.h. build ohne dependencies : ergebnis : building Debian package dpkg-buildpackage: info: source package tinkerforge-brickv dpkg-buildpackage: info: source version 2.4.25 dpkg-buildpackage: info: source distribution stable dpkg-buildpackage: info: source changed by Matthias Bolte <matthias@tinkerforge.com> dpkg-buildpackage: info: host architecture amd64 dpkg-source --before-build . fakeroot debian/rules clean dh clean dh: error: Please specify the compatibility level in debian/compat or via Build-Depends: debhelper-compat (= X) make: *** [debian/rules:4: clean] Fehler 255 dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit status 2 Traceback (most recent call last): File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg.py", line 264, in <module> exit_code = main() ^^^^^^ File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg.py", line 252, in main build_linux_pkg() File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg.py", line 141, in build_linux_pkg utils.build_debian_pkg() File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg_utils.py", line 206, in build_debian_pkg system(['dpkg-buildpackage', '-d', '-us', '-uc'], cwd=self.build_data_dest_path) File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg_utils.py", line 33, in system subprocess.check_call(command, **kwargs) File "/usr/lib64/python3.11/subprocess.py", line 413, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['dpkg-buildpackage', '-d', '-us', '-uc']' returned non-zero exit status 2.

p.s. voraus geht folgender build (der das .deb liefert anstandslos : python3 build_src.py && python3 build_pkg.py

bisher habe ich den brickv ohne probleme bauen können jezt : # dpkg-deb -x ${k}_all.deb deb building Debian package dpkg-buildpackage: info: source package tinkerforge-brickv dpkg-buildpackage: info: source version 2.4.25 dpkg-buildpackage: info: source distribution stable dpkg-buildpackage: info: source changed by Matthias Bolte <matthias@tinkerforge.com> dpkg-buildpackage: info: host architecture amd64 dpkg-source --before-build . dpkg-checkbuilddeps: error: Unmet build dependencies: debhelper-compat (= 10) dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting dpkg-buildpackage: warning: (Use -d flag to override.) Traceback (most recent call last): File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg.py", line 264, in <module> exit_code = main() ^^^^^^ File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg.py", line 252, in main build_linux_pkg() File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg.py", line 141, in build_linux_pkg utils.build_debian_pkg() File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg_utils.py", line 206, in build_debian_pkg system(['dpkg-buildpackage', '-us', '-uc'], cwd=self.build_data_dest_path) File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg_utils.py", line 33, in system subprocess.check_call(command, **kwargs) File "/usr/lib64/python3.11/subprocess.py", line 413, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['dpkg-buildpackage', '-us', '-uc']' returned non-zero exit status 3. ------------------- FEDORA 37 scheint keine dbhelper-compat zu haben mein bisheriger trick, eure deb mittels debian-tools zu kompilieren und dann anschliessend die binaries "rauszuziehen" instf=( lib/udev/rules.d/99-tinkerforge-brickv.rules usr/bin/brickv usr/share/applications/brickv.desktop usr/share/pixmaps/brickv-icon.png ) instd=( usr/share/brickv ) for i in "${instf[@]}" ; do [ -f "deb/$i" ] || continue ; ii="$(dirname "$i")" ; [ -d "/$ii" ] || continue ; done for i in "${instd[@]}" ; do [ -d "deb/$i" ] || continue ; ii="$(dirname "$i")" ; [ -d "/$ii" ] || continue ; done for i in "${instf[@]}" ; do ii="$(dirname "$i")" echo cp "deb/$i" "/$ii" ; sudo cp "deb/$i" "/$ii" ; done for i in "${instd[@]}" ; do ii="$(dirname "$i")" if [ -d "/$i" ] ; then echo rm "/$i" ; sudo rm -rf "/$i" ; fi echo cp "deb/$i" "/$ii" ; sudo cp -r "deb/$i" "/$ii" ; done schlägt fehl .... entweder bitte diese expliziten dependencies mit -d irgendwie managbar machen, oder bitte für fedora / redhat mal eine gute anleitung zum build from source - nicht über dpkg - ICH MÖCHTE NICHT BETONEN, WIE SEHR ICH DEN BRICKV BRAUCHE, NACHDEM ICH DIE AKTUELLE (ALTE) VERSION NICHT MEHR HABE ...

... nur weil ichs wieder einmal dynamisch arbeite und den leidigen vollständigen import von allen tinkerforge-modulen nicht wirklich mehr will : --- statt statisch in main.py als "required header": from tinkerforge.bricklet_temperature import BrickletTemperature --- dynamisch, d.h. vor verwendung nach bedarf : # load with str from importlib import import_module mod = import_module("tinkerforge.bricklet_temperature") cls = getattr(mod,"BrickletTemperature") --- print(' \n'.join([ v for v in vars(cls).keys() if v.lower()==v and not v[0]=="_" ])) get_temperature set_temperature_callback_period get_temperature_callback_period set_temperature_callback_threshold get_temperature_callback_threshold set_debounce_period get_debounce_period set_i2c_mode get_i2c_mode get_identity register_callback --- sonstige verdächtige zur praktischen nutzung nich nur beim enumerate() ... cls.DEVICE_IDENTIFIER cls.DEVICE_DISPLAY_NAME --- obj = cls(ipconn,uid) ... --- btw. wann kommt endlich ein python3.11 brickd der auf generatorbasis (aka "async") läuft, damit der moloch endlich taskfrei und sauber neu geschfieben wird ? ;-) so schöne sachen gibts auch neu dazu : dataclasses, .... - hm ? ... und bitte mal endlich die callbackhölle verlassen können, es gibt elaboriertere dinge für eventbasierte saubere läsungen als eie queue und aus den fugen krachenden code da drumherum, der sie notdürftig zusammenflickt ... ab und zu träume ich von einem wunderbaren dict() aus weakrefs das von einem automaischen enumerate und auto-reconnects im hintergrund gepflegt wird, aus dem man sich dann das rausholt, was man braucht.... auf den brick-devices kann ja von mir aus laufen, was will, aber in der grossen weiten welt des pythonischen ... wär mal eine grundlegende renovierung from scratch eine echt geniale sache ... was bleibt is ein moloch, den ich schon von den verschiedensten seiten her versucht habe, eleganter zu verwenden. was halt bleibt sind die harten fakten einer api, die wie ein stein im magen liegt und eben unverdaulich ist ... die offenischtliche openhab-tragödie spricht ja auch bände, wie hart der stein wohl ist ... keine sorge, bin schon wieder still für die paar automationssachen ist polling mit grossen zyklenzeiten durchaus ausreichend und fürs autoladen auch. wer braucht schon eine gute api .................. ;-) lg

hallo ! ich habe mal was codiert für aout als 0..10V ansteuerung für eine kachelofenheizung, der massiv mit ptc-bricklets gemonitort wird (code ohne alle gewähr !!!!) was man verantwortungsvollerweise ALLENFALLS machen muss : watchdogs einbauen für ALLE EVENTUALITÄTEN dass das programm oder ein teil "stirbt" !!! (d.h. den aout in serie mit relay-bricklets schalten, sodass der leistungssteller sicher stromlos gesetzt wird)

tinkerforge_openhab_bindings_2_0_0_beta9.zip 24-Sep-2019 15:06 3566354 liebe leute ... sosehr ich die nöte einer wallbox-opportunity die eier legt sehe, möchte ich auch drauf hinweisen, dass das tinkerforge-ecosystem aus viel und teuerer brick/bricklet-hardware besteht, das auch ein bisschen was vertragen könnte : ich erwarte sehnlichst eine definitive openhab (3/2???) integration samt definitiver installationsanleitung wo dieser bereich endlich aus den tiefen aufsteigt und auch für normalsterbliche verwendbar ... eine ETA die halbwegs haltbar ist und nicht "mal sehen" wäre da auch glaube ich nichts, was einer zumutung gleichkäme, denke ich danke für das verständnis & die aufwände wp

ok. kleine frage : warum wird dann der request des callbacks des bricklets honoriert (d.h. callback-responses treten erneut auf) ? "Überlebt" der callback des temperature bricklets (und die bricklet-callbacks antworten wieder weil noch aktiv oder wieder aktiviert oder noch nicht deaktiviert) oder wird nur der enumerate-callback quasi "vergessen" ? (edit:) ok. es wurde nur der enumerate-request nicht erneut abgesetzt, und ein erneutes enumerate beim start der bindings fehlt dann .... aber soweit ich gesehen habe erfolgt doch ein enumerate beim start der bindings ... (edit2:) ich habe auch die these, dass die callbacks ja in den bricks ablaufen und nur die mqtt-bridge das vermittelt. d.h. wenn es kein disconnect gibt, läuft alles wie gehabt beim reconnect zum mqtt-broker ... ein RESET topic ist also KEIN echtes reset. was wäre dann ein echtes RESET-topic ? mqtt-disconnect UND ipconn.disconnect ? fragen über fragen. und wie wäre das in eine einheitliche status-maschine zu bringen ? (edit3:) ich habe ein problem, eine definitve entscheigungsgrundlage zu haben, wann die bricks/bricklets WIRKLICH neu konfiguriert werden müsen : wenn es nicht im int-file erfolgt. szenarien: mqtt-disconnect, ipconn-disconnect -> konfiguration verloren, aber keine entscheidungsgrundlage weil nicht in den topics erkennbar nur mqtt-disconnect : gab es einen ipconn-disconnect ? -> siehe oben nur ipconn-disconnect : ist der brickd wohin connected wurde noch intakt ? -> siehe oben warum : es gibt ja auch stateless bricklets wo man intern den "status" behalten muss bzw. wiederherstellen wie das remote switch bricklet, weil man da gar keinen status abfragen kann ... oder NC-digital-outs die bei reinitialisierungen mal ein bisschen lang offen sein könnten ... die sind dann besonders kritisch, vor allem wenn ein impliziter state-change umd sie zu initialisieren recht unangenehm werden kann (sierenen heulen, lichter blinken, womöglich gibts einen disconnect bei der initialen herstellung .... ohgott ...) d.h. die reinitialisierung des brickd hat absoluten vorrang, am besten von der mqtt-bridge aus bei disconnects ! den einzigen gau, den ich akzeptiere ist der stromverlust auf den bricks/bricklets bzw. tod des brickd, denn "kritische" NC sind sowieso mit 2 NO ausgängen & beschaltung auch im stromlosen zustand gewährleistet ;-) aber wie soll das automatisiert wiederherstellbar bzw. konsistent erkennbar sein ??? stromversorgung über spezielle bricklets aus/ein (habe ich auch schon für notfälle über parallen/unabhängigen brickd *ggg*) ??? bitte um kurze erklärung ;-) bzw. best-practice und ausblick, worauf ich mich gefasst machen sollte ;-)