[fhem.pl/AssignIoPort] Fehlende Events beim Reading IODev

[rudolfkoenig]

Sollte sowas dann nicht eher im konkreten Modul als Event generiert werden?

[frank]

Sollte sowas dann nicht eher im konkreten Modul als Event generiert werden?

fangfrage? mit einer antwort sitzt man eventuell schnell in den nesseln. 


unbedarfte usersicht:

- grundsätzlich erwarte ich von einem reading erst einmal events, um mindestens über longpoll änderungen im frontend verfolgen zu können.

- mein vorschlag mit nur event bei änderung ziehe ich hiermit zurück, da ich immer dafür eintrete, dass alle readings von haus aus events bei update generieren sollten. nur mit einheitlichem eventverhalten, finde ich, ist die "trickreiche" event minimierung über attribute für anfänger einigermassen verständlich zu machen.
wenn hier zu viele events bei cul_hm auftauchen, ist es auch ein deutlicher hinweis für den maintainer, dass bei der implementierung von AssignIoPort nachgearbeitet werden sollte. so wird wenigstens nichts unter den teppich gekehrt.

- wenn ein modul das reading IODev über AssignIoPort zur verfügung stellt, ist es natürlich sinnvoll, wenn dieses auch direkt entsprechend genutzt werden kann. genau dieses reading repräsentiert doch dann die auswahl des io (sollte).
ein weiteres modul-reading erhöht nur das risiko, dass beide readings nicht deckungsgleich sind, wie beim spiel "stille post".

- nach internal, reading und attribut IODev nun noch ein 2. reading IODev2 ist nicht nach meinem geschmack.
ausserdem wird es dann in jedem modul wieder unterschiedlich implementiert.

[betateilchen]

da ich immer dafür eintrete, dass alle readings von haus aus events bei update generieren sollten

Das würde in vielen Fällen von readings, bei denen heute kein event erzeugt wird, keinen Sinn machen.
Umgekehrt gibt es heute schon sehr viele (hunderte?) von readings, bei denen die erzeugten events überhaupt keinen Sinn machen.

Als Entwickler mache ich mir sehr wohl Gedanken darüber, bei welchen readings ich ein event erzeuge oder nicht.

Außerdem gibt es wohl immer noch Module, die readings nicht über die dafür vorgesehenen Funktionen befüllen, sondern direkt den hash beschreiben.

[frank]

Als Entwickler mache ich mir sehr wohl Gedanken darüber, bei welchen readings ich ein event erzeuge oder nicht.

ich wollte nicht sagen, dass die entwickler sich keine gedanken über sinnvolle events machen. ganz im gegenteil wäre eine sinnvolle "voreinstellung" grundsätzlich wünschenswert.

weiterhin behaupte ich aber, dass ein entwickler nicht überschauen kann, welche wilden ideen sich user einfallen lassen können. da sind sicherlich alle schattierungen von genial bis wahnsinnig dabei.
aktuell behindert eine im code vorgenommene voreinstellung der events die kreativität des users, da er sie nicht wieder erweitern kann.

für jedes zusätzliche event eine diskussion zu starten ist mitunter sehr ermüdend.

ideal wäre eine sinnvolle voreinstellung durch den entwickler, die der user in beide richtungen verändern kann.

[Beta-User]

Da ich explizit aufgefordert wurde, meine Meinung kundzutun, hier mein Senf:

Bitte keine zusätzlichen Events - jedenfalls nicht vor 6.1 release. Wir wissen derzeit nicht, wie viele Events das (v.a. bei schlecht gecodeten Modulen, falls es solche geben sollte) generieren würde, und manche User sind "eventmäßig auf Kante genäht".

franks Anliegen verstehe ich aus gegebenem Anlass allerdings auch nur zu gut, und von daher: Wenn, dann bitte für den Moment nur, wenn die anfordernde Instanz das ausdrücklich so haben will - optimalerweise über den Instanzhash einstellbar, damit man nicht immer wieder den ganzen Code anfassen muss, wo überall ggf. Assign... aufgerufen wird...

