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

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18932
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: 4428
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: 20192
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: 15744
  • s/fhem\.cfg/configDB/g
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.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18932
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: 1177
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: 18932
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: 3551
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: 5278
  • 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: 18932
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: 15744
  • s/fhem\.cfg/configDB/g
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?
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18932
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: 5278
  • 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: 15744
  • s/fhem\.cfg/configDB/g
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.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5278
  • 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: 20192
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: 15744
  • s/fhem\.cfg/configDB/g
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.

-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5278
  • 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: 2624
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 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

Offline viegener

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3689
    • 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

Online zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2690
    • 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.

2xCCU3, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18932
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: 5278
  • 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: 18932
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: 3551
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)

Online zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2690
    • 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 »
2xCCU3, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach

Online Markus Bloch

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 3551
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)

Online zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2690
    • 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, ...).
2xCCU3, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18932
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: 3551
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: 5278
  • 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: 3551
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: 5278
  • 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)

Online zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2690
    • 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
2xCCU3, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18932
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #34 am: 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)
« Letzte Änderung: 02 Januar 2019, 12:58:57 von justme1968 »
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 3 Liste anzeigen

Online KernSani

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2754
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #35 am: 01 Januar 2019, 23:29:08 »
hänge mich mal rein, weil ich's einen interessanten Ansatz finde...
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Offline Thorsten Pferdekaemper

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

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18932
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #37 am: 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.
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 1 Liste anzeigen

Online Markus Bloch

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 3551
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #38 am: 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
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 justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18932
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #39 am: 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:
$hash->{isDiscoverable} = { ssdp => 'xyz', upnp => {manufacturer => 'YAMAHA', modelName => '/.*/', extract =>{ip =>...}, define => 'define <name> <TYPE> <ip>' };
    d.h. du gibst an welche ssdp und upnp discovery nachricht du matchen willst und welches define kommando dem anwender dafür angeboten werden soll. alles andere geht automatisch. <name> und weiter parameter werden automatisch zu eingabe feldern mit vorausgefüllten defaults. <TYPE> wird automatisch durch den modul TYPE ersetzt, <ip> kommt über den extract teil aus der discovery nachricht.[/li]

  • 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.
« Letzte Änderung: 02 Januar 2019, 13:00:58 von justme1968 »
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 1 Liste anzeigen

Online Markus Bloch

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 3551
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #40 am: 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
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 Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3190
  • ~ Challenging Innovation ~
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #41 am: 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.
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1
Zustimmung Zustimmung x 1 Liste anzeigen

Online mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1322
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #42 am: 20 Februar 2019, 10:32:30 »
Hänge mich hier mal mit rein...

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3190
  • ~ Challenging Innovation ~
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #43 am: 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 ;-)
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18932
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #44 am: 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.
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 Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3190
  • ~ Challenging Innovation ~
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #45 am: 18 März 2019, 14:03:18 »

Uff, hater Tobak während des Schnitzelkomas ;-)

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.


Das denke ich mir, ist komplex und das so zu definieren, dass man dann einfach durchsteigt, ist nicht so einfach. Es soll ja auch leicht zu adaptieren sein für bestehende Module ohne große Hemmschwelle, nehme ich an ;)
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18932
Antw:automatisches erkennen von geräten im netzwerk
« Antwort #46 am: 18 März 2019, 14:10:47 »
:) naja... die komplexität hängt vom modul ab bzw kommt daher das so viel wie möglich vorausgefüllt werden soll.

das define template an sich ist einfach und schaut wirklich wörtlich so aus: define <name> <TYPE> <PARAM 1> [<PARAM 2>]
alles in <..> wird zu einem text feld. der text zwischen den <...> wird zum label des input feldes. wenn es noch ein [] drum rum gibt ist das feld optional und muss nicht ausgefüllt werden. d.h. der click darf auch bei leerem feld erfolgen.

im installer fall gibt es ausser TYPE nichts das automatisch gefüllt werden kann und es müsste alles angezeigt werden. egal ob gross oder klein geschrieben.

das einzig wirklich schwierige sind alternativen. die gibt es bei der discovery erst mal nicht.

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