Temperatur > (größer) und < (kleiner) abfragen

Begonnen von awe, 28 März 2022, 19:59:33

Vorheriges Thema - Nächstes Thema

awe

Ich möchte einen Temperatursensor (HM-WDS30-OT2-SM, WZ_Kaminofen_T2) so nutzen, dass er bei >37 °C einen Schaltaktor (HM-LC-SW1-PL-DN-R1, KU_Dunstabzug) ausschaltet.

Wenn der Kaminofen nicht mehr heizt und die Temp. unter 30°C fällt, soll der Schaltaktor wieder eingeschaltet werden. Natürlich soll der Aktor nur jeweils einmal geschaltet werden und nicht bei jedem neuen Temp.-Telegramm erneut.

Ich habe es so gelöst und es funktioniert.

Allerdings wurde mir schon zugetragen, dass das nicht effizient sei.

Ich lasse mich gerne eines Besseren belehren, also nur zu, wie geht es besser? Bin neugierig.


define WZ_Kaminofen_heiss notify WZ_Kaminofen_T2:temperature:.* IF ([WZ_Kaminofen_T2:temperature] > 37) ((attr WZ_Kaminofen_heiss disable 1),(attr WZ_Kaminofen_kalt disable 0),(IF ("[KU_Kontakt_Fenster:state]" eq "closed") (set KU_Dunstabzug off) ELSE ()))

define WZ_Kaminofen_kalt notify WZ_Kaminofen_T2:temperature:.* IF ([WZ_Kaminofen_T2:temperature] < 30) ((attr WZ_Kaminofen_kalt disable 1),(attr WZ_Kaminofen_heiss disable 0),(set KU_Dunstabzug on))

define KU_Fenster_zu notify KU_Kontakt_Fenster:closed IF ([WZ_Kaminofen_T2:temperature] > 37) (set KU_Dunstabzug off)

define KU_Fenster_auf notify KU_Kontakt_Fenster:open set KU_Dunstabzug on


betateilchen

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

awe

PID20 kannte ich nicht, hab ich mir durchgelesen.
Aber ich verstehe nicht, wie das gehen soll. 🤷🏼‍♂️

Klingt für mich irgendwie auch viel komplizierter als 2 NOTIFY ;)


Adimarantis

Ich löse sowas immer mit DOIF - da kann man auch komplizierte IF-THEN-ELSE Konstruktionen bauen bzw. durch Einbettung von Perl code auch verschachteln - und das alles in einer Device.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU)/RfxTrx433XL/Zigbee
Module: 50_Signalbot, 48_HomeConnect, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Beta-User

#4
Zitat von: betateilchen am 28 März 2022, 20:04:20
Alternative: das Modul 98_PID20.pm
Würde mich auch interessieren, wie diese Aufgabenstellung damit gelöst werden könnte.

Mein Ansatz wäre ein einziges notify, das sowohl durch den Temp-Sensor wie die Fenster getriggert wird und dann prüft, ob der Aktor geschaltet werden muss.

Ungetestet (RAW-Format für das "grüne Plus"):
defmod WZ_Kaminofen_all notify WZ_Kaminofen_T2:temperature:.*|KU_Kontakt_Fenster:closed|KU_Kontakt_Fenster:open {\
my $is = ReadingsVal('KU_Dunstabzug','state','on') eq 'on';;\
my $temp = ReadingsNum('WZ_Kaminofen_T2','temperature', 100);;\
if ( ReadingsVal('KU_Kontakt_Fenster','state','closed') eq 'closed' && $is && $temp > 37 ) {\
  return fhem('set KU_Dunstabzug off');;\
} elsif ( !$is && ( ReadingsVal('KU_Kontakt_Fenster','state','closed') eq 'open' || $temp < 30 ) ) {\
  return fhem('set KU_Dunstabzug on');;\
}\
return;;\
}

DOIF ist mir zu kompliziert, und diese Klammer-Orgien da drin (und bei FHEM-IF) gefallen mir auch nicht...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Thyraz

Ja, würde sowas auch über ein einzelnes Notify lösen wie Beta-User.
Ein Notify muss ja nicht zwingend nur durch ein Event triggerbar sein.

DOIF spielt seine Stärken aus, wenn man zwischen mehreren Zuständen wechseln will.
Es stellt mit seinen verschiedenen Zweigen per Default (ohne Attribut do -> always) ja eine StateMachine dar.

Will/Braucht man das nicht, dürfte Notify oft die passendere Lösung sein.

Erst neulich bin ich wieder über ein "komisches" Verhalten bei DOIF gestolpert,
welches bei der Nutzung der einzelnen Zweige als If/Else zu unerwartetem Verhalten führen kann.

DOIF wertet bei mehreren Events die per Block und nicht einzeln nacheinander gefeuert werden nur einmal aus.
Notify wird hingegen nacheinander für jedes einzelne Event getrennt ausgeführt.

