Warnungen von warnung.bund.de in FHEM einbinden

[KölnSolar]

Danke.
Aber so ganz logisch ist das nicht. Für UWZ mag das so funktionieren. Aber hier nicht immer.

Ich versuchs mal zu strukturieren, was wir brauchen.
1. event bei warnings_count. Will man haben bei Änderung. Aber was, wenn Anz. unverändert bei veränderten warnings ?
2. events auf Inhalte warn_x_ ? Macht wenig Sinn. Inhalte gleicher Warnungen ändern sich offensichtlich nie. Events, nur weil sich die Reihenfolge verschoben hat, für alle warn_x_ ?

Zu 1. könnte man sich ein new_warnings_count als generellen Trigger zusätzlich vorstellen. Ebenso noch ein warning_in_area(polygon, nicht distance)
Zu 2. könnt ich mir maximal vorstellen, dass es so etwas wie last_new_warning mit der Nummer gibt. Dann hat der User einen Trigger bei jeder neuen Meldung. Was er sich dann in eine Nachricht schreibt, kann er sich dann selber je nach Gusto aus den Readings holen.

Ich versteh die event_Flut in manchen Modulen(z.B. echo) nicht. Mir fehlen da die Vorstellungen für use cases. Meine Meinung ist: events so wenig wie möglich, so viel wie nötig.

[CoolTux]

Prima. 
So ist es aber nicht.
x alte Warnungen und y neue Warnungen:
bei y>= x werden die Readings für Warnung 0-x nur überschrieben(wenn ein Parameter nicht vorhanden ist wird das alte Reading gar nicht angefasst). y > x wird neu angelegt
bei y < x  werden die Readings 0-y nur überschrieben, für x > y gelöscht.

Eigentlich müsste es so sein wie Du schreibst: alles löschen u. neu anlegen.

Ich schaue mir das ganze Thema die Tage noch mal in Ruhe an.

[KölnSolar]

Dann nimm bitte meine Gedanken aus dem vorherigen Post mit. Im UWZ  würden doch evtl. events auf ...uwzLevel ausreichen. Sonst sehe ich da(als UWZ-Unwissender) keine sinnvollen events. Unnötige events fressen nur performance.

[frank]

Ich versteh die event_Flut in manchen Modulen(z.B. echo) nicht. Mir fehlen da die Vorstellungen für use cases. Meine Meinung ist: events so wenig wie möglich, so viel wie nötig.

genau.
deswegen möchte ich auch, dass das grundsätzliche verhalten aller readings in jedem modul identisch ist.
ohne event attribute gibt es bei jedem update ein event.
und mit hilfe der event attribute kann ich alle events abschalten.

bei einer neuen definition eines devices könnte das modul durch automatisches setzen entsprechender event attribute durchaus ein gezügeltes verhalten vorgeben.

[KölnSolar]

ich hab jetzt mal umgesetzt, was ich mir so grob vorstelle.

- Jede angezeigte Warnung "Warn_x" erhält ein zusätzliches Reading "Warn_x_Distance" (geringste Entfernung Standort-Polygon)
- zusätzliches reading WarnCountInArea  (wenn longitude/latitude IN einem Polygon liegt, wird der counter hochgezählt;Warn_x_Distance=0)
- Neues Reading NewWarnings ==> zeigt die Anzahl der neuen Warnungen(kann durch Umsortierung verfälscht werden...) zum Zeitpunkt des updates an
- den state modifiziert, um per state zwischen Meldungen für den Standort und der Umgebung(distance) einfach differenzieren zu können

einzige events:

Code Auswählen Erweitern

2019-07-11 14:21:13 MoWaS myMoWaS WarnCountInArea: 0
2019-07-11 14:21:13 MoWaS myMoWaS WarnCount: 1
2019-07-11 14:21:13 MoWaS myMoWaS NewWarnings: 0
2019-07-11 14:21:13 MoWaS myMoWaS Warnungen: 1 Lokal: 0

