automatisches erkennen von geräten im netzwerk

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

Vorheriges Thema - Nächstes Thema

rudolfkoenig

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.

betateilchen

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.

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

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
FUIP

Markus M.

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 7590/7580/546E

HM Aktor/Sensor/Winmatic/Keymatic/Thermostat, HUE, Netatmo Weather/Security/Heating, Xiaomi AirPurifier/Vacuum, Withings Aura/BPM/Cardio/Go/Pulse/Thermo, VSX828, Harmony, Siro ERB15LE
https://paypal.me/mm0

viegener

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

zap

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.

2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

justme1968

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

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

Thorsten Pferdekaemper

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
FUIP

justme1968

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

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

Markus Bloch

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)

zap

#25
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.

2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

Markus Bloch

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)

zap

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, ...).
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

justme1968

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

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

Markus Bloch

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.
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)