Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)

[RalfRog]

Unabhängig von alkazaa's Anmerkung hatte ich das schon mal ausprobiert writeToDB <> writeToDBInTime

Bei "aggregation = hour" kommt da meiner Ansicht nach kein großer Unterschied raus. Zeitbegrenzung 15:00:00 bis 20:59:59
Hab mal ein Beispiel angehängt.
Der erste Wert hat in meinem Beispiel (Screenshot) den Zeitstempel 15:00:00 statt 15:00:01.
Abgesehen von der ausreichenden Anzahl an Datenpunkten würde selbst ein stündlicher Aufruf letztlich auch nur die Zeiten von xx:00:01 auf xx:00:00 verschieben.
War das so gedacht?

Gruß Ralf

[alkazaa]

mea culpa: hatte RTFM geschwänzt ...
-Franz

[DS_Starter]

Habe noch folgende Option für averageValue ergänzt:

writeToDBSingleStart    : schreibt nur einen Wert mit dem Zeitstempel XX:XX:01 am Beginn einer Auswertungsperiode

Bei "aggregation = hour" kommt da meiner Ansicht nach kein großer Unterschied raus. Zeitbegrenzung 15:00:00 bis 20:59:59
Hab mal ein neues Beispiel angehängt.
Der erste Wert hat in meinem Beispiel (Screenshot) den Zeitstempel 15:00:00 statt 15:00:01.
War das so gedacht?

Ja. Es beachtet die Grenzen der Selektion. D.h. wenn du 11:12:08 bis 23:21:16  selektierst, beachten der erste und letzte (neu geschriebene) Datensatz genau diese Zeitgrenzen und gehen mit XX:XX:01 nicht darunter oder mit XX:59:59 darüber.

Die ergänzte Version ist eingecheckt und liegt auch im contrib wenn ihr sie schon benutzen möchtet.

[RalfRog]

Ok...

Dann kann man Attribute geschickt gesetzt natürlich so etwas hinbekommen und ist weg von der 01 bzw. 59:

2023-01-13 15:50:59;    shelly_3em_haus;SHELLY;calculated;avgtwm_hour_total_power;227;
2023-01-13 15:00:00;    shelly_3em_haus;SHELLY;calculated;avgtwm_hour_total_power;227;

2023-01-13 13:50:59;    shelly_3em_haus;SHELLY;calculated;avgtwm_hour_total_power;668;
2023-01-13 13:05:00;    shelly_3em_haus;SHELLY;calculated;avgtwm_hour_total_power;668;

[alkazaa]

Wahrscheinlich werde ich die Version heute einchecken und mich morgen dann mal an den Patch von Franz heranmachen.

Ich hoffe, Du hast noch nicht angefangen: Habe noch weiter "gepatcht" und jetzt wird auch der Anteil des letzten Wertes VOR dem allerersten Mittelungs-bin anteilig berücksichtigt.

Hier nochmal kurz zusammengefasst, was eigentlich gemacht wird:

   
• der letzte Wert eines bins wird anteilig beim aktuellen bin mit gewertet
• er wird als zusätzlicher Wert am Anfang des nächsten bins gesetzt und dadurch auch dort am Anfang anteilig mit gewertet
• beim allerersten bin wird duch ein "peek-back-in-time" der letzte gemessene Wert vor Beginn des ersten Intervalls an den Beginn des ersten Intervalls gesetzt. Dazu wird natürlcih ein extra SQL-query nötig, und ich hoffe, ich habe das richtig gemacht.

So, jetzt hör ich auch auf, versprochen   

Beste Grüße
Franz

EDIT: Anhang korrigiert (am Ende von Zeile 3480 fehlte ein ; )

[DS_Starter]

Ich hoffe, Du hast noch nicht angefangen

Nein, ich wußte dass noch etwas kommt. 

... nee, hatte noch keine Zeit/Lust. Eine andere Sache hatte meine Aufmerksamkeit.

[RalfRog]

...
writeToDBSingleStart    : schreibt nur einen Wert mit dem Zeitstempel XX:XX:01 am Beginn einer Auswertungsperiode
...

