fhem 4 Nerds or users?

[Franz Tenbrock]

Hallo
ich bin ja schon ein paar Jahre hier registiert
einige Jahre lief meine Anlage ohne Probleme und mit nur ganz wenigen Erweiterungen
Ich habe so die Vermutung, dass alles die hier was geschrieben haben alles andere als normale User sind.
DB log kenne ich vomm Namen seit Jahren hatte aber bisher immer Angst es anzuwenden,
fhem.cfg läuft  und ich verstehe auch den Code der da steht.

Ich bin seit 40 Jahren Windows user und nur wegen FHEM quäle ich mich mit Linux, ein Buchstabe fals und nichts geht mehr.
ok schlank, schnell und etrem vielseitig aber für jemanden der nur ganz selten davor sitzt wirklich eine Qual.
Ich bin jemand der sich in ein Thema auch reinquält, viel sind da heute aber anders gestrickt.
Wenn eine App nicht das macht was man will nimmt man halt eine andere.

Was aus meiner Sicht besser gepflegt und auch in einfacherer Sprache gepflegt werden sollte ist das Wiki
User, nicht Nerds, kennen die Sprache nicht so gut, verstehen häufig nicht warum hier ein Komma ohne Leerstelle stehen muss etc.
Es gibt ewig lange Threads und es gehört schon viel Enthusiasmus dazu sich nach Feierabend da durch zu quälen, sie sind so lang, weil eben im Wiki es nicht für den einfachen user dokumentiert ist.

Ich habe mich in den letzten Tagen zB durch die readingsGroup gequält, kleineste Fehler im Code und nichts geht
Damians DOIFs haben mich so fasziniert dass ich es auch haben wollte, ok die Temperaturdarstellung von meiner Heizungsanlage habe ich nun, aber es hat mich fast 3 Stunden gekostet bis es so war, dass ich einen Mehrwert davon hatte.
Dann wollte ich mal eben schnell Tankenclever.de von ihm, Code kopiert, aber es klappt nicht, keine Ahnung warum nicht, warum weiss ich es nicht, weil ich eben den ganzen Code noch nicht verstehe, es wird einfach zu viel da an Wissen vorrausgesetzt
zB diese Zeile hier:
attr Tankstelle devStateIcon {ui_Table::ring(ReadingsVal("$name","Diesel",0),1.00,1.40,120,0,"Diesel",90,undef,2)."
was bedeuten die gnazen Zahlen da hinten ?  man müsste ewig lesen um zu wissen was dies bedeutet, mit probieren kommt man da kaum weiter
Fakt ist, weil ich die Zeile nicht verstehe komme ich nicht weiter
ich würde mir so was wünschen wie dies hier
1.00 = Spritpreis, 1.40= maximaler Preis, 120 = Farbe
ich hoffe ihr versteht was ich meine.
Damian hat so viel Code veröffentlicht, 1000 Dank dafür,
hier nur die Erklärung woran mancher user scheitert, nicht der Nerd.

also nicht böse sein.

habe seit 2,5 Jahren nach meiner Selbstständigkeit einen neuen Job als Angestellter, In der 2 Woche meinte eine Angestellte zu mir: das haben wir schon immer so gemacht, da war mir rausgerutscht : das heisst aber noch lange nicht das dies richtig war

interessante und auch hoch wichtige Diskussion

noch was zum Schluß
Ich hatte 10 Jahre mit 2 Freunden ein Softwareprojekt (maxidoc), ich Anwender und meine Patientenwaren die Anwender, mein Freund der Programmierer. Fast täglich habe ich mit dem programmierer zusammen gesessen und die Probleme aus Anwendersicht besprochen, und die Software entsprechend angepasst. nur wenn der Endanwender damit klar kommt nutzt es allen.

[KölnSolar]

Jetzt kenne ich den Grund für Deine "plötzliche" u. "dauerhafte" Reduzierung Deiner Forum-Aktivitäten. 

habe seit 2,5 Jahren nach meiner Selbstständigkeit einen neuen Job als Angestellter

Ich denke auch, dass das

Was aus meiner Sicht besser gepflegt und auch in einfacherer Sprache gepflegt werden sollte ist das Wiki

der Kern ist. Die Diskussion hier, war mir bisher viel zu detailliert, bereits zu sehr in der Tiefe, dass man sich gedanklich ausklinkt.
Im Sinne von der "Der Fisch...am Kopf..." ist es
1. das Wiki, das für einen einfachen Einstieg neuer User oder eines neuen (ausgereiften) Themas helfen sollte, es aber nicht tut.
2. eine Neuentwicklung immer von einem Nerd ausgeht, dem maintainer eines Moduls.
3. "Standards" für einen maintainer kaum zu finden, oder veraltet, oder ....  sind.

Meine Vorschläge:
zu 2.: wir brauchen nicht "den" maintainer, sondern ein maintainer team. Ich habe mich bisher strikt geweigert das wiki zu pflegen, weil ich als maintainer eben nicht die user Brille aufhabe, sondern aus technischer Sicht und entwicklungshistorisch beschreibe.
zu 1. ohne Wiki, welches von einem "Gremium" begutachtet wird, keine Freigabe
zu 3.
- technische Begutachtung  durch ein "Gremium", sonst keine Freigabe
- technische Standards

Und wo ich das so schreibe, komme ich dem wahren Problem näher Es fehlt uns an Struktur und Organisation.

Prima Erkenntnis. Aber wer soll es wie machen ? Der arme Rudi wird zwar gerne kritisiert, aber er wird auch von uns allen ziemlich allein gelassen.

Ich schließe dann mit der Frage, zumal es gut zu meinen 1. Zeilen passt: Wer committed sich, für was auch immer, Verantwortung zu übernehmen ? Nur so kommt man zu

Struktur und Organisation

Standards

Wiki

Aber ich sehe in meiner Glaskugel schon den nächsten Thread von Rudi, wo er vergeblich nach maintainer-Nachfolge sucht, die community sich aber wieder wegduckt...

[martinp876]

Erst einmal antworten
1) User-readings: Die Einlassung verstehe ich nicht. Klar funktionieren User-readings nur mit einem Trigger. Das ist, wenn nichts angegeben, jegliches Event welches durch die "eigene" entity ausgelöst wird. Dann kann man das noch einschränken - liegt in der Verantwortung des Users. Ich denke nicht , je etwas anderes behauptet zu haben. Das User-Reading wird vom kernal ausgefüllt und kann dann schon sparsam sein.
=> ein Orginal-Reading ist immer "besser" - WENN es zu Verfügung steht.
Ah, jetzt habe ich deinen Punkt: wenn das orginal-Reading kein Event auslöst wird auch das User-Reading nicht ausgeführt. Guter Punkt - scheint korrekt. Werde ich beachten!
Aber: ich habe Orginal-Readings welche SEHR heftig sind und welche ich nicht brauche. Möglich, dass es jemanden interessiert. Also wäre es cool, dies auf User-Ebene abschalten zu können. Es handelt sich um einen seltenen, aber ärgerlichen Fall. Nachdem es bi mir nur auf eine Entity mit einem Reading zutrifft kann man es aushalten....

=> EIGENTLICH... will ich einen Glättungs-algo welcher das übliche Rauschen der Messwerte filtert. WIE man das user-geeignet implementieren KÖNNTE (alles konjunktiv) habe ich noch nicht überlegt. Ich will das orginal schon sehen - allerdings will ich nur das geglättete loggen (falls ich es loggen will). Trigger kann ich auch auf das geglättete auslösen.
==> ich werden mir einmal Gedanken machen, wie ich es lösen könnte - INCL triggeroption! logisch.

Und dass ".*" (für den Rest) ... 

super a) kann man das nachlesen? b) Dokumentation ist der code von event-on-change-readings? Nix "lesbares"? wäre schade, wenn hier Möglichkeiten bereit gestellt werden, welche nur im Code nachzuvollziehen sind. Und ohne Spec besteht die Gefahr, dass es beim nächsten Update nicht mehr geht, weil der Autor es anders "gemeint" hat und es kein "Feature" war.

