SmartVISU + fronthem - Plotübergabe (gelöst)

[alkazaa]

So, mein Spieltrieb hat mir nun doch keine Ruhe gelassen und ich habe meine in diesem Beitrag vorgestellte Berechnung gewichteter Mittelwerte als SQL Query formuliert, sodass die Berechnung nun vom SQL-Server gemacht wird.

Beschrieben habe ich das Query in einem anderen Thread.

Für eine Nutzung in 99_fronthemUtils.pm kann man allerdings nicht mehr den fhem-Befehl "get ... Webchart" nutzen, sondern man braucht zusätzlich zum DbLog-device auch ein DbRep-device in fhem: das stellt den Befehl ' get ... sqlCmdBlocking' zur Verfügung, mit dem beliebige SQL-Queries ausgeführt werden können. (Anmerkung: auch das 'get ... Webchart' arbeitet wohl blockierend, im Gegensatz zu dem was ich in einem vorigen Beitrag sagte).

Um meine angehängte 99_fronthemUtils.pm zu testen, braucht man ein DbRep-device, das mit dem DbLog-device verknüpft ist. Wenn das DbLog device z.B. mylogdb heißt, wird dafür in 99_fronthemUtils ein DbRep erzeugt mit dem Befehl "defmod -silent mylogdbReport DbRep mylogdb".

Zum Aktivieren der Mittelung in SV im Modus 'avg' einen negativen Wert für 'count' angeben.

Gruß,
Franz

[Johann.S]

Hallo Franz,

chapeau!
Testsystem RaspBerry pi mit aktuellem fhem, fronthem aus dem Deloper, 99_fronthemUtils.pm aus dem Anhang und kein maxSendeSize!
Ich komme bei 1 Jahr auf 3.074 Datenpunkte also 8,42 Punkte pro Tag!
Die Geschwindigkeit ist sensationel.

Du und Wolfram habt mich vom avg überzeugt!
Ich habe mein Testsystem schon komplett umgebaut und kann bisher keine Fehler feststellen.
Daten zu vergleichen ist jetzt ein Kinderspiel.
IMHO kann man die Änderungen in den Master übernehmen!
Edit: mehrere Werte in einer Tabelle ärgert noch! Melde mich!

Gruß
Johann

[Johann.S]

Hallo Franz,

ich konnte nur einen "Fehler" finden!
Bei der Berechnung für 1 Jahr (1y) fehlen 9 Tage bei 2 Jahren (2y) 18 Tage usw.,
bei Eingabe der Tage funktioniert es (siehe Anhang)!
Ansonsten keine Auffälligkeiten noch mal chapeau!

Ich habe bis 4 Werte in einem Chart getestet und wie gesagt es funktioniert!
Allso ich denke der Master-Brunch und fhem ruft!

Was mir jetzt doch noch einfällt, ich habe tmax nicht getestet, wird nachgereicht!

Gruß
Johann

[alkazaa]

Hallo Johann,

Bei der Berechnung für 1 Jahr (1y) fehlen 9 Tage bei 2 Jahren (2y) 18 Tage usw.,

Wenn man eine Anzahl N von Daten im vollen Datensatz hat und diesen in count Intervalle zerlegt, kämen (bei einigermaßen gleich über der Zeit verteilten Messpunkten) N/count Daten in ein Teilintervall. Der gemittelte Werte für ein Teilintervall wird (habe ich irgendwo vorher erwähnt) dem Anfangszeitpunkt des Teilintervalls zugeordnet.

Das führt dazu, dass beim Plot N/count Daten zu fehlen scheinen. Wenn N doppelt so groß wird (2 Jahre vs. 1 Jahr), aber count gleich bleibt, scheinen doppelt so viele zu fehlen. Geht man von den konkreten Zahlen in Deinem letzten Beitrag aus, müsste Dein Originaldatensatz etwa (9 Tage) * (8,42 Punkte/Tag) * 3074 = ca. 233000 Messpunkte haben. Passt das in etwa?

Wenn man die Zuordnung des gemittelten Wertes nicht zum Zeitanfang des Intervalls macht, sondern zur Intervallmitte, würden am Anfang 9/2 Tage 'fehlen' und am Ende ebenfalls. Und bei 2 Jahren das Doppelte.

bei Eingabe der Tage funktioniert es (siehe Anhang)!

Ich verstehe nicht, was Du mit 'Eingabe der Tage' meinst.