[rudolfkoenig]

ideal wäre eine sinnvolle voreinstellung durch den entwickler, die der user in beide richtungen verändern kann.

Am besten bequem (mit Regexp) und natuerlich ohne Performance Einbussen. Der Haken ist: ich weiss nicht, wie ich das machen soll.

Im aktuellen Fall wird die Sache dadurch verkompliziert, dass AssignIoPort nicht die "offiziellen" readings*Update Funktionen verwendet, sondern (um Performant zu sein) eine Abkuerzung waehlt. Und selbst bei dieser Abkuerzung gibt es eine Sonderbehandlung (vulgo Hack), was die Anwendung eines generischen Schalters nicht gerade einfacher macht. Und das im Moment fuer einen ganz speziellen Anwendungsfall, was eigentlich anders geloest werden sollte.

Ich will nicht sagen, dass ich irgendwann nicht nachgebe, aber Kosten/Nutzen sollte im Rahmen bleiben.

[frank]

Am besten bequem (mit Regexp) und natuerlich ohne Performance Einbussen. Der Haken ist: ich weiss nicht, wie ich das machen soll.

sicherlich nicht gut überlegt, trotzdem mal erwähnt:

ein attribut (eventsDefault:on|off), das das codierte eventverhalten aller readings eines devices umschalten kann.
eventsDefault=on: das vom entwickler codierte/minimierte verhalten ist wirksam, so wie bisher.
eventsDefault=off: alle codierten restriktionen sind unwirksam, also theoretisch können nun alle readings events on update generieren.

[rudolfkoenig]

ein attribut (eventsDefault:on|off), das das codierte eventverhalten aller readings eines devices umschalten kann.

Das ist deutlich bescheidener als das, was ich befuerchtet habe, und ich kann es auch einbauen, ich wuerde es dann aber forceReadingEvents nennen. Leider wird es in diesem Fall (AssignIoPort) nicht helfen: immer noch interessiert? Wenn ja: gibt es einen konkreten Anwendungsfall?

[frank]

Das ist deutlich bescheidener als das, was ich befuerchtet habe, und ich kann es auch einbauen, ich wuerde es dann aber forceReadingEvents nennen.

cool, dann könnte martin in cul_hm im code ordentlich events minimieren und viele timingprobleme wären gelöst.

Leider wird es in diesem Fall (AssignIoPort) nicht helfen: immer noch interessiert? Wenn ja: gibt es einen konkreten Anwendungsfall?

das hatte ich schon verstanden und interessiert bin ich natürlich auch noch. 
hierbei reicht mir aber events-on-change.

anwendungen wären alle für cul_hm. also eventuell wie vorgeschlagen eine freischaltung pro device:
-zentrales notify, das durch alle io-wechsel getriggert wird, um
--die geänderten einstellungen der io zu checken (was hoffentlich bald nicht mehr nötig sein sollte)
--einen counter zur signalisierung vermehrter wechseltätigkeit einzurichten
    (normalerweise sollten bei mir keine wechsel nötig sein)
-filelog zum speichern und plotten aller wechsel
-wahrscheinlich eine signalisierung für HMinfoTools, die über ein eingefärbtes icon die korrekte nutzung des eingestellten prefferd io charakterisiert (grün, gelb, rot)

[rudolfkoenig]

anwendungen wären alle für cul_hm. also eventuell wie vorgeschlagen eine freischaltung pro device:

Das Du das moechtest, ist mir klar, aber wenn ich forceReadingEvents einbaue, wuerdest Du das nicht koennen.
Mich interessieren die Faelle, die moeglich sind, vulgo die readings*Update(...,0) Aufrufe, die ausgewertet werden wollen.

[frank]

ok, verstanden.

aktuell eher der "umgekehrte" fall, dass ich nun modulautoren bitten kann, events zu reduzieren, da ich mir ja mit dem neuen attribut kein "eigentor" mehr schiessen kann. 

