Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - piwo

Pages: [1] 2 3 ... 5
1
Allgemeine Diskussionen / Re: Betaversion der MQTT-Bindings 2.0
« on: February 11, 2019, 11:39:58 »
bezüglich code-generatoren :

nicht nur ihr erzeugt code dynamisch.
das erzeugen von python-code, der anschliessend ausgeführt wird, ist ja essentiell bei dieser API-struktur ;-)

was aber ganz entscheidend fehlt, ist eine subclassierung aller funktionen in (daten)-getter/setter/callbacks,reine servicefunktionen und sonstige funktionen ...

eine introspektion oder sonstiger generatorcode, der das für jedes bricklet macht : nämlich die oben genannten (daten)-getter/setter/callbacks einer konkreten Bricklet-API als *** halbwegs klar lesbare datenstrukturen *** als python-code visuaisieren, damit man das auch sinnvoll debuggen bzw. den generator anpassen kann ....

am besten wärs ja, wenn man den generierten code gar nicht mehr bearbeiten oder modifizieren muss, weil alles notwendige zur laufzeit handle-bar ist ....

sowas macht z.b. der mqtt-proxy. ... einmal die bindings rein .... speziellen hooks dran um das dann von app-klassen nutzbar zu machen ....

sowas ist nicht die einzige anwendung, die sowas "braucht".
das macht mehr oder minder JEDE intelligente anwendung, die nicht so wie in euren beispielen statisch definiert wird :

mal den/die zielstacks runterenumierieren, die ipconn in entdlosschleife am leben erhalten und mit den gefundenen bricklets halt dann was sinnvolles machen ...

ich bevorzuge ja :

for stackdef in stackdefs: stack_start(stackdef)
"""
host,port,....
uids{} # key uid # meta-informationen der app bzw. wiring von/zur app
"""

def stack_starts(stackdef):
"""
ipconn starten, bei den dynamisch enumerierten mastern die "root master" zu finden, die dann resetten, warten, bricklet-uids der stackdef mit der ipconn initialisieren und dann einfach ein "stackstarted" callback an die app absetzen. irgendwelche exceptions, die sich durch einen impliziten disconnect oder sonstige troubles am stack ergeben wandern in ein "stackexception" callback, das die app dann auswertet und entweder den stack ewig neu startet, oder die app beendet nach einem retry_failure_count > N

RETURNS:

stack_callback_wrappers[] # status-callbacks f. exceptions bzw. die pseudo-exception "stack_started"

bricklet_function_wrappers{} # key : uid # generische wrapper zur bricklet-ansteuerung. entweder "direct-calls" oder mit funktionen aus den app-metainformationen angereichert
"""

damit hat man dann mal schon einen "running stack". ok.
was aber NICHT getan ist, ist ein GENERISCHES WIRING zwischen app und stack ...

für jedes bricklet muss ich mehr oder weniger auch metainformationen aus der doku einbringen, d.h. konkrete implementierungsschritte.

ich schreibe eine app für alle STACKS ja mit bestimmten klassen von bricklets : z.b. 2x irgendein temperatur-sensor, 1x *** irgendein aktor der die heizung schaltet ***

dieser aktor kann ALLES MÖGLICHE SEIN : ein digital-out der ein externes ssr schaltet oder auch ein ssr-bricklet direkt
aber auch die temperatur kann von einem ptc kommen oder auch was anderem. gott weiss.

KONSEQUENZ :

a) ich brauche klassen oder einen funktionsarray für ein generisches "turn on/turn off" bzw. "temperature" auf einer ganzen reihe von Bricklets, welche das denn zur laufzeit sind - gott weiss - aber dafür gibts dann ja die stackdef ;-)

b) selbst bei verschiedenen Bricklets ist nicht nur ein getter notwendig. so ist z.b. beim RemoteSwitch-Bricklet eine ganze funktionskette notwendig (da KANN ich gar nicht "blocking" arbeiten, sondern es muss eben exceptions wie "try_later" geben !!!)

c) desweiteren kann man nicht bei jedem Bricklet einfach EINE art von callback-struktur voraussetzen, die "einfach daten liefert". auch da ist oft eine ganze funktionslogik notwendig um die sonder- und sonstigen fälle abzudecken. für gewisse "alarm"-funktionen sind aber threshholds unabdingbar, weil getter ev. "zu spät" kommen und ein polling viel zu langsam ist (z.b.. distance-ir) ...

d) C O N C L U S I O

"GENERISCHES WIRING" ist daher nur möglich

1) zur LAUFZEIT für ALLE KLASSEN VON BRICKLETS
2) beim "mapping" auf konkrete stacks mit code-generatoren

introspektion bzw. LESBARE strukturen welche alle bricklets abstrakt definieren sind somit unabdingbar

---

