Neues Modul - THRESHOLD

[Damian]

Da fällt mir noch ein, dass ein von außen Abgesetztes "set TH_Name active" oder "set TH_Name desired Wert" das Modul initialisiert. Dann steht im Reading "cmd" "wait for next command" und führt bewusst beim nächsten Event zum Ausführen des entsprechenden Kommandos. Das würde dieses Verhalten erklären.

Gruß

Damian

[det.]

Hallo Damian,
das passiert leider bei jedem Thermometerabruf egal wie INTERVALL eingestellt ist (bei 5 - Mail aller 5s bei 30 - aller halben Minute).
Meine Testdefinition:

Code Auswählen Erweitern

define Temp_Alarm THRESHOLD OWX_28_F213DD030000:temperature:5:28 |{DebianMail('mail@test.de','Temperatur ueberschritten','Temperatur  ueberschritten aktuelle Temperatur '.ReadingsVal("OWX_28_F213DD030000", "temperature", "0") .' Grad');;}|{DebianMail('mail@test.de','Temperatur unterschritten','Temperatur unterschritten aktuelle Temperatur '.ReadingsVal("OWX_28_F213DD030000", "temperature", "0") .' Grad');;}|
(siehe Anhang / see attachement)
Auch ein Verändern der Hysterese oder setzen der desired Temp über das Web Interface ändert daran nichts. - sorry -

[Damian]

Es müsste nach dem Ausführen des Kommandos im "cmd"-Reading cmd1 oder cmd2 stehen, bei dir steht aber noch "wait for next cmd". Das bedeutet normalerweise, dass kein Kommando bisher ausgeführt wurde. Eine dumme Frage: Du hast nicht noch irgendwo ein notify mit der E-Mail laufen;)?

Ich habe bei mir Folgendes getestet:

define TH_Test THRESHOLD T_Dachgeschoss:temperature:0:20 |{Log 2,"Wert überschritten"}|{Log 2,"Wert unterschritten"}|

Es es funktioniert, wie programmiert.

Es wird nur einmalig ein Log ausgegeben.

Mit DebianMail kann ich es nicht testen, da ich einen Windowsrechner habe - wo möglich hängt es damit zusammen.

Mach mal ein List Temp_Alarm. Was steht unter actor_cmd1 bzw. actor_cmd2?

Und probier mal, ob die einfache Definition mit Log-Ausgaben von oben bei dir funktioniert.

Gruß

Damian
 

[Damian]

Ich habe im Code mir die Stelle noch mal angeschaut:

  if ($ret = AnalyzeCommandChain(undef, $cmd_now)) {Log GetLogLevel($pn,3), "output of $pn $cmd_now: $ret";return "";

Schau mal, ob du die Fehlermeldung im Log findest.

Das würde bedeuten, dass AnalyzeCommandChain einen Fehlercode liefert, deine Mail aber dennoch ausgeführt wurde.

Gruß

Damian

[Damian]

Aus deinem Log in der PM sehe ich, dass der Fehlercode 68 zu dem Problem führt.
Womöglich wird er direkt von DebianMail geliefert - das musst du jetzt selbst herausfinden.
Versuche erst mal eine ganz einfache Mail z. B. DebianMail(mail@test.de' (mail@test.de'),"Test").
Solange ein Fehlercode ungleich 0 kommt, wird es eine Fehlermeldung im Log geben und die Sache wird nicht funktionieren, denn nur fehlerfreie Kommandos führen zu Änderung des Status von cmd und damit zu keiner Wiederholung.

Gruß

Damian

[det.]

Hallo Damian,

Dein Beispiel mit LOG Ausgabe funktioniert auch bei mir wie gewünscht - d.h. es schaltet zwischen cmd1 und cmd2 um und meldet nur jeweils einmal die Zustandsänderung. Liegt also doch irgendwie an der Mailgeschichte.... dabei wäre gerade Dein Modul genau die Lösung, eine Fehlfunktion von Kühlschrank oder Gefriertruhe zu überwachen und nur eine Mail abzusenden, wenn die Dinger zu warm geworden sind (z.B. Tür zu lange offen) und danach wieder im richtigen Temperaturbereich arbeiten.

[Damian]

Probier noch mal eine einfache Mail, wie oben beschrieben. Ansonsten nochmal in DebianMail schauen warum Fehlercode 68 kommt.