Könntest Du mal die plot.period Definition aus SV posten? Und die Zahl der Originaldaten nennen?

Besten Gruß und Dank fürs Testen

Franz


Ach ja, noch etwas:
Wenn Daten gemittelt werden wie Temperatur, Luftfeuchte etc., die typischerweise tagesperiodisch sind, sollte immer über Tage oder Vielfache davon gemittelt werden, sonst erhält man irreführende Datendarstellungen. Die ursprüngliche averaging Methode (die auf einem Aufruf von 'get ... webchart...' in 99-fronthemUtils beruht) leistet aus gutem Grund genau das. Sie macht halt kein gewichtetes Mitteln, was bei zeitlich ungleich verteilten Werten auch wieder irreführend sein kann. Ein gewichtetes Mitteln mit stunden-, tage-, oder wochenweise begenzten Intervallen wäre am besten.
Nachdem ich mich nun interessehalber in diese ganze Thematik eingewühlt habe, sehe ich durchaus Möglichkeiten, das umzusetzen. Mal sehen...

[Johann.S]

Hallo Franz,

öhm, ich kanns nicht mehr nachstellen (schäm).
Jetzt funkt es so wie es soll!

Code Auswählen Erweitern

{{ plot.period('', 'ws.windspeed.plot', 'avg', '1y', '', '', '', '-1460', 'Windgeschwindigkeit', '#a00', '', ['avg 1y / -1460', 'Geschwindigkeit in km/h'], 'advanced', '', '', '', '', '', { rangeSelector: {selected: '2'}}) }}
{{ plot.period('', 'ws.windspeed.plot', 'avg', '365d', '', '', '', '-1460', 'Windgeschwindigkeit', '#a00', '', ['avg 365d / -1460', 'Geschwindigkeit in km/h'], 'advanced', '', '', '', '', '', { rangeSelector: {selected: '2'}}) }}

Der einzige Unterschied bei den Kurven war '1y' und '365d'!
Wie schon gesagt, jetzt sind beide gleich!
Das beim Mitteln mal ein Tag weniger rauskommt war mir schon klar aber tmin mit '1y' und '365d' müssen die gleichen Kurven haben, was sie ja auch tun!

tmax habe ich auch schon getestet und konnte nichts negatives entdecken!
Schön währe halt, wenn man auch ein fixes Datum einstellen könnte und/oder
zweimal die gleiche Kurve mit z.B. 1 Jahr Unterschied!
z.B.

Code Auswählen Erweitern

{{ plot.period('', ['ws.windspeed.plot','ws.windspeed.plot'], 'avg', ['1y','1y'], ['', '1y'], '', '', ['-365','-365'], 'Windgeschwindigkeit', '#a00', '', ['avg tmin 1y,1y/ tmax "",1y / -1460', 'Geschwindigkeit in km/h'], ['#a00', '#00a'], ['areaspline', 'spline']) }}

Wobei ich in der Doku gerade gelesen habe, das auch Zeitwerte möglich sind, halt nur im internen Format!
Werde ich mir auch noch ansehen!

Bezüglich der Datenanzahl sehe ich nur minimale Unterschiede, 2.841 und 2.842 Werte, was meines Erachtens vernachlässigbar ist!

Bin weiter am Testen und Berichten.
Gruß

Johann

[alkazaa]

Ich habe jetzt das zeit-gewichtete Mitteln auch für die Strategie implementiert, bei der die Gesamtzeit eines Plots nicht einfach in 'count' Intervalle zerteilt wird, sondern jeweils über Stunden (oder Tage, Wochen, ...)  gewichtet gemittelt wird.
Im angehängten Bild habe ich für einen 18 h Zeitraum die Ergebnisse des gewichteten Mittelns (18 Intervalle), eines gewichteten Mittelns über Stunden-Intervalle und eines nicht-gewichteten Mittelns über Stunden-Intervalle verglichen. Man beachtet, dass beim Stunden-Mitteln die Intervall-Grenzen immer auf vollen Stunden liegen (bei Tagen auf Tagen, usw.)


Im Moment habe ich nur die stundenweise gewichtete Mittelung ins 99_fronthemUtils eingebaut. Die anderen Zeitintervalle einzubauen ist jetzt nur noch Schreibarbeit.