Schönes Feature habs mal dank "alkazaa" zum Kurven vergleichen ausprobiert.

Dabei ist mir folgendes  aufgefallen: 

CommandRef:

Code Auswählen Erweitern

maxValue [display | writeToDB | deleteOther] - berechnet den Maximalwert des Datenbankfelds "VALUE" in den Zeitgrenzen .....
Die Auswertung enthält den Zeitstempel des ermittelten Maximumwertes innerhalb der Aggregation bzw. Zeitgrenzen. Im Reading wird der Zeitstempel des letzten Auftretens vom Maximalwert ausgegeben, falls dieser Wert im Intervall mehrfach erreicht wird

"Im Reading wird der Zeitstempel des letzten Auftretens..."
Tatsächlich wird (auch bei MIN) immer xx:xx:59 eingetragen. Ich weiss natürlich nicht was der Grund dafür ist - aber aus meiner Sicht wünschenswert ist tatsächlich, dass der Zeitstempel des Max/Min-Wertes erhalten bleibt.

Gruß Ralf

[DS_Starter]

Hallo Ralf,

habe min/max gerade mit aggregation hour und day getestet.
Geschrieben wird der richtige Timestamp:

Code Auswählen Erweitern


2023.01.16 22:38:56.720 4: DbRep Rep.CPU - -------- New selection ---------
2023.01.16 22:38:56.721 4: DbRep Rep.CPU - Command: maxValue writeToDB
2023.01.16 22:38:56.722 4: DbRep Rep.CPU - FullDay option: 0
2023.01.16 22:38:56.722 4: DbRep Rep.CPU - Timestamp begin human readable: 2023-01-05 11:12:08
2023.01.16 22:38:56.722 4: DbRep Rep.CPU - Timestamp end human readable: 2023-01-05 23:21:16
2023.01.16 22:38:56.723 4: DbRep Rep.CPU - Aggregation: hour
2023.01.16 22:38:56.745 4: DbRep Rep.CPU - Database connect - user: fhemtest, UTF-8 option set: yes
2023.01.16 22:38:56.756 4: DbRep Rep.CPU - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung' ) AND TIMESTAMP >= '2023-01-05 11:12:08' AND TIMESTAMP < '2023-01-05 12' ORDER BY TIMESTAMP;
2023.01.16 22:38:56.769 4: DbRep Rep.CPU - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung' ) AND TIMESTAMP >= '2023-01-05 12' AND TIMESTAMP < '2023-01-05 13' ORDER BY TIMESTAMP;
2023.01.16 22:38:56.771 4: DbRep Rep.CPU - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung' ) AND TIMESTAMP >= '2023-01-05 13' AND TIMESTAMP < '2023-01-05 14' ORDER BY TIMESTAMP;
2023.01.16 22:38:56.776 4: DbRep Rep.CPU - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung' ) AND TIMESTAMP >= '2023-01-05 14' AND TIMESTAMP < '2023-01-05 15' ORDER BY TIMESTAMP;
2023.01.16 22:38:56.779 4: DbRep Rep.CPU - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung' ) AND TIMESTAMP >= '2023-01-05 15' AND TIMESTAMP < '2023-01-05 16' ORDER BY TIMESTAMP;
2023.01.16 22:38:56.781 4: DbRep Rep.CPU - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung' ) AND TIMESTAMP >= '2023-01-05 16' AND TIMESTAMP < '2023-01-05 17' ORDER BY TIMESTAMP;
2023.01.16 22:38:56.785 4: DbRep Rep.CPU - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung' ) AND TIMESTAMP >= '2023-01-05 17' AND TIMESTAMP < '2023-01-05 18' ORDER BY TIMESTAMP;
2023.01.16 22:38:56.787 4: DbRep Rep.CPU - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung' ) AND TIMESTAMP >= '2023-01-05 18' AND TIMESTAMP < '2023-01-05 19' ORDER BY TIMESTAMP;
2023.01.16 22:38:56.790 4: DbRep Rep.CPU - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung' ) AND TIMESTAMP >= '2023-01-05 19' AND TIMESTAMP < '2023-01-05 20' ORDER BY TIMESTAMP;
2023.01.16 22:38:56.792 4: DbRep Rep.CPU - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung' ) AND TIMESTAMP >= '2023-01-05 20' AND TIMESTAMP < '2023-01-05 21' ORDER BY TIMESTAMP;
2023.01.16 22:38:56.794 4: DbRep Rep.CPU - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung' ) AND TIMESTAMP >= '2023-01-05 21' AND TIMESTAMP < '2023-01-05 22' ORDER BY TIMESTAMP;
2023.01.16 22:38:56.797 4: DbRep Rep.CPU - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung' ) AND TIMESTAMP >= '2023-01-05 22' AND TIMESTAMP < '2023-01-05 23' ORDER BY TIMESTAMP;
2023.01.16 22:38:56.799 4: DbRep Rep.CPU - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung' ) AND TIMESTAMP >= '2023-01-05 23' AND TIMESTAMP <= '2023-01-05 23:21:16' ORDER BY TIMESTAMP;
2023.01.16 22:38:56.805 4: DbRep Rep.CPU - Database connect - user: fhemtest, UTF-8 option set: yes
2023.01.16 22:38:56.816 4: DbRep Rep.CPU - SQL prepare: INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)
2023.01.16 22:38:56.817 4: DbRep Rep.CPU - SQL prepare: UPDATE history SET TIMESTAMP=?, DEVICE=?, READING=?, TYPE=?, EVENT=?, VALUE=?, UNIT=? WHERE TIMESTAMP=? AND DEVICE=? AND READING=?
2023.01.16 22:38:56.818 4: DbRep Rep.CPU - SQL prepare: INSERT IGNORE INTO current (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)
2023.01.16 22:38:56.819 4: DbRep Rep.CPU - SQL prepare: UPDATE current SET TIMESTAMP=?, DEVICE=?, READING=?, TYPE=?, EVENT=?, VALUE=?, UNIT=? WHERE TIMESTAMP=? AND DEVICE=? AND READING=?
2023.01.16 22:38:56.820 4: DbRep Rep.CPU - begin transaction
2023.01.16 22:38:56.830 4: DbRep Rep.CPU - UPDATE history: 2023-01-05 11:35:31|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|3492.1000|, RESULT: 0
2023.01.16 22:38:56.832 4: DbRep Rep.CPU - INSERT history: 2023-01-05 11:35:31|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|3492.1000|, RESULT: 1
2023.01.16 22:38:56.833 4: DbRep Rep.CPU - UPDATE history: 2023-01-05 12:05:00|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|1507.3000|, RESULT: 0
2023.01.16 22:38:56.835 4: DbRep Rep.CPU - INSERT history: 2023-01-05 12:05:00|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|1507.3000|, RESULT: 1
2023.01.16 22:38:56.836 4: DbRep Rep.CPU - UPDATE history: 2023-01-05 13:13:02|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|3297.1000|, RESULT: 0
2023.01.16 22:38:56.837 4: DbRep Rep.CPU - INSERT history: 2023-01-05 13:13:02|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|3297.1000|, RESULT: 1
2023.01.16 22:38:56.839 4: DbRep Rep.CPU - UPDATE history: 2023-01-05 14:36:23|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|1920.2000|, RESULT: 0
2023.01.16 22:38:56.840 4: DbRep Rep.CPU - INSERT history: 2023-01-05 14:36:23|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|1920.2000|, RESULT: 1
2023.01.16 22:38:56.841 4: DbRep Rep.CPU - UPDATE history: 2023-01-05 15:07:52|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|1399.2000|, RESULT: 0
2023.01.16 22:38:56.842 4: DbRep Rep.CPU - INSERT history: 2023-01-05 15:07:52|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|1399.2000|, RESULT: 1
2023.01.16 22:38:56.843 4: DbRep Rep.CPU - UPDATE history: 2023-01-05 16:59:34|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 0
2023.01.16 22:38:56.844 4: DbRep Rep.CPU - INSERT history: 2023-01-05 16:59:34|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 1
2023.01.16 22:38:56.845 4: DbRep Rep.CPU - UPDATE history: 2023-01-05 17:59:28|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 0
2023.01.16 22:38:56.846 4: DbRep Rep.CPU - INSERT history: 2023-01-05 17:59:28|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 1
2023.01.16 22:38:56.847 4: DbRep Rep.CPU - UPDATE history: 2023-01-05 18:59:26|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 0
2023.01.16 22:38:56.848 4: DbRep Rep.CPU - INSERT history: 2023-01-05 18:59:26|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 1
2023.01.16 22:38:56.873 4: DbRep Rep.CPU - UPDATE history: 2023-01-05 19:59:22|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 0
2023.01.16 22:38:56.875 4: DbRep Rep.CPU - INSERT history: 2023-01-05 19:59:22|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 1
2023.01.16 22:38:56.876 4: DbRep Rep.CPU - UPDATE history: 2023-01-05 20:59:15|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 0
2023.01.16 22:38:56.877 4: DbRep Rep.CPU - INSERT history: 2023-01-05 20:59:15|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 1
2023.01.16 22:38:56.878 4: DbRep Rep.CPU - UPDATE history: 2023-01-05 21:58:08|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 0
2023.01.16 22:38:56.879 4: DbRep Rep.CPU - INSERT history: 2023-01-05 21:58:08|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 1
2023.01.16 22:38:56.880 4: DbRep Rep.CPU - UPDATE history: 2023-01-05 22:59:14|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 0
2023.01.16 22:38:56.881 4: DbRep Rep.CPU - INSERT history: 2023-01-05 22:59:14|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 1
2023.01.16 22:38:56.883 4: DbRep Rep.CPU - UPDATE history: 2023-01-05 23:20:33|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 0
2023.01.16 22:38:56.884 4: DbRep Rep.CPU - INSERT history: 2023-01-05 23:20:33|SMA_Energymeter|SMAEM||max_hour_Einspeisung_Wirkleistung|0.0000|, RESULT: 1
2023.01.16 22:38:56.886 4: DbRep Rep.CPU - transaction committed
2023.01.16 22:38:56.887 3: DbRep Rep.CPU - number of lines updated in >LogDB<: 0
2023.01.16 22:38:56.887 3: DbRep Rep.CPU - number of lines inserted into >LogDB<: 13