Zukünftig werde ich im THRESHOLD-Modul anpassen, dass der Zustand trotz Fehlercode geändert wird, damit es nicht zur Wiederholung kommt.

Gruß

Damian

[Damian]

Das Problem ist, dass die Routine DebianMail keinen definierten Returnwert zurück gibt.

Die Lösung des Problems ist, am Ende der Routine (hier: DebianMail) ein Return ""; einzubauen. Damit wird ein definierte Returncode zurück gemeldet und die Sache funktioniert, wie programmiert.

hier der angepasste Code aus dem Wiki:

sub
DebianMail
{
my $rcpt = shift;
my $subject = shift;
my $text = shift;
my $ret = "";
my $sender = "absender\@account.de";
my $konto = "kontoname\@account.de";
my $passwrd = "passwrd";
my $provider = "smtp.provider.de";
Log 1, "sendEmail RCP: $rcpt";
Log 1, "sendEmail Subject: $subject";
Log 1, "sendEmail Text: $text";

$ret .= qx(sendEmail -f '$sender' -t '$rcpt' -u '$subject' -m '$text' -s '$provider' -xu '$konto' -xp '$passwrd' -o tls=no);
$ret =~ s,[\r\n]*,,g; # remove CR from return-string
Log 1, "sendEmail returned: $ret";
return "";
}

Gruß

Damian

[cwagner]

Moin, Damian,

hier melde ich mich mal wieder, da ich mit inzwischen 8, sehr unterschiedlich eingesetzten Threshold-Modulen vom Anfang an inzwischen eine solide Begeisterung für dieses Modul entwickelt habe.

Bis dahin gab es natürlich auch Klippen:
1. Wer von Anfang an dabei war, kannte die Notation mit ":" als Trenner von Optionen. Mit der ersten größeren Überarbeitung wurde "|" eingeführt, die alten Notationen funktionierten in einfachen Thermostaten (also ohne Befehlsketten, Perl-Einsprengseln) auch weiterhin. Doch es gab Zickereien und meine Empfehlung heute ist, alle Threshold-Module auf die in der Doku gezeigten Schreibweise anzupassen.
2. Wenn in Befehlsketten das ";" benötigt wird, sollte man es aktuell m.E. in CF-Dateiengrundsätzlich maskieren (also verdoppeln). Das tut das "modify" in der Web-Oberfläche nämlich auch(zu dem Thema gibt es einen eigenen Thread)
3. Was ich recht mühsam lernen musste, dass Leerzeichen vor einem "|" Ärger machen (können).
4. Sehr hilfreich ist der jüngste Hinweis von Dir, Damian, das nicht fehlerfrei ausgeführte Kommandos wiederholt werden (ein vorausgehender Beitrag in diesem Thread). Da ist es mir wie Schuppen von den Augen gefallen - falls es also nicht gelingt, dieses Verhalten zu ändern, wäre m.E. ein Hinweis in der Doku ganz wichtig.
5. Man muss vor allem bei Verkettung von mehreren Threshold-Modulen mit wechselseitiger Abhängigkeit (z.B. über deaktivieren/aktivieren oder ändern der Schwellwerte) immer berücksichtigen, dass bis zur nächsten Auslösung des Schwellwertes durch den Sensor das Modul im Status "wait for next cmd stehen" bleibt. In Verbindung mit Strom- und Sendeleistung sparenden Einstellungen beim Sensor (Status-Änderung nur, wenn Reading wirklich geändert), kann das dann recht lange dauern.
6. Von Damian erhielt ich den extrem hilfreichen Hinweis, wie ich bei Verwendung eines Sliders, um verschiedene Schwellwerte vorzugeben, den zuletzt eingegebenen Schwellwert auch über einen restart / rereadcfg hinaus "retten" kann. In der Konfiguration wird dann kein Initialwert (desired temp) eingetragen, mit dem Slider wähle ich die aktuell gewünschte Thermostat-Einstellung und mache ein save config. Nun ist der manuell gewählte Wert auch "scharf", wenn ich neustarte. Das fände ich auch in der Doku nützlich.

Aus meiner Praxis habe ich noch ein Feature-Vorschlag:
Es gibt für mich immer mal wieder die Situation, wo Mensch die schlauesten Konfigurationen übersteuern sollte. Also: Threshold soll zwei Aktoren schalten beim Über- oder Unterschreiten eines bestimmten Sensorwertes (bei mir meist Temperatur oder Feuchtigkeit, ich werde noch mit Licht und Windgeschwindigkeit experimentieren). Jetzt geht Mensch oder ein anderer Prozess also hin, und schaltet die beiden Aktoren (was für den Menschen schon mal mehrere Klicks sind). threshold weiß davon nichts und bleibt bis zur nächsten Über/Unterschreitung des Threshold brav noch im aktuellen Status, sagen wir cmd1.
Ich fände es sinniger, wenn Threshold die Möglichkeit böte, über z.B. ein webcmd zwischen cmd 1 und cmd 2 zu wechseln (toggle bzw. konkret an/aus zu schalten). Dies sollte für programmgesteuerte Aktionen ein "set" sein. Damit wäre cmd in Threshold kongruent zu seinen Aktoren und beim nächsten Über/Unterschreiten des Schwellwertes (bei Hysterese 0) oder der beiden Schwellwerte (bei Hysterese ungleich 0) würde Theshold wieder schalten.
In einem Web-Interface wäre leicht einzugreifen und zugleich auch immer eine stimmige Zustandsanzeige.


Grüße

Christian
 

[Damian]

Hallo Christian,

schön, dass dir das Modul das Leben etwas erleichtert.

Ich finde, dass in FHEM noch viel zu wenig "modular" vorgegangen wird. Es werden oft für eine bestimmte Steuerung viele notifys und at-Befehle kombiniert mit if-Abfragen benutzt, die dann gleich auch noch ein paar andere Steuerungen übernehmen. Das mag bei einigen wenigen Steuerung noch gut funktionieren, aber irgendwann durchblickt man sein eigenes System nicht mehr - so geht es mir zumindest und sehe hier im Forum immer wieder diese Vorgehensweise. Es erinnert mich ein wenig an die achtziger Jahre, wo ich in Basic mit gotos rum hantiert hatte. Immerhin gibt es schon sehr viele Module, die bestimmte Aufgaben übernehmen und es werden immer mehr - ich habe deshalb die Hoffnung noch nicht aufgegeben, irgendwann ohne notifys und at-Befehle auszukommen.

Nun zu deinen Anmerkungen:

Punkt 1 bis 6 lässt sich sicherlich in der Doku aufnehmen.

Ich werde, wie ich schon geschrieben habe, zukünftig den Status trotz eines Fehlercode ändern, damit keine Wiederholungen stattfinden.

Ich weiß nicht, ob ich deinen Wunsch richtig verstanden habe?

Du möchtest also z. B. ein set TH_Name cmd1 oder set TH_Name cmd2 haben, das das entsprechende Kommando bis zum nächsten automatischen Schalten übersteuert.

Der einziger Vorteil, den ich jetzt auf Anhieb sehe, ist, dass du in den Readings des THRESHOLD-Moduls bei cmd den tatsächlichen Status siehst bzw. beim Status des THRESHOLD-Moduls selbst, wenn du es in der Definition des Moduls so definiert hast, dass anstatt "active Wert" ein bestimmter Status für cmd1 bzw. cmd2 angezeigt wird (war meine letzte Änderung in dem Modul). OK, wenn man sich auf diesen Status in anderen Modulen bezieht, dann würde es Sinn machen. So etwas lässt sich, so wie ich es auf die Schnelle sehe, leicht einbauen.

Ich möchte, sobald ich etwas mehr Zeit habe, für´s nächste Update noch folgende Funktionen einbauen:

-Unterstützung eines zweiten Readings, der genauso wie der erste Dezimalwerte liefert. Damit könnte man z. B. Umwälz- oder Zirkulationspumpen  steuern, in dem man die Differenz zwischen Vor- und Rücklauftemperatur als Hysterese auswertet.

-Direkte Unterstützung von diversen Wand-Thermostaten, wie FHT, HomeMatic, Max, usw., dann könnte man sich die lästigen notifys für die Übernahme der Desired-Temperatur aus den Profilen sparen (das war immerhin schon zwei Mal ein Thema in diesem Thread). Dazu gäbe es auch zwei Modi, die man setzen kann für: extern- bzw. FHEM-gesteuert. .

-Variable Definition des Modulstatus mit beliebigem Text und Platzhaltern für "Zustand", "Sollwert", "aktueller Wert", "cmd1", "cmd2".

Das war es dann aber erst mal.

Gruß

Damian

[det.]

Hallo Damian,
Deine Erweiterungspläne klingen verlockend. Gut, das ich meine Zirkulationspumpensteuerung mit geschachteltem Notify Konstrukt noch so gelassen habe wie sie seit langem funktioniert. Da warte ich doch gern auf die Neuerungen in Deinem THRESHOLD Modul. Die Mailbenachrichtigung von Tiefkühler und Kühlschrank funktioniert jetzt dank Deiner Hilfe prima.

[cwagner]

Moin, moin, Damian,

genau die einfachere Struktur macht mich ja zum Liebhaber von nun schon 9 Threshold-Modulen: Sie ersetzen auch bei mir viele Notify- und noch viel mehr meist sehr fragile, geschachtelte If-Konstuktionen. Für mich als Perl- und FHEM-Anfänger waren sie eine dramatische Erleichterung und führten einfach zu schnelleren, stabileren, durchschaubareren Ergebnissen.

Meinen Feature-Vorschlag hast Du genau richtig interpretiert.

Dein Plan mit Differenz-Thermostaten erweitert die Möglichkeit zur Einbindung einer Thermo-Solaranlage mit Heizungsrücklaufanhebung. Hier muss ich ja mehrfach Temperaturdifferenzen nutzen, um logische Entscheidungen zu treffen:
a) soll Pumpe überhaupt fördern: ja, wenn Temperatur im Modul auf dem Dach > entweder Speicher 1 (Warmwasser) (dann Dreiwegeventil in Stellung 1) oder Speicher 2 (dann Dreiwegeventil in Stellung 2 für Speicher Rücklaufanhebung)
b) im Heizbetrieb muss threshold2 den Rücklauf aus den Heizkörpern nun laufend vergleichen, um zu entscheiden, ob der kälter ist als die gespeicherte Sonnenwärme im Rücklaufspeicher (dann Dreiwegeventil2 schalten).
c) Auch unsere kontrollierte Lüftung ist mir mit der Werkssteuerung zu unflexibel, hier böte sich ein weiteres Feld, um je nach Wettersituation und Verhältnissen im Haus den Erdwärmetauscher zum Kühlen zu nutzen oder die Wärme im Haus möglichst festzuhalten. Auch hier sind es eigentlich immer Differenzentscheidungen der Art, wenn draußen mehr als 24 Grad und drinnen größer 22 Grad, dann schalte den Erdwärmetauscher ein, damit die Außenluft durch ihn gekühlt wird und das Haus nicht durch die Lüftung mit warmer (und feuchtigkeitsangereicherter) schleichend immer weiter erhitzt wird. Und wenn das Haus dann in Hitzeperioden immer wärmer wird, kann man durch verstärkte Lüftung mit der nachtkalten Luft gegenhalten.

Auch eine kompliziertere Verkettung zweier Thresholds zum Steuern der Warmwassernachheizung durch die Heizung, wenn die winterliche Sonne nicht reicht, mit der Solarthermie ausreichend Warmwasser zu machen, wäre mit Deiner Differenz-Idee vermutlich deutlich zu entschlacken.

Kurz: Da freu ich mich auf neue Chancen, das System schlank und damit für jemanden, der immer nur punktuell sich drum kümmern kann, wartbar zu halten. Das hatte mich ja ganz lange davon abgehalten, mich in ein Abenteuer wie FHEM zu stürzen.

Herzliche Grüße

Christian

[Damian]

Hallo zusammen,

die kalte Zeit ist schon lange vorbei und nun kämpfen wir mit der Hitze.

In diesem Zusammenhang wollte ich endlich meine Rollläden, die sich schon länger abends und morgens automatisch rauf- und runterfahren auch als Schutz vor der Hitze einsetzen.

Was lag da näher als eine Routine dafür zu programmieren. Die Routine wurde in 99_Utils schnell erstellt. Sie war zeitgesteuert, außentemperatur-, innentemperatur- und sonneneinstrahlung-abhängig programmiert und funktionierte zunächst auch. Getrigger wurde die Sache über ein notify des Außentemperatursensors. Was mir jedoch nicht gefiel war, dass das manuelle Übersteuern des Rollladen fünf Minuten später wieder zunichte gemacht wurde, als meine Routine wieder getriggert wurde. Also dachte ich mir, ich müsste mir den letzten Zustand merken und nicht den des Rollos auswerten. Ich war kurz davor mir ein neues Modul zu programmieren, allerdings hatte ich doch da schon was programmiert:

Wenn man Beschattung vor der Hitze als indirekte "Kühlung" betrachtet, dann lässt sich so etwas mit THRESHOLD und Heating_Control wie folgt realisieren:
 

Code Auswählen Erweitern

define TH_R_Keller THRESHOLD T_Keller AND Sonne:state:on R_Keller|set @ 30||2

define HC_R_Keller Heating_Control TH_R_Keller 12:00|20 20:00|30  set @ desired %


Zur Bedeutung:

T_Keller ist Temperaturfühler im Keller, R_Keller der Rollladen und Sonne ein Sonnenschein-Fühler.

Zwischen 12:00 und 20:00 Uhr (potenzielle Sonnengefahr auf der Südseite) wird der Rolladen auf 30 % herunter gefahren, wenn die Raumtemperatur über 20 Grad ist und die Sonne scheint. Im Winter, wenn die Zimmertemperatur niedriger ist (< 20), will ich von der Sonnenenergie profitieren und den Rollladen oben lassen.

Ab 20 Uhr wird die Funktionalität mit set TH_R_Keller desired 30 bis zum nächsten Tag um 12:00 Uhr außer Funktion gesetzt (so heiß wird es nämlich nicht in diesem Raum),  bevor die Sonne wieder kommt und der Rollladen wieder auf 30 % gesetzt wird.


Wer auch das automatische Hochfahren bei Bewölkung bzw. nach 20 Uhr wünscht, der kann auch das Kommando zum Hochfahren definieren (in meinem Fall set R_Keller 100).

define TH_R_Keller THRESHOLD T_Keller AND Sonne:state:on R_Keller|set @ 30|set @ 100|2

Mir persönlich ist das allerdings zu viel Automatisation;)

Die restlichen Fenster werden je nach Ausrichtung mit anderen Zeiten und anderer Raumtemperatur definiert.


Gruß

Damian

[Damian]

Hallo zusammen,

noch können wir die heißen Tage des Jahres genießen. Allerdings werden die Temperaturen bald fallen und da kann man schon an die Optimierungen der nächsten Heizperiode denken;)

Ich bin gerade in der Testphase einer neuen Version des Moduls. Diese Version ist abwärtskompatibel zu der bisherigen.

Die Syntax lautet:

Code Auswählen Erweitern

define <name> THRESHOLD <sensor>:<reading>:<hysteresis>:<target_value>:<offset> AND|OR <sensor2>:<reading2>:<state> <actor>|<cmd1_gt>|<cmd2_lt>|<cmd_default_index>|<state_cmd1_gt>:<state_cmd2_lt>|<state_format>

Die Änderungen sind target_value (bisher init_desired), offset und state_format

Wenn bei target_value eine Zahl angegeben wird  - dann entspricht das der bisherigen Angabe mit init_desired.

Alternativ kann bei target_value ein weiterer Sensor <Sensorname>:<reading> angegeben werden, der dann dynamisch den desired-Wert vorgibt.

Mit offset lässt sich die Verschiebung der Grenzen vornehmen und bei state_format lässt sich über Platzhalter das Aussehen des Status anpassen.

Nun ein Beispiel für meine Zirkulationspumpe abhängig vom Warmwasserspeicher:
 
(siehe Anhang / see attachement)

Zur Bedeutung:

Rücklauf der Zirkulation soll fünf Grad unter der Temperatur des Warmwasserspeichers sein und bis zu fünf Grad schwanken können.

Beim Status wurde mit state_format der Zustand (mode) und cmd_status als Ausgabe definiert, Standard ist wie bisher Zustand und desired-Wert.

Der externe Modus (Vorgabe des Sollwertes durch den Sensor) lässt sich durch "set desired value" übersteuern oder durch "set active" einfrieren und durch "set active external" wieder reaktivieren.


Steuerung mit Hilfe eines Wandthermostats sollte nun wie folgt ohne zusätzliche notifys funktionieren:

Code Auswählen Erweitern

define TH_Heizung THRESHOLD WT:measured-temp:1:WT:desired-temp Heizung

WT ist ein Wandthermostat (MAX, HM, oder FHT).

Anregungen zu den vorgesehenen Änderungen bitte hier posten.

Gruß

Damian

[Damian]

Neue Version wurde hochgeladen - ab morgen per Update verfügbar.
Weitere Informationen zu der Version bitte den umfangreichen Änderungen in der Commandref entnehmen.
Bei Problemen bitte hier posten.

Gruß

Damian