@Martin: Wenn wir schon beim Thema Effizienz im Coden sind: in CUL_HM finden sich ziemlich viele doppelte Quotes. Why?

Hm... vielleicht habe ich nicht gut nachgelesen, bei meiner Perl-selbst-lern phase. "hallo" ist weniger effizient als 'hallo' ? ich hatte es in meiner Anfangsphase einmal versucht, auszumessen - ohne erkennbare performance-änderung. Ich nehmen es gerne auf und werde es korrigieren.

Ich habe so die Vermutung, dass alles die hier was geschrieben haben alles andere als normale User sind.

in dieser Ecke des Forums erwarte ich, dass a) selbstverständlich jeder etwas posten kann - aber b) es um substantielle inhaltliche Fragen von fhem geht, also die Fragen a programmer und super-user geht.

DB...fhem.cfg

ich betrachte aktuell nur das Logging in die datenbank statt in files. Die konfiguration habe ich immernoch in files und bleibe weiter dabei. Ich sehe hier keinen Vorteil.
Grund: Logs werden gerne "ausgewertet" (z.B. Grafiken) und hierbei muss "gesucht" werden. Das kann, macht man es richtig - eine Datenbank effizient. Hier ist auch viel mehr "alarm". Es wird ständig geschrieben und gelesen. Die Datenmengen sind ganz anders - und wenn man nicht irgendwann stoppt wird die Datenbank riesig, da endlos fortgeschrieben wird. Hier suche ich Ansätze, wie ich das beherrschen kann und nicht beherrscht werde. Ich bin gelegentlich Nerd - Am Sofa mit Tablet bin ich User. Und mein Ziel ist, es von hier erfassen zu können.

Ich bin seit 40 Jahren Windows user ...will nimmt man halt eine andere.

nun - linux finde ich gerade an dieser Stelle prima -allerdings ist das nachinstallieren von Module tatsächlich umständlich und nicht mein Metier.
FHEM allerdings sollte vom OS weitgehend unabhängig sein. Perl ist Perl. Die Funktionen und expressions sind ein-eindeutig. Case-sensitiv ist ... geschmackssache. Ich finden es konsequent.
Egal, Geschmackssache.

Was aus meiner Sicht besser gepflegt und auch in einfacherer Sprache gepflegt werden sollte ist das Wiki

Wiki ist exterm unterschiedlicher Level. Und in der Tat wird der Level oft nicht unterschieden. User/Installation/Background/example,...
Ich bin tatsächlich ein Freund der guten alten Doku (so hatte ich auch einst den Anhang zu CUL_HM im Einsteiger-Doc geschrieben.
=> ICH muss bei jedem Dokument, welches ich schreibe, wissen für wen es ist. Programmer, nerd,user, anwender. Sonst kann ich die Sprache nicht treffen.
1) eine Doku sollte alle Optionen enthalten, welche angeboten werden. Um das Modul und dessen Doku "verständich" zu halten stellt sich die ERSTE Frage für den Programmer: brauche ich wirklich alle optionen? Ist da notwendig oder sinnvoll? Welche Optionen sind "expert-level" und können von "user" ignoriert werden,.... das ist, was ich hier ansprechen will/wollte.

Es gibt ewig lange Threads ... user dokumentiert ist.

ich bin zu 120% bei dir: Grundlegende Erkenntnisse aus Threats MÜSSEN in die Doku Einzug halten. Es ist ... fraglich... ob ein ein Threat als Doku gelten soll. Hier werden dinge diskutiert, wieder verworfen, wieder eingeführt. Das will keiner lesen, ich will wissen, was hier und jetzt angesagt ist.

Ich habe mich in den letzten Tagen zB durch die readingsGroup gequält, kleineste Fehler im Code und nichts geht

Code-fehler sind code-fehler. Ich kenne deine Fehler nicht. Die Frage ist allerdings, welche Hilfestellung readings-group zum debuggen liefern könnte. Hier wäre ein tutorial für user sicher hilfreich. Mir fehlen auch SEHR häufig GUTE Beispiele für die Anwendung von Attributen und Modulen. Das muss ich dann experimentell ermitteln - schade