Da man als Nutzer ohne tieferen Einblick in den Quellcode der Module oft nicht weiß, welche Readings einzeln oder als Block aktualisiert werden,
kann kann hier durchaus überrascht werden. ;)

Man müsste also bei DOIF
- auch nur einen Zweig verwenden
- die verschiedenen Events aus dem Eventblock über die Variable $EVENTS holen
- über diese Events loopen
- dann jeweils ausführen was nötig ist

Da dürfte das Notify aber einfacher ausfallen.

Hintergrunddiskussion zu diesem Problem hier:
https://forum.fhem.de/index.php/topic,68892.msg1197644.html#msg1197644


Fhem und MariaDB auf NUC6i5SYH in Proxmox Container (Ubuntu)
Zwave, Conbee II, Hue, Harmony, Solo4k, LaMetric, Echo, Sonos, Roborock S5, Nuki, Prusa Mini, Doorbird, ...

Damian

Zitat von: Thyraz am 29 März 2022, 13:48:35
Man müsste also bei DOIF
- auch nur einen Zweig verwenden
- die verschiedenen Events aus dem Eventblock über die Variable $EVENTS holen
- über diese Events loopen
- dann jeweils ausführen was nötig ist

Da dürfte das Notify aber einfacher ausfallen.

Das glaube ich nicht. Erstens können hier keine Events im gleichen Eventblock kommen, zweites würde ein DOIF trotzdem korrekt funktionieren, denn wenn das eine Event zuschlägt wird vom anderen der aktuelle Zustand ausgelesen:

DOIF ([KU_Kontakt_Fenste:state] eq "closed" and [WZ_Kaminofen_T2:temperature] > 37) 
  (set KU_Dunstabzug off)
DOELSEIF ([KU_Kontakt_Fenste:state] eq "open" or [WZ_Kaminofen_T2:temperature] < 30)
  (set KU_Dunstabzug on)


Was übersichtlicher oder mehr Klammern beinhaltet, kann jeder für sich beurteilen ;)
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Beta-User

#7
In dem Fall glaube ich auch nicht an Probleme aus "bulk"-Events, allerdings bin ich mir nicht sicher, ob die default-Wert-Setzung und Auswertung in diesem speziellen Fall aus Sicherheitsgründen nicht sinnvoll wäre: https://forum.fhem.de/index.php/topic,126999.0.html

Und bei DOIF blicke ich halt nicht durch, was warum wann genau passiert und notiere eben lieber schlicht "im Ablauf", was ich genau haben will. Da ist auch von der Effizienz her vermutlich kaum "Luft nach oben"...
Diese Sichtweise muss man nicht teilen ;) , und bestimmt kann man die defaults auch in der "DOIF-magic"-Schreibweise irgendwie reinknödeln :) .

Und der Fall, dass jemand den Aktor willentlich (z.B. per Taster) angeschaltet hat, ist in dem DOIF übrigens auch nicht (irgendwann mit) abgefangen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

betateilchen

Zitat von: Beta-User am 29 März 2022, 07:41:52
Würde mich auch interessieren, wie diese Aufgabenstellung damit gelöst werden könnte.

Mein Ansatz wäre ein einziges notify, das sowohl durch den Temp-Sensor wie die Fenster getriggert wird

Naja, wenn ich mir die beschriebene Aufgabenstellung anschaue, fallen mir zwei Dinge auf:

Zitat von: awe am 28 März 2022, 19:59:33
Ich möchte einen Temperatursensor (HM-WDS30-OT2-SM, WZ_Kaminofen_T2) so nutzen, dass er bei >37 °C einen Schaltaktor (HM-LC-SW1-PL-DN-R1, KU_Dunstabzug) ausschaltet.

Wenn der Kaminofen nicht mehr heizt und die Temp. unter 30°C fällt, soll der Schaltaktor wieder eingeschaltet werden.


  • Ein-/Ausschalten anhand von zwei Messwerten ist eine typische Aufgabe, die sich mit einem PID lösen lässt. Ob der PID nun eine Fußbodenheizung steuert oder eine Lüftung, ist dem Regler grundsätzlich erstmal egal.
  • Von Fenstern ist in der Aufgabenbeschreibung nicht die Rede.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Beta-User

Ja, das mit den Fenstern erschließt sich nur, wenn man entweder den Ausgangsthread bereits kennt oder sich die Frage stellt, was die weiteren gezeigten Fenster-notify eigentlich sollen.

Sonst wäre auch ein THRESHOLD in Frage gekommen.

Aber nachdem die Aufgabenstellung nochmal in "Klartext" wiederholt wurde: Es handelt sich ja um zwei Homematic-classic-Geräte. Da könnte man das auch mit einem virtuellen Kanal für den Temperatur-"Peer" lösen, oder?
(Oder ein "combine"-Gerät anlegen und was vergleichbares in Software abbilden)

*duck-und-weg*
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors