Neues Modul: 22_HOMEMODE.pm - grundlegende Automationen und mehr

[bmwfan]

Hallo,
benutze nun auch Homemode und komme langsam voran. Mit dem Einbinden meiner Türsensoren habe ich ein Problem. Die magnetischen Sensoren vom Typ HM-SEC-SC werden gefunden, die Sensoren von HmIP (HmIP-SWDO-I) aber nicht.

Code Auswählen Erweitern

Dieses Attribut geht nicht:
attr HomeSensorsContact model=HM-SEC-SC,TYPE=HmIP-SWDO-I
und dieses auch nicht.
attr HomeSensorsContact model=HM-SEC-SC,model=HmIP-SWDO-I
Die HmIP-Sensoren sind über piVCCU und HMCCU eingebunden.

Können HmIP-Komponenten generell nicht eingebunden werden oder hat jemand einen Tip?

Grüße Jürgen

Konnte es lösen. Der Typ war HMCCUDEV und nicht der Gerätetyp. Jetzt wierden die Sensoren angezeigt, zusätzlich auch alle anderen Device diesen Typs (Thermostate...).

[DeeSPe]

Ich habe heute v1.5.4 mit ein paar kleinen Bugfixes und einigen Code-Verbesserungen eingecheckt.
Die neue Version kommt dann mit dem regulären FHEM Update ab morgen Früh.

    - fix calendar placeholders not being replaced
    - improved empty battery handling while adding to HOMEMODE
    - improved function HOMEMODE_name2alias for better alias handling
    - other minor code improvements

Gruß
Dan

[cortmen]

 :)Vielen Dank, neue Version bereits eingespielt, läuft rund.

[sTaN]

Hallo Dan,

das Modul ist echt überwältigend!

Ich habe es schon lange auf meiner ToDo Liste und heute endlich mal herangetraut, da ich bereits ein Resident Device und zwei Presence devices hatte, auch schnell eingerichtet.

Erste Mammut Aufgabe soll sein:
1. bisherige Fenster Offen Meldungen und meine MAX Kontakte in HOMEMODE zu integrieren
2. mich mit formatierten Pushover Nachrichten in Abhängigkeit der Anwesenheit auf verschiedene Presence devices zu informieren
3. zahlreiche dafür verwendete Funktionen in der 99_myUtils.pm zu eliminieren

Soweit klappt das bisher ganz gut und ich erhalte wie zuvor auch die 1. Fenster offen Meldung nach 10 Minuten und die 2. Meldung nach weiteren 10 Minuten über Pushover auf mein device, aber noch ohne Anwesenheitsprüfung.

Aktuell gefällt mir die Darstellung der Pushover Nachrichten aber noch nicht und ich frage mich, wie ich die Pushover Nachrichten, wie bisher auch in Abhängigkeit des Anwesenheitsstatus einfach verschicken kann und dabei die Nachricht hübsch aufbereite, quasi identisch wie bisher.

Aktuell sieht meine 99_myUtils.pm wie folgt aus:

Code Auswählen Erweitern

sub sendNotification($;$$$)
{
my $msg = shift(@_);
my $title = shift(@_);
#my $admin = shift(@_);
my $device = shift(@_);
my $emcy = shift(@_);

$title = "" if !$title;
#$admin = "false" if !$admin;
$device = "" if !$device;
$emcy = "false" if !$emcy;

my $cmdTitle = $title ? "title='$title'" : "";
my $cmdDevice = "";

if($device eq "sTaN")
{
    if($emcy eq "true") {
       $cmdDevice = "device=sTaNs-iPhone priority=2 retry=300 expire=7200";
    } else {
       $cmdDevice = "device=sTaNs-iPhone priority=1";
    }
fhem("set PushsTaN msg $msg $cmdTitle $cmdDevice")
} elsif($device eq "AnSo") {
    if($emcy eq "true") {
       $cmdDevice = "device=AnSos-iPhone priority=2 retry=300 expire=7200";
    } else {
       $cmdDevice = "device=AnSos-iPhone priority=1";
    }
fhem("set PushAnSo msg $msg $cmdTitle $cmdDevice")
} else {
fhem("set PushAnSosTaN msg $msg $cmdTitle $cmdDevice")
}
}