attr Tankstelle devStateIcon {ui_Table::ring(ReadingsVal("$name","Diesel",0),1.00,1.40,120,0,"Diesel",90,undef,2)."
was bedeuten die gnazen Zahlen da hinten ?  man müsste ewig lesen um zu wissen was dies bedeutet, mit probieren kommt man da kaum weiter

ich sehe das "?" jetzt nicht in diesem Statement. Allerdings: Perl-code ist für Fortgeschrittene, genauso wie regexp. Das eignet man sich an der muss darauf verzichten. Aber auch das ist, was ich hier meine: der "simple-admin-User" sollte ohne Perl/SQL/regexp Lösungen finden können. der Advanced user beherrscht Perl - zumindest grundsätzlich und kann coolere Dinge einbauen. und der Nerd kann wie immer alles und coole/irre/fantastische/eigene Dinge implementieren.

ich würde mir so was wünschen wie dies hier
1.00 = Spritpreis, 1.40= maximaler Preis, 120 = Farbe

verstehe ich - ist sicher machbar. Ich kenne jetzt die Funktion nicht und gehe davon aus, dass es  eine generische Funktion ist, nicht nur für Spritpreise. Die Funktion "ring" muss also sauber und einfach erklärt sein (ist sie das) - und zwar an einer Stelle, an der man danach sucht. So in der Art (aus der Hüfte, ich kenne sie nicht)

Code: [Auswählen]

rng(value,param2,upperLevel,color,param5,param6,label,param8,param9)
value  : value to be displayed - must be a number
param2: ???
upperLevel : upper level. If value is above this limit the color changes - oder so etwas
color: display color if below upperLevel
param5 :??
param6:??
label: label to be displayed
param8 :??
param9 :??
so etwas geht in die Richtung API-definition. natürlich wäre eine Beschreibung, was es grundsätzlich macht hilfreich. Das sollte für jeden Funktion vorliegen, welche eine User zu Verfügung gestellt wird. Sicher habe ich hier auch Leichen im Keller

also nicht böse sein.

wir äußern hier unsere Ansichten - konstruktiv. Wie könnte man hier böse sein. Auch meine Anmerkungen sind konstruktiv gemeint - und nie alternativlos.

das haben wir schon immer so gemacht, da war mir rausgerutscht : das heisst aber noch lange nicht das dies richtig war

eine der dümmsten Bemerkungen, welche nicht nur du zu hören bekommst. Auch gerne "früher waren wir noch schlechter" - zumindest inhaltlich. 

[martinp876]

@KölnSolar
ich sehe einen Freigabeprozess als kritisch. In einer Firma mit festen Angestellten gerne. Wenn FHEM hier so etwas stemmen kann, auch gerne. Aber ich habe hier zweifel.

Ich sehe allerdings erst einmal eine triviale und für viele unangenehme  Aufgabe: ein Dokument(ation), wie Module und interfaces zu gestallten sind und was zu dokumentieren ist. das Team,was das erstellt sollte betrachten für wen das Modul/Interface gemacht wird. Also: wie kann das modul vom User betrieben werden, wie vom advanced und wie vom nerd? Wie kann man ihnen das nahebringen.

Anhand so eines Dokuments mir "guidelines" kann man dann ein UI und das gesamte Modul bewerten. Man kann den Entwickler befragen, diskutieren, und am Ende nach einer Einigung Verbeserungen erreichen.
=> Threats sind, wie schon im vorigen Post erwähnt - definitv keine Art der Dokumentation, sondern der Diskussion

[Adimarantis]

Auf die Gefahr mich zu wiederholen:
Das Konzept der individuellen Maintainer ist denke ich überholt. Schaut man sich die gängigen Open Source Projekte an, dann ist dies immer ein Gemeinschaftswerk welches z.B. über die Prozesse die GitHub mit Pull Requests and Reviews zur Verfügung stellt zusammengehalten wird.
Es gibt genug "verwaiste" Module (viele davon nicht offiziell, aber in Realität ist der Maintainer einfach nicht mehr aktiv), von denen Patches gehandelt werden, sich keiner traut tatsächlich etwas einzuchecken, sei es weil er dem Orginalautor nicht auf die Füße treten will oder Bedenken hat implizit zum Maintainer zu werden.

Eine echte gemeinsame Code Basis, mit PR Prozessen würde m.E. einige Probleme lösen
- Einhaltung von Mindeststandards
- Verwaiste Module bekämen zumindest die Chance auf eine Minimalwartung
- Direktes Feedback bzgl. Verbesserungen (da könnte Martin seine Anmerkungen gleich als PR einbringen)

Jetzt wäre ich auch nicht super begeistert, wenn andere ständig in meinen Modulen rumfuhrwerken oder ich erst ewig auf Feedback für meine eigenen Änderungen warten muss. Der Prozess müsste also schon so gestaltet sein, das der jeweilige Hauptmaintainer ohne Feedback committen kann, bzw. das letzte Wort bei der Übernahme von Patches hat.
Wenn aber ein Patch schon x Wochen unkommentiert steht, und ein Gremium aus Powerdeveloppern genug "Daumen hoch" gibt, dann kommts rein und gut.

Würde natürlich bedeuten, dass man FHEM z.B. auf GitHub umziehen müsste und das Projekt entsprechend konfigurieren müsste. Das ist Arbeit und für den Schritt müsste es erstmal eine Mehrheit geben und natürlich jemanden der sich die Migration antut.

Thema Wiki: Da kann doch schon jetzt jeder Mitarbeiten und es gibt auch die entsprechende Historie um Änderungen nachzuvollziehen. Ist ja auch Sinn eine Wikis. Da braucht es denke ich keinen Freigabeprozess. Diesbezüglich ist Dokumentation nicht so kritisch wie Code und kann bei Fehlern schnell vom Entdecker korrigiert werden. Vielleicht muss man hier die "User" mehr motivieren Beiträge zu leisten. Also @Franz: Wenn du nach einem Abend voll durchwühlen von Threads ein Aha-Erlebnis hattest, dann einfach im Wiki ergänzen - oder eben Nerd-Sprache durch allgemeinverständliches ersetzen. Wikis leben davon dass alle mitmachen.
Das gilt aber eben auch für die Maintainer: Jede Frage die im Forum beantwortet wird, sollte gleich ins Wiki einfliessen, damit sie nicht nochmal 10 Seiten später gestellt wird. Bei Signalbot habe ich mich bemüht das so zu halten - schon allein weil ich die selbe Frage eben NICHT zweimal beantworten will.

Jörg

[martinp876]

so, eigentlich wollte ich einen Post über "event-on-change-reading" verfassen.
Ich habe aktuell wieder einmal relevante Performance Probleme den Grund kenne ich noch nicht - beim Suche allerdings finde ich immer wieder Dinge welche "mir nicht gefallen".

Zum Hintergrund ist sicher den Programmieren bekannt, wie fhem mit Events umgeht. Das ist nicht schlecht, meine ich. Allerdings sollten die Programmierer es verstehen und es den Usern leicht gemacht werden, eine effiziente Struktur zu erstellen - ohne sich mit Details befassen zu müssen.

Der FHEM Ablauf ist:
a) eine Entity erzeugt Readings welche von Programmierer typisch auf "erzeuge Events" eingestellt sind. Wenn diese als Bulk abgesetzt werden, werden diese auch als bulk weiter verarbeitet.
b) über event-on-change-reading kann der User den Kernal steuern und die weitere Event-notifikation stoppen, wenn sich das Reading nicht geändert hat.
c) der Kernal notifiziert jede enroled entity. D.h. die Notify funktion wird aufgerufen
c1) ein Modul enroled (erst einmal)jede einzelne seiner Entities für alle readings jedes devices.
c2) jede Entity hat die Möglichkeit zu selektieren, von welchen entites sie events erhalten will. Oder ob überhaupt
 =>wichtig - Beispiel: CUL_HM hat sich für notifcations enroled um config-änderngen bewerten zu können. Es macht aber keinen Sinn, dass jede CUL_HM entity notifizert wird. Daher schalten alle bis auf eine CUL_HM entites die notifikation ab. CUL_HM selbst, also die verbleibenden Entity greift konfigurations-änderungen ab (global) welche attr/rename/define/delete beinhalten.
c3) jede enitiy welche notifikationen benötigt sollt einschränken, von welchern entity dies notwendig ist. Rudi hat hier einen recht effizienten mechanismus implementiert.
c4) jede entity muss dann die Readings/events filtern welche sie verarbeiten will. Readings werden nicht vom kernal gefiltert.

So - nun on-change oder on-update? 
Ich betrachte das (und diskutiere es mit mir hier) anhand von 3 Typen von Readings:
Sporadische Events
Typ: Events wie Licht-An/Aus, also schalt-events. Button-press,... HT Mode Einstellungen
Eigenschaften: sind verhältnissmäßig selten. Nicht zyklisch. Können mehrfach gemeldet werden. Bei CUL_HM durch statusmeldungen, in ACK messages, aber auch in Zyklischen Messages. Auch durch manuellen Status-nachfragen (status-Request). Ein Hoematic-RT Thermostat schickt bspw den aktuellem Mode (auto/manual/...) alle 3 Min mit der regelmäßigen Status-message

Verhalten/Auswertung: interressant ist nur die Änderung. Wenn der Status erreicht ist gilt er fortan bis zur nächsten Änderung. Nachdem - bis auf Ausnahmen - eh keine regelmäßige statusmeldung erfolgt kann man diese events getrost auf "changes-only" stellen. Alles andere kostet notifications. Was sollen diese bringen?
Gefahr: User hatten schon fehlerhafte notifies geschrieben in welchen sie ein "toggel" programmieren wollten, wenn ein Button-Press notifiziert wird. das kann leicht in ins Auge gehen, wenn man "update" als option hat.
periodische Events
das sind typisch Temperaturmessungen. Ein RT oder Bewegungsmelder mit helligkeit sind wie alles Sensoren ein Beispiel.
Der Zustand des Ventils eines HK-Therosataten ändert sich nur selten. Es geht auch stufing. Wie vor kann (muss) ich davon ausgehen, dass der Wert stabil ist, bis eine Änderung vermeldet wird. also "change" ist vollkommen hinreichend.
Auf den Controll-mode trifft das in noch schärferer Form zu. Noch weniger änderungen.
Die Wunschtemperatur dito
die gemessene Temperatur - eigentlich auch. Nun, die Änderung ist eine interpolation... aber wenn sich nichts ändert - ändert sich nichts... "change" ist hinreichend.
special Events
hier sehe ich 2 Beispiele -Motion-detection und Button-press
Ich habe den Motion-detector übernommen welcher "motion" signalisierte wenn eben Motion erkannt wurde. Das Reading stand IMMER auf "Motion" - den Rest musste man im Timestamp nachsehen. Eigentlich ist das realitätsfern. de-facto ist ein MD im Mode "motion" oder "non-motion". Er tastet ab und vermeldet "motion" wenn motion - und wichtig - wenn kein Motion gemeldet wird ist er auf "no-motion"! Dass das Device nicht ständig "no-Motion" sendet macht sinn- zu viele Messages. Aber das ist kein Grund, warum die Zentrale das nicht abbildet.
Ich habe mich also mit den MD von Homematic befasst - und siehe da - es werden ausgiebig timer mitgesendet welche der Zentrale erlauben, non-motion zu generieren.  Das geht mit jedem MD!!!
=> wenn das nicht implementiert ist hat der Programmierer seinen Job nicht vollendet!
Bei Button-Press ist es ähnlich. Man kann ein Event erzeugen, welches anzeigt, ob es ein neuer oder schon verarbeiteter "press" ist