ich löse DERZEIT das so, dass ich in der stackdef (siehe oben) generierten code verwende der möglichst eine generische weiterverwendung durch die app ermöglicht bzw. abstrakte klassen wie ACTOR/SENSOR die auf ganzen subsets von Bricklets arbeiten :

denn was wird man schon von einem Bricklet wollen : seine daten, egal wie es das liefert - bzw. es soll was machen, egal was das ist ;-) ...

... und damit bin ich wieder bein mqtt-proxy. dort läuft ziemlich genau DAS.

... wenn man DAS in einer beliebigen app kriegt, dann trifft das 100%

... und ich seh nicht ein, dass JEDER der tf-komponenten kauft GENAU DIESES RAD JEDESMAL NEU ERFINDEN BZW. NEI IMPLEMENTIEREN MUSS ...

2
Allgemeine Diskussionen / Re: Betaversion der MQTT-Bindings 2.0
« on: February 11, 2019, 10:32:43 »
ad device_factory :

... da hätte ich mir viel lebenszeit erspart, wenn man da mal in den docs mit der nase draufgestossen worden ware ...

3
Allgemeine Diskussionen / Re: Betaversion der MQTT-Bindings 2.0
« on: February 10, 2019, 16:35:36 »
meine kommentare:

1)

(ich habe den code des "alten mqtt-proxys" wenigsten dazu nutzen könnnen, damit ich irgendwo mal ALLE möglichen imports finden kann :

die braucht man ja als erstes, wenn man include-code-generatoren für beliebige stacks schreiben will.

ein "import tinkerforge" ist ja eine noop !

2)

ich habe nirgends (aber vllt. bin ich auch zu deppert) code gefunden, wo zumindest ALLE deviceids in einer datenstruktur versammelt wären, die mir helfen bei meinen include-code-generatoren ...

geschweige denn fand ich subpackage-names und class-names mit key deviceid ...

3)

der naming-wahnsinn geht aber hier weiter ...

bisherige "essentielle" bezeichner z.b. f.d. temperatur bricklet in der 2. version :

- bricklet_temperature_v2 : import subpackage API
- BrickletTemperatureV2   : classname API
- 2113                    : deviceid API

nun kommt dazu :

- temperature_v2_bricklet  : mqtt-name
- TemperatureV2Bricklet    : classname mqtt-proxy
- Temperature Bricklet 2.0 : displayname mqtt-proxy

4)

ich habe ja den verdacht, dass ihr gar keine transparenz wollt.
geschweige denn, dass man

- API-funktionen von stacks dynamisch nutzen kann

- auch nur IN ANSATZ IRGENDETWAS wie introspektion (selbst mit dem vorhandenen source-code) zusammenbringt

5)

der neue mqtt-proxy ist wiederum eine "neuimplementierung" eines brickd

prozedural und wenig transparent.

keineswegs universell einsetzbar : denn es erfolgt keine klare architekturtrennung zwischen PSEUDO-BRICKD / ANWENDUNGSSCHICHT

ein weiteres indiz für meine hypothese, dass es kein interesse gibt, mehr transparenz und benutzerfreundlichkeit umzusetzen.
das gegenteil scheint mir der fall zu sein.

lg wp

4
Allgemeine Diskussionen / Re: python3 wieder einmal ...
« on: February 10, 2019, 15:19:38 »
okok.

... und wie sieht das letzte beispiel mit callbacks aus ?

thresholds & debounce bzw. callback setzen
adäquate einbindung des callbacks ...

nach langen nachdenken wird es wohl nicht ohne EINE queue pro möglichem bricklet-callback laufen ... am besten sollten dort auch gleich die returns der getterfunktion landen, dann hätte das mal alles beisammen ...

es wäre echt toll, wenn es eine referenz-implementierung gäbe, die dann in den docs ist und wo dann mehr leute diese verwenden & ev. eine verbesserung oder ein weiterspinnen möglich ist ...

lgw

5
Allgemeine Diskussionen / Re: python3 wieder einmal ...
« on: February 09, 2019, 23:30:38 »
... letzte worte  für heute :

über concurrent.futures können wir uns unterhalten, sobald die ganze api in EINEM exekutor läuft ;-)

... oder tut sie es bereits ?

lgw

6
Allgemeine Diskussionen / Re: python3 wieder einmal ...
« on: February 09, 2019, 22:58:29 »
... um das nochmals zu konkretisieren :

ich will keine threads (wunschkonzert wider die API)

ich will EINE MAIN LOOP für meine dinge, die ich über coroutinen "kooperativ" nutze. nicht mehr nicht weniger.
wie ich das mache ist mein bier, aber ich muss eben leider mit der API leben, die da dagengearbeitet.

also bitte von seiten der API mal nachdenken, wie man die ein möglichst wenigen hintergrudthreads ein ein coroutinen-umfeld einbinden kann.

