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

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

Offline 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)

Offline 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

Offline 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)