sub sendAnSoNotification($;$$)
{
my $msg = shift(@_);
my $title = shift(@_);
my $emcy = shift(@_);

$emcy = 'false' if !$emcy;

sendNotification($msg, $title, "AnSo", $emcy);
}

sub sendsTaNNotification($;$$)
{
my $msg = shift(@_);
my $title = shift(@_);
my $emcy = shift(@_);

$emcy = 'false' if !$emcy;

sendNotification($msg, $title, "sTaN", $emcy);
}

sub sendAdminNotification($;$$)
{
my $msg = shift(@_);
my $title = shift(@_);
my $emcy = shift(@_);

$title = 'Admin-Nachricht' if !$title;
$emcy = 'false' if !$emcy;

sendNotification($msg, $title, "true", $emcy);
}

sub sendAdminEmergencyNotification($;$)
{
my $msg = shift(@_);
my $title = shift(@_);

$title = 'Admin-Emergency-Nachricht' if !$title;

sendAdminNotification($msg, $title, "true");
}

sub winOpenStart($;$) {
    # Notify dafür
# define winOpen.OpenNotify notify .*:(open|opened|tilted) {winOpenStart($NAME)}


#Als Parameter muss der device-Name übergeben werden
    my $dev=shift(@_);
   
    #Optional kann noch ein Zähler für das erneute Triggern übergeben werden,
    #dieser ist per default 0
    my $retrigger=shift(@_);
    $retrigger=0 if (!$retrigger);
   

    #Erst mal prüfen, ob das übergebene device überhaupt existiert
    if ($defs{$dev}) {
   
        #Aus dem device, sofern vorhanden das Attribut winOpenMaxTrigger auslesen, das
        #angibt, wie oft eine Meldung ausgegeben werden soll.
        #Fehlt dieses Attribut oder ist 0, dann wird für das device gar keine Offen-Meldung ausgegeben
        my $maxtrigger=AttrVal($dev,'winOpenMaxTrigger',0);
   
        if($maxtrigger) {
   
      #Festlegen des Namens für den Timer, der angelegt wird um die Meldung nach gewünschter
          #Zeit auszugeben.
          #my $devtimer=$dev.'_OpenTimer';
  my $sleepId='sleep.'.$dev;

          #Sollte dieser Timer bereits existieren, so wird er zunächst gelöscht.
          #fhem("delete $devtimer") if ($defs{$devtimer});
  fhem("cancel $sleepId") if ($defs{$sleepId});

 
          #Holen von weiteren Attributen, sofern vorhanden:
         
          #Zeit, nach der die Meldung ausgegeben werden soll
          #Default sind 10 Minuten, falls nicht angegeben
          #my $waittime=AttrVal($dev,'winOpenTimer','00:10:00');
  my $waittime=AttrVal($dev,'winOpenTimer','600');

          #Zeit für die Folge-Meldungen, sofern abweichend angegeben
          #Default ist die normale Zeit, die oben schon ermittelt wurde
          my $devtimer2=AttrVal($dev,'winOpenTimer2',$waittime);

          #Ein eventuell definierter "schöner" Name für das Device, der in der Meldung ausgegeben werden soll.
          #Ist der nicht angegeben, wird das Device-Alias genommen, fehlt auch das, wir einfach der
          #device-Name genommen.
          my $devname=AttrVal($dev,'winOpenName',AttrVal($dev,'alias',$dev));
         
          #Eine Art Typ (Tür oder Fenster), der bei mir quasi im Betreff der Offen-Meldung angegeben wird
          my $devtype=AttrVal($dev,'winOpenType','Fenster/Tür');

          #Hier wandeln wir noch den state des devices in deutschen Klartext um
          my $devstate='offen';
          $devstate='gekippt' if (ReadingsVal($dev,'state','') eq 'tilted');
         
          #Hier wird, sofern bereits eine Wiederholung der Offen-Meldung ausgegeben werden soll,
          #dies textlich auch so berücksichtigt.
          my $immer='noch ';
          $immer='immer noch ' if ($retrigger>0);

          #Jetzt wird der Ausgabebefehl für die Offenmeldung zusammengebaut
          #(Ich habe eine sub PushInfo, die Betreff und Text als Parameter erhält und aktuell
          # meine Meldungen über Pushover ausgibt)
          #my $pushcmd="PushInfo('$devtype','$devname ist $immer $devstate');;";
  my $pushcmd="PushInfo('$devtype','";
  $pushcmd.=$retrigger+1;
  $pushcmd.=".Meldung: $devname ist $immer $devstate');;";
         
          #Sind wir schon beim Einrichten einer Folgemeldung, muss die Wartezeit für die Folgemeldungen
          #genommen werden.
          $waittime=$devtimer2 if ($retrigger);

          #Wir erhöhen hier den Trigger-Zähler um 1...
          $retrigger+=1;
          #... und fügen das Re-Triggern als weitere Code-Zeile für das at-DEF an.
          #das sorgt dann dafür, dass diese Funktion hier nach Ablauf des Timers einfach wieder
          #getriggert wird, um einen neuen Timer anzulegen für die Folgemeldung
          $pushcmd.="winOpenStart('$dev','$retrigger');;" if($retrigger < $maxtrigger);

         
          #Nachdem wir hier alles zusammen haben,
          #legen wir den Timer (das at) an und legen ihn freundlicherweise in den, bzw. die
          #selben Räumen ab, wie auch das auslösende device.
          #fhem("define $devtimer at +$waittime {$pushcmd}");
          #fhem("attr $devtimer room ".AttrVal($dev,'room','Unsorted'));
  fhem("sleep $waittime $sleepId;{$pushcmd}");
        }
    }
}

