Die Vielfalt und damit die Dokumentaions-Schnipsel in FHEM steigen (glücklicherweise).
Es gibt zu einigen Themen alternative Implementierungen - und evtl. Ideen welche man nutzen können, würde man sie kennen. Ich habe - wie sicherlich viele andere auch, nicht die Zeit alles zu prüfen um gute Ideen nicht zu verpassen. Ausserdem hasst ich suchen, ich finde lieber.
Im Commandref gibt es nun eine Vielzahl an Module welche ich nutzen kann - allerdings alles ungruppiert und gelegentlich ohne Namensbezug.
Ich würde gerne alles ausblenden was mich nicht interessiert. Das sind schon einmal alle Module welche ich nicht besitze. Manche Module kommen gleich mit einer Vielzahl von Untermodulen - was ok sein kann - aber das Sammelsurium undurchsichtiger macht.
Es wäre - zumindest für mich - hilfreich, an die Module Tags zu hängen nach denen man filtern kann. Kürzlich haben ich ein Modul gefunden, welches "at" Entities strukturieren will. Der Name war "Seltsam" - die Implementierung hat mir nicht zugesagt. Aber ich habe es nur durch Zufall gefunden.
Unter Tags stelle ich mir vereinheitlichte ( und kontrollierte) Namen vor wie
- HWinterface : Das sind Module welche HW direkt Unterstütz wie z-wave, cul_hm,...
- Familien-abhängige wie CUL_HM. Da findet man dann alle zugehörigen Module wie HMLAN, HMinfo, HMtemplate. Andere Familien (HMCCU ) haben ggf noch mehr Module
- Frontends
- timer/notifies
- debug
usw.
Man kann das in Wiki machen (sollte man auch) aber das Commandref sollte es ebenfalls unterstützen.
Wäre das möglich? Die Liste der TAGs sollte endlich sein, sonst ist es sinnlos
Ich
Vielleicht hilft dir commandref modular (https://fhem.de/commandref_modular.html)
ZitatIdeen welche man nutzen können, würde man sie kennen.
und
ZitatIch würde gerne alles ausblenden was mich nicht interessiert. Das sind schon einmal alle Module welche ich nicht besitze
widerspricht sich aber ziemlich.
unabhängig davon: bestimmte tags zu vergeben wäre gut. ich fürchte die diskussion welche die 'richtigen' sind wird schwierig und wir kommen mit einer achse vermutlich nicht aus.
- die kategorien hier im forum wären z.b sinnvoll: beleuchtung, heizung, sprach sprachsteuerung, multimedia, ...
- kategorien für die protokolle/protokollfamilien: homematic, zigbee, z-wave, ...
- frontend (fhemweb, readingsGroup, ...)
- fhem 'programmierung' (timer, event verarbeitung, ...)
- die die kategorien aus dem wiki sind vermutlich auch ein guter anhaltspunkt
es sollten aber sprechende namen sein. CUL_HM findet niemand der nach homematic sucht. hwinterface ist glaube ich eine schlechte kategorie. das hilft niemandem der einsteigt.
zusätzlich wären die schon mal vorgeschlagenen tags für 'frei verfügbares api' und ähnliches sinnvoll.
loredos meta info kann solche und noch viele andere information auslesen, bereitstellen und auch zur laufzeit durchsuchbar machen.
@Rudi
schon mal interessant - aber nahezu unsortiert aus meiner Sicht. Nicht Filterbar. Es gibt nur 3 Kategorien. Keine Zusammenhänge. Zumindest hat es schon einmal eine Kurzbeschreibung.
Nutze ich bspw Homematic - und zwar RF oder wire oder IP,... bin ich nteressiert an allen Modulen, welche hierfür spezifisch "am Markt" sind.
Nutze ich kein homematic sondern andere Devices würde ich gerne die HM-spezifischen ausblenden. Als Entwickler kann ich mir Ideen holen - aber als Anwender sind diese schlicht nicht relevant.
FHEM unterstützt viele Device-Module - welche ich nicht nicht habe.
Somit wäre auch schön - und gruppiert - zu sehen, dass Siemens S7 unterstützt wird. Das ist ein Eintrag. Ich sehe alleine 8 Deivce module - evtl sind auch Helper unterwegs?
@ justme1968
warum ist Ideen suchen und Filtern ein Wiederspruch? Manchmal "surfe" ich. Dann wieder suche ich nach Ideen, Notifies oder Timer zu realisieren, gruppieren und darzustellen.
Und klar kommen wir mit einer Achse nicht aus.
Zitat- die kategorien hier im forum wären z.b sinnvoll: beleuchtung, heizung, sprach sprachsteuerung, multimedia, ...
Das wäre nicht meine erste Wahl, aber auch eine
Zitatkategorien für die protokolle/protokollfamilien: homematic, zigbee, z-wave, ...
Das ist erst einmal mein Einstieg. Um zu Filtern sollte bspw immer (IMMER) eine Familie angegeben werden. Es kann Mehrfachnennungen geben (geht für FS20 und HM,... für HM-RF und HMIP). Wenn es für alle funktioniert (en soll) dann eben "universell".
Praktisch ist es, wenn man neben suchen auch filtern kann. Das bedeuted, dass der Filter für "Famile"bspw immer gefüllt werden muss. Ggf eben mit "universal" ode "all"
meine Probleme aktuell:
Scheinbar habe ich ein Problem mit einem externen RPC server. Hierzu fehlt mir eine Beschreibung. Ist das in Best Practice enthalten?
get <chan> config <device>
a) was soll ich als "device" angeben?
Es muss ein HMCCU I/O Device existieren. Was ist ein HMCCU I/O Device? Ich habe eine HMccu definiert. Das reicht nicht.
b) warum muss ich das Device überhaupt angeben? Kann man das nicht automatisch einsetzen?
get <chan> configdesc <device>
a) das Kommando hat keinen Parameter. Doku und Implementierung sind nicht konsistent
b) Es funktioniert bei mir nicht, mangels external RPC device. Brauche ich das udn wie bekomme ich es?
get <chan> configdesc <device>
Scheinbar habe ich ein grundsätzliches Problem mit einem external RPC device
get <chan> datapoint <datapoint>
liefert kein Ergebnis - keine Reaktion. Wird das Reading upgedated? Sollet ein Fenster aufgehen?
attr <chan> statedatapoint <datapoint>
a) <datapoint> ist der CCU-datapoint, nicht der Umgesetzt. Ist m.E. schade - sollte aber zumindest beschrieben werden. Allerdings ist mir nicht klar, warum ich das brauche. FHEM bietet für State bereits default attribut. Warum nutzt man nicht diese? Was macht statedatapoint anders?
get <chan> devstate
was macht dies? Es ist ein Update readings für genau einen Parameter. macht 'update' nicht das gleich? Ist das Kommando überflüssig?
get <chan> update ...
Die Beschreibung verstehe ich nicht
a) er werden ALLE Datapoints upgedated (sehr gut). Das sollte idR automatisch gehen. Ist also einfach ein manueller Trigger in Sonderfällen. korrekt?
b) With option 'State' the device is queried. Was sagt mir das? Wo soll das Device hin? Ist es ein Device oder der Channel, also schlicht die Entity? Und was wird dann upgedatet - immer noch alle Datapoints?
c)This request method is more accurate but slower then 'Value'.Das ist nun beängstigend. Was bedeutet, dass "Value" nicht akkurat ist? Es kommen manchmal falsche Werte? Ich verstehe den Unterschied schlicht nicht.
In den Beschreibungen wäre es m.E. korrekt zwischen Kanälen und Devices zu unterscheiden. Die Begriffe werden vermischt. Ich nutze (hoffentlich immer :) ) Kanäle, Devices dediziert und entites wenn beides möglich ist.
In der Doku zu HMccu device.list fehlen m.E. ein paar umbrüche für die Lesbarkeit. Mein Vorschlag:
<li><b>get <name> devicelist create <devexp> [t={chn|<u>dev</u>|all}]
[p=<prefix>] [s=<suffix>] [f=<format>] [defattr] [duplicates]
[save] [<attr>=<value> [...]]</b><br/>
create: HMCCU will automatically create client entities for all CCU entities
matching specified regular expression in devexp. <br>
t=chn/dev/all: Creation of entities is limited to CCU channels or devices. dev = default. <br>
prefix/suffix/format: defines a template for entity names in FHEM. All can contain format identifiers which are substituted by corresponding values of the CCU device or
channel: <br>
<li>
%n = CCU object name (channel or device)<br>
%d = CCU device name<br>
%a = CCU address<br>
</li>
Additionally a list of default attributes for the created entities can be specified.<br>
defattr: HMCCU sets default attributes for entities if available. <br>
duplicates: HMCCU will not only create non-existing entites but also overwrite existing entities for existing addresses. <br>
save: auto-save FHEM config after finishing