und

Code Auswählen Erweitern


2023.01.16 22:40:54.607 4: DbRep Rep.CPU - -------- New selection ---------
2023.01.16 22:40:54.610 4: DbRep Rep.CPU - Command: minValue writeToDB
2023.01.16 22:40:54.611 4: DbRep Rep.CPU - FullDay option: 0
2023.01.16 22:40:54.611 4: DbRep Rep.CPU - Timestamp begin human readable: 2023-01-05 11:12:08
2023.01.16 22:40:54.612 4: DbRep Rep.CPU - Timestamp end human readable: 2023-01-05 23:21:16
2023.01.16 22:40:54.613 4: DbRep Rep.CPU - Aggregation: day
2023.01.16 22:40:54.632 4: DbRep Rep.CPU - Database connect - user: fhemtest, UTF-8 option set: yes
2023.01.16 22:40:54.637 4: DbRep Rep.CPU - SQL execute: SELECT VALUE,TIMESTAMP FROM history where ( DEVICE = 'SMA_Energymeter' ) AND ( READING = 'Einspeisung_Wirkleistung' ) AND TIMESTAMP >= '2023-01-05 11:12:08' AND TIMESTAMP <= '2023-01-05 23:21:16' ORDER BY TIMESTAMP;
2023.01.16 22:40:54.651 4: DbRep Rep.CPU - Database connect - user: fhemtest, UTF-8 option set: yes
2023.01.16 22:40:54.660 4: DbRep Rep.CPU - SQL prepare: INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)
2023.01.16 22:40:54.660 4: DbRep Rep.CPU - SQL prepare: UPDATE history SET TIMESTAMP=?, DEVICE=?, READING=?, TYPE=?, EVENT=?, VALUE=?, UNIT=? WHERE TIMESTAMP=? AND DEVICE=? AND READING=?
2023.01.16 22:40:54.661 4: DbRep Rep.CPU - SQL prepare: INSERT IGNORE INTO current (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)
2023.01.16 22:40:54.662 4: DbRep Rep.CPU - SQL prepare: UPDATE current SET TIMESTAMP=?, DEVICE=?, READING=?, TYPE=?, EVENT=?, VALUE=?, UNIT=? WHERE TIMESTAMP=? AND DEVICE=? AND READING=?
2023.01.16 22:40:54.662 4: DbRep Rep.CPU - begin transaction
2023.01.16 22:40:54.663 4: DbRep Rep.CPU - UPDATE history: 2023-01-05 11:12:13|SMA_Energymeter|SMAEM||min_day_Einspeisung_Wirkleistung|0.0000|, RESULT: 0
2023.01.16 22:40:54.664 4: DbRep Rep.CPU - INSERT history: 2023-01-05 11:12:13|SMA_Energymeter|SMAEM||min_day_Einspeisung_Wirkleistung|0.0000|, RESULT: 1
2023.01.16 22:40:54.666 4: DbRep Rep.CPU - transaction committed
2023.01.16 22:40:54.667 3: DbRep Rep.CPU - number of lines updated in >LogDB<: 0
2023.01.16 22:40:54.667 3: DbRep Rep.CPU - number of lines inserted into >LogDB<: 1


