Elemente in einem structure per ftui ein-/ausschalten

Begonnen von Superposchi, 20 Oktober 2024, 13:14:55

Vorheriges Thema - Nächstes Thema

Superposchi

Ist es nöglich in einem structure-Device einzelne Devices temporär zu deaktivieren? Am einfachsten per Checkbox und ftui3.

Hintergrund:
Für eine Alarmanlage soll vor dem einschalten (schlafend/abwesend) geprüft werden ob alle Fenster und Türencgeschlossen sind. Aber im Sommer möchte man ja ggf. Nachts bewusst auch mal ein Fenster offen lassen. Dieses müsste also bei der Prüfung (also im structure-Device) ausgeklammert werden.

Geht das?
Oder wie habt ihr so was gelöst?

rabehd

Ich würde das mit verschiedenen Strukturen lösen.
Auch funktionierende Lösungen kann man hinterfragen.

Superposchi

Ist sicherlich eine Möglichkeit, aber bei 6 Fenstern/Türen die einzeln oder in Kombination geöffnet sein könnten dürfte das eine Menge an structur-Devices ergeben.
Oder wie meinst du das genau?

rabehd

#3
Was sollen das für Kombinationen sein?
Es gibt eine Struktur mit allen Fenstern, die bei Abwesenheit geschlossen sein sollen und eine für Schlaf.
Auch funktionierende Lösungen kann man hinterfragen.

Superposchi

Na mal haben wir ein von zwei Schlafzimmerfenstern off, mal beide, mal auch gleichzeitig die Balkontür auf Kipp gehabt oder das Küchenfenster das zum Balkon geht auf Kipp.
Gerade wo es dieses Jahr teilweise so extrem heiß war haben wir Nachts gern gelüftet wenn es wenigstens etwas kühler war.

Also schon verschiedene Kombinationen und nicht nur das Schlafzimmerfenster allein.

rabehd

Du denkst komisch, überlege Dir doch mal Deinen Anwendungsfälle.

Zitat von: Superposchi am 20 Oktober 2024, 13:14:55Für eine Alarmanlage soll vor dem einschalten (schlafend/abwesend)
Das war Deine Anforderung.
Abwesend sollte klar sein.

Schlafend kann auch nur eine bestimmte Menge Fenster zu sein müssen.
Was soll das mit der Kombination? Du möchteste einen Alarm wenn Du schläft und der "Mörder" ein Fenster aufhebelt? Wenn er das gekippte Fenster nimmt, dann kein Alarm?
Mir scheint Deine Definition von Alarm ist das Problem.
Auch funktionierende Lösungen kann man hinterfragen.

Superposchi

#6
Mir ist schon klar das das Wiedersprüche auslöst und man grundsätzlich davon ausgeht, das ein Alarm bei (allen) geschlossenen Fenstern funktioniert.
Ich habe eben nur im letzten Sommer gesehen was wir alles gemacht haben um die Wohnung wenigstens ein bischen abhukühlen. Ich möchte einfach vermeiden, dass ich jedesmal wenn wir was anders machen am Device rumschrauben muss.

Es geht ja nicht nur darum im Schlafzimmer das Fenster offen zu lassen weil man dann besser schläft, sondern ums Kühlen der Wohnung.

Grundsätzliche Frage, kann man im Def eines Device auf ein Reading zurückgreifen?

betateilchen

Zitat von: Superposchi am 20 Oktober 2024, 23:15:37Grundsätzliche Frage, kann man im Def eines Device auf ein Reading zurückgreifen?

Kann man theoretisch, macht aber praktisch wenig bis gar keinen Sinn.

Für Deine Alarmanlagen-Anforderung solltest Du Dich vielleicht einfach mal mit einem passenden Modultyp beschäftigen und nicht mit structure.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Superposchi

Hab ich schon gemacht. Doch alles was dabei rauskam war Mist.

Für meine Bedürfnisse und mein Verständnis viel zu umfangreich und unübersichtlicht.

Ich denke einfach viel sinpler.
Kch nutze für meinen Roborock im ftui Checkboxen um damit per zusammengesetztem Reading einzelne Räume anzusteuern.
Vom Prinzip das selbe, nur das es halt kein Set-Befehl ist sondern ein Def.

Wenn es also geht, wäre das die -für mich - effektivere Lösung.
Also wenn du einen Tip hast nach welchen Begriffen ich suchen soll um das zu realisieren wäre ich dankbar wenn du sie nennen würdest.

rabehd

Für mich ist diese Frage nicht beantwortet: welches Ereignis soll einen Alarm auslösen? Ganz ohne FHEM gedacht.
Erst mit der Antwort geht man an die Umsetzung.
Ständig an der Oberfläche Parameter zu ändern, ist keine Hausautomation.
Auch funktionierende Lösungen kann man hinterfragen.