Wichtig für die Nutzung: wie wählt man im SV-code die Mittelungsmethode aus?
Mein Vorschlag:

   
• Beim Modus 'raw' wird unabhängig vom Parameter 'count' alles dargestellt.
• Beim Modus 'avg' bestimmt der 1. Term der 'tmin' Angabe das Mittelungs-Intervall, z.B. '0h' für Stunden.
  Mit einem Parameter 'count' = 1 wird dabei die alte, ungewichtete Mittelung benutzt.
• Bei 'avg' mit 'count' > 1 wird gewichtet gemittelt, die Intervalllänge wird über den 1. tmin-Term festgelegt
• Bei 'avg' mit 'count' < 0 wird gewichtet gemittelt, wobei die Gesamtlänge in |count| Intervalle geteilt wird

Wäre das so akzeptabel? Andere Vorschläge?
Und noch eine Frage an Wolfram: wie gibt man in SV feste absolute Zeiten für tmin,tmax an? Eine Zahl wie z.B. 1629109298731 aus der Doku ist ja nicht sehr nutzerfreundlich?


-Franz

Im Vergleichsplot sind dargestellt:

   
• Rohdaten (raw) eines 18-h Intervalls und gewichtete Mittelung in 18 Teilen (w-avg 18)
• Rohdaten und stundenweise gewichtetes (w-avg h) und ungewichtetes Mittel (avg h)
• Die drei Mittelungen in einem Plot

Zwischen 5:00 und 6:00 erkennt man z.B. einen signifikanten Unterschied zwischen gewichtet und ungewichtet.

[wvhn]

Super Arbeit!

Das Vorgeben fester Zeitpunkte geht derzeit tatsächlich nur über die Zeitstempel. Das ist sicher nicht optimal, aber aus meiner Sicht zumutbar. Da die Zeiten ja fest in die Visu-Seiten eingetragen werden müssen, wird man sie sicherlich nicht so häufig ändern. Dann ist der Mehraufwand, auf einer der einschlägigen Websites ein Datum in einen Unix-Zeitstempel (in Millisekunden) umzurechnen, überschaubar.

Gruß
Wolfram

[Johann.S]

@Woflram: Bei einem Auswertungsfenster wird sehr wohl unterschiedliches Datum eingegeben.
                  Der Unterschied ist nur, dass jetzt jeder eine zusätzliche Routine erstellen muss!
                  Wenn man hingegen Date-Time Werte angibt wird das im Plot erledigt!
                  Für Laien (wie mich) wurde ich zweiteres bevorzugen

@Franz:    Ich sehe da Konstellationen die nicht mehr möglich sind z.B. 30 Stunden auf Stunden gemittelt.
                 Das ist zwar lösbar in dem ich auf Minuten oder Tage gehe aber ich denke da sollte man velleicht
                 die Parameter erweitern und z.B. die Mittelung in Klammer angeben '30h (h)' oder so.
                 Angepasst an deine Vorschlag würde es dann so aussehen:

• 
      Beim Modus 'raw' wird unabhängig vom Parameter 'count' alles dargestellt.
  
• 
      Beim Modus 'avg' bestimmt in der 'tmin' Angabe '(h)' das Mittelungs-Intervall für Stunden,
     'd' für Tage usw..
  
• 
      Bei 'avg' mit 'tmin' = '()' wird gewichtet gemittelt, wobei die Gesamtlänge in |count| Intervalle geteilt wird
  
• 
      Mit  'tmin' <> '()' oder '(h)' wird dabei die alte, ungewichtete Mittelung benutzt.
  

                 und 'count' wird belassen wie in der Docu beschrieben!
                 Hat meines Erachtens den Vorteil, die Mittelung kann irgendwo im 'tmin' stehen
                 und die Einstellung erfolgt nur über einen Paramter!

                 Ist nur so ein Gedanke!

Gruß
Johann

[alkazaa]

Moin Johann,

Ich sehe da Konstellationen die nicht mehr möglich sind z.B. 30 Stunden auf Stunden gemittelt.

Doch, das geht problemlos, siehe die drei Beispiele in meinem letzten Beitrag. Die relevanten Teile der plot.period Definitionen dazu sind:

Code Auswählen Erweitern

1. Plot: mode = ['raw','avg'],       tmin = '0h 18h', tmax = '', count = ['1','-18'],     label = ['raw','w-avg 18']
2. Plot: mode = ['raw','avg','avg'], tmin = '0h 18h', tmax = '', count = ['1','2','1'],   label = ['raw','w-avg h','avg h']
3. Plot: mode = ['avg','avg','avg'], tmin = '0h 18h', tmax = '', count = ['-18','2','1'], label = ['w-avg 18','w-avg h','avg h']

