NOTIFYDEV - wie weit optimieren?

[Damian]

Das Hauptproblem liegt hauptsächlich darin, dass der Modulentwickler oft alle seine Readings mit Event setzt. Er kann ja argumentieren, wenn der User sie nicht haben willst, dann kann er sie mit event-on-update-readings eliminieren. Wenn er aber Readings ohne Event schreibt, dann kann der User das Event nicht nachträglich aktivieren.

Der "Normal"-User wiederum achtet zunächst bei einer Definition eines neuen Devices nicht darauf, welche Events dazu kommen und vor allem in welcher Häufigkeit.

Selbst mir geht es so, dass ich alle paar Monate erschreckend feststelle, was da an Events dazugekommen ist und fange wieder an auszumisten - das dürften aber die wenigsten tun.

Besser für die Gesamtperformance wäre, wenn die Events eines neuen Devices zunächst ausbleiben würden (default z.B.: event-on-update-readings state) und der User sie nach Bedarf bewusst erst einschalten müsste, wenn er sie bräuchte - das wäre aber für den User weniger komfortabel. Und solange man immer leistungsfähigere Hardware kaufen kann ...

[frank]

Das Hauptproblem liegt hauptsächlich darin, dass der Modulentwickler oft alle seine Readings mit Event setzt. Er kann ja argumentieren, wenn der User sie nicht haben willst, dann kann er sie mit event-on-update-readings eliminieren. Wenn er aber Readings ohne Event schreibt, dann kann der User das Event nicht nachträglich aktivieren.

doch, das kann man dank rudi mittlerweile "aushebeln".
sehr tricky und gut "versteckt", funktioniert aber hervorragend. 
https://forum.fhem.de/index.php/topic,112825.msg1184583.html#msg1184583

[Beta-User]

@frank: Ich glaube nicht, dass es für die überwiegende Zahl der User hilfreich ist, wenn man das "bewirbt" (oder gar unter Verweis auf diese Option die Maintainer motivieren will, weniger Events zu zeigen)...

Es ist und bleibt m.E. so, dass es sinnvoll ist, den Usern den sinnvollen Einsatz _aller_ eocr-Optionen zu erläutern und ggf. die (vorhandenen) Hilfsmittel so darzustellen, dass man sie relativ einfach anwenden kann.

[alanblack]

Die Optimierungsvorschläge sollte man beherzingen, bevor man Probleme bekommt und nicht erst, wenn es zu spät ist. Und wie optimiert man wohl: Indem man Rechenzeit spart

Das möchte ich so nicht stehen lassen. Wenn ich meinem FHEM-Computer soviel Rechenzeit abverlange, dass der Kühlkörper anfängt zu glühen und Leuchten erst nach sechs statt nach 0,5 Sekunden angehen, dann nehme ich dieses Mehr gerne in Kauf, wenn ich dafür nur noch die Hälfte an Strom- und Heizkosten hätte. Ist für mich eine Optimierung des Systems hin zur Kostenreduktion. Eine Optimierung verlangt mMn immer (mindestens) ein Optimierungsziel.

Allerdings hätte ich in meiner eigenen Installation mit der pauschalen (nachträglichen) ".*"-Lösung gleich zwei Probleme verursacht:
[...]- zum Teil würden manche Eventhandler damit (manchmal!) nicht funktionieren, z.B. (mehr oder weniger) alles, was mit (mehrfach-) Tastern zu tun hat.

So nicht ganz vollständig: setze ich bei diesen Devices noch ein eour (event-on-update-reading)z.B. ein state, funktionieren diese 1a.

Mir ist das klar, aber das würde trotzdem bedeuten, dass praktisch alle Event-Handler nicht mehr (richtig) funktionieren, die Taster-Devices auswerten.

Wie gerade geschrieben: es gibt auch event-on-update-reading.

@frank: Ich glaube nicht, dass es für die überwiegende Zahl der User hilfreich ist, wenn man das "bewirbt" (oder gar unter Verweis auf diese Option die Maintainer motivieren will, weniger Events zu zeigen)...

Jepp!

Es ist und bleibt m.E. so, dass es sinnvoll ist, den Usern den sinnvollen Einsatz _aller_ eocr-Optionen zu erläutern und ggf. die (vorhandenen) Hilfsmittel so darzustellen, dass man sie relativ einfach anwenden kann.

Ja, aller eocr (event-on-change-reading) aber auch aller eour (event-on-update-reading) Optionen.

Grüße

Nachtrag (leicht offtopic):

Code Auswählen Erweitern


attr .*:FILTER=event-on-change-reading!~.+ event-on-change-reading .*

[...]
(Ggf. auftretende Log-Meldungen, wg. nicht unterstütztem eocr sind dabei allerdings zu ignorieren )

Beim Aufruf über die Commandozeile gibt es keine Einträge im Log. 

[Benni]

Das möchte ich so nicht stehen lassen. Wenn ich meinem FHEM-Computer soviel Rechenzeit abverlange, dass der Kühlkörper anfängt zu glühen und Leuchten erst nach sechs statt nach 0,5 Sekunden angehen, dann nehme ich dieses Mehr gerne in Kauf, wenn ich dafür nur noch die Hälfte an Strom- und Heizkosten hätte. Ist für mich eine Optimierung des Systems hin zur Kostenreduktion. Eine Optimierung verlangt mMn immer (mindestens) ein Optimierungsziel.

Jetzt wird's aber OT! 
Optimierungsziel dieses Threads war bisher doch die Eventlast, bzw. die Verarbeitungslast der auftretenden Events zu reduzieren.
Das hat per se erst mal nix mit Strom und Heizkosten zu tun.

gb#

[Beta-User]

Wie gerade geschrieben: es gibt auch event-on-update-reading.
[...]
Ja, aller eocr (event-on-change-reading) aber auch aller eour (event-on-update-reading) Optionen.

Unvollständig.

Mit "_aller_ eocr-Optionen" in

Es ist und bleibt m.E. so, dass es sinnvoll ist, den Usern den sinnvollen Einsatz _aller_ eocr-Optionen zu erläutern und ggf. die (vorhandenen) Hilfsmittel so darzustellen, dass man sie relativ einfach anwenden kann.

waren noch weitere Attribute gemeint, die in den Gesamtkontext auch noch reingehören:
event-min-interval, timestamp-on-change-reading und event-aggregator.

U.A. auch deswegen ist der pauschale Hinweis auf das Setzen nur eines Attributs aus der Familie zwar wichtig, aber eben nicht vollständig.

[alanblack]

Jetzt wird's aber OT! 
Optimierungsziel dieses Threads war bisher doch die Eventlast, bzw. die Verarbeitungslast der auftretenden Events zu reduzieren.
Das hat per se erst mal nix mit Strom und Heizkosten zu tun.

Hey, das ist doch ein normaler Verlauf in einem Forum:
Optimierung von NOTIFYDEV (notifies/watchdogs/...) => Vermeidung von Events (eocr/eour/emi/...) => Optimierung allgemein => ... => wann wird der nicht optimale Einsatz von FHEM besteuert? [IronieOff]

[ ] Meine Beiträge sind immer on-topic, vollständig und fehlerfrei

Ich weiß nicht, aber wenn hier nicht noch Hinweise zu NOTIFYDEV (!) kommen, sollte ich den Thread schließen, oder?

Grüße