devspec auf Modulart erweitern

[igami]

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.

[Loredo]

Warum sollte das bei einem Helper Device nicht sinnvoll sein?


Gruß

Julian

[igami]

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?

[Dr. Boris Neubert]

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?

[betateilchen]

Ist mein HTTPSRV ein Helper?

Möchtest Du eine ehrliche oder eine höfliche Antwort?

[Dr. Boris Neubert]

Eine begründete Antwort anhand einer nachvollziehbaren konsensfähigen Definition eines Helper-Moduls

[betateilchen]

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.

[Dr. Boris Neubert]

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.

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 

[Dr. Boris Neubert]

@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.

[igami]

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.

[betateilchen]

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...

[Loredo]

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.

[betateilchen]

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"

[Dr. Boris Neubert]

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.

[igami]

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. ?

[rudolfkoenig]

Ist 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.

[betateilchen]

und update erzeugt auch Events, ist trotzdem kein Device.

nein, update ist eindeutig ein Command, denn es hat eine CommandFn

[Dr. Boris Neubert]

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.

[betateilchen]

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.

[igami]

Will sagen: dein Wunsch ist nicht ohne Haken zu erfuellen.

Das beantwortet dann ja schon meine Frage