Meines Erachtens lassen sich die wesentlichen use cases abdecken:
1. NewWarnings > 0          # Es gab eine wie auch immer geartete Veränderung bei den Warnungen; das event dient als Auslöser für Aktionen(z.B. Hinweis-Meldungen)
2. NewWarnings = 0          # Es gab keine neuen Warnungen(vielleicht wurden aber Warnungen gelöscht=Entwarnungen !!!)
3. WarnCountInArea > 0    # Es gibt Warnungen für longitude/latitude; event kann mit event-on-change für Aktionen genutzt werden
4. WarnCountInArea = 0    # Es gibt keine Warnungen für longitude/latitude ; event kann mit event-on-change für Entwarnung genutzt werden
5. WarnCount > 0              # Es gibt keine Warnungen für longitude/latitude + distance; event kann mit event-on-change für Aktionen genutzt werden
6. WarnCount = 0              # Es gibt keine Warnungen für longitude/latitude + distance; event kann mit event-on-change als allgemeine Entwarnung genutzt werden

(Fast reichen die events 1.-2.; Individuelle Reaktionen macht man dann von den weiteren Readings-Inhalten abhängig.
Was dann aber fehlt ist ein event für Entwarnung. Dafür lässt sich 4. und/oder 6. (mit event-on-change) nutzen.
Bei 3. u. 5. kann es vorkommen, dass zufällig Anz.NeueWarnungen=Anz.AlteWarnungen ==> event-on-change versagt !!!
==> sollte nicht genutzt werden)

Und weil es irgendwie keinen Sinn(oder will das jemand über die Zeit loggen ?) macht, dass jeder User extra die event-on-Attribute für das gewünschte Verhalten definieren muss, habe ich umgesetzt, dass nur ein jeweiliges event abgesetzt wird, sofern sich eines dieser 3 Readings ändert(also implizites event-on-change). Nebeneffekt ist, dass die timestamps dem Zeitpunkt der Veränderung entsprechen.


Korrekturen:
- nur ein "Warn_x_..." Readings-Block bei mehrfach Areas und Polygonen; Ermittlung der geringsten Entfernung auch bei Mehrfachpolygonen
- angepasste Löschfunktion für "Alt-Readings", damit keine Vermischung von alt und neu stattfindet.

Wie immer, konnte ich natürlich nur begrenzt testen. Deshalb freue ich mich auf jeden detaillierten regionalen Test und hoffe, dass auch alles funktioniert wie gewünscht.
Sicherlich auch interessant, was Ihr von dem event-Konzept haltet. Je nach Anzahl u. Güte der Reaktionen würde ich da auch einen neuen Thread im Developer-Subforum eröffnen.

Grüße Markus

Edit: error correction Area
Edit2: Attachement removed

[CoolTux]

Prima. 
So ist es aber nicht.
x alte Warnungen und y neue Warnungen:
bei y>= x werden die Readings für Warnung 0-x nur überschrieben(wenn ein Parameter nicht vorhanden ist wird das alte Reading gar nicht angefasst). y > x wird neu angelegt
bei y < x  werden die Readings 0-y nur überschrieben, für x > y gelöscht.

Eigentlich müsste es so sein wie Du schreibst: alles löschen u. neu anlegen.

Ich habe eben noch einmal geschaut. Gut möglich das ich was übersehe aber das was ich sehe bedeutet für mich das sämtliche alten Warn Readings gelöscht werden und dann entsprechend neu geschrieben werden.
Hab eich eine Stelle übersehen?


Grüße

[KölnSolar]

Hast Du. 
aktuelles UWZ:

Code Auswählen Erweitern

            my $newState;
            Log $hash, 4, "Delete old Readings";
            for my $Counter ( $values{WarnCount} .. 9 ) {
                CommandDeleteReading( undef,
                    "$hash->{NAME} Warn_${Counter}_.*" );
            }

Die Schleife beginnt also erst mit dem Wert von WarnCount. Es wird also erst ab dort für "nicht vorhandene" Warnungen komplett gelöscht.
Davor wurden die "neuen Warnungen" geschrieben.

Code Auswählen Erweitern

       while ( my ( $rName, $rValue ) = each(%values) ) {
            readingsBulkUpdate( $hash, $rName, $rValue );
            Log $hash, 5, "reading:$rName value:$rValue";
        }


