automatisches erkennen von geräten im netzwerk

Thorsten Pferdekaemper · 08 März 2017, 14:52:19

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

Markus Bloch · 08 März 2017, 14:56:41

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.

Thorsten Pferdekaemper · 08 März 2017, 15:05:56

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

zap · 08 März 2017, 18:28:13

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

justme1968 · 01 Januar 2019, 22:53:51

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)

KernSani · 01 Januar 2019, 23:29:08

hänge mich mal rein, weil ich's einen interessanten Ansatz finde...

Thorsten Pferdekaemper · 02 Januar 2019, 08:27:18

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

justme1968 · 02 Januar 2019, 10:15:38

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.

Markus Bloch · 02 Januar 2019, 12:28:06

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

justme1968 · 02 Januar 2019, 12:56:55

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:

Code Auswählen

$hash->{isDiscoverable} = { ssdp => 'xyz', upnp => {manufacturer => 'YAMAHA', modelName => '/.*/', extract =>{ip =>...}, define => 'define <name> <TYPE> <ip>' };

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.

Markus Bloch · 02 Januar 2019, 12:59:58

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

Loredo · 19 Februar 2019, 14:23:14

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.

mumpitzstuff · 20 Februar 2019, 10:32:30

Hänge mich hier mal mit rein...

Loredo · 18 März 2019, 11:22:53

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

justme1968 · 18 März 2019, 13:26:54

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.