Des weiteren schriebst Du:

   
•     Beim Modus 'raw' wird unabhängig vom Parameter 'count' alles dargestellt.
•     Beim Modus 'avg' bestimmt in der 'tmin' Angabe '(h)' das Mittelungs-Intervall für Stunden,
     'd' für Tage usw..
•     Bei 'avg' mit 'tmin' = '()' wird gewichtet gemittelt, wobei die Gesamtlänge in |count| Intervalle geteilt wird
•     Mit  'tmin' <> '()' oder '(h)' wird dabei die alte, ungewichtete Mittelung benutzt.

aber wo bleibt da die gewichtete Mittelung mit Stunden? Ich muss ja das Mittelungsintervall irgendwo in tmin unterbringen, und irgendwo anders muss ich sagen, ob ich gewichtete oder ungewichtete Mittelung will.


Was ich noch einbauen möchte (teilweise schon habe):

   
• Zeitangaben der Form '1629109298731' (und zwar bei tmin auch als z.B. '0h 1629109298731'  für Mittelungen)
• absolute Zeitangaben der Form '2022-12-16 14:00:00', bzw.  '0h 2022-12-16 14:00:00'

Dank für die Rückmeldungen
und beste Grüße
Franz

[Johann.S]

Hallo Franz,

tmin = '0h 18h'

Ok, mir war nicht bewusst, dass man 0h und 18h gleichzeitig verwenden kann!
Ist für mich nicht logisch.

Beim Modus 'raw' wird unabhängig vom Parameter 'count' alles dargestellt.
    Beim Modus 'avg' bestimmt der 1. Term der 'tmin' Angabe das Mittelungs-Intervall, z.B. '0h' für Stunden.
    Mit einem Parameter 'count' = 1 wird dabei die alte, ungewichtete Mittelung benutzt.
    Bei 'avg' mit 'count' > 1 wird gewichtet gemittelt, die Intervalllänge wird über den 1. tmin-Term festgelegt
    Bei 'avg' mit 'count' < 0 wird gewichtet gemittelt, wobei die Gesamtlänge in |count| Intervalle geteilt wird

Wie machst du eine Mittlung mit der alten Methode und 'count' > 1?
Wenn man 'count' nicht angiebt ist er automatisch 100 also Variante 3?
Würde bedeuten das ich bei 'tmin' = '10d' 100 Werte gemittelt auf Tage bekomme, währen dann also nur 10 Werte oder?

Gruß
Johann

Nachtrag:

aber wo bleibt da die gewichtete Mittelung mit Stunden? Ich muss ja das Mittelungsintervall irgendwo in tmin unterbringen, und irgendwo anders muss ich sagen, ob ich gewichtete oder ungewichtete Mittelung will.

Das währe in meiner Variation der Punkt 2 und bei deiner der Punkt 3.

[alkazaa]

Hallo Johann!

Ok, ich versuch jetzt mal, die Entwicklung dieses Mittelungsverfahrens aus diesem thread nachzuvollziehen:
Zunächst gab es nur das ungewichtete Mitteln, das sich nach tmin richtete, und zwar so, dass
- bei tmin < 2h gar nicht
- bei 2h <= tmin < 2d stundenweise
- bei 2d <= tmin < 2w tageweise
- bei 2w <= tmin < 2m wochenweise
- bei 2m <= tmin < 2y monatsweise
- bei 2y <= tmin jahresweise gemittelt wurde.
tmin hatte immer nur einen Term, count spielte keine Rolle.

Dann wurde implementiert, dass tmin auch mehrere Terme haben durfte (im Einklang mit dem von Wolfram erwähnten SV-Möglichkeiten, z.B. '2m 3d 12h'), wobei der Buchstabe (h|d|w|m|y) des 1. Terms genutzt wurde, das Mittelungsintervall festzulegen.
Das hatte den Nebeneffekt, das man unabhängig von der Gesamtzeit das Mittelungsintervall festlegen konnte. War z.B. sinnvoll, wenn man mit tmin='1y 2w', tmax='1y' einen 2-Wochen-Zeitraum vor einem Jahr mit tageweiser Mittelung anschauen wollte: dann konnte man einfach tmin='0d 1y 2w' angeben, da die Terme in tmin einfach aufaddiert wurden. Ging vorher gar nicht. (Das war der Trick, den ich früher mal erwähnte.)