Einzelne evtl. nicht mehr vorhandene Readings werden nicht gelöscht, sondern bleiben "unangetastet".

Ich hab das jetzt so gelöst, dass ich in der update-Schleife auf die Veränderung der EventID abfrage. Die ist bei mir immer der erste Wert einer Warnung. Ist sie unterschiedlich, lösche ich erst einmal alle Readings der "alten" Warnung.

Code Auswählen Erweitern

       if ($rName =~ m/_EventID/) {
          if (ReadingsVal($name, $rName, undef) ne $rValue) {
     $new_warnings_count++;  # new readings counter
                     MoWaS_Log $hash, 4, "Delete old Readings";
                     CommandDeleteReading(undef, "$hash->{NAME} ". substr($rName,0,6)."_.*") # delete all readings of warning
                  }
               }
               readingsBulkUpdate( $hash, $rName, $rValue,0 );    # update of reading but no event


@all: gerade habe ich ein merkwürdiges Verhalten entdeckt: Es gibt eine dwd-Warnung, die angeblich 3,5 km entfernt ist. Dann eine weitere, die mir viel weniger Readings liefert. Und kaum schreibe ich und mach ein neues update, sind es 3 nun aber vollständige Wettermeldungen. Eine 47 km entfernt, eine 27 und die Dritte 21. Und schon sind sie wieder weg.  Erstes Analyseergebnis: Ich kann nicht einfach gegen die Website vergleichen, weil uns scheinbar noch die Area bei Meldungen fehlt. Habs oben korrigiert.
Die aktuelle Warnung ist für Solingen und 21 km entfernt. Bei distance sehen wir für Area also immer die nächstgelegene Area.

[frank]

genau, reinstes chaos. 

es fehlen ständig readings, art und menge völlig unterschiedlich.
newwarning erkennt keine veränderten inhalte.

ohne events macht es eh keinen spass:   
kein longpoll, keine userreadings, kein timestamp-on-change, ..................


kannst du bitte die alte version wieder bereit stellen?

[CoolTux]

Hast Du. 
aktuelles UWZ:

Code Auswählen Erweitern

            my $newState;
            Log $hash, 4, "Delete old Readings";
            for my $Counter ( $values{WarnCount} .. 9 ) {
                CommandDeleteReading( undef,
                    "$hash->{NAME} Warn_${Counter}_.*" );
            }

Die Schleife beginnt also erst mit dem Wert von WarnCount. Es wird also erst ab dort für "nicht vorhandene" Warnungen komplett gelöscht.
Davor wurden die "neuen Warnungen" geschrieben.

Code Auswählen Erweitern

       while ( my ( $rName, $rValue ) = each(%values) ) {
            readingsBulkUpdate( $hash, $rName, $rValue );
            Log $hash, 5, "reading:$rName value:$rValue";
        }


Einzelne evtl. nicht mehr vorhandene Readings werden nicht gelöscht, sondern bleiben "unangetastet".

Ich hab das jetzt so gelöst, dass ich in der update-Schleife auf die Veränderung der EventID abfrage. Die ist bei mir immer der erste Wert einer Warnung. Ist sie unterschiedlich, lösche ich erst einmal alle Readings der "alten" Warnung.

Code Auswählen Erweitern

       if ($rName =~ m/_EventID/) {
          if (ReadingsVal($name, $rName, undef) ne $rValue) {
     $new_warnings_count++;  # new readings counter
                     MoWaS_Log $hash, 4, "Delete old Readings";
                     CommandDeleteReading(undef, "$hash->{NAME} ". substr($rName,0,6)."_.*") # delete all readings of warning
                  }
               }
               readingsBulkUpdate( $hash, $rName, $rValue,0 );    # update of reading but no event


Das ist das Problem wenn man den Code nicht selber schreibt. Vielen Dank für Deine Aufklärung. Ich werde mir das noch einmal genau anschauen und dann mal sehen ob man es besser machen muss oder es anders aufbauen kann.

[CoolTux]

Zum Thema Events minimieren. Das Problem ist das die User mit Events arbeiten. Einige Logge in Datenbanken, warum auch immer. Andere machen userreadings und so weiter. Wir können als Entwickler den User nicht bevormunden. Und ja ich wäre auch für weniger Events. Bei mir hier gibt es sehr wenige Events. Aber das bestimme halt ich als User und so sollte es auch sein.

