Neues Modul YAAHM - Yet Another Auto Home Module

Begonnen von Prof. Dr. Peter Henning, 09 August 2017, 08:01:55

Vorheriges Thema - Nächstes Thema

Prof. Dr. Peter Henning

Anbei die erste testbare Version des Moduls YAAHM  - Yet Another Auto Home Module.

Geschaffen habe ich das aus diversen Routinen, die bei mir seit Jahren laufen:

- Ein Tagesprofil, das an jedem Tag zu verschiedenen Zeiten (z.B. zu Sonnenaufgang) bestimmte Dinge ausführt
- Mehrere Wochenprofile, z.B. für das tägliche Wecken (unterschiedlich je Wochentag), die ebenfalls definierbare Aktionen ausführen.

Monats- und Jahresprofile fehlen noch.

Die Device-Darstellung gibt es in einer so genannten short table, die man in beliebige Räume einbinden kann (als Weblink definiert), und als long table mit voller Einstellbarkeit in einem eigenen Raum, der auch das Device enthält.

Der eingebaute Wecker ist schon so "smart", dass man mit einem einfachen Befehl "set <device> manualnext <timername> <zeit>" die Weckzeit ändern kann -. bei mir geht das auch über Sprachsteuerung. Die Zeiten für Sonnenaufgang etc. werden aus dem Astro-Modul ermittelt. Ferientage und Feiertage werden aus (konfigurierbaren) Kalender-Devices abgeholt.

Achtung: Die Javascript-Datei yaahm.js muss nach www/pgm2 installiert werden.

Und bitte nicht über die Dokumentation mäkeln - irgendwann in den nächsten Wochen werde ich eine Wiki-Seite dafür schreiben, bisher gibt es nur die Commandref.

LG

pah

Prof. Dr. Peter Henning


UweH

Super Teil, Danke.

Bin zwar noch nicht ganz durchgestiegen, aber langsam kommt's.

Gruß
Uwe

Prof. Dr. Peter Henning

Sag Bescheid, wo es klemmt - möglicherweise ist die Doku noch zu rudimentär.

LG

pah

betateilchen

Die Idee ist gut. Aber DOIF kommt mir nicht ins Haus. Auch nicht durch so eine Hintertür.

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

Prof. Dr. Peter Henning

Mach mal langsam.

Erstens verwendet das Modul jetzt schon interne Timer - und es ist in der Tat angedacht, das als Option auswählbar zu machen, weil ich DOIF auch nicht so sehr mag.

Zweitens sind die Codeblöcke zur Erzeugung der externen Timer gerade mal jeweils 30 Zeilen lang - bei einem Gesamtumfang von fast 3000 Zeilen. Das kann man mit der linken Hand auf "at" umschreiben, vielleicht mach ich das sogar aus sportlichen Gründen.

LG

pah

l2r

hi,

ich hab mir das ganze jetzt auch mal eingebunden.

Was ich noch nicht ganz verstehe ist, was das setzen vom Attribut timeHelper bewirkt. Klar dann werden die Aktionen gefüllt. Aber wie bearbeite ich das Template?! und ist es egal auf welchen Funktionsnamen ich timeHelper setze?

Gruß Michael
Wissen ist Macht.
Ich weiß nix.
Macht nix.

Prof. Dr. Peter Henning

ZitatAber wie bearbeite ich das Template?!

In die eigene 99_myUtils (o.ä) kopieren und dort anpassen.

Zitatund ist es egal auf welchen Funktionsnamen ich timeHelper setze?

Ja.

LG

pah

UweH

Hallo pah,

im Wiki steht:
ZitatDie Aktionsfelder enthalten jeweils eine komma-getrennte List von FHEM-Befehlen, die bei Eintreten des Timer-Events abgearbeitet wird.
Auf welche Art und Weise ich es auch versuche, es wird immer nur der erste Befehl ausgeführt. Wie muss ein korrekter Eintrag in ein Aktionsfeld aussehen?
So:
  }elsif( $event eq "evening" ){
fhem "set NXT_USB cmd dim=20","set Aktor3 gpio 1"

ja offenbar nicht. Aber auch mit Klammer usw. habe ich keinen Erfolg.

Gruß
Uwe

betateilchen

Hallo Uwe, wenn man sich klarmacht, dass "fhem" in Wirklichkeit ein Funktionsaufruf ist, dann wird auch klar, dass man für zwei Befehle die Funktion zweimal verwenden sollte.


  }elsif( $event eq "evening" ){ fhem("set NXT_USB cmd dim=20"); fhem("set Aktor3 gpio 1") }


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

UweH


UweH

#11
Moin,

ich habe noch ein Problem mit den einzelnen Zeiten. Wie ich nun im Astro-Thread erfahren habe, holt sich YAAHM seine Zeiten für Sonnenauf und -untergang aus dem Modul Astro. Dabei habe ich aber Differenzen. Astro meint, SunRise ist um 6:08 und SunSet um 20:37, YAAHM dagegen meint, das wäre 5:41 und 21:08.
Die Aktion, die bei SunRise ausgeführt wird, schlägt dagegen um 5:49 im Log zu Buche.

Die "Astro"-Meldungen im Log, die ich hatte, sind seit der Definition der Koordinaten weg, dafür habe ich nun diese hier:
2017.08.20 00:00:33 1: PERL WARNING: Argument "Datum 20.08.0017 12:00:00 \nJulianisches Datum 1727486.9..." isn't numeric in array element at ./FHEM/95_YAAHM.pm line 1827.
2017.08.20 00:00:33 1: PERL WARNING: Argument "Datum 21.08.0017 12:00:00 \nJulianisches Datum 1727487.9..." isn't numeric in array element at ./FHEM/95_YAAHM.pm line 1828.


Woher kommen diese Differenzen?

Gruß
Uwe


EDIT: Eine Sache kann ich noch nachliefern. Ich weiß, warum das eigentliche Schalt-Event um 5:49 (und das seit Tagen...) ausgeführt wird.
In der Definition von YAAHM taucht diese Zeit auf, und zwar als "s_sunrise". Dieser Wert wurde seit dem 17.08. nicht mehr aktualisiert.

Prof. Dr. Peter Henning

#12
Na, dann versuch mal diese Version.

Achtung: Erfordert ggf. einen restart von FHEM, damit alles sauber angezeigt wird.

LG

pah


UweH

Hmmm...keine Änderung (ja, ich habe neu gestartet)

Prof. Dr. Peter Henning

Sieht so aus, als ob Astro.pm keinen Sonnenaufgang liefern kann. Ruf mal mauell auf

{YAAHM_GetDayStatus($defs{'<devicename für das yaahm-Device>'})}

LG

pah