Welche Aggregation hast du verwendet ?

[RalfRog]

...
Welche Aggregation hast du verwendet ?

Oh Mist...
Sehe gerade, dass die Werte die ich geprüft habe vom vom "reduceLog max" stammen und nicht vom maxValue 
Sorry!

War meine Vorgehensweise um auf der einen Seite per averageValue writeToDBSingle Mittelwerte (timeWeighted) zu haben und trotzdem "recht einfach" die DB mit einem interessanten Wert zu reduzieren.
Aber mir würde auch der echte Zeitstempel gefallen. "reduceLog average" auf xx:xx:30 ist (für mich) logisch und gut.

[DS_Starter]

Aber mir würde auch der echte Zeitstempel gefallen.

Das wäre ein zu großer Umbau. Die Zeitstempel bei reduceLog sind ein Kompromiss und werde je nach Verfahren vorbelegt:

                'average' -> '30:00'
                'max'      -> '59:59'
                'min'      ->  '00:01'
                'sum'     ->  '00:00'

Dadurch soll sichergestellt werden, dass Ergebnsisse verschiedener reduceLog Verfahren sich nicht (zufällig) überdecken.

[RalfRog]

Ja klar.

Sorry manchmal schaut man in die DB und stolpert... und hat dann die unterschiedlichen Methoden "reduclog Parameter" gegenüber "average|min|maxValue" nicht so direkt auf dem Schirm.

