Gast piwo Geschrieben March 6, 2019 at 13:17 Geschrieben March 6, 2019 at 13:17 hallo "gemeinde" ! darf ich meine "nutzerprprofil" mich kurz vorstellen : ich kenne die "leistungen" seitens tinkerforge.com seit jahren und schätze die auswahl und qualität der hardware sehr. sie ist dauerbetriebstauglich, und mal abgesehen von den "steckkontaktproblemen" (die gehen mir ein bisschen zu leicht ab) und ab und sehe ich strukturelle funktionsprobleme (ich denke an die emr-problem mit dual relay und ein paar andere firmware-bugs, die halt zum tagesgeschäft zählen, bzw. unabänderlich sind ...) aber das ist nicht was ich hier thematisieren will. es geht mir um den software-aspekt. ja es gibt hier viele "bindings" und zugangspunkte. ich persönlich bevorzuge python, und auch sonst sehe ich, ist python vom generieren der dokus bis zum "basis-binding" (shell-bindings sind ja nichts anderes als ein wrapper da drauf) auch das "rückgrat" das von tinkerforge.com selber massiv eingesetzt wird ... aus naheliegenden gründen ist die architektur, die allen bindings zugrunde liegt immer dieselbe. was wunder, der ganze hardware-zoo wäre ja sonst nicht verwaltbar. es wäre das chaos, und das ist ja auch nicht im sinne der end-user. auch gibt es auf githup millionen zeilen python-code, meist generiert, aber mit viel manueller pflege auch, wie mir scheint. vom python-user standpunkt aus ist für ad-hoc und fixed-wire kleinprojekte das alles ganz toll. mit ein paar zeilen code integriert man hardware schnell und effektiv, misst mal einen wert da, feuert mal einen aktor dort, passt, wunderbar. --- wenn man das nun mal von einem "höheren" standpunkt für x-beliebige stacks aus betrachtet, dann sieht die sache aber für mich ganz anders aus. 1) brickv ist das "universelle" programm, das auf tf-komponenten-"haufen" aka STACKS introspektion & konfiguration liefert, nun einen "logger" eingebaut hat und somit das universellste instrument ist, das den ganzen zoo managt und zugänglich macht. 2) brickd ist detto ein universelles hw-stack-backend das die (tcp)-api auf hardware-low-level umsetzt und mit den jeweiligen bindings-frontends die jeweilige anwendungs-api verfügbar macht. 3) der mqtt-proxy ist die dritte universelle anwendung, die eigentlich nichts anders ist, als eine vereinigung von brickd mit python-frontend das stacks mittels mptt-pub-sub "universell zugänglich macht" *** FRAGE *** : was ist aber, wenn man mit python selber all diese funktionen in einer art "generischen" api genauso universell nutzen will, wie diese komponenten 1)-3) das offensichtlich ganz erfolgreich machen ANTWORT : der einzige zugang (ich bleib mal bei python) ist die python-forefront-api (die openhab-integration seitens des red-brick lass ich mal aus, denn die erfordert ja eine nochmalige "schattenkonfiguration" und ist für generische zwecke vollkommen unbrauchbar) was dabei fehlt sind alle funktionen abseits der in der architektur fix vorgegebenen zugangs-funktionen und auch das forefront ist eben das was es architekturmässig halt gewachsen ist : eine haufen von threads, locks, queues, vollkommen intransparent in seiner sicherstellung von konsistenz & concurrency, eine nachträglich optimierte monolithische ad-hoc-lösung, durchsetzt von tricks und sonderfällen ... wie man gesehen hat weitgehend nicht refaktorierbar, wenn es z.b. zu anforderungen kommt wie saubere isolation in einer eigenen event-loop mit sauber definierten übergangspunkten in andere event-loops ... um es mit wenigen worten zu sagen : das python-frontend-api ist nicht "freundlich" gebaut. es seht im raum und ist nicht eine hilfskomponente, die man unkompliziert in ein anderes paradigma einbauen kann, sondern es ist eine "unfreundliche library" um die man alles herumbauen muss, die man ev. als eigenen prozess auslagern sollte. aber selbst das ist nicht einfach möglich. mit einfachen worten : das python-forefront ist alles andere als "pythonic". resumee : man hat nur scherereien, damit, wenn man ihm nicht die rolle des "hauptdarstellers" geben kann, den es beansprucht. 4) nun, man kann nun sagen, ok : neben den architektur-problemen : eine forefront-api ist eben ein zugriffslibrary, punkt. friss oder stirb. ist weder anwendungsfreundlich, noch pythonic, eher tyrannisch, aber : hier bei tinkerforge gibts nur das und punkt. (so kommt es rüber, und so ist es zweifellos auch ...) was aber auch dazukommt, wo ich sagen würde, was auch fehlt, wo ein anwender vollkommen im regen steht : WO sind werkzeuge, wie sie in 1)-3) ja von tinkerforge programmiert wurden, die offensichtlich unabdingbar sind, um einen stack-zoo überhaupt programmatisch zugänglich zu machen ? wo ist eine "erweitere" app-lib, die komponenten, die in 1)-3) immer wieder zum einsatz kommen, auch für den "otto-normalprogrammierer" verfügbar machen ich habe noch keine gesehen. es ist offensichtlich auch weder erwünscht von tinkerforge, dass es so etwas gibt, noch hat man vor da irgendwelche aktivitäten zu setzen ... die strategie scheint a) wenn du was kaufst, dann nimm den brickv, konfigurier das und : das muss genügen. mit dem logger kannst dann noch ein bisschen was ansehen und ein trace genierieren, aber dann ist : schluss b) "integration" mit der iot-welt wird vollkommen auf mqtt "abgeschoben". musst halt dann weiterschauen dort. die inhärenten latenzen bei message-passing, der sonstige overhead ... nicht mehr unser problem ... pubsub und basta ... c) selbst der red-brick ist eher ein "legacy" spielzeug für openhab2 (dass dann keiner sagen kann das gäbs nicht) racksteuerung und ein paar sonstige spielwiesen ... ist auch zum stiefkind geworden ... wennst sonst was machen willst : nimm ein raspi und mach dort weiter : alleine : auf dem raspi hilft mir auch keiner ... hat halt mehr ps und was bleibt : auch dort nur ein brickd & keine änderung. ein weiteres "dont blame us", wie es scheint ... --- THEMENWECHSEL betrachten wir das ganze nun mal "von aussen". es gibt zig-fache frameworks, die defizite von tinkerforge etwas abmildern können. 2 x-beliebige, aber sinnvolle beispiele : node-red & stackstorm für node-red gab es mal einen versuch, die node-hs bindings zu nutzen. ist nich maintained, aber selbst das was vorhanden ist ist vollkommen unbrauchbar. bleibt also nur der umweg über mqtt .... in stackstorm wäre der weg über einen python-producer wirklich reizvoll, alleine : man handelt sich die "üblichen" probleme der python-forefront-api ein : keine unterstützung für generische stacks. keine chance auf wenige generische klassen zurückzugreifen, die das alles was ein brickv/mqtt bietet "under the hood". man kann es drehen und wenden wie man will ... man stösst immer wieder an dieselben probleme ... deswegen meine GENERELLEN FRAGEN : - wie sieht man bei tinkerforge die "generelle use-case-lage" ? - hat man überhaupt überlegungen diesbezüglich ? - wie soll es weitergehen ? --- liebe leute. für mich sind diese fragen wirklich essentiell. vielleicht auch für andere, wenngleich ich befürchte, eher nein. ich muss da jetzt wirklich eine entscheidung treffen, ob ich tinkerforge als zukunftsträchtigen supplier von "nutzbarer hardware" betrachten soll (und da viel von meiner lebenszeit reistecken, damit man das zur effektiven systemintegration verwenden kann) oder ob ich von einem zwar netten, aber toten pferd absteigen soll ... in anderen worten : wird es abseits von der effektiven "klein-klein" bzw. ad-hoc-lösungen, die selbst für 2 aktoren und 2 sensoren - sauber programmiert mit allen schikanen - 700 zeilen bash-code erfordern mal eine python-app-lib geben, die "value-added" was zum normalen brickd-frontend bieten wird ? oder wird es nur die "exit-lösung" mqtt geben, die alles andere wiederum nach aussen delegiert. bitte um diskussion & antwort Zitieren
Gast piwo Geschrieben March 6, 2019 at 13:55 Geschrieben March 6, 2019 at 13:55 noch ein kleiner nachtrag : es wurde ja der brickv neu geschrieben ... die historische chance wär das gewesen, da ein "middleware-schicht" einzuziehen, die basis für einen "generischen zugang", nicht nur zur visualisierung bzw. zu den "üblichen funktionen" des brickv, hätte sein können ... d.h. eine klare trennung zwischen forefront/backend die dann auch noch "zusatznutzen" geboten hätte ... sozusagen der (erste?) anfang eines "high-level" api für python auf x-beliebigen stacks ... schon klar. das hätte ein major redesign des "üblichen" zugangs bedeutet, wie es im bisheringen code erfolgreich praktiziert wurde, und es scheint mir, dass zuvorderst der grundsatz gegolten hat : never change a running system ... ich kann trotzdem nur sagen : aber ... unendlich schade das ... lg wolfgang Zitieren
Equinox Geschrieben March 6, 2019 at 14:21 Geschrieben March 6, 2019 at 14:21 Hallo, für mich sind diese fragen wirklich essentiell. vielleicht auch für andere, wenngleich ich befürchte, eher nein. Korrekt. Völlig unerheblich. Außerdem kann ich Leute nicht ernst nehmen, die sich über schlechtes Design usw. beschweren aber die Groß- und Kleinschreibung ignorieren. Zitieren
Gast piwo Geschrieben March 6, 2019 at 14:24 Geschrieben March 6, 2019 at 14:24 *ggg* die geballte weitsicht als primäre reaktion .... nett .... ich schätze es durchaus, wenn evangelisten zur verteidigung antreten, aber das bringt einen nicht in der sache weiter ... ich stelle hier durchaus sinnvolle fragen, denke ich, die eine sinnvolle antwort bekommen dürfen ... ich nehme auch jede antwort ... alleine, sie sollte mal von den zuständigen chefs hier erfolgen bitte ... Zitieren
borg Geschrieben March 6, 2019 at 15:35 Geschrieben March 6, 2019 at 15:35 wo ist eine "erweitere" app-lib, die komponenten, die in 1)-3) immer wieder zum einsatz kommen, auch für den "otto-normalprogrammierer" verfügbar machen Hier hast du mich abgehängt. Der Brick Viewer nutzt die ganz normalen Python-Bindings ohne Änderungen. Die Komponenten dafür stehen also zur Verfügung. Der Brick Daemon nimmt Pakete über USB entgegen und sendet sie per TCP/IP wieder raus (und umgekehrt). Da gibt es keinerlei Magie. Die MQTT-Bindings werden genauso generiert wie die anderen Bindings auch. Da stecken nicht mehr und nicht weniger Information oder Abstraktion drin wie in den anderen Bindings. Die MQTT-Bindings (und auch der obsolete MQTT-Proxy) vereinen auch nicht den Brick Daemon mit irgendetwas. Den Wandler von USB nach TCP/IP benötigst du ach noch wenn du die MQTT-Bindings einsetzt. Welche Komponenten nutzen wir im Brick Viewer/Daemon und in den MQTT-Bindings die dir nicht zur Verfügung stehen? Zitieren
Loetkolben Geschrieben March 6, 2019 at 19:10 Geschrieben March 6, 2019 at 19:10 ich stelle hier durchaus sinnvolle fragen, denke ich, die eine sinnvolle antwort bekommen dürfen ... Aber nicht muessen. 1. Sinnvolle Fragen haben auch ein sinnvolles Aussehen. 2. Sinnvoll aus wessen Sicht? Der Loetkolben Zitieren
Gast piwo Geschrieben March 7, 2019 at 14:40 Geschrieben March 7, 2019 at 14:40 ... ist das alles ? kommt noch was ? ... ich mein generell bzw. nicht nur bei den details und das mantra "es ist alles da" ... wo fehlts denn ... ... ode wars das dann ? Zitieren
borg Geschrieben March 7, 2019 at 15:24 Geschrieben March 7, 2019 at 15:24 ... ist das alles ? kommt noch was ? ... ich mein generell bzw. nicht nur bei den details und das mantra "es ist alles da" ... wo fehlts denn ... ... ode wars das dann ? Ich hab deinen letzten Post wie folgt verstanden: Du möchtest so etwas ähnliches wie Brick Viewer oder Brick Daemon bauen und dir fehlen die Tools dafür. Meine Antwort darauf ist: Brick Viewer/Daemon basieren auf den Tools die wir veröffentlicht haben. Ich weiß nicht welche Tools dir fehlen um etwas ähnliches zu bauen. Wenn das nicht gut genug ist als Antwort versuch doch bitte einmal deine Gedanken zu sortieren und eine konkrete und verständliche Frage zu stellen. Zitieren
remotecontrol Geschrieben March 7, 2019 at 19:03 Geschrieben March 7, 2019 at 19:03 was dabei fehlt sind alle funktionen abseits der in der architektur fix vorgegebenen zugangs-funktionen Was soll das sein? Entweder gibt es vorgesehene Zugangswege oder nicht. Alles andere sind eher nicht vorgesehene Lücken, aber keine geplanten Zugangswege. Immerhin gibt es zwei Zugangswege: die APIs in verschiedenen Sprachen und das TCP/IP Protokoll. Ob die API intern diverse Threads nutzt ist mir erstmal egal, dafür ist es ja die API, um die Threads muss ich mich nicht kümmern. Das TCP/IP Protokoll wurde auch schon in diversen Projekten genutzt; ich selber nutze das auch zur Stack-Emulation und damit zum automatisiertem Test -> geht super. Und wenn die API die alles Erfüllende hyper Moderne wäre: wo bliebe denn da der Spaß, sich selber Gedanken zu machen? Ist doch gerade zum Basteln gedacht, darum Tinkerforge. Gerade die einfache API bringt mich dazu, zu überlegen wie ich das z.B. in C++ so anbinde, damit ich mich in meiner Anwendung nicht mehr drum kümmern muss, ob ein V1, V2 oder V3 Bricklet angestöpselt ist und nur noch "sage": gibt es ein Bricklet mit der Funktionlität "Temperatur Sensor" oder "Display". Und siehe da: der Tausch des LCD 20x4 durch LCD 128x64 macht der Anwendung nichts aus ... Zitieren
jgmischke Geschrieben March 8, 2019 at 09:04 Geschrieben March 8, 2019 at 09:04 Ganz ehrlich? Die Problematik erschließt sich mir nicht. Wer mit der API nicht zufrieden ist, dem steht es doch frei, sein eigenes Ding zu bauen. ALLES bei TF ist Open Source und "nur" mit der Arbeit des Einarbeitens verbunden. Und wie soll sie Python Super API kompatibel zu all den anderen Sprachen sein. Eine Super API für jeweils C, PHP und was weiss ich, die alle unterschiedlichste Zusatzmodule brauchen? Sorry, ich glaube das TF alles mitliefert und das so minimalistisch und aufgeräumt wie es eben möglich ist. ( Und für alle Sprachen ) Zitieren
Gast piwo Geschrieben March 9, 2019 at 13:38 Geschrieben March 9, 2019 at 13:38 der zugang zu tf-hardware ist weder elegant noch userfreundlich ... das beste was es zu geben scheint ist pub/sub aka mqtt-client ... (wobei der code des mqtt-clients nicht refakturierbar ist und auch schon gar nicht in eine middleware umgewandelt werden kann, die was anders ausser mqtt-pub/sub macht ... vielleicht sollten sich die autoren ja mal überlegen, wie sie was programmieren ... aber es scheint eher absicht zu sein den code quasi zu "obfuscaten", damit ihnen ja niemand anders oder "bequem" einsetzen kann ... wie im kommentar oben : man muss sich abmühen, wenn man tinkerforge-hw verwendet ... entweder man ist masochist oder evangelist oder wasweissich was ...) ich ziehe jedenfalls meine konsequenzen. schert sowieso keinen, was oder worauf ich hinauswill. usability ? tellerrand ? eigenerkenntnis ? hier scheint man schon lange in einer sehr dichten filterblase zu stecken. naja. solang das geschäft läuft ... viel glück danke für die zusammenarbeit Zitieren
Equinox Geschrieben March 9, 2019 at 16:38 Geschrieben March 9, 2019 at 16:38 Hallo, man muss sich abmühen, wenn man tinkerforge-hw verwendet Seltsam ist, dass nur du dieses Problem hast. Die meisten anderen, inkl. mir, kommen sehr gut damit zurecht. schert sowieso keinen, was oder worauf ich hinauswill. Stimmt. Das liegt aber vor allem daran, dass dein Gejammer einfach völlig unverständlich, weil auch uNLesBAr, ist. Beachtung der Groß- und Kleinschreibung wäre ein erster Schritt. Und dann, wie borg schon sagte, solltest du deine Gedanken mal sortieren und auf den Punkt bringen. Zitieren
bernhard.graeuler Geschrieben March 9, 2019 at 19:11 Geschrieben March 9, 2019 at 19:11 schert sowieso keinen, was oder worauf ich hinauswill. Stimmt. [...] Nein, das stimmt so nicht. Deshalb möchte ich das gerne zum Anlass nehmen hier ein großes Lob für die Tinkerforge-Repräsentanten (namentlich vor allem borg) loszuwerden. Jede noch so schwammig formulierte Kritik (mir lag erst gehässiges in den Fingern) wird eben nicht, wie hier von Piwo dargestellt ignoriert ("schert sowieso keinen"), sondern es gibt Rückfragen, konstruktive Vorschläge, und Hilfestellung - für Profis ganz genau so wie für Anfänger. Das wiederum ignoriert piwo unangenehm regelmäßig. Das Problem ist, so wie ich es verstehe, dass Piwo eine Eierlegende Wollmilchsau will, nach dem Motto: "Ich steck jetzt 50 TF Brick(let)s zusammen, nehme die Premium Library von Tinkerforge, schreibe noch 20 Zeilen eigenen Code, und dann tut es genau das was ich will." Das gibt's aber halt leider nicht, und deswegen wird hier herumgemault. Mein Eindruck ist, dass piwo selber nicht genau weiß was er will, aber seinen Kopf sollen sich bitteschön andere zerbrechen. Zitieren
duaw Geschrieben March 10, 2019 at 10:45 Geschrieben March 10, 2019 at 10:45 Ein großes Lob auch von meiner an die Sachlichkeit & Besonnenheit von borg in dieser Diskussion! Professionell. Zitieren
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.