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

[ComputerZOO]

Wow,
bin überrascht über die Fortschritte, die das Wiki macht. Gefällt mir echt gut.
Mein HOMEMODE übernimmt inzwischen immer mehr Aufgaben, welche vorher etwas verstreut im System waren. Ich hätte da evtl. noch eine Idee für einen Zusatz im Modul:
Ich habe bei mir jeweils ein AT, welches stündlich Aufgaben ausführt, und eines welches sog. ,,Midnight-Procedures" ausführt. Da ja auch andere tageszeitabhängigen Funktionen in HOMEMODE ausgeführt werden, wäre so etwas wie HomeCMDhourly und HomeCMDmidnight doch in diesem Modul recht gut aufgehoben!? 

[binford6000]

Da ja auch andere tageszeitabhängigen Funktionen in HOMEMODE ausgeführt werden, wäre so etwas wie HomeCMDhourly und HomeCMDmidnight doch in diesem Modul recht gut aufgehoben!? 

Mitternacht könntest Du bereits jetzt schon mit dem Attribut HomeDaytimes erreichen: 00:00|Mitternacht
HomeCMDhourly wäre aber auch ganz nett 
VG Sebastian

[ComputerZOO]

Moin,

Guess what...

Mitternacht habe ich bei mir bereits genau so realisiert 

Dachte bloß, dass das unabhängig von Daytimes besser aufgehoben ist, wenn z.B. die Nacht von 23:00 bis 06:00 geht.

Edit: HomeCMDmode-night ergibt ja hier auch keinen Sinn, da das ja z.B. vom HomeCMDmode ,,overruled" wird.

[DeeSPe]

Moin,

Guess what...

Mitternacht habe ich bei mir bereits genau so realisiert 

Dachte bloß, dass das unabhängig von Daytimes besser aufgehoben ist, wenn z.B. die Nacht von 23:00 bis 06:00 geht.

Edit: HomeCMDmode-night ergibt ja hier auch keinen Sinn, da das ja z.B. vom HomeCMDmode ,,overruled" wird.

HomeCMDmode ,,overruled" HomeCMDmode-night nicht, sondern wird nur vor HomeCMDmode-night ausgeführt.

Habe soeben v1.2.2 in SVN eingecheckt.
Beim Erstellen des Wikis sind mir ein paar kleinere Fehler aufgefallen.

Changelog:

v1.2.2
    - add missing placeholders %NAME%, %TAMPEREDCT%, %TAMPEREDHR% and %OPENHR%
    - fix placeholder %OPEN% and %PRESSURETREND%
    - use regex for HomeSensorsSmokeValue
    - minor commandref additions and changes
    - add Wiki page to commandref

Gruß
Dan

[kjmEjfu]

Gibt es eigentlich eine Möglichkeit auch den Sabotage-Status von Geräten zu überwachen, die weder ein Kontaktsensor noch ein Bewegungsmelder sind?
Würde gerne meine Sirene mit überwachen lassen, die macht aber rein inhaltlich bei keinem der beiden Sinn.

[volschin]

Irgendwo muss in den Homebridge-Mappings wohl ein Fehler hängen, denn nachdem das System von absent auf gone geschaltet hat, ist mein HomeKit der Meinung, die Alarmanlage ist ausgeschaltet.

[DeeSPe]

Gibt es eigentlich eine Möglichkeit auch den Sabotage-Status von Geräten zu überwachen, die weder ein Kontaktsensor noch ein Bewegungsmelder sind?
Würde gerne meine Sirene mit überwachen lassen, die macht aber rein inhaltlich bei keinem der beiden Sinn.

Nein, gibt es bisher nicht!

Irgendwo muss in den Homebridge-Mappings wohl ein Fehler hängen, denn nachdem das System von absent auf gone geschaltet hat, ist mein HomeKit der Meinung, die Alarmanlage ist ausgeschaltet.

Gerade getestet und kann ich nicht bestätigen, bei mir bleibt es auf "armaway".
Warum sollte sich das auch ändern? Bei modeAlarm gibt es keinen Unterschied zwischen absent und gone.
Schon mal "set <HOMEMODE> updateHomebridgeMapping" ausgeführt?

Gruß
Dan

[volschin]

Das Update des Homebridge Mappings und anschließendes Durchstarten von Homebridge hat das Problem behoben. Ich muss mir nochmal anschauen, wo die Unterschiede zwischen bisherigem und neuem Mapping lagen, habe auf Anhieb keine gesehen.

[DeeSPe]

Komisch.
Soweit ich mich richtig erinnere habe ich an dem Mapping für die Alarmschaltung nie etwas verändert.
Hauptsache es funktioniert nun wieder wie erwartet.

Gruß
Dan

[volschin]