ansonsten hatte ich vor längerer zeit eine für mich sehr unbefriedigende diskussion mit dem autor von 77_Nina.pm (nicht svn). dort wurden damals events extrem minimiert, so dass ich mir die events selber eingebaut habe.
dort brauchte ich einen trigger on-update, es wurde aber nur on-change angeboten.

ideen hatte ich sicher noch ein paar wenige, aber wahrscheinlich keine energie, um diskussionen zu starten. bei einigen
autoren ist vermutlich schon die frage nach weiteren events eher energieverschwendung.
mit einer einführung von forceReadingEvents werden wahrscheinlich wieder ideen kommen, die bisher "verkümmert" sind.

[betateilchen]

Wenn man nun tatsächlich anfängt, mich als Entwickler mit solchen Mechanismen zu entmündigen, indem man meine Überlegungen zu readings und events einfach ignoriert und -noch schlimmer - übersteuerbar macht, werde ich mir überlegen müssen, wie ich das als Entwickler verhindern kann.

Und wenn es nicht anders geht, werde ich halt wieder anfangen, den readings-hash direkt zu beschreiben.

Wenn ich mir überlege, dass die ganze Diskussion letztendlich nur wegen eines einzigen Moduls (CUL_HM) angestossen wurde, sollte man sich m.E. eher darum kümmern, dieses eine Modul in geordnete Bahnen zu lenken, anstatt die komplette Community von Entwicklern plötzlich zu gängeln und zu bevormunden.

[frank]

Wenn man nun tatsächlich anfängt, mich als Entwickler mit solchen Mechanismen zu entmündigen, indem man meine Überlegungen zu readings und events einfach ignoriert und -noch schlimmer - übersteuerbar macht, werde ich mir überlegen müssen, wie ich das als Entwickler verhindern kann.

Und wenn es nicht anders geht, werde ich halt wieder anfangen, den readings-hash direkt zu beschreiben.

Wenn ich mir überlege, dass die ganze Diskussion letztendlich nur wegen eines einzigen Moduls (CUL_HM) angestossen wurde, sollte man sich m.E. eher darum kümmern, dieses eine Modul in geordnete Bahnen zu lenken, anstatt die komplette Community von Entwicklern plötzlich zu gängeln und zu bevormunden.

jetzt weiss ich endlich, wozu man popcorn braucht. 

danke für deine wirklich perfekte untermalung meiner gewagten these:

bei einigen autoren ist vermutlich schon die frage nach weiteren events eher energieverschwendung.

trotzdem noch mal ernsthaft:

wenn deine angebotenen events wirklich so perfekt gesetzt sind, braucht doch kein mensch für deine module dieses attribut. wo wirst du entmündigt, gegängelt oder bevormundet? du sollst, musst und brauchst nichts ändern, soweit ich das überblicke.
was haut dich so aus den socken?

[Beta-User]

Meine 2ct:
Wir sollten nicht Rechenleistung einplanen für Prüfungen, die man nur in ganz seltenen Ausnahmefällen vielleicht braucht (und dann auf andere Weise einbauen kann, und zwar optimalerweise jeweils im "Problemmodul" selbst). Bin also weiter gegen Events, egal ob zwangsweise oder optional herstellbar und auch gegen zusätzliche interne Prüfungen/Abfragen.
Noch ein event-on.*-Attribut ist vermutlich auch aus Usersicht nicht hilfreich; da hat jetzt schon - vorsichtig ausgedrückt - eine nicht unerhebliche Zahl der User Probleme, die bestehenden Optionen sinnvoll zu setzen.

Und bitte - bei allem Herzblut, das da teils drinsteckt - bleibt doch bei der Sache.

Wei gesagt: Nur meine 2ct.

[betateilchen]

Bin also weiter gegen Events, egal ob zwangsweise oder optional herstellbar und auch gegen zusätzliche interne Prüfungen/Abfragen.

Danke! Zumindest bin ich mit meiner Meinung und Denkweise nicht alleine.