[KölnSolar]

genau, reinstes chaos. 

ich vermute, dass das nur an der Datenbereitstellung vom dwd liegt und sich die Meldungen permanent ändern. Ist dann eine negative Auswirkung von distance. Zumindest ist alles OK, wenn man set .... update  mehrfach in kurzen Abständen manuell ausführt. Ich versuch das mal weiter zu verifizieren, wenn mal wieder Wetterwarnungen im Sekundentakt kommen....

newwarning erkennt keine veränderten inhalte

Das kann ich mir kaum vorstellen, da es ja keine inhaltlichen Veränderungen gibt. Beispiel ?

kein longpoll

na doch, aber eben nur für die 3 readings, sofern sie sich verändert haben. longpoll hilft auch nicht, wenn neue Readings angelegt wurden(im hiesigen Beispiel, wenn neue Warnungen hinzu gekommen sind). Dann muss sowieso ein refresh des Browsers gemacht werden.

keine userreadings

sollten problemlos mit einem dieser 3 readings als trigger funktionieren.

kein timestamp-on-change

das ist doch auch wieder nur ein Attribut, das der User explizit setzen muss. Ich mach das modulintern, so dass sich der User gar keine Gedanken machen muss.

@Cooltux,frank: Das Problem ist doch bei dieser Art von devices, dass alle warn_X-Readings zig unnötige events auslösen würden, obwohl sich nichts oder alle zugehörigen Readings geändert haben. Jedes unnötige(keine Änderung,redundant) event muss aber durch alle notifys und X_Notify-Funktionen. Und klar, kann man alles auch User-spezifisch über die readingFnAttributes steuern. Ich bezweifle allerdings stark, dass ein "normaler" User auf diese Idee kommt, um die performance seines Systems zu beeinflussen. Zumal die Attribute dann noch komplizierte RegExp erfordern, mit denen die meisten User eh auf Kriegsfuß stehen.
Ich versuche es mal etwas anders deutlich zu machen: da sich die readings je Warnung inhaltlich nicht ändern, könnte man auch auf die Idee kommen, alle Informationen zu einer Warnung in genau einem Reading Warn_X auszugeben. 

Ich sehe immer noch keinen use case, der gegen die Reduzierung von events spricht. Ich sehe nur den Vorteil, dass die Performance jeden Users positiv beeinflusst wird. Da aber der Irrglaube unter den Usern vorherrscht "change eines readings gleich event", muss natürlich in der commandref deutlich auf das event-Verhalten hingewiesen werden.

-----------------------------------------------------------------------------------------------------------------
Aktuell gab es ein Polygon -1.0,-1.0 9.423,54.084 9.414,54.074 9.423,54.078 9.423,54.084
Das ergibt natürlich ein RIESIGES Polygon bis südlich des Äquators und westlich von Greenwich. 

[frank]

@Cooltux,frank: Das Problem ist doch bei dieser Art von devices, dass alle warn_X-Readings zig unnötige events auslösen würden, obwohl sich nichts oder alle zugehörigen Readings geändert haben. Jedes unnötige(keine Änderung,redundant) event muss aber durch alle notifys und X_Notify-Funktionen. Und klar, kann man alles auch User-spezifisch über die readingFnAttributes steuern. Ich bezweifle allerdings stark, dass ein "normaler" User auf diese Idee kommt, um die performance seines Systems zu beeinflussen. Zumal die Attribute dann noch komplizierte RegExp erfordern, mit denen die meisten User eh auf Kriegsfuß stehen.

ein einziges attribut ohne regex erreicht genau das selbe, was du gerade unnötig erzwingst: 
3 readings erzeugen events bei änderung und der rest ist tot.

Code Auswählen Erweitern

attr mowas event-on-change-reading NewWarnings,WarnCount,WarnCountInArea

das könntest du sicherlich beim anlegen eines neuen devices automatisch setzen und alles ist gut. 

Ich sehe immer noch keinen use case, der gegen die Reduzierung von events spricht. Ich sehe nur den Vorteil, dass die Performance jeden Users positiv beeinflusst wird.