Die Stolperei hört jetzt vermutlich auf, da der Shelly3EM und das Logging & LangzeitLogging der gewünschten Werte eingestellt sind.

Und nochmal vielen Dank für DBLog & DBRep.
Wenn man sich getraut hat umzustellen (beim Einarbeiten hat HeidiSQL sehr geholfen) sind viele Sachen deutlich einfacher. Allein die ganzen Datenmanipulationen mit DBRep in den  letzten 10 Tagen 

Gruß Ralf

[DS_Starter]

Mein Job als Maintainer ist es unter anderem die Gesamtheit im Auge zu behalten.
Gelingt mal besser mal schlechter. 

Aber Spaß macht es immer (naja meistens) 

(Und danke für deine/eure Ideen/Mitarbeit !!)

[andies]

Ich habe nach einem Update folgende Meldung im Log

Code Auswählen Erweitern

Error:Modul 93_DbRep deactivated:
"evalDecodeJSON" is not exported by the FHEM::SynoModules::SMUtils module
Weiß jemand, was ich tun muss?

[DS_Starter]

Hast du ein relativ aktuelles FHEM, d.h. das Modul  ../lib/FHEM/SynoModules/SMUtils.pm aktualisiert ?
Ich hatte vor vllt. 14 Tagen (?) die Datei SMUtils.pm ergänzt und ausgeliefert.

LG,
Heiko

[andies]

Danke. Komischerweise wurde das bei mir nicht aktualisiert.