##> ALLE Readings können so gestelltet werden, dass man OHNE PROBLEME auf "change" triggern kann
##> sollte das mit einem Reading nicht funktionieren ist zu hinterfragen, ob das Reading schlecht implementiert ist . Besser wäre dann, die Quelle des Problems zu bearbeiten .

Event-on-update
alles was man auf "update" stehen lässt kann man nachträglich filtern. Das kostet Performance, da es erst weitergeleitet wird und am Ende gefiltert wird. Jedes Notify muss das für sich selbst machen. Kostenfrei ist das nicht zu haben.


Meine (Nabel-)Schlussfolgerung
bisher habe ich alles problemlos mit event-on-change readings hinbekommen. Bei CUL_HM sowieso. In der Tat würde ich gerne noch mehr wegfiltern!
Für einen "user" wäre die Anweisung " setze alles auf "notify-by-change" eine klare und einfache Anweisung. Noch besser: könnte man in global als default setzen (da man schon verpasst hat , es als default zu setzen). einfacher geht kaum.

Die Auswertung:
Es besteht ein Problem bei Grafiken. Allgemein: wenn ich wissen will, welchen Wert die Desired-temp am 01.12.2022 11.11.11 hatte kann die Datenbank den letzten Wert vor dem Timestamp suchen und mir geben. Das ist einfach und schnell aus der DB abzufragen. 
Es gibt also noch etwas zu tun - aber nur work, keine Probleme

So nun warte ich auf die Gegendarstellung mit Beispiel. Also: wo geht "change" nicht? was geht nicht und wie kann man einem User sagen und vermitteln wie er es einzustellen hat?
Bin gespannt.

[martinp876]

@Jörg,

alles ok.
Dennoch vermisse ich die guidelines - in schriftform. Nicht in Chats/emails/threats. Etwas gegen das man messen kann. Das ist unabhängig vom Maintainer!!!!!!!

[frank]

so, eigentlich wollte ich einen Post über "event-on-change-reading" verfassen.
Ich habe aktuell wieder einmal relevante Performance Probleme den Grund kenne ich noch nicht - beim Suche allerdings finde ich immer wieder Dinge welche "mir nicht gefallen".

vielleicht hast du dir selbst ein bein gestellt? 
denn viele cul_hm user haben ggf erhebliche event probleme, wenn sie die default einstellung "attr commStInChn on" nutzen.

grundsätzlich macht die event philosophie in fhem (alle events on update) jedem irgend wann probleme, wenn man nicht selbst aktiv wird und gegensteuert.
dadurch lässt man alle erst mal an die wand laufen, finde ich. anders herum wäre humaner.

theoretisch könnte mittlerweile jeder maintainer alle events im code auf change setzen.
wenn wirklich mal ein event on update gebraucht wird, hätte jeder user die möglichkeit das über das bestens versteckte attr forceEvents zu ändern.

[martinp876]

Hall Frank
a) commStInChn... vielleicht. Sollte ein Service sein. Könnte ich auf "no-Event" setzen Aber wieso macht es in diesem Zudammenhang so viele Schwierigkeinten?

grundsätzlich macht die event philosophie in fhem (alle events on update) jedem irgend wann probleme, wenn man nicht selbst aktiv wird und gegensteuert.
dadurch lässt man alle erst mal an die wand laufen, finde ich. anders herum wäre humaner.

genau meine Meinung!

theoretisch könnte mittlerweile jeder maintainer alle events im code auf change setzen.

das halte ich nun einmal für eine ganz schlechte Idee. Mehrere Gründe
I) der Kernel hat diesen Filter vorgesehen. Ich hatte das schon vor ~8 Jahren - zu meiner Anfangszeit - im code vorsehen wollen. Da es aber der Kernel macht sollte es auch dort bleiben
II) wenn es jeder einzeln einbaut kommt nur ein durcheinander heraus. Es wird noch chaotischer. Bitte bitte nicht
III) man kann es (wie immer) nicht umstellen - das klappt dann bei allen Usern erst einmal nicht mehr.
IV) Vorschlag wäre, ein "attr global event-default onChange" vorzusehen. Dann kann es jeder selbst einbauen. Überall vermerken, das dies bestCurrentPractice ist.
Und für Ausnahmefälle und Testfälle event-on-update - ist kein Schaden. "level: expert"

---------------------------------------
so hier meine Bewertung zu Performance. Ich habe eine Performance-improvement-aktion meines Systems gestartet... und mein altes Schlachtross apptime ausgepackt. Verrichtet immernoch gute Dienst.

Code: [Auswählen]

