Modul weekprofile + FHEMWEB widget

Begonnen von Risiko, 23 Dezember 2015, 20:16:54

Vorheriges Thema - Nächstes Thema

Beta-User

Vorab mal: Danke für's Einchecken und das feedback!




Um Wiederholungen zu vermeiden: Betr. das Anliegen von beaune hatten wir an einer Stelle, von der ich nicht weiß, ob die hier schon explizit verlinkt war, schon eine etwas ausgiebigere Diskussion: https://forum.fhem.de/index.php/topic,122120.0.html

Vielleicht wird dann klarer, auf welche Weise beaune weekprofile nutzen will. Und evtl. ist das auch für DS_Starter ein guter Einstieg (zusammen mit dem "Weishaupt-MQTT2"-Thread)

(Das war ausdrücklich kein Votum in irgendeine Richtung!)

(Falls Beispiele zur parseParams-Verwendung im Zusammenhang mit der Auswertung von Attributen gewünscht ist: RHASSPY (in contrib) macht das recht exzessiv; ggf. einfach fragen oder die Beispiele in der commandref/help ansehen (da reicht es, das Modul ins Modulverzeichnis zu ziehen...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

beaune

#661
Hallo,

Danke schon mal dass Du Dir das anschaust. ich möchte kurz zu ein paar Punkten Stellung nehmen:
Zitat von: Risiko am 12 September 2021, 20:40:30
Was machst du denn eigentlich mit den Zeitplänen in weekprofile - nur visualisieren?
Du schreibst, die "Temperaturen werden Zentral verwaltet". Das verstehe ich leider nicht. Wäre es denn nicht sinnvoll, diese Temperaturen mit einstellen zu können? Wie\wer stellt diese Temperatur denn ein?
Das ist glaube ich der zentrale Verständnispunkt: Es gibt eine Heizungssteuerung, die ihre Aufgabe auch zukünftig haben soll. Nicht fhem steuert, sondern die Heizungssteuerung. Fhem dient zur alternativen Eingabe der Konfiguration, und zur Visualisierung. Fällt fhem oder der eBUS-Adapter aus, läuft trotzdem alles weiter.

Das Vorgehen ist so:

  • Man konfiguriert in einer Heizungssteuerung einen Sollwert für die Tagestemperatur und einen für die Nachttemperatur (Absenkbetrieb).
  • Anschließend konfiguriert man den Wochen-Zeitplan, d.h. man gibt an, wann kein Absenkbetrieb sein soll.
  • Manchmal kann man dann noch Datum-Intervalle für Ausnahmen vorgeben, aber das hat dann nichts mehr mit einem regelmäßigen Wochenprofil zu tun und ist hier OT.

Und daraus resultieren dann eben einige Anforderungen:

  • Man konfiguriert nur die ON-Intervalle. Die OFF-Intervalle sind dann automatisch alles dazwischen.
  • Die Intervallanzahl ist durch die Heizungssteuerung begrenzt.
  • Innerhalb des Wochenplans braucht man keine Temperaturangabe

Zitat von: Risiko am 12 September 2021, 20:40:30
Wenn ich es richtig verstehe, möchtest du nur Zeitpläne für Heizung ist AN verwalten. Zeitpläne für AUS und Temperaturen gibt es nicht. Die Keywords ON,OFF sind unter der Haube auch Temperaturen.
Ja genau. Wichtig war mir hier insbesondere, dass die JSON-Struktur gleich bleibt. Klar hätte man anstatt ON und OFF dort auch die an anderer Stelle konfigurierten Temperaturwerte eintragen können. Würde aber heißen, dass man immer dann, wenn jemand den Tages- oder Nachtsollwert ändert, alle Wochenprofile nachführen muß. Das schien mir nicht gut zu sein. Da Du aber an anderer Stelle schon erlaubst, dass Temperaturwerte zu einem Namen gemappt werden können, bin ich darauf gekommen, dann eben direkt die Namen ins JSON einzutragen. Das kann man natürlich auch anders lösen, indem man z.B. 0° als OFF und 100° als ON definiert. Mir schien es so das Konsequenteste zu sein, aber vielleicht läßt sich das auch geschickter lösen oder hat Nebeneffekte, die ich nicht gesehen habe.


Zitat von: Risiko am 12 September 2021, 20:40:30
Ich muss mich noch weiter damit beschäftigen, um entscheiden zu können, ob eine Integration wirklich Sinn macht. Wenn ja, wäre meiner Meinung nach ein konkreter Modus sinnvoll. Also wenn man explizit diesen Modus ohne Temperaturen verwendet, dann würden auch einige Attribute, Befehle, etc. wegfallen. Sonst gibt es viele ungültige Kombinationsmöglichkeiten\Varianten.
Die Bedenken kann ich gut nachvollziehen. Ich habe mich deswegen zunächst gegen einen dedizierten Modus entschieden, weil mir schien, dass manches eben nicht spezifisch für den Einsatz mit einer Heizungssteuerung ist, sondern auch in anderem Umfeld sinnvoll sein könnte, und die Vermischung mehrerer unabhängiger Themen das Verständnis der Ergänzungsvorschläge erschweren könnte. z.B.

  • nolink, noheadings: hat gar nichts mit dem Wochenprofil selbst zu tun, sondern ist lediglich ein UI-Thema, angelehnt an die entsprechenden Attribute einer readingsGroup.
  • maxNumInterval: auch bei anderen Geräten mag es Begrenzungen geben, wieviele Intervalle man verwalten kann/möchte. Dennoch muß dann nicht zwingend eine konstante Anzahl an eingebbaren Intervallen vorliegen (fixedProfileSettings).
Aber das ist sicher Geschmackssache. Ich kann auch gut mit einem dedizierten Modus leben. Oder vielleicht ist auch parseParams ne gute Idee, das hab ich mir bislang noch gar nicht angeschaut.

Bin gespannt zu welche Ergebnis Du kommst.

Beta-User

Zitat von: beaune am 13 September 2021, 16:57:03
Das ist glaube ich der zentrale Verständnispunkt: Es gibt eine Heizungssteuerung, die ihre Aufgabe auch zukünftig haben soll. Nicht fhem steuert, sondern die Heizungssteuerung. Fhem dient zur alternativen Eingabe der Konfiguration, und zur Visualisierung. Fällt fhem oder der eBUS-Adapter aus, läuft trotzdem alles weiter.
Unabhängig von allem anderen nochmal der Hinweis, der anscheinend bisher nicht bei dir angekommen ist: Dass die Steuerung dann mit den übertragenen Werten autark auf der Hardware läuft, ist kein "ebus"-Alleinstellungsmerkmal. Das ist bei MAX! und CUL_HM-Thermostaten so, und auch manche zigbee-Geräte sowie einige ZWave-Typen kennen sowas (und der MQTT2-zigbee-Code dazu kann das auch entsprechend codiert an die Geräte weitergeben).

Der einzige Unterschied ist der, dass man an Ebus eben nur An (= setpointHeating im ZWave-Spreech) bzw. Aus (=setpointEnergySaveHeating (? oder so ähnlich) sendet.
Auch das ist nicht komplett neu, sowas kann man - neben der "echten" Teperaturweitergabe auch dann via WeekdayTimer - erreichen (muss da aber ggf. eben im WDT mappen).
Effektiv ist es also auch bei Ebus nicht an und aus, was übermittelt wird, sondern eben nur die Grenzzeiten für "Temperaturwert 1" bzw. "Temperaturwert 2". Im Ebus-Code ist der Grenzwert (default) bei 20°, also könntest du auch on- und off-Value entsprechend in weekprofile setzen (?), das wäre in der Anzeige dann vermutlich dann nahe dem, was du dir vorstellst.

Bzgl. der "Modus"-Frage noch folgende spontanen Gedanken:
Wenn man parseParams auf zwei Attribute loslassen würde, könnte man das eine für "allgemein sinnvolle Tweaks am UI" verwenden, und mit dem anderen die "Modusumstellung" machen.

Generell finde ich persönlich weiter die Vorstellung "ein Endgerät, eine UI" verquer bzw. schlecht mit dem "verwalte und verteile zentral eine Vielzahl von Profilen (@Topics: für eine Vielzahl von Endgeräten)"-Prinzip vereinbar und glaube, dass das für die meisten FHEM-User eher verwirrend sein wird, wenn man das aufweicht.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Risiko

#663
Zitat von: beaune am 13 September 2021, 16:57:03
Hallo beaune,

danke für die Ausführungen. Vieles davon hattest du bereits geschrieben.
Wie Beta-User richtig sagt, ist da bei ebus bzw. deiner Heizungssteuerung nicht anders. Auch andere Systeme laufen ohne FHEM autark. Man nutz FHEM zur Visualisierung und zur Verstellung der Parameter\Eigenschaften

Was ich leider immer noch nicht verstehe, wieso macht man bei ebus das verstellen der Solltemperatur mittels FHEM nicht möglich?
Dann würde sich gegenüber den anderen Systemen vom Prinzip nichts unterscheiden und man müsste bei weekprofile nicht diesen Sonderweg ohne Temperaturen gehen.
Soll heißen, wenn es ein Modul für ebus gäbe (oder besser für die Heizungssteuerung) , was die Zeitpläne + Solltemperatur (auch wenn Solltemperatur nur AN\AUS oder feste Temperaturwerte sind) akzeptiert, dann würde es prima passen. Auch "Topics", "master device", etc. könnte man dann einfach verwenden.

Risiko



Risiko

Zitat von: Beta-User am 13 September 2021, 17:23:51
Generell finde ich persönlich weiter die Vorstellung "ein Endgerät, eine UI" verquer bzw. schlecht mit dem "verwalte und verteile zentral eine Vielzahl von Profilen (@Topics: für eine Vielzahl von Endgeräten)"-Prinzip vereinbar und glaube, dass das für die meisten FHEM-User eher verwirrend sein wird, wenn man das aufweicht.
Verstehe ich leider gerade nicht (könnte an der Uhrzeit liegen ;)).
Könntest du es ggf. anders formulieren?

Beta-User

Zitat von: Risiko am 14 September 2021, 22:19:59
wieso macht man bei ebus das verstellen der Solltemperatur mittels FHEM nicht möglich?
Na ja, zum einen KANN man das afaik prinzipiell schon von FHEM aus (für verschiedenste Temperaturvorgaben), das ist nur eben eine ganz andere Baustelle, die nichts mit Temperaturprofilen (oder Tag/Nacht-ON/OFF-Profilen) zu tun hat. Wenn man da zeitabhängig was machen wollte (was mir aber nicht sinnvoll erscheint), dann wäre eher WeekdayTimer (iVm. weekprofile) ein geeignetes Zwischendevice.

Zitat von: Risiko am 14 September 2021, 22:23:52
Verstehe ich leider gerade nicht (könnte an der Uhrzeit liegen ;) ).
Könntest du es ggf. anders formulieren?
Schwierig, da ich selbst weekprofile mit Topics im Einsatz habe. Dabei reicht mit eine weekprofile-Instanz, um alle (Hardware-) Zielgeräte zentral zu verwalten, ganz egal, ob das CUL_HM-Instanzen sind oder ZWave (vermittelt durch WeekdayTimer). Nicht alle Zielgeräte kennen alle Topics. Hätte ich ebus im Einsatz, würde ich einfach die betreffenden Profile* noch in die zentrale weekprofile-Instanz mit reinnehmen, um dann alles zentral umschalten zu können.

*Für ebus sehe ich dann mehrere MQTT2_DEVICE-Instanzen für jedes (Teil-) Gerät, das für sich ein Profil intern (auf der Hardware) verwalten kann, also für das zentrale Heizgerät, die Warmwasser-Umwälzpumpe, etc pp (bei der Weishaupt waren das 3-4 Instanzen). Damit würden dann die Zeiträume für das zentrale Heizgerät dann immer auch passend zu den Heizprofil-Anforderungen der Thermostate passen...

beaune scheint eher sowas haben zu wollen:
- "weekprofile-Instanz A" (mit genau einem Profil) -> ein Endgerät A,
- "weekprofile-Instanz B" (mit genau einem Profil) -> ein Endgerät B.

Hoffe, das ist jetzt etwas besser verständlich?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

beaune

Zitat von: Risiko am 14 September 2021, 22:19:59
Was ich leider immer noch nicht verstehe, wieso macht man bei ebus das verstellen der Solltemperatur mittels FHEM nicht möglich?
Dann würde sich gegenüber den anderen Systemen vom Prinzip nichts unterscheiden und man müsste bei weekprofile nicht diesen Sonderweg ohne Temperaturen gehen.
Mein Punkt ist der:

  • Natürlich kann man die Sollwerte per fhem verstellen. Das mache ich auch. Ist aber eine ganz andere Stelle, also aus eBUS-Sicht andere Variablen.
  • Man könnte die Sollwerte in der UI darstellen. Allerdings "passt" die Eingabemöglichkeit nicht zu dem, was die Heizungssteuerung speichern kann. Es gibt dort einfach keine Möglichkeit, jedem Intervall einen individuellen Temperaturwert mitzugeben. Würde man die Eingabemöglichkeit anbieten, müßte man die eingegebenen Werte spätestens bei der Übertragung zur Heizungssteuerung verwerfen bzw sich für einen (welchen?) davon entscheiden, wenn der User verschiedene Werte für verschiedene Intervalle eingestellt hat.
  • Ich fänd es aber blöd Dinge einstellbar anzuzeigen, die man im Gerät faktisch gar nicht einstellen kann. Das verwirrt und braucht einfach nur Platz in der Darstellung.
  • Um aber hier die Unterschiede zu anderen Geräten nicht zu groß zu machen, war meine Idee ja, nur die Anzeige zu beeinflussen, die Speicherstruktur aber unverändert zu lassen. Bis eben auf die Tatsache, dass ich Bezeichner anstatt Temperaturen speichere, was man ja auch anders lösen könnte.

beaune

Zitat von: Beta-User am 15 September 2021, 10:04:29
beaune scheint eher sowas haben zu wollen:
- "weekprofile-Instanz A" (mit genau einem Profil) -> ein Endgerät A,
- "weekprofile-Instanz B" (mit genau einem Profil) -> ein Endgerät B.
Ne das hab ich nicht gemeint (siehe Screenshot aus früherem Post). Ich nutze genau eine weekprofile-Instanz. Als Profile nutze ich aber keine Teilgeräte wie Brenner, Pumpe usw., sondern die logischen Heizkreise. Das sind bei mir: Fußbodenheizung, konventionelle Heizkörper und Warmwasser. Genau für die kann man in der Heizungssteuerung Sollwerte und Wochenprofile hinterlegen, und das wollte ich analog in fhem darstellen, also Auswahl des Heizkreises über die Combobox des weekprofiles.

Risiko

#668
Zitat von: Beta-User am 15 September 2021, 10:04:29
Dabei reicht mit eine weekprofile-Instanz, um alle (Hardware-) Zielgeräte zentral zu verwalten, ganz egal, ob das CUL_HM-Instanzen sind oder ZWave (vermittelt durch WeekdayTimer). Nicht alle Zielgeräte kennen alle Topics. Hätte ich ebus im Einsatz, würde ich einfach die betreffenden Profile* noch in die zentrale weekprofile-Instanz mit reinnehmen, um dann alles zentral umschalten zu können.

*Für ebus sehe ich dann mehrere MQTT2_DEVICE-Instanzen für jedes (Teil-) Gerät, das für sich ein Profil intern (auf der Hardware) verwalten kann, also für das zentrale Heizgerät, die Warmwasser-Umwälzpumpe, etc pp (bei der Weishaupt waren das 3-4 Instanzen). Damit würden dann die Zeiträume für das zentrale Heizgerät dann immer auch passend zu den Heizprofil-Anforderungen der Thermostate passen...
Joh, so oder so ähnlich meinte ich es auch.

Risiko

Zitat von: beaune am 15 September 2021, 12:09:07
Genau für die kann man in der Heizungssteuerung Sollwerte und Wochenprofile hinterlegen, und das wollte ich analog in fhem darstellen, also Auswahl des Heizkreises über die Combobox des weekprofiles.
Ja, aber die Sollwerte hast du doch in weekprofile entfernt.
Wäre es nicht richtiger für die  logischen Heizkreise ein entsprechendes Device\Modul zu haben?

Risiko

Zitat von: beaune am 15 September 2021, 12:02:06

  • Natürlich kann man die Sollwerte per fhem verstellen. Das mache ich auch. Ist aber eine ganz andere Stelle, also aus eBUS-Sicht andere Variablen.
Liegt da nicht das Problem bzw. sollte man sich da nicht was anderes einfallen lassen? Kann ich aber nicht wirklich beurteilen, kenne das ebus System nicht. Aber auch Beta-User schlägt dies ja vor.

  • Man könnte die Sollwerte in der UI darstellen. Allerdings "passt" die Eingabemöglichkeit nicht zu dem, was die Heizungssteuerung speichern kann. Es gibt dort einfach keine Möglichkeit, jedem Intervall einen individuellen Temperaturwert mitzugeben. Würde man die Eingabemöglichkeit anbieten, müßte man die eingegebenen Werte spätestens bei der Übertragung zur Heizungssteuerung verwerfen bzw sich für einen (welchen?) davon entscheiden, wenn der User verschiedene Werte für verschiedene Intervalle eingestellt hat.
Verstehe ich leider nicht wirklich. Wenn man die Solltemperatur prinzipiell ändern kann, dann kann man doch für eine Zeitspanne A die Solltemperatur auf X stellen und für eine Zeitspanne B auf Y. Jetzt muss nur noch festgelegt werden, wer dies macht (glaube, das geht mit weekdaytimer). Weekdaytimer und weekprofile arbeiten bereits zusammen.

  • Ich fänd es aber blöd Dinge einstellbar anzuzeigen, die man im Gerät faktisch gar nicht einstellen kann. Das verwirrt und braucht einfach nur Platz in der Darstellung.
Das verstehe ich, aber man könnte ja auch die einstellbaren Werte begrenzen (geht übrigens schon).
  • Um aber hier die Unterschiede zu anderen Geräten nicht zu groß zu machen, war meine Idee ja, nur die Anzeige zu beeinflussen, die Speicherstruktur aber unverändert zu lassen. Bis eben auf die Tatsache, dass ich Bezeichner anstatt Temperaturen speichere, was man ja auch anders lösen könnte.
Das passt eben nicht zur Philosophie. Es werden die Temperaturen gespeichert und durch tempMap kann man diese zur Keywords mappen. Bein Übertragen kann man festlegen, ob man die Werte oder die Keywords an ein Device sendet.


beaune

Ich versuchs nochmal anders zu erklären.

  • Die Heizungssteuerung kennt täglich drei Intervalle ("ON"), in denen die Tagessolltemperatur gilt.
  • Zwischen diesen 3 Intervallen sowie davor und danach gilt die Nachtsollwerttemperatur.
  • Würde man das konventionell im weekprofile darstellen, müßte man täglich 7 Intervalle anzeigen, zu denen man jeweils auch einen Temperaturwert angeben könnte. Pro Woche also 49 Temperaturwerte.
  • Die Heizungssteuerung kennt aber nur genau 2 Werte (Soll Tag und Soll Nacht). Mehr kennt sie einfach nicht und kann auch nicht mehr speichern.
Würde man die 49 Einstellmöglichkeiten zulassen, müßte man aus den 49 Werten die "richtigen" 2 ermitteln (z.B. erster Wert am Montag ist Nacht-Soll, zweiter Wert ist Tag-Soll), und diese dann in die entsprechenden Readings eintragen. Aber dann müßte man konsequenterweise an den anderen Stellen andere Eingaben verhindern, bzw. den zulässigen Wert auf genau diese beiden einschränken. Denn was sollte fhem tun, wenn man jetzt im dritten Intervall eine andere Temperatur einstellt, als die im ersten Intervall? Könnte man nur verwerfen. Das wäre für mein Empfinden eine ziemlich dynamische und auch nicht wirklich intuitive Auswertung, die es aktuell nicht gibt.

Alternativ könnte man die Temperatureingabe im weekprofile-Editor optional verhindern und nur anzeigen. Dann könnte man die beiden anderswo eingestellten Wert im Hintergrund als Speicherwert nehmen. Geht, hätte aber den Nachteil, dass man sämtliche gespeicherten Profile immer dann automatisch abändern müßte, wenn einer der beiden Sollwerte geändert wird. Das wäre dann irgendwie zu lösen, gibt es so heute ja auch nicht. Und ich finde es zumindest für die Übersichts-Darstellung des weekprofile auch nicht glücklich, wenn da immer wieder derselbe Temperaturwert steht. Das kostet Platz, bietet aber keine Information. Die Heizungssteuerung beschränkt sich darauf, nur die On-Intervalle darzustellen, und davon auch nur die konfigurierten. Das ist sehr kompakt, enthält aber dieselben Informationen. Deshalb der Ansatz, die Darstellung optinal auf die konfigurierten ON-Intervalle ohne Temperaturangabe einzuschränken. Ist aber auch unabhängig davon, was man jetzt wirklich speichert.

Die Tatsache, dass man in der Heizungssteuerung die beiden Sollwerte außerhalb der Zeitintervalle einstellt, kann man beklagen, macht irgendwo aber auch Sinn. Zumindest der Tagessollwert ist wahrscheinlich der Parameter, den man am häufigsten ändert, und der daher auch sehr prominent ist (bei Vaillant: einfach am Rädchen drehen). Dementsprechend prominent wünsche ich es mir dann eben auch in fhem, und nicht versteckt in einem Wochenprofil, dass wahrscheinlich eher selten geändert wird.

Ist es jetzt klarer geworden?


Beta-User

Vielleicht mal etwas anders betrachtet... Ich bin jetzt mal im Schnelldurchlauf durch die Änderungsvorschläge am .pm-Code.

Eigentlich sind es "nur" zwei Themenkreise:

Dass es sehr viele Attribute/Einstellmöglichkeiten sind, die man aber meinem Eindruck nach wirklich relativ einfach in weniger Attributen (eigentlich: einem einzigen?) untergebracht werden könnten. Alles, was da an Schlüsselwort drinsteht, ist aktiv, alles andere aus der "Zusatzliste" nicht:
attr <wp> uiTweaks fixedNumInterval fixedProfileSetting hideTransferButton
Dann bräuchte man das ganze nur nach $me->{helper} schieben (was da ist mit Wert 1, der Rest nicht), und könnte/müsste dann halt durch direkten Hash-Zugriff abfragen (defined $me->{helper} && defined $me->{helper}->{<tweak>}).

Zum anderen scheint mir weekprofile grundsätzlich etwas sehr schweigsam zu sein, was seine eigenen Aktivitäten angeht. Die (aus dem Code übernommene) konkrete Lösung über den DoTrigger finde ich nicht so gelungen, aber was spricht dagegen, alle "Aktionen" (triggernd) in ein (einziges) Reading zu schreiben und dann noch etwas mehr Info reinzupacken?
Also statt
DoTrigger($me,"WRITE_TO_DEVICE $name",1);
dann:
readingsSingleUpdate($me, 'lastAction', "WRITE_TO_DEVICE $name $topic:$profile",1);
Evtl. müßte man sich anschauen, ob bzw. wie lange (im Sinne von $feature_level) es sinnvoll ist, die alten Events zusätzlich zu generieren, und wie man das so gestaltet, dass es dann auch zusammenpaßt; evtl. wäre es eine Idee, das "restore"-Event auch da reinzupacken?

Dem Gefühl nach wäre es so oder so sinnvoll, sich den 2. Punkt mal anzuschauen, und für den ersten Punkt müßte man halt entscheiden, ob man das haben will. Aber da der Eingriff in den Code überschaubar ist...

Das ganze ändert ja soweit erkennbar nichts an der Art und Weise, wie weekprofile intern seine Daten speichert, oder übersehe ich was?

(Ich finde diese Art der Bedienung immer noch "eigen", aber das muss ja nichts heißen, "there's more than...".)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

@Risiko: Zwischendurch mal noch ganz was anderes...

Wir haben vermutlich eine etwas größere Baustelle: https://forum.fhem.de/index.php/topic,118985.msg1134287.html#msg1134287. Dachte, ich mache einen Reparaturvorschlag dazu, aber das ist was größeres, wenn man nicht einfach an den betreffenden Stellen dann schlicht den korrekten package-Verweis davorknallen will. Außerdem habe ich irgendwie im Ohr, dass data::Dumper möglichst außerhalb von echtem debugging vermieden werden sollte, würde daher die JSON-Evaluierung auch eher anders notieren und das ausbauen. (muss nicht richtig sein).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Risiko

Danke Beta-User für den Link.
Ist völlig an mir vorbei gegangen. Habs gefixt.
data::Dumper wird doch nur im Fehlerfall verwendet, um die Daten auszugeben und nicht zur JSON-Evaluierung selbst.