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