name                                     function                               max    count      total  average   maxDly   avgDly TS Max call     param Max call
 iolgw:keepAlive                          HMUARTLGW_Ready                         11   705628   66566.75     0.09     0.00     0.00 03.12. 05:34:46 HASH(iolgw:keepAlive)
 rhasspyMQTT2                             MQTT2_CLIENT_connect                    20   705628  282105.81     0.40     0.00     0.00 02.12. 20:09:49 HASH(rhasspyMQTT2)
 hlt                                      HMLAN_Ready                             13   532835  136090.24     0.26     0.00     0.00 03.12. 10:08:04 HASH(hlt)
 ScnFlur                                  LightScene_Notify                       90   207844   29151.06     0.14     0.00     0.00 02.12. 17:02:23 HASH(ScnFlur); HASH(lfTreppeK)
 ScnGarden                                LightScene_Notify                      123   207844   12286.72     0.06     0.00     0.00 03.12. 09:48:33 HASH(ScnGarden); HASH(loDoorBall)
 ScnWohn                                  LightScene_Notify                      128   207844   15218.93     0.07     0.00     0.00 03.12. 10:22:03 HASH(ScnWohn); HASH(laLnge)
 WEB                                      FW_Notify                                1   207844    3724.10     0.02     0.00     0.00 03.12. 14:42:36 HASH(WEB); HASH(prRHMccu)
 WEBphone                                 FW_Notify                               10   207844    2189.22     0.01     0.00     0.00 03.12. 09:02:21 HASH(WEBphone); HASH(hwEss)
 WEBtablet                                FW_Notify                                4   207844    2109.08     0.01     0.00     0.00 03.12. 12:12:59 HASH(WEBtablet); HASH(hb_Clima)
 avgWeather                               average_Notify                          18   207844  117909.35     0.57     0.00     0.00 02.12. 16:34:13 HASH(avgWeather); HASH(h_burner_Pwr)
 dayTemp                                  average_Notify                          11   207844   81143.11     0.39     0.00     0.00 02.12. 15:13:38 HASH(dayTemp); HASH(hwSalon)
 et                                       eventTypes_Notify                       12   207844   66164.58     0.32     0.00     0.00 02.12. 17:04:43 HASH(et); HASH(haLnge)
 hZheating                                average_Notify                          14   207844   79150.21     0.38     0.00     0.00 02.12. 18:00:48 HASH(hZheating); HASH(hb_Clima)
 hlt                                      HMLAN_Notify                             7   207844    4511.92     0.02     0.00     0.00 02.12. 19:08:55 HASH(hlt); HASH(ScnGarden)
 ht                                       HMtemplate_Notify                        4   207844    4752.56     0.02     0.00     0.00 03.12. 00:03:13 HASH(ht); HASH(ccu)
 pa_stereo                                YAMAHA_NP_Notify                         3   207844    4635.76     0.02     0.00     0.00 02.12. 17:04:43 HASH(pa_stereo); HASH(haLnge_Clima)
 rg_Thermostate                           readingsGroup_Notify                    32   207844   34197.16     0.16     0.00     0.00 02.12. 14:59:38 HASH(rg_Thermostate); HASH(global)
 rg_battery                               readingsGroup_Notify                    25   207844   30899.62     0.15     0.00     0.00 02.12. 14:59:38 HASH(rg_battery); HASH(global)
 rg_critic                                readingsGroup_Notify                    64   207844   23780.12     0.11     0.00     0.00 02.12. 14:59:38 HASH(rg_critic); HASH(global)
 rg_heater                                readingsGroup_Notify                    98   207844   24188.40     0.12     0.00     0.00 02.12. 14:59:38 HASH(rg_heater); HASH(global)
 rg_pres                                  readingsGroup_Notify                    49   207844   24539.70     0.12     0.00     0.00 02.12. 14:59:38 HASH(rg_pres); HASH(global)
 testme                                   weekprofile_Notify                      58   207844    6213.75     0.03     0.00     0.00 02.12. 14:59:38 HASH(testme); HASH(global)
 tmr-CUL_HM_sndIfOpen                     sndIfOpen                              296   180830  130026.17     0.72  8610.98     7.51 03.12. 10:24:10 sndIfOpen:ioPCB
 ioPCB                                    HMUARTLGW_Read                        8815    87505 1068272.91    12.21     0.00     0.00 03.12. 10:22:10 HASH(ioPCB)
 b                                        ntf_Notify                              44    60070   19345.37     0.32     0.00     0.00 02.12. 14:59:37 HASH(b); HASH(global)
 iolgw                                    HMUARTLGW_Read                        1389    45741  519093.68    11.35     0.00     0.00 02.12. 14:32:14 HASH(iolgw)
 dblog                                    myDbMgmt_Log                            18    36262   33632.65     0.93     0.00     0.00 03.12. 00:27:14 HASH(dblog); HASH(WetterSchnaittach)
 tmr-YAMAHA_NP_GetStatus                  HASH(0x3ff1ac0)                         18    24850   91124.21     3.67  4374.70    18.90 02.12. 20:08:53 HASH(pa_stereo)
 deviceStateHM                            ntf_Notify                              45    19125   24414.36     1.28     0.00     0.00 02.12. 20:26:48 HASH(deviceStateHM); HASH(h_s_aussen)
 tmr-HMUARTLGW_CheckCredits               HMUARTLGW_CheckCredits                  11    12793   38103.78     2.98  7943.95    12.71 03.12. 05:23:06 HMUARTLGW_CheckCredits:iolgw
 ntfy_burnCnt                             ntf_Notify                              35    10124    3551.01     0.35     0.00     0.00 02.12. 14:59:38 HASH(ntfy_burnCnt); HASH(global)
 d_rpc178046BidCos_RF                     HMCCURPCPROC_Read                      331     8681  813479.43    93.71     0.00     0.00 02.12. 20:37:10 HASH(d_rpc178046BidCos_RF)
 tmr-HttpUtils_TimeoutErr                 HASH_unnamed                             8     6647    4929.60     0.74  7267.81    39.07 02.12. 18:37:04 HASH(0x83d8ed8)
 telnetPort                               telnet_Read                             12     4588   12198.61     2.66     0.00     0.00 02.12. 15:08:03 HASH(telnetPort)
 h_burner_SenPwr                          CUL_HM_Set                               5     3963    5442.84     1.37     0.00     0.00 03.12. 10:25:08 HASH(h_burner_SenPwr); h_burner_SenPwr; ?
 prBtPhonePapa                            PRESENCE_lanBtRead                     181     3318   23721.05     7.15     0.00     0.00 03.12. 15:12:50 HASH(prBtPhonePapa)
 tmr-DbLog_execmemcache                   HASH(0x2a55e50)                         59     3007   55652.52    18.51  4340.53    35.18 02.12. 18:42:20 HASH(dblog)
 tmr-PRESENCE_daemonScanScheduler         HASH(0x6113cb8)                        244     3007  257726.17    85.71  4389.95    52.30 02.12. 20:28:31 HASH(PsnceDaemon)
 prBtTablet                               PRESENCE_lanBtRead                     209     2333   15337.98     6.57     0.00     0.00 03.12. 15:08:38 HASH(prBtTablet)
es zeigt mir mit wenigen clicks genau, was ich wissen will.
Mein System ist auf "change-Event for all " eingestellt.
Die Auswertung ist auf Anzahl ereignisse eingestellt und sortiert. Schnell sieht man, was erst einmal falsch läuft und was ganz einfach zu beheben wäre - gefunden?

Die beiden high-runner sind pflicht- keep alive muss so oft kommen. MQTT2 - kenne ich noch nicht... kann ich abschalten.
HMLAN ready ... muss ich prüfen.

So nun die Bösewichte. Alle danach haben identisch 207844 aufrufe aus notify erhalten. Sie dauern nicht lange, ok. Aber unnötig. Offensichtlich haben sie sich pauschal eingetragen bei notify und werden bei ALLEN notifies alarmiert. Das macht schon einmal gar keinen Sinn.
Die WEB interfaces lasse ich durchgehen.
LightScene könnte kinderleicht eintragen, bei wem sie notifizert werden wollen.
ReadingsGroup dito - etwas komplizierter, aber machbar.
Average... ebenso
=> wenn ich nun event-on-update nutzen würde wäre da noch schlechter.
 hm - nun muss ich wohl für die Module ein add-on erstellen bei welchem ich das Enrolen übernehmen. So werde ich das nicht lassen...
Merke: das sind zig-fach zu viele Aufrufe
Und: der kernel macht alles richtig - die Modul-schreiber sind das Problem.

Anzumerken: mein gepimptes dblog-notify  myDbMgmt_Log  braucht nur noch 36510 Aufrufe. Gesamtzeit 34sec. Mal sehen, ob es noch schneller geht.
Und hier werden ALLE events und entites geprüft, von welchen wir etwas loggen wollen. Ich bin auf den Weg....

[Beta-User]

a) commStInChn... vielleicht. Sollte ein Service sein. Könnte ich auf "no-Event" setzen Aber wieso macht es in diesem Zudammenhang so viele Schwierigkeinten?

Weil die meisten User das Thema "Event-Minimierung" (und NOTIFYDEV) nicht wirklich auf dem Schirm haben, und erst dann was tun, wenn es "komisch" wird (überbordende Logs oder Performance-Probleme).

Wir merken halt, dass das ein echter "Dauerbrenner" ist, und die Sinnhaftigkeit des defaults hat sich der Mehrheit der CUL_HM-User bisher nicht erschlossen.

Zum Thema "Doku zu event-on-change-reading". In der commandref steht (das zu finden ist wieder eine andere Sache):

Wenn hinter dem Namen eines "readings" eine :Schwelle angegeben ist, wird das Event nur getriggert wenn die Änderung grösser als diese Schwelle ist.

Soweit also völlig klar. Das einzige, was in der Doku fehlt, ist der Hinweis, dass alle diese Attribute der Reihe nach abgearbeitet werden wie vom User angegeben und bei einem Treffer dann "Schluss" ist.
Nicht so ganz deutlich steht auch nicht dort, dass das jeweils als eine Art "whitelist" zu sehen ist: Wenn da was steht, wird auch nur das geprüft und der Rest (bei eocr) stillgelegt.

Rudi freut sich bestimmt über einen Patch, denn dass das so ist, ist kein Zufall...

Doku/Wiki ist aber in der Tat ein Thema allgemein ein Thema, und (halb-) verwaiste Module (und deren Kennzeichnung) sind es auch, ebenso die Frage, wie man es den Usern "einfach" machen kann, "gute" Einstellungen zu finden (und diese zu verstehen, damit sie sie ggf. anpassen können).

Es gibt dazu bereits diverse Wege. Gut angenommen wird attrTemplate bei MQTT2_DEVICE und HTTPMOD (weil man da eben "alles" über Attribute konfiguriert).
Komplett unverstanden ist archetype, aber auch das könnte vielen Usern das Leben erleichtern. (Und dann gibt es noch weitere Tools, die ich aber auch nicht vertieft kenne oder nutze).

