Neues Modul - THRESHOLD

[Markus Bloch]

Hallo Damian,

Ich habe das Modul aus dem ersten Post heruntergeladen, leider kommt bei meiner definition immer "wrong syntax".

Code Auswählen Erweitern


define Waschmaschine_Fertig THRESHOLD Verbrauch_Waschmaschine:current:0.01 {Log 2, "Fertig"}



Mach ich etwas falsch?

Viele Grüße

Markus

So funktioniert es leider nicht.
Das Modul ist dafür konzipiert einen Sollwert zu halten. Das geschieht z. Zt. über 'set Aktor cmd1' beim Überschreiten des Sollwertes und 'set Aktor cmd2' beim Unterschreiten des Sollwertes. Die Syntax ist lt. Doku actor:cmd1:cmd2. Mit {Log 2, "Fertig"} wird es leider nicht funktionieren, da kein Aktor bzw. keine sinnvollen set-Befehle definiert sind.

Eine Erweiterung auf alle möglichen Befehle ist denkbar, allerdings etwas aufwändig, da ich z. Zt. in der Logik des Moduls den Status des Aktors auswerte, um mehrfaches Schalten zu unterbinden.

Gruß

Damian

Damian

Ja Gut, dann werd ich noch etwas warten müssen :-(

[Damian]

Ja Gut, dann werd ich noch etwas warten müssen :-(

Dein Warten hat nun ein Ende;)

Ich habe nun eine erweiterte Version produziert, die beliebige FHEM/Perl-Befehle ausführen kann.

Hier ein Auszug aus der Doku:

define <name> THRESHOLD <sensor>[:<reading>[:<threshold>]] [AND|OR <sensor2>[:<reading2>][:<state>]] <actor>[:<cmd_max>][:<cmd_min>][:<cmd_default>]

oder, wenn beliebige FHEM/Perl-Commdandos ausgeführt werden sollen:

define <name> THRESHOLD <sensor>[:<reading>[:<threshold>]] [AND|OR <sensor2>[:<reading2>][:<state>]] |command_max|command_min|command_default

Beispiele:

define Thermostat THRESHOLD Sensor |{fhem("set Switch1 on;set Switch2 on")|{fhem("set Switch1 off;set Switch2 off")|{fhem("set Switch1 on;set Switch2 on")
define Thermostat THRESHOLD Sensor |{Log 2,"Wert überschritten"}|set Alarm off|{fhem("set Switch1 on;set Switch2 on")}
define Thermostat THRESHOLD Sensor ||{Log 2,"Wert unterschritten"}||

Die vollständige Dokumentation befindet sich im PM-Modul (deutsch und englisch) und kann mit commandref_join.pl aus dem contrib-Verzeichnis in die commandref übernommen werden.

Es ist zusätzlich eine default-Aktion hinzugekommen, die nach dem Setzen von desired Wert ausgeführt wird, bis der Maximal- oder Minimalwert auftritt (Es hat mich immer gestört, dass man nach dem Setzen der Soll-Temperatur immer warten musste bis die Temperatur auf Minimum fallen musste, bevor geheizt wurde).

Das Modul ersetzt das ursprüngliche und wurde weitgehend von mir getestet.

Gruß

Damian

[Markus Bloch]

*_* Werde ich umgehend testen ;-)

[Markus Bloch]

Zwei Sachen bezgl. der Doku hab ich schonmal.

Einmal

Code Auswählen Erweitern


# ./contrib/commandref_join.pl
EN FHEM/98_THRESHOLD.pm: Unbalanced ul (1, last line ok: 223)
#



Und

(siehe Anhang / see attachement)

Bitte ersetze hier die Sonderzeichen und füge <br> für die Zeilenumbrüche ein.

Code Auswählen Erweitern

ä => ä
ö => ö
ü => ü
Ä => Ä
Ö => Ö
Ü => Ü
ß => ß
< => &lt;
> => &gt;

Und offenbar scheint die Doku generell nur in deutsch zu sein.

Ich versuch mich mal drann. Ich melde mich ;-)

Vielen Dank aber schonmal dafür.

Viele Grüße

Markus

[Markus Bloch]

Hallo Damian,

leider funktioniert die Definition nicht aufgrund der Meldung.

Code Auswählen Erweitern


Thermostat: Unknown actor device ||{Log specified



Dies liegt an Zeile 87

Code Auswählen Erweitern


  my ($actor, $actor_cmd1,$actor_cmd2) = split(":", $actor_defs, 3);

  if(!$defs{$actor}) {
      my $msg = "$pn: Unknown actor device $actor specified";
      Log 2, $msg;
      return $msg;
  }



Meine Definition war:

Code Auswählen Erweitern


define Thermostat THRESHOLD Verbrauch_Waschmaschine:current:0.02 ||{Log 2,"Wert unterschritten"}||


Viele Grüße

Markus

[Damian]

Hallo Damian,

leider funktioniert die Definition nicht aufgrund der Meldung.

Code Auswählen Erweitern


Thermostat: Unknown actor device ||{Log specified



Dies liegt an Zeile 87

Code Auswählen Erweitern


  my ($actor, $actor_cmd1,$actor_cmd2) = split(":", $actor_defs, 3);

  if(!$defs{$actor}) {
      my $msg = "$pn: Unknown actor device $actor specified";
      Log 2, $msg;
      return $msg;
  }



Meine Definition war:

Code Auswählen Erweitern


define Thermostat THRESHOLD Verbrauch_Waschmaschine:current:0.02 ||{Log 2,"Wert unterschritten"}||


Viele Grüße

Markus

Mir scheint es, als würdest du mit der alten Version zu arbeiten. Denn auch die Doku ist von der alten. In der neuen habe ich die UTF-8 Kodierung vorgenommen, da funktioniert es auch mit den Umlauten. Fehlermeldungen gibt es bei mir bei der Erzeugung von Commandref auch keine.


Gruß

Damian

[Markus Bloch]

-,- hatte das neue Modul in meinen SVN Developing Ordner geschoben. Jetzt klappts auch. Ich schmeiß gleich mal eine Waschmaschine an und berichte heute Abend.

Vielen Dank

Gruß
Markus

[Markus Bloch]

Hi Damian,

schonmal vielen Dank für dein Modul. Funktioniert super.

Code Auswählen Erweitern


define alarm_Waschmaschine THRESHOLD Verbrauch_Waschmaschine:current:0.02 |{Log 2,"Waschmaschine läuft"}|{Log 2,"Waschmaschine fertig"}


Und auch genau richtig im Log:

Code Auswählen Erweitern


2013.02.17 15:41:06 2: Waschmaschine läuft
2013.02.17 17:02:08 3: Watchdog watchdog_Anwesenheit triggered
2013.02.17 17:02:08 2: CUL_HM set LED_Kueche off rxt:1
2013.02.17 17:02:08 2: CUL_HM set Licht_Bad off rxt:1
2013.02.17 17:02:08 2: CUL_HM set Licht_Kueche off rxt:1
2013.02.17 17:02:08 2: CUL_HM set Licht_Schlafzimmer off rxt:1
2013.02.17 17:02:08 2: CUL_HM set Licht_Wohnzimmer off rxt:1
2013.02.17 17:02:08 2: CUL_HM set TV_Steckdose off rxt:1
2013.02.17 17:02:09 2: CUL_HM set LED_Kueche 0 rxt:1
2013.02.17 17:08:53 2: CUL_HM set Jalousie_Wohnzimmer off rxt:1
2013.02.17 17:08:53 2: CUL_HM set Jalousie_Schlafzimmer off rxt:1
2013.02.17 17:08:53 2: dummy set Status_Jalousie_Automatik -1
2013.02.17 17:16:06 2: Waschmaschine fertig


Ich hätte da lediglich nur ein paar Schönheitspunkte, die ich noch ändern würde.

- sobald ein THRESHOLD Objekt definiert wurde, sollte es im Status "defined" stehen. Damit man weis, das es zwar da ist, aber noch nicht aktiviert ist.

- sobald man via set <name> desired einen Wert vorgegeben hat, sollte das Objekt im Status "active" sein, damit man weis, dass das Teil arbeitet

- sobald man via Attribut "disable" ein Objekt deaktiviert, sollte der Status "disabled" sein. (siehe dazu AttrFn bei der Initialisierung um sowas sofort zu verarbeiten).

- im Reading "state" würde ich nicht das Kommando hinterlegen was gerade ausgeführt wurde, sondern eine Bezeichnung für das Kommand (z.B. "cmd_max_executed", "cmd_min_executed"). Je nach User kann dieses Kommando ellenlang sein und mit allen möglichen HTML Fallen gespickt sein.


Ansonsten Top, auch wenn ich es gerne vermeiden würde, dass man erst einen set-Befehl absetzen muss, um das ganze anzuschalten. Dadurch kann man gerne mal bei einem Neustart ohne Statefile ein stehendes Device haben.

Ich hatte angenommen, das der Parameter "threshold" eine Grenze darstellt, die je nach dem ob sie unter oder überschritten wird via Kommando getriggert wird (was ja in deinem Fall aber erst durch ein Set-Befehl gegeben wird).

Evtl. kann man so etwas noch einbauen.

Viele Grüße

Markus

[Markus Bloch]

evtl. kann man ja die Definition folgendermaßen ändern:

define <name> THRESHOLD <sensor>[:<reading>[:<threshold>[:<initial-desired-value>]]] [AND|OR <sensor2>[:<reading2>][:<state>]] <actor>[:<cmd_max>][:<cmd_min>][:<cmd_default>]

Würde ich persönlich zumindest begrüßen, da so der Threshold sofort mit dem Wert arbeiten würde. Währe evtl. auch für eine Heizung/Entfeuchter nicht uninteressant, denn auch der soll nach einem evtl. Neustart sofort wieder arbeiten, auch wenn mal das State-File nicht funktioniert (hatte schon paar mal diese Situation).

Viele Grüße

Markus

[Damian]

Code Auswählen Erweitern


- sobald ein THRESHOLD Objekt definiert wurde, sollte es im Status "defined" stehen. Damit man weis, das es zwar da ist, aber noch nicht aktiviert ist.


Ich hatte zu erst initialisiert drin stehen gehabt. Das hatte zur Folge, dass ein Neustart  von FHEM dazu führte, dass der letzte Status überschrieben wurde.

Code Auswählen Erweitern


- sobald man via set <name> desired einen Wert vorgegeben hat, sollte das Objekt im Status "active" sein, damit man weis, dass das Teil arbeitet


War vorher auch so ähnlich, fand aber diese Information nicht so Aussagekräftig wie die aktuell gesetzte Temperatur (siehe Screenshot unten).

Code Auswählen Erweitern


- sobald man via Attribut "disable" ein Objekt deaktiviert, sollte der Status "disabled" sein. (siehe dazu AttrFn bei der Initialisierung um sowas sofort zu verarbeiten).


Hatte ich auch überlegt, das hat aber zur Folge, dass durch das Löschen des Attibutes (um es wieder zu aktivieren) der vorheriger Zustand und damit der aktive, z. B.  desired 20, nicht mehr sichtbar wäre.

Code Auswählen Erweitern


- im Reading "state" würde ich nicht das Kommando hinterlegen was gerade ausgeführt wurde, sondern eine Bezeichnung für das Kommand (z.B. "cmd_max_executed", "cmd_min_executed"). Je nach User kann dieses Kommando ellenlang sein und mit allen möglichen HTML Fallen gespickt sein.


Z. Zt. Vergleiche ich diese Readings, um unnötiges Schalten zu verhindern. Z. B. ist defaultmäßig cmd_max und cmd_default "set Aktor on". Wenn also zuerst cmd_default ausgeführt wurde, wird danach nicht mehr cmd_max ausgeführt, weil beides "set Aktor on" ist. Wenn ich die Kommandonamen dort ablegen würde, würde ich unnötig in solchen Fällen "set Aktor on" ausführen, weil "cmd_dafault" ungleich "cmd_max" ist.

(siehe Anhang / see attachement)
Gruß

Damian

[Damian]

evtl. kann man ja die Definition folgendermaßen ändern:

define <name> THRESHOLD <sensor>[:<reading>[:<threshold>[:<initial-desired-value>]]] [AND|OR <sensor2>[:<reading2>][:<state>]] <actor>[:<cmd_max>][:<cmd_min>][:<cmd_default>]

Würde ich persönlich zumindest begrüßen, da so der Threshold sofort mit dem Wert arbeiten würde. Währe evtl. auch für eine Heizung/Entfeuchter nicht uninteressant, denn auch der soll nach einem evtl. Neustart sofort wieder arbeiten, auch wenn mal das State-File nicht funktioniert (hatte schon paar mal diese Situation).

Viele Grüße

Markus

Ist durchaus sinnvoll und lässt sich leicht realisieren.

Gruß

Damian

[Markus Bloch]

Hatte ich auch überlegt, das hat aber zur Folge, dass durch das Löschen des Attibutes (um es wieder zu aktivieren) der vorheriger Zustand und damit der aktive, z. B. desired 20, nicht mehr sichtbar wäre.

Mach dir doch einfach eine Hilfsvariable unter $hash->{helper}{XXXX....}. Dort kannst alles mögliche hinterlegen, ohne das es der user sieht. Erst mit einem "list <device>" sieht man die internen Variablen. Da kannst du temporär den letzten Zustand speichern und beim entfernen des disable-Attributs oder beim setzten auf 0 den letzten Status wieder direkt setzen.

Z. Zt. Vergleiche ich diese Readings, um unnötiges Schalten zu verhindern. Z. B. ist defaultmäßig cmd_max und cmd_default "set Aktor on". Wenn also zuerst cmd_default ausgeführt wurde, wird danach nicht mehr cmd_max ausgeführt, weil beides "set Aktor on" ist. Wenn ich die Kommandonamen dort ablegen würde, würde ich unnötig in solchen Fällen "set Aktor on" ausführen, weil "cmd_dafault" ungleich "cmd_max" ist.

Mach dir auch hier eine Hilfsvariable unter $hash->{helper}. FHEM Kommandos habe generell nix in den Readings zu suchen.

Generell währe es aber nicht verkehrt, "mit set <name> desired XX" ein Reading "desired" zu setzen. Dieses wird auch im State-File gehalten und du hättest keine Probleme mit State-Änderungen.

Und du solltest auf jedenfall die Reading-Functions verwenden um Readings zu setzen (readingsBeginUpdate, readingsBulkUpdate, readingsEndUpdate, readingsSingleUpdate).

Viele Grüße

Markus

[Damian]

Hatte ich auch überlegt, das hat aber zur Folge, dass durch das Löschen des Attibutes (um es wieder zu aktivieren) der vorheriger Zustand und damit der aktive, z. B. desired 20, nicht mehr sichtbar wäre.

Mach dir doch einfach eine Hilfsvariable unter $hash->{helper}{XXXX....}. Dort kannst alles mögliche hinterlegen, ohne das es der user sieht. Erst mit einem "list <device>" sieht man die internen Variablen. Da kannst du temporär den letzten Zustand speichern und beim entfernen des disable-Attributs oder beim setzten auf 0 den letzten Status wieder direkt setzen.

Z. Zt. Vergleiche ich diese Readings, um unnötiges Schalten zu verhindern. Z. B. ist defaultmäßig cmd_max und cmd_default "set Aktor on". Wenn also zuerst cmd_default ausgeführt wurde, wird danach nicht mehr cmd_max ausgeführt, weil beides "set Aktor on" ist. Wenn ich die Kommandonamen dort ablegen würde, würde ich unnötig in solchen Fällen "set Aktor on" ausführen, weil "cmd_dafault" ungleich "cmd_max" ist.

Mach dir auch hier eine Hilfsvariable unter $hash->{helper}. FHEM Kommandos habe generell nix in den Readings zu suchen.

Generell währe es aber nicht verkehrt, "mit set <name> desired XX" ein Reading "desired" zu setzen. Dieses wird auch im State-File gehalten und du hättest keine Probleme mit State-Änderungen.

Und du solltest auf jedenfall die Reading-Functions verwenden um Readings zu setzen (readingsBeginUpdate, readingsBulkUpdate, readingsEndUpdate, readingsSingleUpdate).

Viele Grüße

Markus

Die Sache mit den helper-Variablen kannte ich noch nicht. Das macht die Sache natürlich einfacher. Den Reading desired kann ich wieder einbauen, den hatte ich rausgenommen, weil mir die Sache mit Reading max und Reading min intuitiver vorkam, als das Reading delta und desired in der vorherigen Version.

Gruß

Damian

[allp]

Hallo Damian,

Erstmal ein großes Lob! Das THRESHOLD Modul ist genau das was ich für meine Fußbodenheizung schon lange gesucht habe!

Ich bin ein Anfänger was fhem angeht, habe mich aber in den letzten tagen gründlich eingelesen, unter anderem auch deine Beiträge. Fhem läuft bereits auf meiner fritzbox und die Sensoren/Aktoren werde ich mit Sicherheit ohne Probleme einbinden können.  
Bis jetzt habe ich noch keine Komponenten gekauft da ich mich nicht wirklich entscheiden kann.
Ich würde 1-wire Sensoren  für die temperaturerfassung bevorzugen, nur wohne ich zurzeit in einer Mietwohnung und hab nicht die Möglichkeit (versteckte) Leitungen zu legen (oder vielleicht doch? Wie hast du das gelöst?).  
Sonst bleibt ja nur der Funk. Da kann ich mich aber nicht wirklich entscheiden. Homematic oder Fs20.
Tendiere mehr zu homematic wegen der Rückmeldung der Geräte und somit die Sicherheit! Oder brauche ich es bei fhem nicht (sprich diese Funktion wird von fhem gewährleistet).
Hoffe du kannst mir bei meinem vorhaben weiterhelfen ;)

[Damian]

Hallo Damian,

Erstmal ein großes Lob! Das THRESHOLD Modul ist genau das was ich für meine Fußbodenheizung schon lange gesucht habe!

Danke.
Wir haben auch Fußbodenheizung mit 230V Stellantrieben. Ich habe auch lange überlegt, wie ich die Sache in FHEM einbinden kann.
Die ganzen Lösungen, wie FHT, MAX oder ähnliches sind zunächst für konventionelle Heizkörper gedacht.
Da wir nur Fußbodenheizung haben, gibt´s direkt die richtige Vorlauftemperatur von der Therme. Mischer brauche ich nicht.

Die Steuerung beschränkt sich auf ein einfaches Öffnen und Schließen der 230V Stellantriebe, was bei reiner Fußbodenheizung auch üblich ist. Da FB ja sowieso sehr träge ist, macht eine PID-Steuerung wenig Sinn.

Was bei uns über digitale Raumthermostate 14 Jahre lang gut funktionierte, sollte nun auf FHEM umgestellt werden.

Zuerst habe ich das PID-Modul auf einfaches on/off-Schalten erweitert. Danach habe ich das separate Modul THRESHOLD erstellt. Die Vorgeschichte, kennst du ja schon aus dem Thred.

Nun zu meiner Lösung:

Wie du aus dem obigen Screenshot erkennen kannst, entnehme ich die Temperaturen über 1-Wire Sensoren. Kosten ca. 1 € pro Stück. Voraussetzung ist, dass man rechtzeitig Kabel gelegt hat.

Wenn man keine Kabel hat, bieten sich die S300TH-Sensoren für 15 € pro Stück an. Die kann man mit einem CUL 868 empfangen. Die produzieren natürlich Funkverkehr. Bei meinen 10 Tempsensoren, wäre die Funklast schon nicht unerheblich.

Die alten Raumthermostate habe ich einfach gegen HM-Schalter ausgetauscht, die werden dann über das THRESHOLD Modul einzeln angesteuert. Da es einfache Schalter sind, kann man die auch manuell schalten und damit die Automatik bis zum nächsten Schaltzeitpunkt übersteuern. HM ist natürlich zuverlässiger als FS20, allerdings auch teurer. Auch die ganze Therme kann ich mittlerweile über FHEM ein und ausschalten.

Seit gestern habe ich auch die ultimative Sparautomatik, die sich relativ einfach über FHEM realisieren ließ.

Ich habe meine HM-Schalter von allen Zimmern zu einer Gruppe über structure zusammen gefasst. Und dann einfach ein notify zum Schalten der Therme auf diese Structure definiert.

Das Ergebnis ist, dass nun die ganze Therme ausgeschaltet wird, sobald alle Stellantriebe geschlossen sind und wieder eingeschaltet wird, sobald ein Stellantrieb (HM-Schalter) über das THRESHOLD-Modul geöffnet wird.

Da meine Therme nur auf 10 KW runter modulieren kann, hat sie in der Vergangenheit immer getaktet (an-/ausgeschaltet) hauptsächlich, wenn die Stellantriebe geschlossen waren, weil der Heizkreislauf dann klein war.
Dieses Problem dürfte nun entschärft sein. Das dürfte den Gasverbrauch reduzieren und die Lebensdauer der Therme erhöhen.

Ich hoffe dir ein paar Anregungen gegeben zu haben.

Gruß

Damian