dann musst du doch aber nicht auch allen anderen deren kreativität im keim ersticken. dieser satz regt mich gerade am meisten auf, sorry.

vor einem halben jahr sollten die hilferufe (critical battery) meiner homematic devices aus fhem verbannt werden, weil sie nicht zum mainstream (low battery) passen. nun willst du das noch toppen, indem du dutzende readings "kastrierst". die nächsten schritte in diese öde richtung stehen scheinbar auch schon auf der todo liste:

Ich versuche es mal etwas anders deutlich zu machen: da sich die readings je Warnung inhaltlich nicht ändern, könnte man auch auf die Idee kommen, alle Informationen zu einer Warnung in genau einem Reading Warn_X auszugeben.

da hätte ich mir die gestrige arbeit zum erstellen einer rss-seite mit den für mich relevanten daten in einem mir genehmen layout für den tv ja sparen können.

Sicherlich auch interessant, was Ihr von dem event-Konzept haltet. Je nach Anzahl u. Güte der Reaktionen würde ich da auch einen neuen Thread im Developer-Subforum eröffnen.

ist dort dann auch schon eine abstimmung geplant, um im sommerloch still und heimlich eine neue regel durch zu winken, dass alle ähnlichen module diese event-beschneidung erfahren?


ein event-basiertes system mit event-freien modulen macht für mich wenig sinn, oder?

[KölnSolar]

Guten Morgen Frank,

da hätte ich mir die gestrige arbeit zum erstellen einer rss-seite mit den für mich relevanten daten in einem mir genehmen layout für den tv ja sparen können.

Und das ist genau der Grund, dass die Daten in mehreren readings geliefert werden. Damit der User sich die Informationen individuell und einfach für seinen Zweck selektieren kann. Und das bleibt auch so. War nur der Versuch zu verdeutlichen, dass es sich bei einer Warnung nur um genau ein Ereignis handelt, welches aber 15(habs gerade gezählt) Readings erzeugt.

dann musst du doch aber nicht auch allen anderen deren kreativität im keim ersticken. dieser satz regt mich gerade am meisten auf, sorry.

Mir fehlt nach wie vor das Beispiel, welche Kreativität im Keim erstickt wird. Für welchen use case braucht man für ein und dasselbe Ereignis 15 events ?

ist dort dann auch schon eine abstimmung geplant, um im sommerloch still und heimlich eine neue regel durch zu winken, dass alle ähnlichen module diese event-beschneidung erfahren?

Das siehst Du falsch. Wir reden hier nicht über eine neue Regel. Letztendlich ist das seit Urzeiten schon so. DevelopmentModuleIntro:

Zum Setzen von Readings .... Dabei kann man auch angeben, ob dabei ein Event ausgelöst werden soll oder nicht. Events erzeugen, je nach Hardwareperformance, spürbare Last auf dem System (siehe NotifyFn), das Ändern von Readings ohne dass dabei Events erzeugt werden jedoch nicht.

Und hier findest Du die Doku zu den FHEM-readings-Funktionen, wo ausdrücklich parametergesteuert die Möglichkeit geschaffen wurde, events bei einem reading zu erzeugen oder nicht, oder ein update eines readings nur dann, wenn sich Inhalte geändert haben.
Mir geht es nur darum andere Modulautoren für das Thema Performanceverlust durch unnötige events zu sensibilisieren. Mir persönlich ist wichtiger, dass auch z.B. unerfahrene PiZero-User FHEM ohne detaillierteres Wissen von FHEM performant betreiben können, als dass jemand den short_text.... einer Warnung einfach loggen kann(mit detailliertem Wissen macht der Ausnahme-User sich z.B. einfach userReadings und kann loggen, wenn es ihm Spaß macht).

ein event-basiertes system mit event-freien modulen macht für mich wenig sinn, oder?

100% Zustimmung. Aber die events sind doch da. Du regst Dich darüber auf, dass es keine quasi redundanten events für Warn_X_Instruction, Warn_X_LongText, Warn_X_ShortText..... gibt.

das könntest du sicherlich beim anlegen eines neuen devices automatisch setzen und alles ist gut.