füttern von queues etc. also bitte nicht in den api-threads, sondern in welchen in der MAINLOOP = KOOPERTIV GENUTZTES (und einzig wichtiges) HAUPTPROGRAMM (ja. wie in der steinzeit *gggg*)

ich habe die nase von threading voll.
und python3 geht da in die ganz richtige richtung :
statt dem abfeuern von unzähmbarer concurrency in threads, die man dann mit locks, notify und dem ganzen brimborium wieder mühsam sequentialisieren muss, rendezvous erzwingen, barriers setzen usw.:

bullshit. es geht auch anders.
danke den python3-entwicklern.
und ich werde nur mehr so die dinge angehen.
mir reichts ....

lg wp

7
Allgemeine Diskussionen / Re: python3 wieder einmal ...
« on: February 09, 2019, 22:39:13 »
mein gott -

was ist daran so schlimm wenn man coroutinen einsetzen will
(=kooperative nutzung EINES main-threads !!!!) durch intelligentess "loslassen" (nennt sich await) bei io-bound dingen bzw. hauptsächlichem nasenbohren ...

mir ist schon klar, dass ich da AUCH mit dem multithreaded design der API leben muss.

und mir ist klar, dass man da von heute auf morgen kein redesign vom zaun brechen kann ...

ABER in worten *** ABER ***

1) die implementierung der API muss grundsätzlich eine (sinnvolle!) einbindung von kooperativem multiprocessing (COROUTINES)
ERLAUBEN. und das in einer form, die das nicht ad-absurdum führt

2) man die offensichtlich nicht kompatibel implementierte API SCHONDEND einbinden können, d.h. dass dort nur die ALLERNOTWENDIGSTEN threads laufen, und dass auch die ZÄHMBAR sind.
gibt genug nicht async-kompatible software, genauso wie es tonnen von nicht threadsafen libraries gibt.

aber ich finde, die erbauer sollten sich da mal wirklich fundierte gedanken drüber machen. schnellschüsse aus der hüfte sind da nicht hilfreich.

danke für das verständnis.
bitte mal die natur coroutinen vs. threads behirnen.
danke wp

da ein feuerwerk mit thread-exekutoren abzufackeln ist NICHT das was in einem KOOPERATIVEN environment sinn macht

2)

8
Allgemeine Diskussionen / Re: python3 wieder einmal ...
« on: February 08, 2019, 21:55:07 »
... ich möchte die low-level routinen vermeiden ...

d.h. keine futures, sondern ** tasks ** die ge-gathered werden

möglicherweise mit einem loop-argument falls ich mehrere loops instanziere, und mit return_exceptions=True/False

die auswirkungen von Exceptions auf das canceln von concurrent tasks bzw. das handling in der routine, die die tasks scheduled bin noch heftig am studieren ;-)

jedenfalls soll das design sowas ähnliches wie invariante ergebnisse (d.h. alles oder nichts) über alle rekursiven task-ketten liefern

ich habe keine lust, mich mit problemen "unten" einzeln durchzukämpfen...

entweder alle operationen laufen, oder der ganze stack (und auch alle von seinen operationen abhägigen komponenten werden gecancelt oder auch restarted ... d.h.

der stack ist in meinem design producer/consumer für sämtliche darübergelagerten tasks, die im wesentlichen aber nur ein "wiring" bzw. "mapping" von daten vom stack machen.
alles was vom stack kommt ("sensor") oder in diesen injiziert wird ("actor") ist als gesamtheit zu sehen. als "kontrakt" zwischen "stack" und "rest". die state-machine dieser "beziehung" kennt nur 2 zustände des stacks : RUNNING oder FAILED.
nach N mal FAILED in einem floating fenster gibts dann einen sys.exit(1) mit entsprechendem alarm per sms oder so ...

eigentlich nichts wirklich unübliches, denke ich.
und ich denke so ein design mit "minimalem coding" ist durchaus im interesse der allgemeinheit ....

lgw

9
Allgemeine Diskussionen / Re: python3 wieder einmal ...
« on: February 08, 2019, 19:55:42 »
... gibts das obige beispiel auch mit argumenten bei den calls des

*** tf_async_call ***

???

dass callbacks direkt aufgerufen werden und in die queue einspeisen ist irgendwo klar.

aber wie geht man mit argumenten bzw. dem handling von argumenten von settern in deiner implementierung um ?

async def tf_async_call(name, func, *args):
 ... run_in_executor(_executor, func,*args)

oder mit partials ?

lgw

10
Allgemeine Diskussionen / Re: python3 wieder einmal ...
« on: February 08, 2019, 03:03:12 »
d.h.
pro bricklet eine Queue und 10 workers ?
oder gibt es da noch optimierungen ?

sorry, aber ich habe meistens 12-16 bricklets pro stack ;-)

