ich spiele gerade mit dem gedanken für ein modul das alle durch fhem steuerbaren geräte im lokalen netz anzeigt und per kopfdruck ein passendes device dafür anlegt. wenn man so etwas direkt auf der start seite einer neuen fhem installation anbietet könnte das den einstieg erleichtern. einige der 'anderen' home automation systeme bieten so etwas an und es macht glaube ich schon etwas her wenn man das gut hin bekommt.
mein problem ist gerade nicht die erkennung an sich. die geht schon für sonos, fritzbox, hue bridge, plex, unifi und einigen anderen.
sondern wie man den code modularisiert so das jedes modul seine eigene such routine mit bringen kann. so etwas ins modul selber z.b. in eine serachFn einzubauen wäre zwar naheliegend, aber leider nutzlos da noch nicht verwendete module natürlich noch nicht geladen sind.
d.h. die frage ist: wie kommt man an eine modul spezifische routine ohne jeweils alle module zu laden und ohne ein zweites file pro modul zu haben.
hat jemand ideen dazu ?
gruss
andre
FHEM-Befehl search oder so, der alle Module lädt und die searchFn aufruft?
Alle Module zu laden ist problematisch, da einige komische Perl-Module brauchen.
Man koennte sie natuerlich als Datei durchsuchen, und im XXX_Iniitalize nach einem SearchFn suchen.
Was ich nicht verstehe: die meisten Netzwerkgeraete sollten ein Passwort haben. Wei geht man damit um?
Zitat von: rudolfkoenig am 18 Februar 2017, 21:15:43
Was ich nicht verstehe: die meisten Netzwerkgeraete sollten ein Passwort haben.
die wenigsten Netzwerkgeräte, um die es hier vermutlich geht, haben ein Passwort.
das erkennen ist unabhängig von irgendwelchen passwörtern oder sonstigen credentials.
geräte lassen sich z.b. per upnp bzw. ssdp oder bonjour oder anderen geräte spezifischen broadcast nachrichten finden. das sind erst mal nur allgemeine dinge wie: ich bin hier, bin vom typ xy, mein name ist xz und vielleicht noch ein icon.
die eigentliche anmeldung ist dann geräte spezifisch gesichert und muss vom modul gehandhabt werden.
sonos braucht tatsächlich kein password. das trifft vermutlich für die meisten media player zu. auf der hue bridge musst du den pairing button drücken, für die fritzbox musst du ein password angeben, plex musst du per myplex account oder pin frei geben, die harmony remotes haben aktuell kein password, ...
Zitatein modul das alle durch fhem steuerbaren geräte im lokalen netz anzeigt und per kopfdruck ein passendes device dafür anlegt.
Wäre das nicht am logischsten im Rahmen des Autocreate aufgehoben?
Ist ja im Prinzip nix anderes, nur eben auf Netzwerk-Basis statt USB.
lg, Stefan
wo es genau landet ist noch offen. im gegensatz zum usb autocreate soll auf jeden fall dazu kommen:
- modularer aufbau, module können ihren eigenen erkennungs code mitbringen
- erkennung über spezifische such routinen passieren. nicht über bloßes rum probieren
- gui das erkannte geräte anzeigt
- autocreate erst auf knopfdruck und mit benutzer interaktion um z.b. passwörter oder andere parameter einzugeben
wenn das dann irgendwann mal funktioniert könnte man überlegen ob man das usb autocreate auch modularisiert.
ein wichtiger unterschied ist das durch die geräte spezifische netzwerk suche keine probleme auftreten sollten wie sie durch das einfache öffnen aller usb devices passieren kann wenn ein gerät nicht damit klar kommt.
Ich meine mich zu erinnern, dass es im Forum mehrfach den Versuch eines UPNP-Moduls zu machen, was eben genau nach FHEM-bekannten Geräten per Broadcast sucht und diese dann via Autocreate anlegt.
Generell ist jedoch das gleiche Problem wie im zweistufigen Modulkonzept. Ohne alle Module in FHEM aktiv zu laden, sind die modulspezifischen Erkennungsroutinen nicht verfügbar und müssen daher in dem entsprechenden Modul implementiert werden oder zumindest in einer zusätzlichen Mapping-Table als separates *.pm File wie bspw. bei HMConfig.pm.
Man müsste zumindest eine Art Match-Regexp für jedes Modul kennen, woran man eine Discover-Antowrt von z.B. einem SONOS Gerät erkennt. Anschließend wird SONOS geladen und bspw. eine DiscoverFn ausgeführt mit den empfangenen Daten, so dass SONOS weitere Parameter extrahieren kann um die Geräte per autocreate anzulegen.
Gruß
Markus
Hi,
Zitat von: justme1968 am 18 Februar 2017, 20:03:48
d.h. die frage ist: wie kommt man an eine modul spezifische routine ohne jeweils alle module zu laden und ohne ein zweites file pro modul zu haben.
meiner Meinung nach ist das schon ein Widerspruch in sich. Ok, man könnte die Dateien wie vorgeschlagen nach einer bestimmten Routine scannen und dann erst laden. ...naja.
Warum wäre es eigentlich so schlimm, mehrere Datein pro Modul zu haben? Wenn man das ganze schön ordnet, dann wäre es gar nicht so schlimm, wenn man mehrere Dateien erlaubt. Z.B. könnte man statt der flachen Liste in <fhem>/FHEM erlauben, dass es Unterverzeichnisse zum jeweiligen Modul gibt.
Alternativ könnte man auch Unterverzeichnisse für verschiedene Aspekte hinzufügen, so wie es z.B. auch für FHEMWEB und TabletUI gemacht wurde. Was spräche z.B. gegen ein Verzeichnis <fhem>/autocreate, in dem modulspezifische Autocreate-Routinen stecken?
Gruß,
Thorsten
@rudi: das irgendwelchen speziellen perl module gebraucht werden wäre kein problem. diese devices würden dann eben nicht automatisch geladen. man müsste auch nicht alle fhem module automatisch laden sondern nur die bei denen es eine discoveryFn gibt.
@Markus Bloch: mit einer art match list ist es leider nicht getan. die module müssen die möglichkeit haben die komplette routine zu implementieren weil das ganze nicht nur mit upnp/ssdp funktionieren soll sondern auch mit anderen ports/adressen/methoden.
das DLNARenderer renderer modul wäre auch ein kandidat für so ein neues nicht blockierendes discovery modul. aktuell wartet es blockierend 1-2minuten. mit dem discovery modul könnte man das nicht blockierend und dynamisch machen und für jedes device das neu erscheint oder sich abmeldet ein event erzeugen.
@Thorsten Pferdekaemper: das ist nicht unbedingt ein widerspuch. man könnte z.b. den modul code nach der entsprechenden routine scannen und nur diese per eval ausführen. das ist halt nicht sehr elegant und je nach kreativität des modulautors muss man eventuell recht viel perl parser implementieren.
ein eigenes unterverzeichniss wäre eine möglichkeit, allerdings würde man dann den code der module läd duplizieren oder zumindest erweitern müssen um diese routinen zu laden. eventuell wird auch code zwischen dem modul und der discovery routine dupliziert.
gruss
andre
Eine 99_disccoveryUtils.pm, in die alle modulspezfischen discoveryFn() von den zuständigen Modulautoren eingepflegt werden?
ja. daran hatte ich auch schon gedacht. es käme vermutlich auch einen versuch an wie gut das klappt.
Hi,
warum dann nicht gleich 99_discovery<Modulname>.pm ?
Gruß,
Thorsten
Weil es keinen Sinn macht, eine Unzahl von Moduldateien auszuliefern, die beim FHEM Start alle automatisch geladen werden und jeweils nur eine einzige Funktion beinhalten.
Warum?
Ich meine betateilchen uebertreibt etwas mit "keinen Sinn", schoen finde ich das aber auch nicht. Und andres Argument mit Code-Dopplung bleibt auch erhalten.
Eine Variation von MatchList waere eine im Modul gefuehrte Liste von Modulnamen, die bei Bedarf geladen werden, um eine bestimmte Funktion aufzurufen. Damit koennte man Reihenfolge und je nach Situation eine Filterung der Module bewerkstelligen. Nachteil: neue Module muessen angemeldet werden, damit der Maintainer sie eintraegt. Das finde ich aber nicht schrecklich.
Zitat von: rudolfkoenig am 19 Februar 2017, 20:56:24
Und andres Argument mit Code-Dopplung bleibt auch erhalten.
Man könnte das aber auch zum Vorteil nutzen.
Da eine 99_....pm zu einem sehr frühen Zeitpunkt beim FHEM Start geladen wird, könnte man darin eine rudimentäre DiscoveryFn() unterbringen, die beim Laden des zugehörigen Echt-Moduls, wenn es denn wirklich benötigt wird, von dessen vollständiger DiscoveryFn() per redefine überschrieben werden kann.
Egal wie die Aufgabe letztendlich gelöst wird, die Funktionalität sollte auf jeden Fall global abschaltbar sein. Es kann nämlich innerhalb eines einzelnen Netzwerkes auch mehrere FHEM Instanzen geben, von denen sich 1..(n-1) überhaupt nicht für vorhandene Netzwerkgeräte interessieren.
Zitat von: rudolfkoenig am 19 Februar 2017, 20:56:24Und andres Argument mit Code-Dopplung bleibt auch erhalten.
Die Code-Dopplung ist doch aber eher eine Folge der Vorbehalte gegen "viele Dateien". Man könnte ja den gemeinsamen Teil in eine eigene Datei auslagern, die dann halt von beiden benutzt wird.
Allerdings müsste man vielleicht erst einmal das Coding konkret sehen. Vielleicht ist es ja gar nicht so "schlimm".
Zitat von: betateilchen am 19 Februar 2017, 21:20:49
Egal wie die Aufgabe letztendlich gelöst wird, die Funktionalität sollte auf jeden Fall global abschaltbar sein. Es kann nämlich innerhalb eines einzelnen Netzwerkes auch mehrere FHEM Instanzen geben, von denen sich 1..(n-1) überhaupt nicht für vorhandene Netzwerkgeräte interessieren.
Soweit ich das verstanden habe, soll das sowieso nicht komplett automatisch ablaufen, sondern im Dialog mit dem Benutzer. D.h. man startet den Prozess, bekommt eine Liste und kann dann wählen, welche man wirklich in (diesem) FHEM haben will.
Gruß,
Thorsten
Idee für einen späteren Schritt 2:
Viele Module die nur über eine API angebunden sind oder ein Passwort benötigen, haben Geräte im Netzwerk die eventuell auch über offene Ports, Header etc. erkennbar sein könnten.
Sent from my iPhone using Tapatalk
Erstmal @justme1968, ich finde die Idee ausgesprochen gut, bin nur erst spät über den Thread gestolpert (worden ;)).
@Thorsten: Die "Discovery" in eine eigene Datei auszulagern (in einem eigenen Verzeichnis) finde ich im ersten Moment am saubersten, denn das parsen von perl-Dateien oder ähnliches wäre wirklich eher unschön.
Codedoppelung müsste es ja nicht geben, das eigentlich Modul könnte ja das discovery-Modul ebenfalls per use ... einbinden und damit den Code nutzen.
Probleme sehe ich eher darin, dass man die Discovery-Module ohne die "schrägen" perl-Module schreiben muss und da müsste sich auch jeder dran halten, sonst hat man wieder Vorraussetzungen für discovery zu erfüllen.
Zitat von: viegener am 06 März 2017, 21:47:29
Probleme sehe ich eher darin, dass man die Discovery-Module ohne die "schrägen" perl-Module schreiben muss und da müsste sich auch jeder dran halten, sonst hat man wieder Vorraussetzungen für discovery zu erfüllen.
Damit würdest Du aber die Module vom Discovery ausschließen, die für den Discovery-Prozess zwingend weitere "schräge Module" (schöner Begriff, wann ist ein Modul schräg?) benötigen. Oder diese Module müssten den Code entsprechend selbst implementieren. Aber was für ein Aufwand.
warum wird etwas ausgeschlossen? jeder darf mit machen der sich an ein paar regeln die bei so etwas nötig sind.
'schräge' module sind oft noch garnicht zur erkennung sondern nur zum define und betrieb nötig. in diesen fällen ist es auch kein problem. die muss man dann zur laufzeit dynamisch laden. das ist auch für fehlermeldungen eigentlich besser.
und wenn sogar die discovery nur per zusatz modul geht lässig so ein gerät halt nur erkennen wenn die module auch installier sind. wo ist das problem? alles andere geht doch trotzdem noch.
Hi,
wie wäre es, wenn wir erst einmal ein paar Beispiele sammeln und entsprechende Erkennungs-Routinen dafür basteln. Dann müssten wir nicht mehr rumtheoretisieren, sondern würden sehen, welche Probleme wirklich auftreten.
Ich könnte vielleicht eine Routine für iRobot Roomba 980 beisteuern.
Gruß,
Thorsten
kommt. bald. :).
Ich würde für meine Yamaha-Module ebenfalls gerne beisteuern.
Prinzipiell könnte ich mir vorstellen, Homematic CCUs, Meteohub-Sever und den ein oder anderen Dienst mit TCP Schnittstelle zu discovern.
Bei solchen Diensten und Geräten mit TCP-Schnittstelle gäbe es auch Synergie-Effekte. Benötigt wird eine Funktion, die (mindestens) das Subnet, in dem sich FHEM befindet, scanned und prüft, ob unter den einzelnen IPs bestimmte Ports erreichbar sind.
Beispiel: Port 2001 erreichbar => evtl. Homematic CCU
Ggf. könnte man diese Scan-Funktion auch noch mit einer abzufragenden URL füttern, die eine verlässlichere Erkennung ermöglicht. Bei Webdiensten reicht der Port alleine sicher nicht.
Gleiches gilt für TCP/telnet Schnittstellen. Auch das könnte man generisch lösen, indem man bestimmte Muster bei einem Connect automatisch einem Gerätetyp zuordnet.
Einen Haken hat das Port-Scanning allerdings: Bei jedem Connect auf einen Port ohne Listener auf der Gegenseite wird auf den Timeout gewartet. Müsste also im Hintergrund laufen.
Einen expliziten Portscan im gesamten Netz sollte eine Software ohne Zustimmung des Users keinesfalls durchführen. Generell sollte man im ersten Schritt sich erstmal auf UPnP beschränken.
Damit schließt Du aber eine Menge Netzwerk Geräte von vorneherein aus, auch solche, die z.B. zar UPNP können, bei denen es aus Sicherheitsgründen aber deaktiviert ist (z.B. meine Fritzbox, mein Pioneer AVR, ...).
ich würde in einem ersten schritt alles unbauen was sich zuverlässig, eindeutig und passiv erkennen lässt.
ein aktives scannen dann in einem zweiten schritt und mit zustimmung.
wenn jemand aus sicherheitsgründen upnp und ähnliches deaktiviert sollte er nicht erwarten das die geräte gefunden werden und will ziemlich sicher keinen unaufgeforderten aktiven scan.
Zitat von: zap am 08 März 2017, 14:26:16
Damit schließt Du aber eine Menge Netzwerk Geräte von vorneherein aus, auch solche, die z.B. zar UPNP können, bei denen es aus Sicherheitsgründen aber deaktiviert ist (z.B. meine Fritzbox, mein Pioneer AVR, ...).
VORSICHT: Ich habe
nicht gesagt, dass sowas nicht durchgeführt werden darf. Ich habe nur angemerkt, dass der User diesem explizit zustimmen sollte und nicht automatisch im Hintergrund ohne wissen des Users das ganze netz gescannt wird.
Hi,
war es nicht sowieso von Anfang an die Idee, das ganze nur mit Benutzer-Interaktion laufen zu lassen?
Soweit ich es verstanden habe soll das ganze vom Benutzer explizit angestoßen warden und wenn es was findet, dann muss der Benutzer auch explizit sagen, dass das entsprechende Gerät angelegt warden soll.
Gruß,
Thorsten
Das durchaus, so habe ich es auch verstanden ;) Ob die Erkennung passiv oder aktiv durch Portscans, Verbinden und Patternmatching erfolgt ist jedoch ein ennormer Unterschied sowohl aus IT-Security-Sicht, als auch der Aufwand der für FHEM dahinter steckt.
Ein aktiver Scan von well-known Geräteports im gesamten Netz kann schnell als Bedrohung erkannt werden.
Tja, da stellt sich die Frage, wie man das handhabt. Mal angenommen, wir lassen das System eine Frage stellen wie "Darf ich IP-Adressen und Ports scannen?". Derjenige, der diese Frage versteht und sie auch tatsächlich "informiert" beantworten kann, braucht den Scan wahrscheinlich nicht...
Gruß,
Thorsten
Ich bin ja bei Markus, wenn es um das Thema Sicherheit geht. Also erst mal rein passiv "sniffen", was sowieso "geschwätzig" ist. Das alleine würde schon vieles vereinfachen.
Beim aktiven Scannen könnte man ja vielleicht so vorgehen:
- Man bietet dem Nutzer eine Auswahl von in FHEM unterstützten Gerätetypen an.
- Der Nutzer hakt die ab, die er gerne integrieren möchte.
- Falls er weiß, welche IP-Adressen die Geräte haben, kann er sie angeben. Dann entfällt der Scan.
- Alternativ gibt der Nutzer einen IP-Range an, den er gerne gescannt hätte oder wählt explizit einen Subnet Scan
Gruß
Dirk
mal ein kurzes update hierzu :)...
ein erster prototyp läuft. zur zeit wird unterstützt:
- ssdp/upnp
- bonjour
- diverse hardware/modul spezifische discovery routinen
die ersten beiden arbeiten generell, module können parametrisierte match regeln angeben um spezifische geräte zu erkennen. letzteres ist modulspezifisch und erfordert im besten fall nur eine minimale änderung an den oft schon vorhandenen routinen. zusätzliche protokolle sind einfach zu ergänzen. alles passiert non blockig im hintergrund.
die von den allgemeinen protokollen gesammelte info steht auch nachträglich komplett zur verfügung und kann von modulen abgefragt werden. damit würden auch blockierende UPnP oder Bonjour libs die zum teil verwendet werden zumindest für die erkennung überflüssig.
module die sinnvoll für die erkannten geräte definiert werden könnten werden in fhemweb angezeigt, es gibt links auf die commandref, eventuell nötige parameter für das deine lassen sich eintragen und auf knopfdruck lässt sich das device dann anlegen.
wenn es bereits ein fhem device gibt wird es mit namen und link auf die detail seite ebenfalls angezeigt.
wenn autocreate deaktiviert ist werden die entsprechenden events ebenfalls gesammelt lassen sich auf knopfdruck anlegen. wenn ein modul statt autocreate den neuen discovery mechanismus unterstützt lassen sich die gefunden 2.stufe devices ebenfalls mit den manuellem eingriff in device namen und parameter anlegen.
die device module haben die wahl was genau angezeigt wird:
- ein 'normales' device
- ein 'bridge' (1. stufe) device (sonos und mPower im screenshot)
- mögliche child (2.stufe) devices die automatisch angelegt werden sobald das bridge device angelegt ist (sonos player, mPower outlets)
- mögliche child (2.stufe) devices die manuell angelegt werden können (im screenshot nicht zu sehen, z.b. hue sensoren nach dem pairing)
für ein device können sich mehr module zuständig fühlen. es werden dann mehrere möglichkeiten in fhemweb angezeigt (fritzbox und fritzboxcallmonitor im screenshot)
hänge mich mal rein, weil ich's einen interessanten Ansatz finde...
Hi,
findet das eigentlich auch ein anderes FHEM im lokalen Netzwerk? Man könnte dann anbieten, das per FHEM2FHEM anzubinden. Für FUIP wäre das auch ganz nett, da ich hier auch mit "entfernten" FHEMs arbeite.
Gruß,
Thorsten
bis jetzt nicht.
aber es wäre kein problem wenn eine fhem installation sich selber über eines der discovery protokolle bekannt macht.
das könnte ohne probleme noch mit ins modul.
Wow Andre,
das sieht ja richtig gut aus. Da habe ich natürlich sofort die erste Frage von Developer zu Developer, wie kann ich das in mein Modul (YAMAHA_AVR) integrieren? Ich weis, dass sich das Gerät per UPnP discovern lässt und würde das dort ebenfalls gerne discovern. Was müsste ich (oder auch Du) dazu machen?
Vielen Dank
Gruß
Markus
kommt demnächst in der ausführlichen beschreibung.
aktuell gibt es zwei möglichkeiten:
- die upnp perl lib verwenden -> schlecht weil blocking
- ssdp/upnp im modul selber implementieren -> hab ich bis schon mehrfach gemacht, blöd weil redundant :(
also beides nicht machen und noch etwas warten :)
demnächst:
- entweder du baust in deine initialize routine etwas in der art ein:
$hash->{isDiscoverable} = { ssdp => 'xyz', upnp => {manufacturer => 'YAMAHA', modelName => '/.*/', extract =>{ip =>...}, define => 'define <name> <TYPE> <ip>' };
d.h. du gibst an welche ssdp und upnp discovery nachricht du matchen willst und welches define kommando dem anwender dafür angeboten werden soll. alles andere geht automatisch. <name> und weiter parameter werden automatisch zu eingabe feldern mit vorausgefüllten defaults. <TYPE> wird automatisch durch den modul TYPE ersetzt, <ip> kommt über den extract teil aus der discovery nachricht.[/li]
- oder wenn das nicht reicht: du kannst in deinem modul auch auf die events aus der discovery reagieren und hast zugriff auf alle daten und kannst dich beliebig austoben was die auswertung angeht. hier ist dann etwas mehr code im modul nötig, vor allem da das modul schon etwas tun muss, ohne das es schon ein device dafür gibt und es somit nicht 'normal' geladen ist. genauso funktionieren auch die device spezifischen discovery protokolle.
der knackpunkt an dem ich gerade noch arbeite ist: wie bekomme ich am elegantesten einzelne felder aus der device info in das define (der extract teil für die ip im beispiel oben) ohne das man im modul code dafür schreiben muss. wahrscheinlich läuft es je nach komplexität auf json, grep und xpath hinaus.
um zu schauen welche info überhaupt da ist gibt es für das discovery device ein paar set und get um zu schauen was alles im cache liegt.
Super, das klingt sehr interessant. Ich freu mich auf das Ergebnis!!!
Dann warte ich mal ab. Bei mir wirds dann wohl die erste Variante werden (Initialize => isDiscoverable).
Viele Grüße
Markus
In diesem Zusammenhang: Toll wäre, wenn man den Discovery-Prozess auch auf einem entfernten Rechner starten könnte, ähnlich wie bei den Node.js Paketen schon.
Dann könnte man den Prozess, der Multicast Pakete o.ä. auf einem direkten Host betreiben, der direkt in dem Netzsegment hängt und müsste nicht zwangsläufig die gesamte FHEM Instanz priviligiert betreiben, nur damit der Netzwerk Zugriff da ist.
Hänge mich hier mal mit rein...
Ist in diesem Zusammenhang auch schonmal darüber nachgedacht worden, wie man dann automatisch ein Device anlegen kann bzw. dem User das per Knopfdruck ermöglicht?
Ich frage deshalb, weil es derzeit ja keine maschinenlesbare Möglichkeit gibt zu erkennen, welche Parameter ein define zwingend und optional erwarten würde und in welcher Notation genau. Einen solchen Button würde ich auch gerne im Installer mit einbauen, aber ein einfaches "define randomName <TYPE>" reicht da ja eben nicht ;-)
im discovery fall ist es so:
ein modul muss folgendes bereit stellen:
- device TYPE, icon, ...
- info über das protokoll anhand dessen geräte im netzt erkannt werden können:
- protokoll (ssdp, bonjour, ...)
- parameter aus dem protokoll die relevant sind (welche bonjour records, welcher teil der ssdp nachricht, quell ip, ...)
- welchen wert diese parameter haben müssen und welchen symbolischen namen sie haben sollen
oder
- perl code der direkt discovery daten liefert
- kommando das ausgeführt werden kann um so ein device anzulegen
- syntax angelehnt an commandref: define <name> <TYPE> <PARAM 1> [<PARAM 2>]
- parameter <...> die klein geschrieben werden darf der anwender ändern
- parameter <...> die gross geschrieben sind werden fest vorgegeben
- optionale parameter stehen in [...]
die infos über das device, aus der protokoll nachricht und den daraus extrahierten parametern werden dann genommen um ein ui zum anlegen des device auf knopfdruck anzuzeigen. werte aus der protokoll nachricht die einen symbolischen namen haben der zu einem parameter aus dem kommando zum anlegen passt werden vorausgefüllt. siehe screenshot weiter oben (war noch ohne optionale felder).
wenn das kommando ein define ... ist wird bei klick der autocreate mechanismus angestossen. ein modul kann aber statt define ... alles angeben was in fhem erlaubt ist. inklisive perl code. dann ohne über autocreate zu gehen.
das funktioniert so weit im prinzip alles. eine der größten baustellen ist die reverse suche. d.h. zu einem per discovery erkannten gerät rauszufinden ob in fhem schon ein device dafür angelegt wurde. das wird gebraucht damit schon angelegte devices nicht immer wieder neu angezeigt werden. das ist nicht in jedem fall komplett automatisch möglich. hier müssen module manchmal nachhelfen.
den eintrag für das create kommando könnte man standardisieren und auch vom installer modul verwenden und vielleicht sogar automatisch in die commandref generieren. ich bin nur noch nicht so weit das format endgültig festzulegen.
Uff, hater Tobak während des Schnitzelkomas ;-)
Zitat von: justme1968 am 18 März 2019, 13:26:54
den eintrag für das create kommando könnte man standardisieren und auch vom installer modul verwenden und vielleicht sogar automatisch in die commandref generieren. ich bin nur noch nicht so weit das format endgültig festzulegen.
Das denke ich mir, ist komplex und das so zu definieren, dass man dann einfach durchsteigt, ist nicht so einfach. Es soll ja auch leicht zu adaptieren sein für bestehende Module ohne große Hemmschwelle, nehme ich an ;)
:) naja... die komplexität hängt vom modul ab bzw kommt daher das so viel wie möglich vorausgefüllt werden soll.
das define template an sich ist einfach und schaut wirklich wörtlich so aus: define <name> <TYPE> <PARAM 1> [<PARAM 2>]
alles in <..> wird zu einem text feld. der text zwischen den <...> wird zum label des input feldes. wenn es noch ein [] drum rum gibt ist das feld optional und muss nicht ausgefüllt werden. d.h. der click darf auch bei leerem feld erfolgen.
im installer fall gibt es ausser TYPE nichts das automatisch gefüllt werden kann und es müsste alles angezeigt werden. egal ob gross oder klein geschrieben.
das einzig wirklich schwierige sind alternativen. die gibt es bei der discovery erst mal nicht.
Hi André,
mit Bezug auf die Diskussion mit Heiko hier (https://forum.fhem.de/index.php/topic,97589.msg929760.html#msg929760) über weiterführende Informationen habe ich überlegt, wie man das sinnvoll auseinander dividieren könnte.
Generische Informationen, die alle gleichwertig sind (quasi eine Link-Sammlung mit Titel und Beschreibungstext) ist natürlich kein Problem.
Nun gibt es aber einige Infos, deren Vorhandensein etwas mehr Aussagekraft hätten. Ich denke da beispielsweise auch an API Infos (cloudfree, openapi - siehe hier (https://forum.fhem.de/index.php/topic,94650.0.html)), aber auch Informationen zu Hardware Modellen etc. Viele Module führen ja eine solche Liste im Code und arbeiten damit aktiv, aber man kann diese Informationen eben auch wieder nicht von außen über eine standardisierte Schnittstelle auslesen, besonders nicht, ohne ein Device zu definieren.
Um jetzt die Brücke zum Discovery Modul zu schlagen: Ich glaube wenn wes um die API Informationen geht, gehören da auch die Protokollsprachen mit rein, inkl der Info, ob das Device darüber "discoverable" ist. Ich glaube du sagtest, dass du noch keine Idee für eine Struktur in META.json für den Discoverable Bereich hast. Wäre es hier klug die Köpfe zusammenzustecken und mal zu schauen, ob wir das alles unter einen Hut bringen?
Ich blicke nämlich nicht mehr durch, was Models, Types, Subtypes, Characteristics, etc angeht und wann es ein Synonym ist und wann eine eigene Bedeutung... bei Homematic gibt es das ja ebenfalls zuhauf, und noch gleich in mehreren Modulen leicht unterschiedlich.
Bisher bin ich so weit gekommen:
"x_product": {
"vendor": {
"Stark Industries": {
"web": "https://www.starkindustries.com",
"mailto": "contact@starkindustries.com",
"support_commercial": {
"mailto": "support@example.com",
"title": "Stark Support Team",
"web": "https://support.starkindustries.com"
},
"support_community": {
"title": "Stark Community Support",
"web": "https://forum.starkindustries.com"
}
}
},
"api": {
"cloudfree": true,
"openapi": true,
"web": "https://developer.starkindustries.com",
"protocols": {
"MQTT": {
"proprietary": false,
"discoverable": true
}
}
},
"types": {
"typeA": {
"subTypes": {
}
}
},
"models": {
}
}
Meine Absicht war es, dass es bei Type oder Model (so es denn gleichbedeutend wäre) nur eine kleine Standardstruktur gibt, der Modulautor dann aber dort eben auch alle anderen, technischen Spezifika hinterlegen kann, die er später auch im Modulbetrieb braucht, so dass eine doppelte Pflege entfällt. Ideal wäre, wenn (jetzt mal unabhängig vom Aufwand für den Umbau bestehender Module) dann im Quellcode keinerlei Typen/Model spezifischer Informationen mehr in einem internen Hash gespeichert werden müssten.
Comments?