Wahrscheinlich wiederhole ich mich da mal wieder, aber mAn. braucht es nicht unbedingt neue Tools, sondern eine Art "gemeinsames Verständnis", wie die Dinge zu sein haben und was man Usern ggf. einfach empfehlen sollte (selbst, wenn es "ultrakompliziert" aussieht). Ändern können es die Einsteigenden dann immer noch...

Nachtrag noch zum Thema "Aktualisierungen sehen": event-on-change-reading (auch mit "Schwelle" verhindert nicht das Aktualisieren des timestamps. Das kann man zusätzlich unterdrücken, aber man sieht, ob ein Device noch lebt!

Nachtrag  zu ".*": Bei Tastern ist das Kontraproduktiv, und manche Module verarbeiten auch nur, was irgendeine Gegenstelle ihnen schickt. Das ggf. mit watchdog-Funktionen aufzubohren geht zwar, aber warum einen workaround für ein Problem schaffen, das man selbst mit "Dogmatismus" generiert hat...?

[Icinger]

Um nochmal kurz auf

zB diese Zeile hier:
attr Tankstelle devStateIcon {ui_Table::ring(ReadingsVal("$name","Diesel",0),1.00,1.40,120,0,"Diesel",90,undef,2)."
was bedeuten die gnazen Zahlen da hinten ?  man müsste ewig lesen um zu wissen was dies bedeutet, mit probieren kommt man da kaum weiter

zurückzukommen:

Was genau wäre an

Code: [Auswählen]

ring ($value,$min,$max,$minColor,$maxColor,$unit, $sizeHalf,$colorRef,$decFont,$model,$lightness)

$value     # darzustellender Wert
$min       # minimaler Wert, optional, default=0
$max       # maximaler Wert, optional, default=100
$minColor  # Farbe (hue: 0-360) des kleinsten Wertes, optional, default = undef
$maxColor  # Farbe (hue: 0-360) des maximalen Wertes, optional, default = undef
$unit      # Einheit des Wertes, optional, default = undef
$sizeHalf  # "<size>,<half ring>" size: Größe der Grafik, optional, default = 100, half ring: 1 für Halbring
$colorRef  # Referenz auf eine Funktion, die zu einem Wert einen Farbwert (hue: 0-360) bestimmt, oder eine Referenz auf eine Arrayliste mit Grenzwerten und Farben, optional, default = undef
$decFont   # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
$model      # '<Farbverlauf>,<Min/Max>,<Innenring>,<Zeigerstärke>,<Modus>',
            #   Farbverlauf: 1 für monochrom,
            #   Min/Max: Style-SVG-Attribute oder 1 zum Anzeigen der Min-/Maxwerte,
            #   Innenring: Style-SVG-Attribute oder 1 zum Anzeigen des Innenringes, Zeigerstärke: in Pixel,
            #   Zeigerstärke: Breite des Zeigers,
            #   Modus: 0 Standard Min-Max, 1 Min-Null-Max, 2 Null-Min/Max,
            #   alle Parameter sind optional, default keine Angaben: ',,,,,'
$lightness  # Helligkeit einzelner Elemente (0-100) "<ring>,<inner ring>,<minMax>,<unit>,<value>", optional, default: "50,50,50,40,50"
Wird $colorFunc nicht angegeben, so wird der Farbwert zwischen $minColor und $maxColor linear interpoliertnoch besser zu beschreiben? Steht genau da, wo es sein soll -> im Wiki
siehe https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Farbskalierte_Anzeige_eines_Zahlenwertes_mit_Hilfe_der_universellen_SVG-Funktion_ring

[martinp876]

Weil die meisten User das Thema "Event-Minimierung" (und NOTIFYDEV) nicht wirklich auf dem Schirm haben, und erst dann was tun, wenn es "komisch" wird (überbordende Logs oder Performance-Probleme).

das Problem ist nicht nur ein User-Problem - auch gestandene Module-owner schlampen - erheblich!

Wir merken halt, dass das ein echter "Dauerbrenner" ist, und die Sinnhaftigkeit des defaults hat sich der Mehrheit der CUL_HM-User bisher nicht erschlossen.

CUL_HM User? Das ist ein allgemeines Problem. Das trifft alle Module.

FHEM Admins könnten schnell etwas dagegen unternehmen. Und wenn immer wieder langjährige "Berater" davor warnen, auf Event-On-Change umzustellen hemmt es die Umsetzung ungemein. Der User braucht zwingend eine einfache Methode, die Events einzudämmen. Mehr noch: der User sollte eigentlich erst einmal garnichts machen müssen - es muss default sein.

Wenn hinter dem Namen eines "readings" eine :Schwelle angegeben ist, wird das Event nur getriggert wenn die Änderung grösser als diese Schwelle ist.

ok, werde ich testen.
Mit Attribute meinst du die Liste der Parameter des Attributs? Ok, ich bin ein Stinker und selbst nicht immer konsequent. "event-on-change-reading" ist ein Attribut welches eine Liste von Parametern enthalten kann. Anderer Vorschlag zur Wortwahl?
Ein Beispiel wäre hier definitiv cool:
attr xxx event-on-change-reading .*,measured-temp:0.5
oder
attr xxx event-on-change-reading measured-temp:0.5,.*
Das meintest du mit "er Reihe nach". Wie gesagt ein Beispiel würde einem User sicher helfen.
Interessant ist hier dann auch die Wirkung. Wenn sich also die measured-temp um nur 0.3° ändert: wird die Webseite upgedated? Notifys werden nicht getriggert. Einem Programmierer und Nerd sind die Fragen sicher klar. Dem User muss klar gemacht werden (ein satz) was es bedeutet, wenn KEIN Event getriggert wird.

Es gibt dazu bereits diverse Wege. Gut angenommen wird attrTemplate bei MQTT2_DEVICE

kenne ich nicht, hört sich aber gut an. Ich bin ein großer Freund von templates. Dennoch: Meine erste Forderung ist, dass sich ein Module oder eine Entity schon bei der Definition erst einmal in einer standard konfig selbst einrichtet. Der Anwender kann dann rumspielen. optimieren ider es zertören. Aber die erste Konfig sollte einfach erst einmal das sein, was der Anwender typisch will.

... braucht es nicht unbedingt neue Tools, sondern eine Art "gemeinsames Verständnis", wie...

100% Zustimmung.  Ein gemeinsames Verständnis, wie man ein Modul designen sollt wünsche ich mir schon lange. Die Liste meiner offenen Punkte ist lang. Ich kenne keine Dokumentation, was man in Internals schreiben sollte, was die UUID soll, wie man mit renames umgehen sollte, .....
Mein Vorschlag wäre demnach ein Dokument zu erstellen (wie hier schon einmal erwähnt ist das Forum eine Diskussionsplattform - keine Dokumentation) was die Bedeutung der einzelnen Elemente ist. Schriftlich ist unabdingbar. Wiki ist möglich, ein PDF würde ich bevorzugen.
Beispiel: wenn ein rename stattfindet ist es Aufgabe der einzelnen Elemente welche auf das referenzierte Element verweisen, das rename nachzuziehen. Kann man auch anders definieren. wovon ich abrate. Dennoch: definiert ist es nicht.

Nachtrag noch zum Thema "Aktualisierungen sehen": event-on-change-reading (auch mit "Schwelle" verhindert nicht das Aktualisieren des timestamps. Das kann man zusätzlich unterdrücken, aber man sieht, ob ein Device noch lebt!

Das mit den Timestamp ist auch sinnvoll. Der sollte schon aktualisiert werden. Auch der Wert, wenn er unter der Schwelle liegt. Nur die Benachrichtigung an andere Module wird unterbunden. Das betrifft dann auch das Logging im File oder der DB.
=> wie man sieht ist hier etwas Text zu hinterlegen, damit der Anwender auch erfassen kann, was "event-on..." bedeutet.

Nachtrag  zu ".*": Bei Tastern ist das Kontraproduktiv, und manche Module verarbeiten auch nur, was irgendeine Gegenstelle ihnen schickt. Das ggf. mit watchdog-Funktionen aufzubohren geht zwar, aber warum einen workaround für ein Problem schaffen, das man selbst mit "Dogmatismus" generiert hat...?

verstehe ich nicht. Wenn du auf CUL_HM Buttons anspielst: mit event-on-change-reading kann man ganz einfach nur einen Trigger erhalten. Konsequente Einstellung des Systems. Einen Kostenlosen Zähler erhält an auch. Man kann erkennen wer antwortet. Man kann eigentlich alles sehen. Und doppelte Trigger erhält man nicht. Ein Zusatzmodul ist nicht notwendig. Ein Module-owner muss die angebotenen Readings gemäß den geltenden Regeln generieren. Nur sind die Regeln eben nicht definiert. Das Dokument fehlt.

@Icinger: Perfekt. Das muss auch ein User erfassen können.

[KölnSolar]

Sorry Martin, wenn ich weniger zu Deinen Detailfragen beitrage, sondern Deinem Threadtitel.

Dazu schmeiße ich mal diesen Link zu Wiki-Thema Development in die Runde. Ich bezweifle, dass den jeder kennt(nutzt), der als "Entwickler" klassifiziert ist. DevelopmentModuleIntro ist eine sehr gute Basis. Hier werden Fragestellungen aus diesem Thread zu events, Internals aufgegriffen. Auch readings. Aber kein Hinweis auf die Kombi reading-event. Dass es überhaupt die Funktionalität gibt, dass readings nie ein event erzeugen oder nur bei inhaltlicher Änderung, findet sich erst in DevelopmentModuleAPI#Readings_.2F_Events, das vermutlich noch weniger Entwickler kennen. Und eine guidline, wie was einzusetzen ist fehlt gänzlich. Die Verbindung zu den diversen event-...-Attributen ebenso.

Die Versionsgeschichte der DevelopmentGuidelinesReadings spricht Bände, dass ein guter Ansatz im Sande verlaufen ist.

Thema Wiki: Da kann doch schon jetzt jeder Mitarbeiten und es gibt auch die entsprechende Historie um Änderungen nachzuvollziehen. Ist ja auch Sinn eine Wikis. Da braucht es denke ich keinen Freigabeprozess. Diesbezüglich ist Dokumentation nicht so kritisch wie Code und kann bei Fehlern schnell vom Entdecker korrigiert werden. Vielleicht muss man hier die "User" mehr motivieren Beiträge zu leisten. Also @Franz: Wenn du nach einem Abend voll durchwühlen von Threads ein Aha-Erlebnis hattest, dann einfach im Wiki ergänzen - oder eben Nerd-Sprache durch allgemeinverständliches ersetzen. Wikis leben davon dass alle mitmachen.

ist meines Erachtens der Trugschluss aus "viel hilft viel". Fühle ich mich jetzt berufen, an den vorgenannten Dokumenten "rumzuwurschteln"? NEVER. Aus Ehrfurcht vor denen, die die Beiträge bis hierhin entwickelt haben, schmeiße ich doch nicht die Struktur und Inhalte über den Haufen. Ich arbeite aber gerne mit oder mache einem "Gremium" Vorschläge für Änderungen.

Nun bin ich dann doch irgendwie wieder bei Martins "Detailfragen" gelandet.

Und wer ändert nun das Wiki mit den in diesem Thread gemachten Hinweisen, damit man den nächsten Martin einfach auf das dortige Dokument verweisen kann ?

[Beta-User]

das Problem ist nicht nur ein User-Problem - auch gestandene Module-owner schlampen - erheblich!

Das mag sein, aber es macht m.E. auch keinen großen Sinn, "Entwicklungs-Interessierte" mit "noch mehr" Zeug zu belasten, das sie unbedingt beachten müssen, und das im ersten Moment unverständlich erscheint.

Einen (Qualitäts-) Review  machen zu lassen, trauen sich viele leider nicht, erfahrungsgemäß werden zielführende Tipps allerdings doch in der Regel gerne angenommen. Das Problem ist halt oft, dass "irgendeine" (häufig leider "schlechte") Vorlage (ähnliches Modul) kopiert wird, und dann noch aus Unerfahrenheit weitere Böcke geschossen werden.

CUL_HM User? Das ist ein allgemeines Problem. Das trifft alle Module.

Jein. Es tritt halt empirisch gesehen gerne in der Kombination von CUL_HM (ohne abgeschaltete Kommunikationsreadings) und MQTT auf (da kann aber das Modul nichts dafür!).

Und ich habe vor einiger Zeit eine Testversion von VALVES ins Forum gestellt, die sehr viel seltener triggert als die alte. Das werde ich wieder umstellen, weil diese Art Einstellung in User-Hand gehört. Warum? Ich will die virtuelle Ventilöffnung an eine MCU senden, die die Vorlauftemperatur entsprechend ändert. Bekommt die nicht regelmäßig einen aktuellen Wert, funktioniert das so nicht, und man muss einen umständlichen workaround bauen. Wußte ich nur "damals" noch nicht...

ERGO: Die Entscheidung, was wann warum wie oft triggern soll gehört in User-Hand! Der Modulautor sollte das nicht zu sehr einschränken.

FHEM Admins könnten schnell etwas dagegen unternehmen. Und wenn immer wieder langjährige "Berater" davor warnen, auf Event-On-Change umzustellen hemmt es die Umsetzung ungemein.

Jedenfalls ich warne NUR (!) vor dem (m.E. engstirnigen!) Festhalten an der pauschalen Empfehlung, einfach überall 

Code: [Auswählen]

attr DEVICE event-on-change-reading .*zu setzen. Das ist einfach zu kurz gesprungen, weil man nämlich mit

Code: [Auswählen]

attr DEVICE event-on-change-reading measured-temp:0.3,.*GENAU DAS erreichen kann, was du als eine Art "Goldstandard" anzusehen scheinst.

Und GENAU DAS kann archetype automatisiert bei der Definition eines neuen Gerätes  verteilen, und zwar so, wie es der USER vorher eingerichtet hat. Ich hasse es dagegen, wenn mir Module vorschreiben wollen, wie Attribute gefüllt zu sein haben. Zum einen macht es den Code unleserlich, und zum anderen kann der Modulautor nicht wissen, was ich mit den Infos machen will. Er kann gerne (!!!) einen Vorschlag machen, aber das sollte m.E. nicht direkt im Modul stehen, es gibt dafür - wie bereits erwähnt - andere Wege! Man muss sie nur kennen...

Deswegen kann ich Sätze wie

der User sollte eigentlich erst einmal garnichts machen müssen - es muss default sein.

nicht unterstützen. Der User muss (!) sich Gedanken machen, wie sein System funktionieren soll, und man kann und sollte ihm Vorschläge machen.

Ich warte übrigens seit Jahren (!) darauf, dass jemand für die als "geschätzig" bekannten Shelly einen Vorschlag liefert für Event-minimierende Attributeinstellungen, die ich dann auch in attrTemplate aufnehmen würde - nur leider bisher Fehlanzeige. Keine Idee, warum...
(Ich nutze die selbst nicht (mehr) und habe keine Neigung, da was aus dem Elfenbeinturm raus vorzugeben. Übrigens auch weil ich möchte, dass das Thema besser bei den Usern ankommt).

Beispiel: wenn ein rename stattfindet ist es Aufgabe der einzelnen Elemente welche auf das referenzierte Element verweisen, das rename nachzuziehen. Kann man auch anders definieren. wovon ich abrate. Dennoch: definiert ist es nicht.

Schwierig. Im Moment haben wir keine "replace" Funktion, und das ist bei mir der Hauptanwendungsfall für rename... Da will ich aber grade haben, dass (z.B. LightScene) das mit den beiden Umbenennungen nicht nachvollzieht! Und über die Implikationen für devspec-basierte Eventhandler haben wir auch schon ein paar Mal ergebnislos nachgedacht...

Im Übrigen spreche ich nicht immer nur von CUL_HM! Meine Welt ist etwas "bunter", es gibt da u.a. noch ZWave, HUEDevice, MQTT-basierte Hardware mit diverser Funktionalität und MySensors...
Bei den Tastern hatte ich an HUEDevice-Geräte gedacht, aber dasselbe "Problem" besteht, wenn man die z.B. über zigbee2mqtt einbindet. Auch da darf "eocr" nicht auf ".*" stehen...

Was das Wiki angeht, ist es aus mehreren Gründen nicht so einfach, da Hand anzulegen. Zum ersten muss man wirklich sehr tief drin sein, um da überhaupt Hand anzulegen, und zum anderen müßte man z.B. auch ein gemeinsames Verständnis dazu haben, was Hilfsmittel wie PBP/perlcritic angeht. Da sind Prototypen z.B. extrem hinderlich.

Auch stilistisch stellt sich manche Frage. Beispiel gefällig:

Code: [Auswählen]

sub X_Define($$) {
 my ( $hash, $def ) = @_;
 my @a = split( "[ \t][ \t]*", $def );
...Warum schreibt man das so? Meine Module sehen in der Regel an der Stelle so aus:

Code: [Auswählen]

sub Define {
    my $hash = shift // return;
    my $def  = shift // return;
    my @arr  = split m{\s+}xms, $def;
    my $name = shift @arr;

Und zu Prototypen ein aktuelles Beispiel. Vorzufinden war da:

Code: [Auswählen]

sub MODULE_ParseResponse($$$) {
    my ( $param, $err, $data ) = @_;   
    Aha. Der Modulautor meint, man braucht zwingend drei Argumente für diese Funktion. Denkste... Es geht so weiter:

Code: [Auswählen]

    my $hash = $param->{hash};
    my $queue_hash = $param->{hash};
    my $cmd = $param->{cmd};
    my $arg = $param->{arg};
    my $options = $param->{options};
    $data = "" unless(defined($data));
    $err = "" unless(defined($err));
So einen Code kann jedenfalls ich nicht warten...

Jetzt sieht das so aus:

Code: [Auswählen]

sub ParseResponse {
    my $param = shift // return;
    my $err   = shift // q{};
    my $data  = shift // q{};
Und mittelfristig gibt es dann noch ein "carp" dazu, damit auch klarer wird, warum es nicht klappt, wenn man das einen zwingende Argument nicht übergibt...

Kurz: Es gibt insgesamt ein Haufen Punkte, über die man sich mal einigen sollte, wie das mittelfristig aussehen soll.

[martinp876]

@KölnSolar
Ich bin mir nicht gazz sicher, as du aussagen willst, aber: ich habe die Dokumente nicht durchgearbeitet. Werde ich ohl einmal machen, danke dafür.
Am Ende bewerte ich hier (aus meiner Nabel sicht - und diskutierbar!!!) was aktuell Sache ist, was ich so sehe.
Was ich nicht erkennen kann auf den Ersten Blick ist eine übergreifende Philosiphie, eine Zielgruppe. Ich (also ICH!) bin der Meinung, das einiges doch "automatisch" oder "per default" eingestellt werden sollte (user geeignet) und für experten (nerds) modifiziert werden kann - nicht umgekehrt. Also erst einmal alles offen lassen, es dann "nutzbar" zu machen kann man mit Einstellungen erreichen.
Beides möglich, klar.
Ich mache das an Details fest, anders befürchte ich, kann ich es nicht rüber bringen.

@Beta-User

ERGO: Die Entscheidung, was wann warum wie oft triggern soll gehört in User-Hand! Der Modulautor sollte das nicht zu sehr einschränken.

das sehe ich genauso - sorry, wenn es nicht so rüber gekommen ist.

Code: [Auswählen]

attr DEVICE event-on-change-reading measured-temp:0.3,.*

da hast du recht. gehe ich weiter unten darauf ein.

Der User muss (!) sich Gedanken machen, wie sein System funktionieren soll, und man kann und sollte ihm Vorschläge machen.

hm. klar muss er das. Aber das System kann doch in einem sinnvollen Default hochkommen. Dann merkt der User was es macht und passt es an. Oder es kommt im Default hoch und er ändert es gleich. Das System kommt immer in einem Default hoch - nur eben in welchen. Ich befürworte ein "geschmeidiges" welches automatisch ein "gut funktionierenes" system abbildet. Selbstverständlich!!! kann man es nach allen Seiten personalisieren.

[quoteI]m Übrigen spreche ich nicht immer nur von CUL_HM! Meine Welt ist etwas "bunter", [/quote]
Ist mir klar

Aha. Der Modulautor meint, man braucht zwingend drei Argumente für diese Funktion. Denkste... Es geht so weiter:

ich habe einen Command-parser geschrieben für get/set und Attr - werde ich später einmal zeigen. Ich finde ihn cool (oh wunder, habe ihn selbst gemacht ).

Aber beim Code-review bin ich eigentlich nicht.
---------------------------------
Mein Thema heute ist eigentlich Event-on-change-reading. Und, danke Beta-User. In meiner unendlichen Ignoranz habe ich den optionalen Threshold verdrängt. Das ist wirklich gut - und der Rückbau meines Systems hat mir einen halben Tag gekostet ( wegen der langsamen Datenbank).

Ich denke hier fehlt noch deutlich mehr info für den User.  Umrissen muss man erklären, wie es funktioniert und welche Auswirkungen es hat. Warum sollte der User events sparen, wenn er nicht weiss, warum?

Erklärung zum Ablauf
S

ystem bahaviour readings, events, notifications:
readings are set by the module based on aktivities or sensors which are processed by the entity.
Typically a reading causes an event, which can be processed by other entites in the system.
The event will be passed to entites in the system that enroled for notification from the sourcing entity.
The notified entity filters the readings and values it is interessted in and executes the programmed action.

User can reduce system load by supressing events from readings.
By default an event is generated upon update of a reading. I.e. if the reading is updated with the same value an event is triggered.
By "event-on-change-reading" user can restrict events to "trigger only if the value changed".
For even more reduction the user can programm a threshold for numerical readings. I.e. only if the value of a reading has changed for more than "xx" then trigger an event.
This is especially to be considered for sensor readings. Very often a sensor reads a value (thermometer in 0.1°C) with a high resolution. A jitter is the result and the reading might change with every repetition. Typically it is sufficient to only trigger for changes higher than 0.2 or even 0.5 degree.

Backside or supressing events:
as described above: if no event is issued no other entity is notified about the change. This also includes web-frontend as well as logging entites. Explicitely:you will be notified about changes of a reading in the browser (red marking of the changed value, update of value) only, if an event is triggered.
Secondly also the data to be logged to the history-database is captured if an event is triggered. Remind that this feature can be used to restrict data in the history database. Subsequently the less data will improve speed of evaluating this data - e.g. for graphics

Note that default for readings is "event-on-update".
As a matter of fact we have
event-on-update
event-on-change
event-on-threshold (included in attr event-on-change-reading)

system recommendation is to setup
attr device event-on-change-reading thrReading1:thr1,thrReading2:thr2,thrReading3:thr3,changedReading
attr device event-on-update-reading updtReading1,updtReading2

it is recommended that event-on-change-reading ends with ".*"
also "on-update" should be used with care - it typically is not necessary

Der text ist so auf die Schnelle - geht sicher besser. Im Commandref würde ich leicht andres schreiben und im Wiki ausführlicher.
Klar zu stellen ist, wie threshold GENAU funktioniert. Was passiert mit
25,3°C
temp:25,3
noTempmeasured
 

--------------------
ansonsten bin ich mit den Performance verbesserungen schon einmal selbst zufrieden bis hier her. Da es aber etas gedauert hat frage ich mich eben: wie kann man diesen Weg dem "user" ersparen. das ist das Ziel des Threats