THRESHOLD Modul und die OR Funktion - evtl. änderbar per Attribut?

Begonnen von fsyy, 02 Dezember 2025, 15:13:10

Vorheriges Thema - Nächstes Thema

fsyy

Hallo,

wenn ich mit Threshold 2 Sensoren mit OR auslese um ein Gerät zu schalten, dann schaltet das Gerät zwar an wenn einer der Sensoren den Schwellwert erreicht, aber es schaltet nur aus wenn beide Sensoren den Schwellwert erreichen.

Gibt es denn eine Möglichkeit ein richiges OR zu definieren? Es soll quasi als Ausfallsicherheit für die Sensoren dienen. Wenn einer ausfällt dann steuert der andere das ganze weiter.

Da ich keine Developer bin und nicht wirklich Ahnung von der Materie habe, dachte ich es wäre evtl. ein leichtes die OR Funktion per Attribut zu einem vollen OR macht, also egal welcher der Sensoren einen der Schwellwerte erreicht, wird geschaltet.

In meinem Fall wäre das THRESHOLD Modul optimal, da ich dann mit AT bei bestimmten Ereignissen einfach die Hysterese oder die Desired Temperatur anpassen kann.

Also z.B. so: defmod timer.Tag at *{sunrise} set gh.Hygrostat_Temp desired 25;; set gh.Hygrostat_Temp hysteresis 4

Vielen Dank schonmal für den Input.

betateilchen

Um bei Deinem Beispiel zu bleiben:

Sensor 1 meldet 26 Grad
Sensor 2 meldet 20 Grad

Welche Reaktion erwartest Du dann? Wie soll THRESHOLD entscheiden, welcher Wert zu ignorieren ist?

Ich würde das einfach in einem notify lösen, das auf die beiden Sensoren triggert, dort kannst Du eine vergleichende Logik selbst einbauen.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

fsyy

mein Gedanke war, wenn Sensor1 stehen bleibt bei z.B. 23 Grad. Der Threshold sagt aber 25 Grad mit 4 Grad Hysterese. Sensor2 steigt aber weiter bis 25 Grad erreicht sind, dann soll abgeschaltet werden.
Das gleiche Spiel in die andere Richtung.

Das sollte doch einem ausgefallen Thermostat Herr werden. Momentan ist es ja so, das zwar bei Unterschreiten des Schwellwertes einer der Sensoren die Heizung angeschaltet wird, aber wenn dann der obere Schwellwert nur von einem erreicht wird dann schaltet das System nicht ab. Bei Ausfall einer der Sensoren würde dann einfach ewig weitergeheizt.

Das ist so mein Verständnis des THRESHOLD Moduls mit OR.

fsyy

Ich denke der verantworliche Codeschnippsel ist der hier:

} elsif ($hash->{operator} eq "OR") {
                if (($s_value > $sensor_max) || ($s2_state eq $sensor2_state)) {
                  THRESHOLD_setValue($hash,1);
                } elsif (($s_value < $sensor_min) && ($s2_state ne $sensor2_state)){
                    THRESHOLD_setValue($hash,2);
                  } else {
                      THRESHOLD_setValue($hash,$cmd_default) if (ReadingsVal($pn,"cmd","") eq "wait for next cmd" && $cmd_default != 0);
                    }
              }


Vermutlich würde es reichen wenn man das elsif (($s_value < $sensor_min) && ($s2_state ne $sensor2_state)) in das ändert elsif (($s_value < $sensor_min) || ($s2_state ne $sensor2_state))

Prof. Dr. Peter Henning

Es wäre unverantwortlich, das komplette Verhalten des THRESHOLD-Moduls auf einen Einzelwunsch hin zu ändern - das würde sicherlich die Installationen vieler FHEM-Nutzer zum Schlechten verändern.

Abgesehen davon ist es auch nicht sinnvoll, die Logik wie beschrieben umzubauen - denn die sähe ja im Fall einer Kühlung anders aus, als im Fall einer Heizung.

Also bitte selbst einen entsprechenden Handler schreiben. Und auch gleich noch ein Tipp dazu: dieser Handler sollte jeden der beiden Sensoren separat überwachen und ein Attribut setzen, das den "Gesundheitszustand" des Sensors angibt.

LG

pah


fsyy

Da stimme ich zu, deshalb fragte ich auch nach dem Attribut oder ähnlichem. Man könnte das Modul Default lassen wie es ist, aber wenn das Attribut gesetzt ist dann reagiert OR eben auf Sensor1 oder auf Sensor2.

Damit würde man nichts kaputt machen und man hätte das Modul um eine Funktion erweitert.