Neues Modul 98_alarmclock ein Fhem Wecker

Begonnen von FlorianZ, 18 Dezember 2016, 19:03:23

Vorheriges Thema - Nächstes Thema

FlorianZ

Hallo Fixel,

Wenn ich es zeitlich schaffe, werde ich das am Wochenende mit einbauen.

Gruß
Florian



Fixel2012

Zitat von: FlorianZ am 26 April 2017, 11:06:49
Hallo Fixel,

Wenn ich es zeitlich schaffe, werde ich das am Wochenende mit einbauen.

Gruß
Florian

Super, Danke dir Vielmals!
Fhem 5.8 auf Raspi 3, HMLAN und 868MHz CUL mit einigen Komponenten, Z-Wave Rollladenaktoren, Tablet UI, 433 MHz CUL mit Baumarktsteckdosen und Temp Sensoren, Amazon Echo, Echo Dot, 2x SONOS  play1, 1x SONOS Connect AMP,  presence, HUE, Lightify

FlorianZ

#32
Hier eine neue Version zum testen.

Neue Attribute:
HolidayDevice => Name des Holiday Device
HolidayCheck:1,0 => 1 aktiviert ; 0 deaktiviert

Neue set Befehle:
AlarmTime8_Holiday => Weckzeit für Tage, an denen der status des HolidayDevice nicht "none" ist.
AlarmOff 8_Holiday => Weckzeit für Holiday wird auf Off gesetzt. Hier würde die OffDefaultTime greifen.

Gruß
Florian

Fixel2012

Zitat von: FlorianZ am 28 April 2017, 23:00:31
Hier eine neue Version zum testen.

Neue Attribute:
HolidayDevice => Name des Holiday Device
HolidayCheck:1,0 => 1 aktiviert ; 0 deaktiviert

Neue set Befehle:
AlarmTime8_Holiday => Weckzeit für Tage, an denen der status des HolidayDevice nicht "none" ist.
AlarmOff 8_Holiday => Weckzeit für Holiday wird auf Off gesetzt. Hier würde die OffDefaultTime greifen.

Gruß
Florian

Hut ab, das ging schnell!

Danke dir, ich werde es die nächsten Tage Testen!

dankende Grüße Fixel
Fhem 5.8 auf Raspi 3, HMLAN und 868MHz CUL mit einigen Komponenten, Z-Wave Rollladenaktoren, Tablet UI, 433 MHz CUL mit Baumarktsteckdosen und Temp Sensoren, Amazon Echo, Echo Dot, 2x SONOS  play1, 1x SONOS Connect AMP,  presence, HUE, Lightify

FlorianZ

Update auf Version 0.0.6 mit der Möglichkeit 5 Wochenprofile zu speichern.

Gruß
Florian

Fixel2012

Hey Florian,

wollte dir nochmal eine kurze Rückmeldung geben:

Die eingestellte Zeit für Holiday Tage (abhängig vom Holday device) hat heute erfolgreich gegriffen und ich wurde zur gewünschten Zeit geweckt!

Das abspeichern verschiedener Profiles ist eine Super Idee!! Sehr nützlich wäre es wenn man diese auch noch individuell umbenennen könnte, aber das ist nur schönheits-verbunden  :P

Wenn sich Zeit findet würde ich mich über diese Erweiterung trotzdem freuen freuen!  ;D

Dankende Grüße

Fixel
Fhem 5.8 auf Raspi 3, HMLAN und 868MHz CUL mit einigen Komponenten, Z-Wave Rollladenaktoren, Tablet UI, 433 MHz CUL mit Baumarktsteckdosen und Temp Sensoren, Amazon Echo, Echo Dot, 2x SONOS  play1, 1x SONOS Connect AMP,  presence, HUE, Lightify

Rudy

Zunächst einmal: Ich finde das Modul klasse und bin gerade dabei meine bisherige Weckerlösung hierdurch zu ersetzen.

Ein paar Fragen und Anregungen habe ich jedoch noch:

1. Das Attribut "MaxAlarmDurationInSec". Was passiert nach Erreichen der hier eingestellten Zeit? Wird damit einfach der state von "Alarm is running" wieder auf "OK" zurückgesetzt? Wenn nein, wo liegt der Unterschied zu HardAlarm?

2. Der state gibt ja einige interessante Informationen wieder. Für die einfache Abfrage ob der Wecker aktiviert oder deaktivert (im Sinne von disable 0/1) ist, eignet er sich aber leider nicht. Ein weiteres Reading wie activestate oder ähnliches wäre hilfreich, auch für eine einfache Integragion in FTUI.

3. Es wäre schön wenn das Modul bald in FHEM direkt integriert werden würde.

4. Was muss ich bei HolidayDevice eingeben, damit die Urlaubsprüfung funktioniert (bspw. Device:Reading)? Und welchen Wert muss dieses mögliche Reading liefern, damit Urlaub ja bzw. nein erkannt wird?

Rudy

Zitat von: MarkusHiba am 03 März 2017, 14:55:28
Ja hab es schon erledigt werde es hier mal Posten. Aber ich habe festgestellt das die Readings nicht aktualisieren erst nach einen reload des Browsers welche Ursachen könnte das sein alle anderen Readings aktualisieren sofort.

Gesendet von meinem E6653 mit Tapatalk
Dieses Problem habe ich auch. Bei anderen Modulen kann man das Attribut event-on-change-reading setzen. Bei alarmclock jedoch (noch) nicht. Wäre das eine Lösung, dies zu integrieren?

CoolTux

Soweit ich mich erinnere werden die meisten Readings gesetzt ohne das ein Event ausgelöst werden soll. Zu mindest war der Code so. Daher kann da auch nicht aktuallisieren im Frontend.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

