automatisches erkennen von geräten im netzwerk

Begonnen von justme1968, 18 Februar 2017, 20:03:48

Vorheriges Thema - Nächstes Thema

justme1968

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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Dr. Boris Neubert

FHEM-Befehl search oder so, der alle Module lädt und die searchFn aufruft?
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

rudolfkoenig

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?

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

justme1968

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

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Icinger

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
Verwende deine Zeit nicht mit Erklärungen. Die Menschen hören (lesen) nur, was sie hören (lesen) wollen. (c) Paulo Coelho

justme1968

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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Markus Bloch

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

Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Thorsten Pferdekaemper

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

FUIP

justme1968

@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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

betateilchen

Eine 99_disccoveryUtils.pm, in die alle modulspezfischen discoveryFn() von den zuständigen Modulautoren eingepflegt werden?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

justme1968

ja. daran hatte ich auch schon gedacht. es käme vermutlich auch einen versuch an wie gut das klappt.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Thorsten Pferdekaemper

Hi,
warum dann nicht gleich 99_discovery<Modulname>.pm ?
Gruß,
   Thorsten
FUIP

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Thorsten Pferdekaemper

FUIP