Mit meine monitorin Modul ist es möglich einen globalen ActionDetector zu definieren, welcher nach dem Ausbleiben von Events das device auf eine Liste setzt. Nun ist ja nicht sinnvoll, dass auch helper Module davon betroffen werden.
Könnte man devspec einfach auf die Modulart erweitern? Im Commandref Teil wird ja angegeben ob es ein device, helper oder command ist.
Warum sollte das bei einem Helper Device nicht sinnvoll sein?
Gruß
Julian
Weil die ganen helper nicht von sich aus readings erzeugen, sondern auch nur im Zusammenhang mit anderen devices.
Mit dieser Aussage stellt sich mir die Frage: sind Nmap, PRESENCE und Twilight tatsächlich helper?
Zitat von: igami am 06 April 2017, 18:56:56
Mit dieser Aussage stellt sich mir die Frage: sind Nmap, PRESENCE und Twilight tatsächlich helper?
Gretchenfrage: was ist ein Helper? Das habe ich mich schon öfters gefragt. Ist mein HTTPSRV ein Helper?
Zitat von: Dr. Boris Neubert am 06 April 2017, 20:17:44
Ist mein HTTPSRV ein Helper?
Möchtest Du eine ehrliche oder eine höfliche Antwort?
Eine begründete Antwort anhand einer nachvollziehbaren konsensfähigen Definition eines Helper-Moduls
Die Erklärung, was "helper" sind, ist eigentlich eindeutig und nachvollziehbar - und nichts, was nichts geklärt wäre.
Es gab hier im Forum vor längerer Zeit eine quasi "offizielle" Definition von Rudi, die besagt, dass "device" alle Module sind, die readings aus "(Mess-)werten" erzeugen, mit denen man weiterarbeitet (triggern auf events, plotten von Messwerten usw.)
Alle anderen Module werden unterschieden in "commands" und "helper". In die Gruppe "helper" fallen die Module, die keine CommandXXX sind.
Um auf HTTPSRV zurückzukommen: ich würde sowohl für "höflich" als auch für "ehrlich" wahrscheinlich antworten: "outdated". Will sagen: Ich bin mir nicht sicher, ob das Modul heute tatsächlich noch benötigt wird.
Zitat von: betateilchen am 06 April 2017, 21:17:38
Module sind, die readings aus "(Mess-)werten" erzeugen, mit denen man weiterarbeitet (triggern auf events, plotten von Messwerten usw.)
Alle anderen Module werden unterschieden in "commands" und "helper". In die Gruppe "helper" fallen die Module, die keine CommandXXX sind.
Sehr gut. Wir müssen besser/mehr dokumentieren.
Damit sind Presence, Twilight und HTTPSRV Devices. Mindestens ein Anwender, der nicht ich bin, setzt es ein, um Informationen vom Client an den HTTPSRV zurückzugeben.
Zitat
Um auf HTTPSRV zurückzukommen: ich würde sowohl für "höflich" als auch für "ehrlich" wahrscheinlich antworten: "outdated". Will sagen: Ich bin mir nicht sicher, ob das Modul heute tatsächlich noch benötigt wird.
Weiß ich auch nicht. Es gibt allerdings aktive 2.100 Installationen in den letzten 12 Monaten 8)
@Julian, wir müssen nach Devices umziehen...
@igami: warum willst Du Helper explizit ausnehmen? Damit Du den ActionDetector mit .* füttern kannst? Aber es gibt ja Devices, die nicht tot sind und trotzdem eine ganze Weile stillhalten, weil sie nichts zu melden haben.
Eigentlich wollte ich hier gar keine Diskussion was nun genau helper, device und commands sind.
Ich würde es aber auch so sehen, dass alle Module die eigenständig Daten bereitstellen als device einzuordnen sind und Module die irgendwas weiterverarbeiten helper sind. Deswegen werde ich Nmap nun auch mal als device kategorisieren.
Aber zurück zum Thema: ließe sich devspec auf diese Modulart einfach erweitern? Vllt. könnte man es einfach als neues Internal SUBTYPE oder so einführen.
@Boris: mein modul hat eine blacklist die devspec auswertet, um es einfach zu halten würde ich dann einfach alle helper da drauf setzen. Am anfang habe Meldungen von readingsGrop bekommen.
Welche devices meinst du denn die lange Stillhalten? Ist holiday ein helper? ::)
Als Workaround habe ich beim monitoring modul erstmal ein whitelist Attribut eingefügt. Damit kann dann jeder Nutzer einfach definieren für welche TYPE er eine Benachrichtigung bekommen möchte.
Zitat von: igami am 06 April 2017, 21:39:09
Ist holiday ein helper? ::)
Nein, das ist definitiv ein device, weil es mehrere (!) readings als Ergebnis erzeugt. Wenn auch nur einmal pro 24 Stunden.
Ich habe übrigens at-devices, die nur einmal pro Jahr ausgeführt werden...
Ich verstehe, dass "helper" nicht wirklich gut greifbar ist. Allerdings tue ich mich sehr schwer einfach alles in die Device-Kategorie zu packen, obwohl kein physisches Gerät dahinter steht.
Ich würde also deshalb andere/klarere Kategorien erwarten. Vielleicht macht es z.B. Sinn einmal eine Kategorie "Services" zu haben, z.B. für die ganzen Internetdienste (Pushover, Alexa, Siri, Wunderground...).
Meine Module RESIDENTS, ROOMMATE, GUEST sind Automations-Helfer, aber wohl nach dem Verständnis von Helper Modulen eher mehr als das. Trotzdem ist es kein physisches Device und deshalb für mich nicht in diese Kategorie einordbar. Dafür würde mir eher eine Kategorie "virtual" o.ä. einfallen.
Ich denke auch, dass diese Einordnung sich als INTERNAL widerspiegeln sollte. Das es aber nichts untergeordnetes zu TYPE ist, sondern eher darüber, würde mir dazu eher sowas wie TYPECAT (=TYPE Category) oder so einfallen.
Man sollte das Denken in Hardwarekategorien aufgeben.
Die Definition anhand der readings mit ihren Werten finde ich sehr eingänglich, denn letztendlich ist es doch egal, ob ein Temperaturwert von einem vor Ort installierten Sensor kommt oder von einer Wetterwebseite. Die beiden zugehörigen FHEM Module sind für mich eindeutig vom Typ "device"
Zitat von: betateilchen am 07 April 2017, 09:10:53
Man sollte das Denken in Hardwarekategorien aufgeben.
Das bringt es auf den Punkt. Ich denke, dass diese Aufteilung müßig ist. Die Trennung in Geräte (hat Readings) und Helper (hat keine Readings) ist noch gut nachvollziehbar. Allerdings lässt sich auch ohne neue Subkategorie herausfinden, ob ein Gerät Readings hat. Lediglich nicht für igamis Anwendungsfall, dass ein Gerät, das Readings haben sollte, keine hat, weil eine Störung aufgetreten ist.
Zitat von: Dr. Boris Neubert am 07 April 2017, 09:20:14
Das bringt es auf den Punkt. Ich denke, dass diese Aufteilung müßig ist. Die Trennung in Geräte (hat Readings) und Helper (hat keine Readings) ist noch gut nachvollziehbar. Allerdings lässt sich auch ohne neue Subkategorie herausfinden, ob ein Gerät Readings hat. Lediglich nicht für igamis Anwendungsfall, dass ein Gerät, das Readings haben sollte, keine hat, weil eine Störung aufgetreten ist.
helper können schon Readings haben, nur sind die eben weiterverarbeitete Werte.
Für mein Modul habe ich es nun, wie gesagt, durch eine whitelist gelöst.
Wie sollte man IO Module einordnen? TUL, HMUART, CUL, etc. ?
ZitatIst holiday ein helper?
Nein, das ist definitiv ein device, weil es mehrere (!) readings als Ergebnis erzeugt. Wenn auch nur einmal pro 24 Stunden.
Danke fuer den Hinweis, habs geaendert. Auch wenn ich nach genaueren Nachgruebeln meine Definition fuer ungenau halte: jedes Modul kann Readings haben, und update erzeugt auch Events, ist trotzdem kein Device. Man koennte sich auch fragen, wieso igamis Modul nicht anzeigt, dass der Benutzer seit einem Jahr kein update gemacht hat. Ich bleibe dabei, dass at ein helper ist, trotz Readings und Events. Und igamis Modul braucht ein at auch nicht zu ueberwachen. Wie gesagt, diese Definition ist schwammig, aber bis jemand mit einem Besseren kommt, bleiben wir dabei, um in der Doku ein bisschen Struktur zu haben.
@igami:
die helper Eigenschaft ist Teil der Doku (=item helper). Entweder versucht LoadModule die Doku zu parsen, was teuer und fehleranfaellig ist, oder wir muessen anfangen in allen Initialize Funktionen diesen Parameter einzubauen, was bei den vielen Modulen/Entwicklern lange dauern wird. Will sagen: dein Wunsch ist nicht ohne Haken zu erfuellen.
Zitat von: rudolfkoenig am 07 April 2017, 10:10:39
und update erzeugt auch Events, ist trotzdem kein Device.
nein, update ist eindeutig ein Command, denn es hat eine CommandFn ;)
Zitat von: betateilchen am 07 April 2017, 10:42:57
nein, update ist eindeutig ein Command, denn es hat eine CommandFn ;)
Wir führen jetzt die Begrifflichkeiten solange ad absurdum, bis sie nicht mehr zu halten sind: angenommen, ich baue ins template-Modul noch wie angedacht eine DefineFn ein. Dann ist template ein Kommando und ein Helper. Und wenn das template-Device dann auch noch Readings bekommt, um sich die damit erzeugten Devices anzeigen zu lassen, dann ist es auch ein Device.
Ich bin im Moment bei Rudi: solange uns keine zündende und einfach durchsetzbare Idee kommt, sollten wir es belassen, wie es ist.
Zitat von: Dr. Boris Neubert am 07 April 2017, 10:52:11
Ich bin im Moment bei Rudi: solange uns keine zündende und einfach durchsetzbare Idee kommt, sollten wir es belassen, wie es ist.
Dafür bin ich auch.
Zitat von: rudolfkoenig am 07 April 2017, 10:10:39
Will sagen: dein Wunsch ist nicht ohne Haken zu erfuellen.
Das beantwortet dann ja schon meine Frage