11
Allgemeine Diskussionen / Re: python3 wieder einmal ...
« on: February 07, 2019, 18:28:51 »
... na da sieht man, wie gut das ist : hatte noch niemals eine TimeoutException über jahre ;-)
... vielleicht hat auch keiner die gehandelt ;-) ;-)

12
Allgemeine Diskussionen / Re: python3 wieder einmal ...
« on: February 07, 2019, 18:26:07 »
ok.

asyncio getters werd ich implementieren ...

callbacks werd ich :

a) vergessen (ist kein drama ; ich bevorzuge sowieso totale kontrolle nach "meinen vorstellungen" ;-)

b) entgegen euren empfehlungen ".... callbacks sind IMMER zu bevorzugen ..." NICHT IMPLEMENTIEREN

c) in eine awaitable Queue zwingen : ok. und wie ?
da muss man ja die callbacks irgendwie für coroutinen tauglich machen ...

ad c)

ich fürchte, das geht nicht "ohne weiteres". dein beispiel mit dem injizieren in die QT-loop ist zwar schlüssig, setzt aber die verwendung von den brickv-(client)-imports voraus.

ich hoffe, diese unterscheiden sich nicht allzusehr von den "normalen" (client)-python-bindings ... ( -> am besten durch NULL DIFFERENCE ;-)

GENERELL :

ich fürchte mich nicht vor separaten threads, die es in einem co-routinen-tauglichen umfelt zu initialisiern gibt ...

threading.local-kontexte are your friend ;-)

ziel sollte halt sein, dass irgendein x-beliebiger brickd (vor allem auf red-brick) oder ein x-beliebiger tinkerforge-stack mit wlan-extension-v1,v2 via tcp-bindings angesteuert werden kann in einem co-routinen-tauglichen umfeld ...

welche helper oder wrapper oder leck-mich-am-... ich da brauche ist mir EGAL. am ende sollen asyncio-tasks konstruierbar sein, die auch entsprechend yielden und nicht in der nase bohren (= pfui teufel ;-) ) ...

13
Allgemeine Diskussionen / Re: python3 wieder einmal ...
« on: February 07, 2019, 17:59:18 »
corr: "optimiertes antwortzeitverhalten" :

wenn ich eine setter-function absetze, will ich als paranoider mensch auch, dass ich nicht nochmals einen getter nachwerfen, ob das auch so passt ... d.h. will nicht nachher womögich über exceptions stolpern, die "so nicht ausgemacht sind" ;-)

wenn ein "return" returned, dann sollte er auch indizieren, dass alles passt ... auch bei den settern
ob das wirklich SO der fall ist, weiss ich nach jahren noch immer nicht, bzw. GLAUBE, dass das dann auch "passt"

please enlighten me ;-)

lg wp

14
Allgemeine Diskussionen / Re: python3 wieder einmal ...
« on: February 07, 2019, 17:48:44 »
Quote
Edit: Hab das gerade nochmal ein bisschen aufgebohrt, damit man sieht das ich wirklich async calls machen kann während der getter-Aufruf läuft

bitte sieh all das nicht als quälerei ...
vielleicht bin ich ja der erste (trottel), aber diese dinge kommen sowieso bald auf euch zu ...

ich kann dir ja mal eine "old-fashioned" implementierung mailen, wo ich rein durch (rekursives, irrsinniges) __init__ eine stackumgebung definiert habe und dann eine alarmanlagenüberwachung "soft-pluggable" gemacht habe : wenn die objekte "richtig" definiert wurden, ist das ding losgerattert für BELIEBIGE STACKS ;-)

aber ich hab im moment von solchen zaubereien die nase voll und will in ein NEUES "soft-configurable" design wechseln auf basis von asyncio und python3 - die "alten dinger" zahlen sich heutzutage in den "neuen zeiten" nicht mehr aus. python2 und prozedurale zaubereien sind für io-bound tasks VORBEI ....  echt .... ;-)

15
Allgemeine Diskussionen / Re: python3 wieder einmal ...
« on: February 07, 2019, 17:41:16 »
bezüglich mqtt-proxy :

ich bin schon dazu übergegangen, den "normalen" d.h. nicht den BETA mqtt-proxy für queuing in einem async-umfeld zu "durchleuchten".

bin noch auf keinen verifizierbaren grünen zweig gekommen.
absicht dabei ist : statt topics in paho zu injizieren diese in eine async-queue zu füttern und vice-versa

ich wäre ja schon zufrieden, wenn ich diesen (universellen) moloch als seperaten thread weit weg von den "normalen" coroutinen bedienen könnte. einen thread pro stack. der soll machen was er will, hauptsache, er passt in ein "echtes" asyncio-umfeld.

got the idea ?

Pages: [1] 2 3 ... 5