Superposchi

Im Normalfall soll der Alarm selbstverständlich auslösen wenn eins der Fenster im aktiven Zustand geöffnet wird.

Da ich aber jetzt schon weiß,  dass ich beim Schlafen manchmal das Fenster gekippt lasse oder im Sommer mehrere Fenster zum Durchlüften ganz auflasse möchte ich das eben einkalkulieren. Ich weiß aber eben jetzt nicht wann, welche Fenster und/oder welche Kombinationen das sein werden.

Und um eben nicht ständig an den Parametern ändern zu müssen wäre eine Lösung in der ich jedes Fenster einzeln in der Überwachung ein-/ausschalten kann die Lösung. Andernfalls müsste ich jedesmal in der Oberfläche das structure-Device händisch anpassen und das wäre eine Anpassung der Oberfläche, oder nicht?

MadMax-FHEM

#11
Zitat von: Superposchi am 21 Oktober 2024, 10:03:02Und um eben nicht ständig an den Parametern ändern zu müssen wäre eine Lösung in der ich jedes Fenster einzeln in der Überwachung ein-/ausschalten kann die Lösung. Andernfalls müsste ich jedesmal in der Oberfläche das structure-Device händisch anpassen und das wäre eine Anpassung der Oberfläche, oder nicht?
Pasiert die Auswertung, also ob Alarm per notify? (oder DOIF)

Warum nicht per Oberfläche ein reading im Fenster-Device setzen, z.B.:

setreading Fenster-Device excludeFromAlarm 0/1

Das sollte doch per Oberfläche (FTUI keine Ahnung) gehen, ginge in einer readingsGroup...
Dort dann per klick vor dem Schlafengehen die Fenster "ausknipsen", die nicht zu einem Alarm führen sollen (so habe ich das verstanden)...
...im notify/DOIF oder was auch immer den Alarm auslöst auf das Reading prüfen, ist es da und auf 1 gesetzt, dann führt ein Öffnen bei diesem Fenster zu keinem Alarm.

Vorausgesetzt ich habe vestanden was du willst...
EDIT: ansonsten halt "besser" erklären und auch mal schreiben, wie deine Alarmauslösung passiert...

Alternativ geht nat. auch Attribut (wäre eigentlich "korrekter") aber das ist nach einem Restart ja wieder "auf alt"...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

betateilchen

"Ein Teil dieser Antworten würde die Bevölkerung verunsichern"

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

Superposchi

@MadMax-FHEM
Nun, der auslöser erfolgt per DOIF (bevorzuge ich persönlich gegenüber notify aufgrund der Vielfältigeren Anwendungsmöglichkeiten). Sprich wenn das Gesamt-structure ein open zurück gibt, dann soll das DOIF anschlagen - so die erste überlegung.
Dein Vorschlag wäre entsprechend ohne structure-Device zu arbeiten und dafür im Doif direkt jedes Fenster abzufragen und zu reagieren wenn eins schalten. Und innerhalb des DOif's dann die einzelnen Fenster per untergeordnetem If und einem eigenen Reading im jeweiligen Device ein-/auszuschalten, richtig verstanden?
Die Idee ist interessant und verringert sogar die Menge der benötigten Devices, da das structure ja überflüssig würde.

Ich denke schon das du es richtig verstanden hast. Das mit dem Erklären ist leider nicht so einfach wenn man nicht weiß was für den anderen relevant ist. An den Auslöser hätte ich nämlich jetzt nicht gedacht, da er für mich praktisch feststeht.
Ich muss mir das Morgen mal praktisch anschauen und ausprobieren.

MadMax-FHEM

Gut ich denke zwar über DOIF anders aber ist geschmackssache...

Bei notify könnte es wie folgt sein:
define nFensterAlarm notify Fenster_.*:opened {myFensterAlarm($NAME)}

Angenommen alle Fenster heißen "Fenster_IRGENDWAS", ansonsten halt anpassen...

myUtils dann:
sub myFensterAlarm($)
{
  my ($Device) = @_;
 
  if(ReadingsNum($Device, "excludeFromAlarm", 0) == 1)
  {
    Log3(undef, 1, "Fenster $Device wurde geöffnet, sollte aber keinen Alarm auslösen");
  }
  else
  {
    "Alarm"
  }
}

Statt "Alarm" natürlich das, was dann passieren soll ;)

Hier hat "Vorrang", dass das "excludeFromAlarm" bewusst gesetzt sein muss.
Ist es nicht vorhanden, gilt es als nicht gesetzt und es gibt einen Alarm...

Geht bestimmt irgendwie auch mit DOIF...

Und das setzen des Readings excludeFromAlarm eben mittels set (-> setList) oder setreading...
Oder per Attribut, dann statt ReadingsNum eben AttrVal (oder AttrNum)...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)