WeekDayTimer Variable als Parameter übergeben

[sz]

Hallo FHEM Gemeinschaft,

ich melde mich hier neu an Board mit der Bitte um Hilfe. Ich hänge jetzt seit einer Woche an u.s. Problem. Habe "Heimautomatisierung-mit-fhem.pdf" gelesen & schon sämtliche Foren-Beiträge durchgestöbert und bin langsam am verzweifeln.

Ich möchte global einen Default-Wert für den Temperatur-Setpoint eines Thermostates hinterlegen. Idealerweise sollte das in "99_myConstantsUtils.pm" geschehen. Das sieht bei mir dann so aus:

Code Auswählen Erweitern


package main;

use strict;
use warnings;

  my $OG_KZ_temp_min = 15;
  my $OG_KZ_temp_max = 22;

sub
myConstantsUtils_Initialize($$)
{
  my ($hash) = @_;

}


Anschließend wollte ich diese Variable dann als Parameter an WDT übergeben:

Code Auswählen Erweitern

define meinWDT_OG_KZ_Thermostat WeekdayTimer OG_KZ_Thermostat de 78|16:13|$main::OG_KZ_temp_min

... und bekomme die Fehlermeldung:

Code Auswählen Erweitern

Global symbol "$main" requires explicit package name (did you forget to declare "my $main"?) at (eval 11372) line 1

Das direkte Ändern des SP über das Eingabefeld auf dem WEB UI per:

Code Auswählen Erweitern

set OG_KZ_Thermostat thermostatSetpointSet $main::OG_KZ_temp_min
funktioniert hingegen.

Auch Varianten wie:

Code Auswählen Erweitern

define meinWDT_OG_KZ_Thermostat WeekdayTimer OG_KZ_Thermostat de 78|16:54|{fhem("set OG_KZ_Thermostat thermostatSetpointSet $main::OG_KZ_temp_min")}
führen nicht zum Erfolg. Auch das globale Definieren der Variablen mit "our" statt "my" hilft nicht.

Ich habe dann versucht, das als dummy Device in der fhem.cfg zu definieren.
Auch hier klappt wieder der direkte Weg:

Code Auswählen Erweitern

{fhem("set OG_KZ_Thermostat thermostatSetpointSet " .ReadingsVal("dummy_device", "state", "14"))}

im WDT per:
define meinWDT_OG_KZ_Thermostat WeekdayTimer OG_KZ_Thermostat de 78|16:54|{fhem("set OG_KZ_Thermostat thermostatSetpointSet " .ReadingsVal("dummy_device", "state", "14"))}
gings aber wieder nicht.

Hat jemand einen Tipp?
Danke schon mal & VG, Sören

[Beta-User]

Ähm, ja, also...

Der "Event", also der zweite bzw. dritte Parameter jedes Schaltzeitpunktes ist "Klartext", kein Perl.

Lösen kannst du das eventuell, wenn du "hinten" Perl für COMMAND verwendest und dann ggf. einfach den Variablennamen da übergibts. Bin aber nicht sicher...

Code Auswählen Erweitern

define meinWDT_OG_KZ_Thermostat WeekdayTimer OG_KZ_Thermostat de 78|16:54|OG_KZ_temp_min {fhem("set OG_KZ_Thermostat thermostatSetpointSet $$EVENT")}
Das ganze kommt mir aber unflexibel vor, würde ggf. mal die weekprofile-Variante andenken oder ggf. die energy-irgendwas-Heating und heating-Setpoints auf den Thermostaten entsprechend setzen. Dann kannst du die über den WDT ansteuern, ggf. auch über den Umweg eines WDT_eventMap aus weekprofile raus...

Ach so: der WDT sollte den COMMAND im $main-Kontext ausführen.

[sz]

Erst mal.

Code Auswählen Erweitern

define meinWDT_OG_KZ_Thermostat WeekdayTimer OG_KZ_Thermostat de 78|16:54|OG_KZ_temp_min {fhem("set OG_KZ_Thermostat thermostatSetpointSet $$EVENT")}

hat leider so nicht funktioniert.

Log:

Code Auswählen Erweitern

2021.01.28 19:52:00 4: [meinWDT_OG_KZ_Thermostat] command: '{fhem("set OG_KZ_Thermostat thermostatSetpointSet $$EVENT")}' executed with %EVENT=>OG_KZ_temp_min,%NAME=>OG_KZ_Thermostat
2021.01.28 19:52:00 5: Cmd: >{fhem("set OG_KZ_Thermostat thermostatSetpointSet $$EVENT")}<
2021.01.28 19:52:00 1: ERROR evaluating my $EVENT=   $evalSpecials->{'%EVENT'};my $EVTPART0=   $evalSpecials->{'%EVTPART0'};my $NAME=   $evalSpecials->{'%NAME'};{fhem("set OG_KZ_Thermostat thermostatSetpointSet $$EVENT")}: Can't use string ("OG_KZ_temp_min") as a SCALAR ref while "strict refs" in use at (eval 12014) line 1.

2021.01.28 19:52:00 3: Can't use string ("OG_KZ_temp_min") as a SCALAR ref while "strict refs" in use at (eval 12014) line 1.

Die weekprofile-Variante schau ich mir mal an. Vielleicht hilft mir das weiter. Das fest in den Thermostaten zu hinterlegen, wollten ich vermeiden - mal davon abgesehen, dass ich nicht sicher bin, ob die Thermostate (Eurotronic Z-Wave Plus) das überhaupt supporten.

Nochmal ganz kurz zum Hintergrund meiner Überlegung:
Ich hätte gern eine zentrale Ablagemöglichkeit für alle festen Parameter. Aus diesen wollte ich mir als Grundgerüst ein einfaches Tagesprofil erstellen in dem Tags über eine bestimmte Temperatur gesetzt wird, Nachts dann eine Nachtabsenkung. Über Kalendereinträge sollen diese Default Einträge dann personalisiert überschrieben werden können.

[Beta-User]

hat leider so nicht funktioniert.

Erst mal zu den Perl-Themen:

Vermutlich liegt es (auch?) an dem doppelten Siegel, _vielleicht_ kann man es so hintricksen:

Code Auswählen Erweitern

define meinWDT_OG_KZ_Thermostat WeekdayTimer OG_KZ_Thermostat de 78|16:54|OG_KZ_temp_min {fhem("set OG_KZ_Thermostat thermostatSetpointSet $".$EVENT)}

Generell: Zur zentralen Ablage von Daten ist der Weg über globale Variablen eher ungewöhnlich. Da es hier eigentlich nicht um was Zentrales geht, sondern um individuelle Vorgaben für den einzelnen Thermostaten, würde ich das eher über ein Attribut (->userAttr) oder ein Reading (->setreading) abfackeln. Wenn zentrale Speicherung, dann eher über %data (siehe https://wiki.fhem.de/wiki/99_myUtils_anlegen#Globale_Ablage_von_Daten).

Zu dem Spirit:

Das fest in den Thermostaten zu hinterlegen, wollten ich vermeiden - mal davon abgesehen, dass ich nicht sicher bin, ob die Thermostate (Eurotronic Z-Wave Plus) das überhaupt supporten.

Einen "Spirit" habe ich auch im Einsatz, sonst wüßte ich nicht, dass man das können dürfte. Interessant wäre, warum du das vermeiden willst? Man setzt den Wert, wenn man unbedingt will, checkt man (einmalig), ob es geklappt hat und packt es ggf. in ein entsprechendes (user-?) Reading, dann weiß FHEM, was Sache ist...

Zur Vorgehensweise als solcher:

Die weekprofile-Variante schau ich mir mal an. Vielleicht hilft mir das weiter.
[...]
Nochmal ganz kurz zum Hintergrund meiner Überlegung:
Ich hätte gern eine zentrale Ablagemöglichkeit für alle festen Parameter. Aus diesen wollte ich mir als Grundgerüst ein einfaches Tagesprofil erstellen in dem Tags über eine bestimmte Temperatur gesetzt wird, Nachts dann eine Nachtabsenkung. Über Kalendereinträge sollen diese Default Einträge dann personalisiert überschrieben werden können.

Die grundlegende Aufgabenstellung ist bei diesen Heizungsgeschichten eigentlich immer ähnlich, die eigentliche Frage ist also, wo man überhaupt welche Einstellungsmöglichkeit hat (gibt es ggf. autonom auf dem Thermostat laufende Wochenprofile? Hier: nein), und wie man die "Schichten" dann übereinanderlegt.
Mein Ansatz bei der Erweiterung von WeekdayTimer in Richtung weekprofile-Support (und jetzt auch in Richtung "mapping" und "sendDelay") war die, alles zentral über eine Stelle "abfackeln" zu können, nach der simplen Regel: ein Thermosat=ein WeekdayTimer. Früher brauchte man mehrere (bzw. mehrere Heating_Control-Devices), wenn man unterschiedliche Anwendungsszenarien hatte, und musste dann die gegenseitigen Abhängigkeiten extern regeln.
Jetzt geht das einfacher. Du sagst einfach einem zentralen weekprofile-Device, welches Anwendungsszenarium du hast (alle weg, eine bestimmte Person zuhause, homeoffice, ...) (=du wechselst das "Topic"), und weekprofile stellt dann alle "Clients" um, die das Topic kennen. Das kann direkt die Hardware sein, oder eben auch eine beliebige Anzahl WeekdayTimer, die dann ihrerseits die neuen Temperaturen (eventuell verzögert und ggf. "gemappt") an die Zieldevices (=meistens: Thermostate) weitergeben.

Es gibt im entsprechenden Forumsbereich ein oder zwei Threads, wo erläutert ist, wie das im Detail funktioniert und wo man was einstellen muss.

[sz]

Zunächst erst mal vielen Dank für die ausführliche Hilfe!

Meine Überlegung war, alle Parameter übersichtlich an einem Ort zu haben. Zugegeben: die strikte Zuordnung zu den Devices hat sicher auch seinen Charme. Glaube da muss ich noch etwas drüber grübeln.

Deinen Ansatz das hierarchisch über einen übergeordneten WeekDayTimer zu machen klingt erst mal vielversprechend. Da schaue ich mir mal die diesbezüglichen Forenbeiträge an - hast Du zufällig einen Link oder ein Schlüsselwort zur Hand, wo ich da fündig werde (  falls nein  - auch nicht schlimm, da such' ich mich durch die Foren-Beiträge; hab ich ja jetzt schon Übung drin    )?

Was mir wichtig ist, ist die Steuerung einigermaßen Benutzerfreundlich zu gestalten - meine Oldies wohnen im gleichen Haus und müssen auch damit zurecht kommen. Deshalb die Überlegung das über den Kalender quasi als UI zu realisieren. Vielleicht lässt sich das mit dem  WeekDayTimer-Ansatz sinnvoll kombinieren...

[Beta-User]

Das mit dem Kalender sollte trotzdem gehen, wobei das bisher etwas diffus ist, wie das im Detail sein soll. Ich stelle aber z.B. auch den Modus auf "Ferien" (zwischenzeitlich via Topic-Wechsel), wenn der Kalender das sagt...

Etwas länglich, aber mAn. ist das evtl. ein guter Thread, um die Zusammenhänge ggf. besser nachvollziehen zu können:
https://forum.fhem.de/index.php/topic,116719.0.html

Ansonsten einfach: weekprofile-Device anlegen, Topics aktivieren, WDT für jeden Thermostaten anlegen, auf das weeprofile in der DEF verweisen und den "entity"-Namen in dessen "weekprofile"-Attribut hinterlegen, dann die DEF von dem WDT nochmal anfassen, dass ihn weekprofile dann sieht. (bis auf das Anegen der eigentlichen Profile in weekprofile) Done...

[pittbullpower]

Hallo Beta-User,

folgendes Problem habe ich mit dem Weekdaytimer und den Eurotronics / Varmo Spirit Thermostaten:

Schalte ich die Thermostaten direkt über FHEM habe ich kein "ZWDongle_ProcessSendStack: no ACK, resending message"

Schaltet der Weekdaytimer die Temperatur, habe ich öfters "ZWDongle_ProcessSendStack: no ACK, resending message".

Ich habe mich hier bereits eingelesen, und alle Updates installiert, bzw. Neighborupdates gemacht. Kann dieses Verhalten eventuell dadran liegen, das hier ein Temperaturwert mit "." übergeben wird?

Über den Thermostat wird z.B. auf 20° eingestellt, über den WDT auf 20.0°.

Ich hoffe, ich bin hier richtig?

Gruß

Markus

[Beta-User]

Ich hoffe, ich bin hier richtig?

...vermutlich nicht, weil hier mal ein ganz anderer Denkansatz Anlass der Diskussion war...

Schalte ich die Thermostaten direkt über FHEM habe ich kein "ZWDongle_ProcessSendStack: no ACK, resending message"

Schaltet der Weekdaytimer die Temperatur, habe ich öfters "ZWDongle_ProcessSendStack: no ACK, resending message".

Kann es sein, dass da mehrere gleichzeitig angesteuert werden?

Wenn ja: WDT_sendDelay ansehen/einstellen.

Ich habe mich hier bereits eingelesen, und alle Updates installiert, bzw. Neighborupdates gemacht. Kann dieses Verhalten eventuell dadran liegen, das hier ein Temperaturwert mit "." übergeben wird?

Das sollte gleichgültig sein, der Wert wird vom ZWave-Modul sowieso in was "sendetaugliches" umgewandelt...

[pittbullpower]

Kann es sein, dass da mehrere gleichzeitig angesteuert werden?

Hallo Beta-User,

das habe ich bereits umgestellt.

Für jeden einzelnen Thermostat habe ich einen WDT eingerichtet.

Bei mir muckeln die Thermostate aber nur bei der Übergabe vom WDT rum, schalte ich diese über den Slider läuft es normal?

Das sollte gleichgültig sein, der Wert wird vom ZWave-Modul sowieso in was "sendetaugliches" umgewandelt...

Hier habe ich definitiv 2 Werte die angezeigt werden, 20° und 20.0°....

Habe gerade auch den Beitrag mit dem"." gefunden, bin aber nicht schlauer geworden.

Gruß

Markus

[Beta-User]

...so war es nicht gemeint:

Wenn du zwar mehrere WDT hast, aber alle zur exakt gleichen Zeit Befehle an verschiedene Thermostate senden, gibt das Probleme...

Deswegen hatte ich das v.a. im Hinblick auf "Massenänderungen" durch "Nach-hause-kommen" oder "Profilwechsel" (bei weekprofile-Nutzung) um dieses delay-Attribut ergänzt.

[pittbullpower]

...so war es nicht gemeint:

Wenn du zwar mehrere WDT hast, aber alle zur exakt gleichen Zeit Befehle an verschiedene Thermostate senden, gibt das Probleme...

Deswegen hatte ich das v.a. im Hinblick auf "Massenänderungen" durch "Nach-hause-kommen" oder "Profilwechsel" (bei weekprofile-Nutzung) um dieses delay-Attribut ergänzt.

Hier habe ich 1Minute Zeitverzug angesetzt, was mir aber nicht gefällt. Aber so kann man es machen. 05:00 05:01 05:02, usw...

Aber auch bei WDT Zeiten, wo kein Traffic ist, habe ich diese Meldung...

Gruß

Markus

[Beta-User]

Na ja, mAn. liegt das dann nicht am WDT-Modul, sondern eher an der Funkverbindung an sich, was aber dann ein ZWave-Thema wäre.

Wenn die ".0" das "Problem wäre, würde es nie gehen, und das Umrechnen (falls es erforderlich ist...) dauert mit ziemlicher Sicherheit nicht so lange, als dass es dadurch Schwierigkeiten geben dürfte.

Ich habe die Beobachtung aber auch schon ohne WDT gemacht, dass es dauern kann, bis eine Rückmeldung von dem Spirit kommt...

[pittbullpower]

Hallo Beta-User,

danke für Deine Info und Hilfe.

Zwave-Seitig habe ich alles gemacht inkl. ex + Neuinklusion, Neighborupdate, List usw.
Das habe ich mir bereits angetan.

Bei mir fällt es nur auf, wenn der WDT das Gerät schaltet. Schalte ich eine andere Temperatur gibt es keine Fehlermeldung.

Danke nochmal

Markus