sub winOpenStop($) {
    #Notify dafür:
#efine winOpen.CloseNotify notify .*:closed {winOpenStop($NAME)}

#Dazu muss das entsprechende device (TK/FK) per Name hierher übergeben werden

    #Den übergebenen device-Namen holen
    my ($dev)=@_;

    #Den Namen des Timers zusammenbauen
    #my $devtimer=$dev.'_OpenTimer';
my $sleepId='sleep.'.$dev;
       
    #Existiert ein Timer diesen Namens, so wird er jetzt gelöscht und das war's auch schon.
    #if ($defs{$devtimer}) {
        #fhem("delete $devtimer");
fhem("cancel $sleepId");
    #}
}

sub PushInfo($$) {
   my ($msgsubj,$msgtext) = @_;
   #Anwesehneitsprüfung
   my $sTaN = ReadingsVal('rr_sTaN', 'state', "");
   my $AnSo = ReadingsVal('rr_AnSo', 'state', "");
   
   if ($sTaN eq "home" && $AnSo ne "home") {
#fhem("set PushsTaN msg 'winOpenMessage' '$msgsubj - $msgtext' ");
sendsTaNNotification("'winOpenMessage' '$msgsubj - $msgtext'");
   } elsif ($sTaN ne "home" && $AnSo eq "home") {
    #fhem("set PushAnSo msg 'winOpenMessage' '$msgsubj - $msgtext' ");
sendAnSoNotification("'winOpenMessage' '$msgsubj - $msgtext'");
   } elsif ($sTaN eq "home" && $AnSo eq "home" || $sTaN eq "absent" && $AnSo eq "absent") {
    #fhem("set PushAnSosTaN msg 'winOpenMessage' '$msgsubj - $msgtext' ");
sendNotification("'winOpenMessage' '$msgsubj - $msgtext'");
   }
}

1;

Die Funktionen sub winOpenStart($;$) und sub winOpenStop($) könnten also durch HOMEMODe ersetzt werden.

