Autor Thema: automatisches erkennen von geräten im netzwerk  (Gelesen 2074 mal)

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16894
automatisches erkennen von geräten im netzwerk
« am: 18 Februar 2017, 20:03:48 »
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
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH
Gefällt mir Gefällt mir x 2 Liste anzeigen

Offline Dr. Boris Neubert

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 3738
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #1 am: 18 Februar 2017, 21:03:06 »
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!

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 17092
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #2 am: 18 Februar 2017, 21:15:43 »
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?

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 13521
  • Das "S" in "IoT" steht für "Security"
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #3 am: 18 Februar 2017, 21:31:06 »
Was ich nicht verstehe: die meisten Netzwerkgeraete sollten ein Passwort haben.

die wenigsten Netzwerkgeräte, um die es hier vermutlich geht, haben ein Passwort.
-----------------------
Nächster Hamburg-Stammtisch: 15.12.2017

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16894
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #4 am: 18 Februar 2017, 21:37:56 »
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, ...

FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline Icinger

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1062
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #5 am: 18 Februar 2017, 21:45:52 »
Zitat
ein 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

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16894
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #6 am: 18 Februar 2017, 21:55:06 »
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.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Online Markus Bloch

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 3177
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #7 am: 19 Februar 2017, 03:37:19 »
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)

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3990
  • Finger weg von der fhem.cfg
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #8 am: 19 Februar 2017, 09:04:33 »
Hi,
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

RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16894
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #9 am: 19 Februar 2017, 11:09:13 »
@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
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 13521
  • Das "S" in "IoT" steht für "Security"
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #10 am: 19 Februar 2017, 12:39:50 »
Eine 99_disccoveryUtils.pm, in die alle modulspezfischen discoveryFn() von den zuständigen Modulautoren eingepflegt werden?
-----------------------
Nächster Hamburg-Stammtisch: 15.12.2017

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16894
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #11 am: 19 Februar 2017, 12:43:51 »
ja. daran hatte ich auch schon gedacht. es käme vermutlich auch einen versuch an wie gut das klappt.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3990
  • Finger weg von der fhem.cfg
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #12 am: 19 Februar 2017, 20:37:58 »
Hi,
warum dann nicht gleich 99_discovery<Modulname>.pm ?
Gruß,
   Thorsten
RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 13521
  • Das "S" in "IoT" steht für "Security"
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #13 am: 19 Februar 2017, 20:41:07 »
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.
-----------------------
Nächster Hamburg-Stammtisch: 15.12.2017

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3990
  • Finger weg von der fhem.cfg
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #14 am: 19 Februar 2017, 20:47:56 »
Warum?
RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 17092
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #15 am: 19 Februar 2017, 20:56:24 »
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.

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 13521
  • Das "S" in "IoT" steht für "Security"
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #16 am: 19 Februar 2017, 21:20:49 »
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.

-----------------------
Nächster Hamburg-Stammtisch: 15.12.2017

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3990
  • Finger weg von der fhem.cfg
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #17 am: 19 Februar 2017, 23:18:03 »
Und 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".

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
RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)

Offline Markus M.

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1873
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #18 am: 20 Februar 2017, 11:30:48 »
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
FHEM dev + HomeBridge + Lenovo Flex15 + HM-CFG-USB + RFXtrx433 + Fritz!Box 7490 + FRITZ!Powerline 546E

HM Aktoren/Sensoren/Winmatic/Keymatic/Thermostate, HUE, Netatmo Weather/Security/Heating, Xiaomi AirPurifier/Vacuum, Withings Aura/BPM/Cardio/Go/Pulse/Thermo, VSX828, Harmony
https://paypal.me/mm0

Offline viegener

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3059
    • Meine Seite im fhemwiki
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #19 am: 06 März 2017, 21:47:29 »
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.

Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1519
    • HMCCU
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #20 am: 08 März 2017, 09:10:23 »
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.

CCU2 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
HMCCU: Schnittstelle CCU2 - FHEM (best of both worlds approach)

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16894
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #21 am: 08 März 2017, 09:36:38 »
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.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3990
  • Finger weg von der fhem.cfg
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #22 am: 08 März 2017, 11:10:36 »
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
RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16894
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #23 am: 08 März 2017, 11:15:28 »
kommt. bald. :).
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Online Markus Bloch

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 3177
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #24 am: 08 März 2017, 13:54:39 »
Ich würde für meine Yamaha-Module ebenfalls gerne beisteuern.
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1519
    • HMCCU
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #25 am: 08 März 2017, 14:15:19 »
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.

« Letzte Änderung: 08 März 2017, 14:20:15 von zap »
CCU2 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
HMCCU: Schnittstelle CCU2 - FHEM (best of both worlds approach)

Online Markus Bloch

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 3177
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #26 am: 08 März 2017, 14:19:49 »
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.
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1519
    • HMCCU
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #27 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, ...).
CCU2 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
HMCCU: Schnittstelle CCU2 - FHEM (best of both worlds approach)

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16894
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #28 am: 08 März 2017, 14:30:13 »
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.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Online Markus Bloch

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 3177
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #29 am: 08 März 2017, 14:32:33 »
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.
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3990
  • Finger weg von der fhem.cfg
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #30 am: 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
RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)

Online Markus Bloch

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 3177
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #31 am: 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.
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3990
  • Finger weg von der fhem.cfg
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #32 am: 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
RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1519
    • HMCCU
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #33 am: 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
CCU2 mit diversen Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für den Rest (Sonos, AVR, Meteohub, Beacons, Heizung, Hue)
HMCCU: Schnittstelle CCU2 - FHEM (best of both worlds approach)

 

decade-submarginal