Ich gebe zu, dass das nicht intuitiv und logisch aussieht, aber man könnte ja auch, wie von Dir vorgeschlagen, mit vorangestelltem oder folgendem (h), (d), ... den gleichen Effekt erzielen. Würde ich aber nicht machen, da es dann bei jemand, der die alte 1-Term-für-tmin-Angabe benutzt, nicht funktioniert.

Nun gibt es aber zusätzlich das gewichtete Mitteln, und man muss jetzt irgendwo unterbringen, welche der beiden Methoden genommen werden soll. Da habe ich mich entschieden, das mit dem Parameter count zu machen (den ich ja schon beim gewichteten Mitteln mit 'brutaler' Einteilung der Gesamtzeit in |count| Intervalle missbraucht hatte.)

Mit Modus 'avg' und count>1 das gewichtete Mitteln auszuwählen ist vernünftig, da das ungewichtete Mitteln bei ungleichen Zeitabständen der Messwerte nicht sinnvoll ist. (Und bei gleichen Zeitabständen liefern beide Methoden das gleiche Ergebnis. Wer es trotzdem ungewichtet möchte, kann es mit count=1 immer noch erzwingen. Muss natürlich alles gut dokumentiert werden).

Wenn mit Deiner Variante 2 das gewichtete Mitteln gewählt wird, verstehe ich nicht, wie bei Deiner Variante 4 das Mittelungsintervall angegeben wird.

Ich hoffe, wir reden nicht zu sehr aneinander vorbei...

Gruß
Franz

[wvhn]

Hallo zusammen,

super Zusammenfassung, @alkazaa. Das bringt gut Transparenz in die Sache.
Ein neues Format für die Angabe der Mittelung anzugeben - z.B. "(h)" - ist wegen Kompatibilität zu bisherigen Visu-Seiten der Anwender und auch hinsichtlich der anderen Backend-Systeme ungünstig. Darauf würde ich gerne verzichten. Schon die negative Angabe für count ist eine Krücke, aber vermutlich das Beste, was einem einfallen kann um die gewichtete Mittelung ohne negative Begleiteffekte für bestehende Visu-Seiten einzuführen.

Das Beispiel "0h 18h" ist etwas ungünstig, weil zweimal die gleiche Einheit verwendet wird. Das funktioniert zwar, aber das "0h" ist überflüssig, weil bereits "18h" als erster Termin die Mittelung über Stunden bewirkt. Nimmt man "0h 18d" wird es vielleicht klarer: mit vorangestelltem "0h" wird stundenweise gemittelt, anderenfalls tageweise.

@JohannS, ich kenne das "Auswertungsfenster" nicht. Kannst Du den Zweck und die Funktionsweise beschreiben?

Gruß
Wolfram

[Johann.S]

Hallo Wolfram,

am Auswertungsfenster bastle ich gerade herum!
Sinn und Zweck ist es in diesem Fenster die Werte Plotname, tmin, tmax, count usw. einzugeben/auszuwählen!
Anschliesend wird ein unabhängiges Fenster göffnet mit dem Plot!
Bei der nächsten Eingabe kommt wieder ein unabhängige Fenster usw..
Somit kann man mehrer Plots in unabhängigen Fenster anzeigen und vergleichen!
So ähnlich wie hier im Forum die angehängten Bilder!

Damit muss ich nicht alle Vergleiche im vorhinein wissen/erstellen und kann Kraut und Rüben mit einander vergleichen!

Ich hoffe die Erklährung war verständlich?

Wegen der Parameter bin ich mit allem Einverstanden, ich bin ja froh das es endlich funktioniert!
Ein Jahr warten hat sich ausgezahlt!

Ohne Franz währen wir nie so weit gekommen!

Danke noch mal!

Gruß
Johann

[alkazaa]

Moin Johann, Wolfram,

danke für das fette Lob (rot-werd). Ich will das dann mal (vorerst) abschließen mit der 99_fronthemUtils.pm im Anhang.

Ich habe noch paar Anmerkungen dazu:

A) Parameterübergabe aus plot.period:

   
• mode 'raw' liefert immer alle Werte im angegebenen Zeitfenster tmin,tmax
  (Also keine Änderung gegenüber vorher)
