Neues Modul 98_alarmclock ein Fhem Wecker

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

Vorheriges Thema - Nächstes Thema

rudolfkoenig

ZitatDu aktivierst Events und setzt gleichzeitig Attribut event-on-change-reading .* In der define wenn das Attribut nicht gesetzt ist.
Kann mir jemand erklaeren, wozu das gut ist? Es ist nicht das erste mal, dass ich das sehe, deswegen kann ich nicht ausschliessen, dass es einen sinnvollen Grund hat. Ist aber mAn nur ein CPU-intensives No-Op, und verursacht mir Kopfschmerzen, wenn es mit anderen event-* Attributen kombiniert wird.

CoolTux

Hallo Rudi,

Der Sinn bestand darin das keine Systembelastenden Events erzeugt werden, da sie in diesem speziellen Fall nicht benötigt werden.
Ich kann mich erinnern das Du vor kurzem schon mal sagtest das event-on-* CPU Last nimmt. Da meine persönlichen Erfahrungen vor 2 Jahren mit vielen Events sehr nüchtern ausgefallen sind, habe ich bei den meisten Devices event-on-* eingestellt.



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

Hallo Rudi,

Zitat von: CoolTux am 03 Mai 2017, 21:03:13
Der Sinn bestand darin das keine Systembelastenden Events erzeugt werden, da sie in diesem speziellen Fall nicht benötigt werden.

war auch 1:1 mein Gedankengang.
Welche Nachteile oder Probleme ergeben sich hierdurch?

Gruß
Florian

rudolfkoenig

ZitatDer Sinn bestand darin das keine Systembelastenden Events erzeugt werden, da sie in diesem speziellen Fall nicht benötigt werden.
Das wird aber weder durch das Setzen von "event-on-change-reading .*" noch durchs weglassen bewerkstelligt.
Wenn man event-on-change-reading nicht setzt, dann werden alle Events normal generiert. Wenn man es setzt, dann wird jedes Event gegen diese Regexps geprueft, und falls passt, dann ein Event generiert.

Wenn man keine Events generieren will, dann ruft man entweder readingsSingleUpdate oder readingsEndUpdate mit 0 als letztes Argument auf.

CoolTux

Aber dann haben wir wieder das Problem das sich bei einem setzen eines neuen Readings FHEMWEB nicht aktuallisiert. Man muss also immer die Seite neu laden um das geänderte Reading zu sehen.
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: rudolfkoenig am 03 Mai 2017, 22:18:49
Das wird aber weder durch das Setzen von "event-on-change-reading .*" noch durchs weglassen bewerkstelligt.
Das war mir so nicht bewusst.
Dann werde ich das setzen des Attributes in der define wieder entfernen.
Die Events bei den Readings lasse ich aktiv.
Sehe das in diesen Fall nicht so problematisch, da das Modul sehr wenig Events erzeugt.
Das wäre dann eher eine generelle Frage wie man "Frontend kompatible" Readings setzt, wenn das Modul
selber keine Events benötigt.

Gruß
Florian

rudolfkoenig

@CoolTux: Bitte "dann" definieren.

Version 1: man will keine Events (warum auch immer): readingsSingleUpdate($hash, reading, wert, 0) oder readingsEndUpdate($hash, 0)

Version 2: man will Events (Normalfall): readingsSingleUpdate($hash, reading, wert, 1) oder readingsEndUpdate($hash, 1);

Ohne Events kriegt natuerlich keiner (inkl FHEMWEB) die Aenderungen mit. Dieses Modul sollte mit den paar Events niemanden stoeren.

CoolTux

Guten Morgen Rudi,

Vielen Dank für Deine Ansicht und Empfehlung.
Dann lassen wir mal den Flo entscheiden ob er mit oder ohne Event haben möchte.
Meine Empfehlung mit event-on-* möchte ich dann hiermit zurück ziehen.


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

#53
Hallo zusammen,

98_alarmclock ist jetzt im FHEM Repository und sollte mit dem morgigen Update verfügbar sein.

Viele Grüße
Florian

Loredo

Hallo Forian,

gerade erst gesehen, dass es das Modul gibt.
Mich würde dabei noch interessieren: Wieso kam es für dich denn nicht in Frage einen Patch für den vorhandenen Wakeuptimer in RESIDENTStk bereitzustellen statt eines neuen Moduls, was außen vor ist?




Gruß
Julian
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

FlorianZ

Hallo Julian,

Anfangs wollte ich nur meine eigenen Anforderungen an einen Wecker in FHEM abbilden und
Perl lernen. Mit der Zeit und Spaß daran ist dann dieses Modul entstanden.
Wollte dir da im Bezug auf RESIDENTS Wakeuptimer mit Sicherheit nicht auf die Füße treten.
Zitatstatt eines neuen Moduls, was außen vor ist?
Naja so weit außen vor sehe ich das garnicht. Bei mir läuft alarmclock produktiv  im engen Verbund mit
Residents. Auf der anderen Seite ist das Modul vielleicht auch für User interessant, die kein
Residents einsetzen. Sozusagen standalone.
Eines meiner Hauptanliegen war/ist auch das Modul so zu gestallten, dass keine weiteren
DOIF/Notify oder Usercode mehr nötig sind.

Gruß
Florian

Loredo

Der Grund, weshalb ich frage ist eigentlich nur, dass du eben Funktionen teils doppelst und dabei die Integration in ROOMMATE/GUEST (zumindest auf den ersten Blick) nicht dem entspricht, wie es sein sollte (sprich, 98_alarmclock ist kein vollwertiger Ersatz). Die Erwartung der Nutzer wäre sicherlich, dass ROOMMATE vollständig unterstützt wird. Allerdings habe ich weder Zeit doppelten Code zu pflegen noch auf Fremdcode Rücksicht zu nehmen.


Solange sich niemand beklagt, ist ja alles gut :-)


Ich wollte nur sichergehen, dass hier keine falschen Erwartungen bei der Nutzung von alarmclock zusammen mit ROOMMATE/GUEST entstehen.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

FlorianZ

Zitat von: Loredo am 07 Mai 2017, 19:01:16
die Integration in ROOMMATE/GUEST (zumindest auf den ersten Blick) nicht dem entspricht, wie es sein sollte
kannst Du das bitte etwas genauer definieren?
Alarmclock greift auf keiner Weise auf das Modul Residents zu.

Gruß
Florian

Loredo

Zitat von: FlorianZ am 07 Mai 2017, 19:10:40
kannst Du das bitte etwas genauer definieren?
Alarmclock greift auf keiner Weise auf das Modul Residents zu.


Eben. Du schreibst aber in deinem ersten Beitrag hier im Thread, dass du damit dein ROOMMATE/GUEST Device steuerst. Das ist dann wohl etwas missverständlich, denn es impliziert für jemanden, der den Wakeuptimer benutzt/kennt, dass alarmclock ein Ersatz dafür ist.
Zumindest führte das bei mir dann zumindest schonmal zu dieser Annahme. Da alarmclock aber die wakeup Funktionen von ROOMMATE/GUEST nicht unterstützt, sollte das besser etwas relativiert werden, um hier wie gesagt keine falschen Erwartungen zu wecken (und uns beiden damit eine menge Support Arbeit zu ersparen  ;) )


LG
Julian
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

FlorianZ

Ok jetzt verstehe ich was du meinst.  ;)
Werde das Beispiel ändern.

Gruß
Florian