Da kann man drüber nachdenken. Finde ich aber persönlich noch mehr User-Bevormundung, wenn ich ein Attribut automatisch anlege. Und ich weiß ehrlich gesagt nicht, ob das performancetechnisch das selbe ist.

Letzteres macht mir klar, dass wir 2 Dinge durcheinanderschmeißen, die sich auch programmtechnisch unterscheiden:

1.

Die Funktion readingsBulkUpdateIfChanged() führt ein Update eines einzelnen Readings für die Definition $hash durch, sofern sich der neue Wert $value gegenüber dem vorherigen Wert verändert.

Das ist, zumindest aus Anwendersicht, nichts anderes als event-on-change. Es vermeidet events, wenn sich gar nichts geändert hat.
Im hiesigen Fall: Die "Ereignisermittlung" erfolgt zyklisch. Der User kann die Periode selber bestimmen. Hat sich innerhalb der Periode inhaltlich nichts geändert, gibt es auch kein update und auch kein event. Dadurch kann der User die Periode beliebig klein definieren, ohne dass sein System in die Knie geht.
2.
Ein Ereignis (Warnungsänderung) befüllt anwenderfreundlich eine Vielzahl von readings Warn_x_.....
Da ist es doch sinnfrei für dieses eine Ereignis das System mit events Faktor 15 zu belasten.

Zu 1.: Wenn es sich um Daten handelt, die man graphisch in einem Plot darstellen könnte, macht es Sinn, den User entscheiden zu lassen, wie seine Punktedichte in der Grafik ist. Im Logging von unveränderten Textinformationen sehe ich dagegen keinen Sinn. Vielleicht fehlt mir ja nur die Vorstellungskraft, was andere User mit unveränderten Textnachrichten so interessantes machen. Ich bekomme aber auch nicht den konkreten use case.  Vorteil ist ganz klar die performance des Moduls, ohne dass der User etwas besonderes tun muss. Dadurch lässt sich der Zyklus userfreundlich und individuell beliebig klein definieren.

Zu 2.: Vielleicht ist mein aktuell realisierter Ansatz zu sportlich, vernebelt den Blick auf das Ziel und ist nicht leicht nachzuvollziehen.
Ist es ein Kompromiss und dadurch transparenter, wenn es genau ein event je Ereignis(Warnung) gibt ? Ich könnte die eindeutige EventID events erzeugen lassen. Konkret: Readings Warn_X_EventID liefern events, nicht aber Warn_X_Instruction, Warn_X_LongText, Warn_X_ShortText.....

Und nochmal ein Zahlenbeispiel, zur Rechtfertigung meines Ansatzes:
Ein user definiert eine große distance, weil ihn nicht nur die lokalen Warnungen interessieren. Dadurch bekommt er regelmäßig 10 Warnungen. Durch den Faktor 15 würden je Abfragezyklus 150 events ohne meine event-Reduzierung entstehen. Und das, obwohl sich gar nichts verändert hat. Readings-updates würden lediglich belegen, dass das Modul läuft.
Mit meinem "Kompromiss-Vorschlag" gibt es kein einziges event, wenn es bei den 10 Warnungen geblieben ist. Ändern sich die Warnungen(eher Ausnahme als Regel) dann doch einmal, gibt es 1-10 events, auf die der User konkret auf EINE Warnung reagieren kann.

@all

Zitat
genau, reinstes chaos. 

ich vermute, dass das nur an der Datenbereitstellung vom dwd liegt und sich die Meldungen permanent ändern. Ist dann eine negative Auswirkung von distance. Zumindest ist alles OK, wenn man set .... update  mehrfach in kurzen Abständen manuell ausführt. Ich versuch das mal weiter zu verifizieren, wenn mal wieder Wetterwarnungen im Sekundentakt kommen....

Ich vermute mittlerweile, dass meine "Löschfunktion" die Probleme verursacht. Da ich zwischenzeitlich bei den dwd-Meldungen auch die Farbe der Warnmeldungen extrahieren und in einem Reading Warn_X_Color ablegen konnte, stelle ich später mal eine neue Version ohne "Löschfunktion", mit Color-Readings und dem event für ..EventID ein.