• mode 'avg' und count > 2 liefert gewichtete Mittelwerte in count Intervallen
  (Das ist neu, und es vermeidet einen negativen count-Wert. Es ist auch der einzige Fall
  wo der Wert von count die Zahl der Intervalle angibt)
• mode 'avg' und count = 2 liefert gewichtete Mittelwerte in Intervallen, die durch den ersten
  Buchstaben (h|d|w|m|y) in den tmin-Angaben festgelegt sind. tmin kann mehrere Werte haben,
  die aufaddiert werden, z.B. ergibt '1y 3m 2d' eine Dauer von 1 Jahr, 3 Monaten und 2 Tagen.
  In der SV-Dokumentation ist das als 'duration-format' bezeichnet. Ein vorangestelltes '0h' oder
  '0d' etc. trägt ( wegen der 0) nicht zur Gesamtdauer bei, aber legt Stunden (h) (oder Tage etc.)
  als Mittelungsintervall fest.
• mode 'avg' und count = 1: wie vor, aber ungewichtetes Mitteln
• bei den Modi 'min', 'max', 'sum' ist alles wie vorher (der count-Wert ist irrelevant, die Intervalldauer
  wird durch den ersten Term in tmin festgelegt

B) weitere Features:

   
• In tmin und tmax können timestamps der Form 1670259921000 angegeben werden. Ein führender
  Term '0h', '0d', etc. wird in tmin akzeptiert und wirkt sich aus wie oben beschrieben
• Außer Jahr (y), Monat (m), Woche (w), Tag (d) und Stunde (h) habe ich auch Viertel-Tage (also 6h-Zeiträume)
  und Viertelstunden implementiert. Allerdings: die entsprechenden Kürzel (q und v habe ich gewählt)
  werden von SV nicht übergeben. Kann man das in SV ändern?
• Ebenso kann SV keine 'human-readable' Absolutzeiten der Form "2022-11-11 11:11:00" verdauen:
  Sie werden zwar an fronthemUtils übergeben (und dort auch richtig verarbeitet), aber im Browser tauchen
  merkwürdige x-Achsen auf, sodass keine Daten zu sehen sind.

C) Besonderheiten/Einschränkungen:

   
• für die Nutzung der o.g. features wird in FHEM automatisch ein DbRep-device angelegt, dessen Name dem des DbLog-device mit angehängtem 'Report' entspricht
• die implementierten SQL-Queries sind z.Zt. nur für MySql verfügbar. PostGreSQL und sqlite kann ich nicht testen
• in Plotfile() sind keine der Änderungen aktiv
• ausführliches Testen als Sahnehäubchen fehlt noch (obwohl ich den Eindruck habe, dass annähernd 100%
  derjenigen, die FHEM-SV-Plot nutzen schon getestet haben  )

Einen schönen 4. Advent noch!
Franz

Nachtrag
In DbRep ist zwar bereits ein gewichtetes Mitteln implementiert. Die Punkte eines Mittelungsintervalls werden dort aber mit separaten SQL-Queries eingelesen (und dann im Perl-code weiterverarbeitet). Dadurch fällt immer der jeweils letzte Datenpunkt eines Intervalls "unter den Tisch", da sein Zeitabstand zum nächsten Punkt außerhalb des Intervalls nicht bekannt ist. Fällt zwar nur auf, wenn nur wenige Datenpunkte pro Intervall vorliegen, aber trotzdem...

Mit der reinen SQL-Berechnung. die ich gewählt habe, kann man das vermeiden. Ich habe das so implementiert, dass der Wert, der durch einen Datenpunkt am Ende eines Intervalls repräsentiert wird, korrekt auf dieses und das folgende Intervall verteilt wird.  Der zugehörige SQL-Code sieht allerdings gelinde gesagt abschreckend aus, wenn man die Lust verspürt, ihn im sourcecode anzuschauen. In der beiliegenden ZIP Datei habe ich ihn daher in etwas leichter lesbarer formatierter Form zusätzlich beigefügt (am besten mit notepad++ o.ä. anschauen).

[Johann.S]

Hallo Franz, Wolfram,

danke noch mal für die spitzen Leistung, ich fülle mich wie Weihnachten, ach ja ist ja Weihnachten 

Also von meiner Seite kann man das jetzt in fhem einfliessen lassen (oder wie immer man das nennt)!
Für meine Verhältnisse ist es mehr als ich mir gewünscht habe!

Ich werde es heute in meine Hauptversion installieren!

Schöne Feiertage!
Johann