Die Funktion sub PushInfo($$) sendet mir aktuell nur Pushover Nachrichten an das jeweilige Device, wenn die Person zu Hause ist und innerhalb dieser Funktion greife ich auf verschiedene sendNotification Funktionen zu, wie z.B.:

Push an alle Bewohner zu Hause:
sendNotification("'winOpenMessage' '$msgsubj - $msgtext'")

Push nur auf mein iPhone, wenn ich zu Hause bin und meine Frau nicht:
sendsTaNNotification("'winOpenMessage' '$msgsubj - $msgtext'")

Push nur auf das iPhone meiner Frau, wenn Sie zu Hause ist und ich nicht:
sendAnSoNotification("'winOpenMessage' '$msgsubj - $msgtext'")

Meine Fenster Offen Meldung haben dann das Pushover Format: winOpenMessage Fenster - 1. Meldung: Fenster %ALIAS% ist noch offen! . Wobei nach 1. Meldung auch Tür stehen kann, wenn es sich um einen Türkontakt handelt.

Mit HOMEMODE und folgender Definition wie im Wiki beschrieben, für das attr HomeCMDcontactOpenWarning1:

Code Auswählen Erweitern

{
  my $a = "%ALIAS%";
  $a =~ s/d/D/;
  fhem "set PushsTaN msg $a ist noch offen!";
}

erhalte ich eine Pushover im Format:
Zuhause Das %ALIAS% ist noch offen!

Wie kann ich bei den Attributen jetzt noch die Anwesenheitsabfrage und die Formatierung der Pushover Nachricht einbauen und das möglichst ohne in jedes Attribut komplexe Perl Funktionen einzubauen und nach Möglichkeit die Funktionen in der 99_myUtils.pm zu eliminieren?

Oder gibt es dazu bereits HomeCMD's und device Attribute, die das erledigen? 

Ich hoffe dies war verständlich.

Gruß
sTaN

[trinitywhm]

Schau dir mal den FHEM-Befehl msg an. Der sollte einiges deiner Anforderungen abdecken:
https://wiki.fhem.de/wiki/Msg

Und gerade in Verbindung mit residents und Homemode ist das eine klasse Ergänzung.

[DeeSPe]

Schau dir mal den FHEM-Befehl msg an. Der sollte einiges deiner Anforderungen abdecken:
https://wiki.fhem.de/wiki/Msg

Und gerade in Verbindung mit residents und Homemode ist das eine klasse Ergänzung.

Genau dem kann ich nur zustimmen.
Du kannst dann z.B. innerhalb von HOMEMODE mit "msg push @%RESIDENT% mein toller text" Deine Nachrichten in Abhängigkeit zum Anwesenheitsstatus versenden.

Gruß
Dan

[sTaN]

Genau dem kann ich nur zustimmen.

Danke euch! Mit msg habe ich es jetzt prima umsetzen und einige Funktionen in der 99_myUtils eliminieren können. Als nächstes war die Batteriewarnung dran, die mich ohnehin aktuell nervt, da ich jedes Mal, wenn ich z.B.: meinen Philips HUE Schalter betätige und die Batterie <20% ist, eine Batteriewarnung erhalte. Auch sobald meine MAX Wandthermostate den Status wechseln. Da würde mir einmal am Tag reichen mit Angabe der battery Prozentzahl.

Ich hatte bisher immer folgendes Notify BatteryLowPushover laufen:

Code Auswählen Erweitern

.*:[Bb]attery:|.*:[Bb]atteryS { if(($EVENT !~ m/ok/) and ($EVENT !~ m/100/) and ($EVENT !~ m/[2-9][0-9]/)) {my $alias = AttrVal($NAME,"alias",$NAME); {fhem("set PushsTaN msg FHEM Batteriewarnung, $alias: $EVENT:\nBatterien sollten demnächst gewechselt werden!");Log 3, "$NAME: Batteriewarnung $EVENT";}}}