[CoolTux]

Da das Thema Event Vermeidung und welche werden tatsächlich gebraucht ein großes Für und Wieder hat schlage ich folgendes vor. Aus eigener Erfahrung.
Markus gestaltet sein Modul wie er es in seinen Augen für richtig hält in Bezug auf Events und wir warten auf die Reaktionen der User. Ach Markus! Frank ist übrigens ein User. Aber warten wir einfach mal ab was noch kommt. Wie gesagt, eigene Erfahrung. Ich prophezeihe Dir da einen User Ansturm wieso weshalb da nichts passiert. Warum sehe ich nicht die Änderung des Warn Textes in meinem TabletUI, wieso kann ich Warn Text nicht loggen und so weiter.
Wichtig finde ich aber immer das man nicht am User vorbei Entwickeln sollte. Wenn also die Nachfrage größer wird später solltest Du bitte nicht Stur sein.


Grüße

[KölnSolar]

Ach Markus! Frank ist übrigens ein User.

Weiß ich doch. Und ein Verdienter um FHEM. Und ein Nutzer meines einzigen offiziellen Moduls, wo ich meine Philosophie bei Erstveröffentlichung umgesetzt hatte. Aber ohne Diskussion/offene Kommunikation. Ohne, dass frank es bisher gemerkt hat. Auch hat kein anderer User sich bisher etwas anderes gewünscht. In dem Fall ist es so, dass z.B. das reading modelName eines TV sich weder tatsächlich ändert, noch in FHEM, noch ein event erzeugt.  Wozu auch ?  Bei mir ist der timestamp vom 3. Februar. 
Das echo-device weist mich, ich glaub minütlich, per event dagegen darauf hin, dass meine Anschrift gleich geblieben ist, es immer noch ein Echo dot ist......

Wichtig finde ich aber immer das man nicht am User vorbei Entwickeln sollte. Wenn also die Nachfrage größer wird später solltest Du bitte nicht Stur sein.

Da stimme ich Dir zu. Kein System ohne User-Akzeptanz. Allerdings erwarte ich dann schon, dass man seinen individuellen und (aus meiner Sicht) vielleicht noch so abstrusen use case, der mit meiner Umsetzung nicht lösbar sei, wenigstens zur Nachvollziehbarkeit beschreibt. Bisher klang das alles eher nach: "War schon immer so.......". Ich brauche auch meine Motivation, um wider meiner Philosophie zu arbeiten. 
Ich hab mal mit FHEM auf der Fritte begonnen. Wenn ich mir da Antwortzeiten meines heutigen Systemumfangs vorstelle, .....Ich glaube ich hätte FHEM entnervt aufgegeben.

Es wäre auch schön, wenn sich noch weitere User/Entwickler melden würden. Und wenn wir "demokratisch" seitens des Moduls readingsupdate immer gleich event befürworten, dann würd ich in der development-Ecke dafür plädieren die Funktionen, die etwas anderes ermöglichen, abzuschaffen. Denn dann sollte erst gar keine technische Möglichkeit bestehen, gegen den Grundsatz zu arbeiten.
Umgekehrt (ich weiß jetzt nicht mehr wo, bin mir aber sicher, dass es irgendwo in wesentlichen Dokumenten falsch steht) müsste eben das Gegenteil klar herausgestellt werden: "In der Regel erzeugt ein readingsupdate ein event. Es kann aber aus performance- oder modulspezifischen Gründen Sinn machen, dass in manchen Modulen von dieser Regel abgewichen wird. Eine Abweichung wird in der jeweiligen offiziellen Doku(englische commandref) beschrieben."

Attached die Version mit den zuvor beschriebenen Anpassungen.

Edit: Aktuell treibt der dwd wieder sein Spiel. Permanent neue Warnungen im distance-Bereich. Ich hab zumindest mit der letzten Version nicht mehr beobachten können, dass Readings zu EINER Warnung nicht vollständig sind.
Köln gehört nun zum Weimarer Land.  Wie gestern beginnt das Polygon mit -1/-1. Ich versuch mal wenigstens negative Werte zu "ignorieren". Kommt gleich....


Edit: Attachement removed