FlorianZ

Hallo Rudy

Zitat von: Rudy am 02 Mai 2017, 19:37:31
1. Das Attribut "MaxAlarmDurationInSec". Was passiert nach Erreichen der hier eingestellten Zeit? Wird damit einfach der state von "Alarm is running" wieder auf "OK" zurückgesetzt? Wenn nein, wo liegt der Unterschied zu HardAlarm?

Nach Erreichen der eingestellten Zeit bei MaxAlarmDurationInSec wird die AlarmRoutineOff ausgeführt. Der Wecker verhält sich hier identisch als wäre eine EventForAlarmOff eingetreten.
Das kann man als Alternative zu einen getriggerten Event betrachten, um den aktiven Wecker zu stoppen oder einfach die maximale Alarmdauer zu begrenzen. Das Attribut ist optional und muss nicht gesetzt werden.
HardAlarm ist für Leute gedacht, (wie mich  :D ) die ihren Wecker gerne überhören oder ignorieren.
Man kann hier mit dem Attribut HardAlarmTimeInSec die Zeitspanne festlegen, in der der aktive Wecker deaktiviert werden muss. Sollte der Wecker nicht in dieser Zeitspanne deaktiviert werden, wird die HardAlarmRoutine ausgeführt. Kann man zb nutzen um die Lautstärke des Weckers zu erhöhen.

Zitat von: Rudy am 02 Mai 2017, 19:37:31
2. Der state gibt ja einige interessante Informationen wieder. Für die einfache Abfrage ob der Wecker aktiviert oder deaktivert (im Sinne von disable 0/1) ist, eignet er sich aber leider nicht. Ein weiteres Reading wie activestate oder ähnliches wäre hilfreich, auch für eine einfache Integragion in FTUI.

Werde ich mir ansehen und ggf ein weiteres Reading mit aufnehmen.

Zitat von: Rudy am 02 Mai 2017, 19:37:31
3. Es wäre schön wenn das Modul bald in FHEM direkt integriert werden würde.

Steht auf meiner todo ganz oben.  Eventuell kommendes Wochenende.

Zitat von: Rudy am 02 Mai 2017, 19:37:31
4. Was muss ich bei HolidayDevice eingeben, damit die Urlaubsprüfung funktioniert (bspw. Device:Reading)? Und welchen Wert muss dieses mögliche Reading liefern, damit Urlaub ja bzw. nein erkannt wird?

Nur den Namen des HolidayDevice eingeben. Es wird jede Nacht um 5 Sekunden nach Mitternacht der state des HolidayDevice überprüft. Ist dieser nicht none , greift die AlarmTime8_Holiday

Gruß Florian

FlorianZ

#40
Zitat von: CoolTux am 02 Mai 2017, 20:28:05
Soweit ich mich erinnere werden die meisten Readings gesetzt ohne das ein Event ausgelöst werden soll. Zu mindest war der Code so. Daher kann da auch nicht aktuallisieren im Frontend.

Ja das ist richtig. Sollte ich das nur für das Frontend ändern?
Die Modulfunktion selbst würde eigentlich hier keine Events benötigen.

Gruß
Florian

CoolTux

Gute Frage. Gebraucht wird es ja nicht. Du hast halt nur ein Darstellungsproblem in den Frontends. FHEMWEB kann man ja noch so neu laden, FTUI ist da schon ungünstiger.

Mach es so. Du aktivierst Events und setzt gleichzeitig Attribut event-on-change-reading .* In der define wenn das Attribut nicht gesetzt ist.

Dann kannst Du auch gleich Deine eine if Abfrage mit den vielen einzelnen readingsSingleUpdate auf readingsBulkUpdate umstellen.
Ist ein Vorschlag


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

FlorianZ

Zitat von: CoolTux am 02 Mai 2017, 20:40:43
Du aktivierst Events und setzt gleichzeitig Attribut event-on-change-reading .* In der define wenn das Attribut nicht gesetzt ist.
Dann kannst Du auch gleich Deine eine if Abfrage mit den vielen einzelnen readingsSingleUpdate auf readingsBulkUpdate umstellen.
Ja das klingt sehr gut.
Werde ich im nächsten Update so mit umbauen.

Gruß
Florian

FlorianZ

#43
So Events sind jetzt in Version 0.0.7 aktiviert.
Event-on-change-reading kann genutzt werden.
Sollte bei einer neuen Def automatisch gesetzt werden.

Bitte kurze Rückmeldung bzgl. FTUI und FHEMWEB.

Gruß
Florian

Rudy

Hallo Florian,

danke für die Informationen. Der Unterschied zwischen MaxAlarmDurationInSec und  HardAlarm ist nun klar. Auch wie Holiday funktioniert habe ich nun verstanden. An das Modul holiday hatte ich leider gar nicht mehr gedacht. Aber auch, weil ich bei mir den Urlaub über ein Dummy steuere, bei dem bei Bedarf ein Reading auf Urlaub gesetzt wird. Dies geschieht bei mir über einen Kalender, den ich über das Modul calendar eingebunden habe. Finde ich komfortabler als das holiday-Modul. Ich könnte mir vorstellen, dass auch andere dies nicht nicht nutzen, da bspw. die Module HOMEMODE und RESIDENTS längere Abwesenheiten wie Urlaube abgebildet werden können.

Daher schon wieder ein Vorschlag. Deinem Wecker sagen können, in welchem Reading er nachschauen soll ob Urlaub vorliegt. Außerdem noch den Wert angeben können, der Urlaub repräsentiert. So würde das Modul noch universeller einsetzbar.

Gruß
Rudy