Hallo Dan,
Deine Aussage kann ich so bestätigen, das Homebridge Mapping ist unverändert. Also hängt es mit dem Homebridge Neustart zusammen, der das glatt gezogen hat.
Ich schaue mal, ob ich das Verhalten irgendwie reproduziert bekomme.

[DeeSPe]

Wenn das Mapping durch "set <HOMEMODE> updateHomebridgeMapping" verändert wurde, äußert sich das seit v1.2.0 in speicherbaren Änderungen durch das rote Fragezeichen hinter "Save config".

Gruß
Dan

[Pr3mut05]

Ich habe jetzt begonnen mich mit HOMEMODE zu beschäftigen
Ein unglaublich mächtiges Tool, was vor allem mir als Anfänger es teils sehr leicht komplexe Befehle zu automatisieren

Welche ist die einfachste Lösung hier zu automatisieren

Licht einschalten WENN zuhause (HomeCMDmode-home) UND es laut Twilight Dunkel ist (also etwa unter 6 und über 8 )


Bisher hatte ich diese Lösung, welche eigentlich ganz OK scheint. aber HOMEMODE sollte das ja überflüssig machen können
https://voizchat.de/fhem-tutorial-serie-teil-7-ablaeufe-automatisieren-anwesenheit-abwesenheit/

[volschin]

Ich habe das bei mir so gelöst:
Im Attribut HomeCMDtwilight-sr_indoor

{
  if (%PRESENT% == 1) {
      fhem "set s_Rollos.Wohnen off";
    }
}

Nur ein Beispiel. Bei Dir würde ss besser passen. Die Frage ist, was das triggernde Event sein soll. Die Aktionen, die bei Ankunft ausgeführt werden sollen, stehen bei mir in arrival.

[DeeSPe]

Ich habe jetzt begonnen mich mit HOMEMODE zu beschäftigen
Ein unglaublich mächtiges Tool, was vor allem mir als Anfänger es teils sehr leicht komplexe Befehle zu automatisieren

Welche ist die einfachste Lösung hier zu automatisieren

Licht einschalten WENN zuhause (HomeCMDmode-home) UND es laut Twilight Dunkel ist (also etwa unter 6 und über 8 )


Bisher hatte ich diese Lösung, welche eigentlich ganz OK scheint. aber HOMEMODE sollte das ja überflüssig machen können
https://voizchat.de/fhem-tutorial-serie-teil-7-ablaeufe-automatisieren-anwesenheit-abwesenheit/

Das Tutorial ist, freundlich ausgedrückt, eine nette Spielerei, hat aber nicht im Entferntesten was mit den Möglichkeiten von RESIDENTS und HOMEMODE zu tun.

Zu Deiner eigentlichen Frage:
Der Vorschlag von volschin ist schon ganz gut super!
Du kannst bei Ankunft die Platzhalter %TWILIGHT% und/oder %TWILIGHTEVENT% auswerten und entsprechend das Licht einschalten.

Z.B. in HomeCMDpresence-present:

Code Auswählen Erweitern

if (%TWILIGHT% < 7)
{
  fhem "set Licht on";
}

Gruß
Dan

[DeeSPe]

Ich habe eben v1.3.0 in SVN eingecheckt.

Wie lange gewünscht, ist es nun endlich möglich Calendar Devices zu benutzen.
Sie können als devspec in den Attributen HomeEventsCalendarDevices und/oder HomeEventsHolidayDevices hinterlegt werden. Beide Attribute nehmen devspec vom Type Calendar/holiday an. Alle Calendar/holiday Devices werden nur einmalig für HOMEMODE verwendet.
Ansonsten sind die HomeCMD Attribute und auch die aus der holiday-Kalender-Integration bekannten Platzhalter verfügbar.
Speziell ist noch zu beachten dass Devices vom Type Calender auch mehrere Events gleichzeitig starten/laufen haben können.
Dies ist kein Problem. Solange die Events unterschiedliche Namen (summary) haben werden diese durch Komma getrennt im zugehörigen Reading "event-<Calendar-Name>" dargestellt.

Ich habe zum Beispiel alle Events rund um die Wohnung im iCal Format als "WOHNUNG" eingebunden (BT-Tag für Putzfrau aktivieren, Urlaub zuhause/verreist).
Eine für mich leicht zu modifizierende Code-Version lege ich dann in "HomeCMDevent-WOHNUNG-each" und reagiere auf die resultierenden Platzhalter entsprechend. Werde das auch noch im Wiki ergänzen.

Wünsche viel Spaß mit der neuen Funktionalität und bin gespannt was ihr so damit anstellt.

Changelog:

v1.3.0
    - add attr HomeEventCalendarDevices
    - minor changes in sub HOMEMODE_uwzTXT
    - add readings alarmSmoke to commandref
    - get checkIP return "Service not available" if no IP available
    - logtexte only on set updateInternalsForce
    - fix name for atTmp for modeAlarm-for-minutes and dnd-for-minutes

Gruß
Dan