Die Pushover Nachricht beim z.B.: Schlafzimmer Schalter (batteryPercent = sah dann so aus:
FHEM Batteriewarnung, Schlafzimmerschalter: battery:8 Batterien sollten demnächst gewechselt werden!

Nach Umstellung auf HOMEMODE vermisse ich allerdings die Anzeige von batteryPercent in der Pushover Nachricht. Bekommt man das auch in HOMEMODE irgendwie eingebaut und mitgeschickt?

Aktuelle Config ist:
attr HomeSensorsBatteryLowPercentage 20
attr HomeCMDbatteryLow

Code Auswählen Erweitern

{
  my $msg;
  $msg = "Die Batterien von %BATTERYLOW% sollten demnächst gewechselt werden!" if (%BATTERYLOWCT% == 1);
  $msg = "Die Batterien bei folgenden Geräten sollten ausgetauscht werden: %BATTERYLOWALL%" if (%BATTERYLOWCT% > 1);
  fhem "msg push |Batteriewarnung| $msg";}

Gruß
sTaN

[guhu]

Das Modul ist wirklich genial. Ich habe dadurch einen ganzen DOIF-Zoo verschwinden lassen können, z. B. nutze ich es für die Überwachung der Batterien und der geöffneten Fenster, wenn die Heizung läuft.

Ich würde noch gerne ein Thema darüber laufen lassen, um DOIFs zu vermeiden, und das ist die Überwachung der Lüftung im Badezimmer. Dazu habe ich ein Device mit einem "Dewpoint", also einem Taupunkt. In Verbindung mit der aktuellen Temperatur könnte man dann entweder die Belüftung regeln oder aber -idealerweise über msg- Aufforderungen zum Öffnen oder Schließen des Fensters absetzen.

Ich habe gesehen, dass Humidity als Variable überwacht wird, aber weiß nicht so recht, ob ich das Thema mit dem jetzigen Stand von HOMEMODE umsetzen kann. Hat da jemand eine Idee oder habe ich gar etwas übersehen?

[gestein]

Hallo,

Möchte mit guhu anschließen ...
ich habe die Frage zwar schon mal gestellt, aber ich bin halt mal lästig 
Denn ich wickle die meisten Hausautomationen mit Homemode ab - funktioniert ja auch toll, Kompliment.
https://forum.fhem.de/index.php/topic,64317.msg1056992/topicseen.html#msg1056992

Volschin hat damals gemeint, dass HOMEMODE eher die Denke einer Alarmanlage verfolgt und daher eine Temperatur ausreicht.
Für mich sind das auch Alarme, wenn der Kühlschrank, der Gefrierschrank oder ein Server zu warm werden.

Wäre toll, wenn ich alles an einer Stelle integrieren könnte.
Ist es angedacht, auch die Temperatursensoren von Geräten zu integrieren?

Lg, Gerhard

[DeeSPe]

Moin guhu und gestein,

aus meiner Sicht geht Euer Wunsch über die mit diesem Modul verfolgten "grundlegenden Automationen" weit hinaus.
Ursprünglich ging es mir mit diesen Modul hauptsächlich um die Steuerung/Überwachung von RESIDENTS/ROOMMATE/GUEST, deren anwesend Erkennung und dem damit verbundenen Status der Alarmanlage. Erst später sind dann die vielen heute verfügbaren weiteren Möglichkeiten dazu gekommen.
Wirklich komplexe Funktionen habe ich auch bewusst nicht integriert weil sie 1.) die Komplexität des Moduls exponentiell erhöhen und 2.) die verfolgten Lösungsansätze von Benutzer zu Benutzer unterschiedlich sein können. Oder einfach gesagt sind mir einige Themen viel zu komplex und individuell um sie mit einem Modul allen Benutzern recht zu machen.
Wie an anderer Stelle schon erwähnt ist für mich die Entwicklung dieser Modulversion abgeschlossen. Es wird bei v1.5 bleiben, somit wird es keine weiteren neuen Funktionen und auch keine grundlegenden Änderungen mehr geben. Es werden nötigenfalls noch Fehlerkorrekturen vorgenommen, wie vor Kurzem mit der v1.5.4.
Zeitlich bin ich im Moment, und auch voraussichtlich die nächsten Monate, stark gebunden und habe wenig Zeit für Programmierung. Wenn ich wieder mehr Zeit zur Verfügung habe, werde ich die Entwicklung von "HOMEMODE 2.0" weiter voran treiben, wo es dann eine grundlegende Veränderung für die Konfiguration der von HOMEMODE überwachten Geräte geben wird und natürlich auch wieder neue Funktionen. Weiterhin werden Ideen und Wünsche dafür im Beitrag "HOMEMODE 2.0: Wunschliste" gesammelt. Ihr könnt also gern dort Eure Wünsche formulieren und Vorschläge machen wie es umgesetzt werden kann/soll.

Gruß
Dan

[guhu]

Danke, Despee, ich habe es als Anregung für Homemode 2.0 angegeben

[gestein]

Hallo Dan,

Danke. Habe meines ebenfalls in der Wunschliste eingetragen.

lg, Gerhard

[RockSteadyBeat]

Servus zusammen,
ich benutze das Modul nun schon seit den ersten Tagen, habe nun erstmals ein Problem was ich nicht nachvollziehen kann.
Ich habe mir einen HUE Bewegungsmelder zugelegt diesen bereits als HUE-Sensor in FHEM eingebunden, nun möchte ich ihn als MotionSensor zu HOMEMODE hinzufügen, habe die DevSpec dahingehend geändert, jedoch stürzt FHEM dann ab.
folgendes finde ich im log:

Code Auswählen Erweitern

Nested quantifiers in regex; marked by <-- HERE in m/^Die-drei-??? <-- HERE ---Live$/ at ./FHEM/22_HOMEMODE.pm line 3433.

Die DevSpec teste ich vorher mit "list"...

Hat jemand eine Idee?

LG Olli

[DeeSPe]

Servus zusammen,
ich benutze das Modul nun schon seit den ersten Tagen, habe nun erstmals ein Problem was ich nicht nachvollziehen kann.
Ich habe mir einen HUE Bewegungsmelder zugelegt diesen bereits als HUE-Sensor in FHEM eingebunden, nun möchte ich ihn als MotionSensor zu HOMEMODE hinzufügen, habe die DevSpec dahingehend geändert, jedoch stürzt FHEM dann ab.
folgendes finde ich im log:

Code Auswählen Erweitern

Nested quantifiers in regex; marked by <-- HERE in m/^Die-drei-??? <-- HERE ---Live$/ at ./FHEM/22_HOMEMODE.pm line 3433.

Die DevSpec teste ich vorher mit "list"...

Hat jemand eine Idee?

LG Olli

Das klingt mir sehr merkwürdig!
In Zeile 3433 geht es um Calendar/holiday Events. Mich wundert was das mit Bewegungsmeldern zu tun haben soll!?
Was soll "m/^Die-drei-???" für ein Devspec sein?

Gruß
Dan

[RockSteadyBeat]

Hallo Dan,

Asche auf mein Haupt!!!   Sorry!!!
Hätte selbst eher etwas tiefer graben sollen...    (die 22_HOMEMODE.pm mal auf Zeile 3433 prüfen...)

Es lag an einem Eintrag im Kalender: "Die drei ? ? ?  - Live"
Dieser Termin hätte schon längst in 2020 erledigt sein sollen, aber aus bekannten Gründen verschiebt er sich regelmäßig... (aktuell ins Jahr 2022)

Also Lösung: Termin umbenannt, die ? ? ? in Emoji-Symbole getauscht ❓❓❓, nun läuft alles...
DevSpec war ja bereits korrekt...

Vielen Lieben Dank!!
Gruss Olli

(Kaffee kommt...)