Autor Thema: AutoCreate versus "New discovered Devices"-Liste  (Gelesen 662 mal)

Offline gvzdus

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 720
AutoCreate versus "New discovered Devices"-Liste
« am: 20 Januar 2021, 21:52:00 »
Ich verschiebe die Diskussion aus ShellyMonitor hierhin.

Das Problem:
Mit "autocreate" liegt ein schöner Mechanismus (autosave / FileLog / Room) vor, um Geräte neu anzulegen. Aber manche schalten ihn ab (wenn sie wissen, wo). Weil sie aus guten Gründen (Geräte des Nachbarn, Fehler, "gleich einen guten Namen wählen") lieber selber über das Ob und Wie entscheiden wollen.

Überlegung:
Module, die neue Geräte erkennen können (MQTT-Server, MAX, ShellyMonitor, HUE, UPnP (?) u.v..m.) melden diese erkannten Geräte an einem zentralen Modul wie autocreate an. Die "Noch-Nicht-Geräte" tauchen in einer Gerätelistenansicht wie bei ShellyMonitor auf (Alternative: Ein Room, die Geräte sind "real", aber werden über "ignore" unterdrückt). Der Benutzer kann diese Liste einsehen und den Einrichtungsvorgang triggern, oder aber über ein permanentes Ignore entscheiden. Bei der Einrichtung kann er mindestens den Gerätenamen wählen, ggf. aber auch interaktiv weitere Attribute wie bei MQTT.

Details:
Der Funktionsaufruf sollte auch Attribute mitliefern, der Zeitstempel sollte erfasst werden, vielleicht noch ein Text und oder ein Link zu einer Anleitung für die Einbindung des Gerätes. Beispiel: Unter /dev/serial/by-id/ taucht
usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_...auf. Unter UPnP plärrt eine HUEBridge oder deConz. *So* viele Möglichkeiten, was das wohl für den FHEM-Anwender als Vorschlag bedeuten könnte, gibt es nicht.
Prinzipiell werden UPnP / Broadcast - Detektoren ja teils mehrmals pro Minute das gleiche Gerät sehen. Es sollte im AutoCreate einen Schnellcheck über einen (Hash-)Key geben: "Habe ich Dir den schon gemeldet?", um zu verhindern, dass die komplexe Struktur für das Anlegen regelmäßig neu geschrieben wird.
Es sollte eine TTL geben, die mit angemeldet wird. Eine Abfrage auf den Hashkey verlängert diese TTL. So verschwindet der Fehler / Nachbar mit dem MAX in der Tasche kurz am Haus vorbeigegangen auch wieder aus der Liste.

Soviel einmal als Überleitung aus dem ShellyMonitor-Thread und Ergänzung.
Gefällt mir Gefällt mir x 3 Liste anzeigen

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 17095
  • s/fhem\.cfg/configDB/g
Antw:AutoCreate versus "New discovered Devices"-Liste
« Antwort #1 am: 20 Januar 2021, 23:52:44 »
Mit "autocreate" liegt ein schöner Mechanismus (autosave / FileLog / Room) vor, um Geräte neu anzulegen.

Aber doch nur, wenn es auch ein autocreate-device in der FHEM Installation gibt. Oder redest Du von etwas anderem?
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Lesen gefährdet die Unwissenheit!

Offline gvzdus

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 720
Antw:AutoCreate versus "New discovered Devices"-Liste
« Antwort #2 am: 21 Januar 2021, 07:50:25 »
Wenn man FHEM für Raspian / Debian nach Anleitung installiert (über deb http://debian.fhem.de/nightly/ / in der sources.list), dann ist das autocreate-Device von Haus aus da.

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 17095
  • s/fhem\.cfg/configDB/g
Antw:AutoCreate versus "New discovered Devices"-Liste
« Antwort #3 am: 21 Januar 2021, 09:50:55 »
Das Löschen des autocreate und des initialUsbCreate ist bei mir eine der ersten Aktivitäten nach der Installation eines frischen FHEM.

Und wer ein "frisches" FHEM direkt mit configDB installiert, hat die beiden devices erstmal gar nicht in der Konfiguration.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Lesen gefährdet die Unwissenheit!

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 23667
Antw:AutoCreate versus "New discovered Devices"-Liste
« Antwort #4 am: 21 Januar 2021, 10:05:56 »
autocreate ist in der ausgelieferten fhem.cfg da, manche "Influencer", die es scheinbar besser wissen, raten leider zu dessen Deaktivierung.
Etliche meiner Module (ZWave, MQTT2*) haengen von einem vorhandenen Instanz ab, und ich habe schon viel Supportaufwand gehabt wegen abgeschalteten autocreate.

Zu den Vorschlaegen:
- den zugewiesenen Raum kann man in autocreate auch jetzt setzen, default ist %TYPE
- neu erkannte Geraete von vornherein mit ignore zu begluecken mag fuer erfahrene Benutzer und eine "fertige" FHEM-Installation die Wahl sein, fuer Anfaenger und Support (d.h. wir) wird es aber ein Albtraum sein. Bin aber nicht abgeneigt, ueber zusetzliches autocreate Attribut sowas zu erlauben
- wir koennen auch eine Moeglichkeit schaffen, mit autocreate die neuen Namen zu vergeben, ich meine aber, dass der Modulautor das besser steuern kann.
- Module koennen "schon immer" ueber $moduleHash->{AutoCreate} {ATTR} weitere Attribute fuer neu angelegte Geraete vergeben.
- gegen "voruebergehende"  Signale gibts das Attribut autocreate_threshhold, auch ueber $moduleHash konfigurierbar

Wir koennen autocreate gerne erweitern (dann bitte konkrete Probleme beschreiben), ich habe auch kein Problem mit einem neuen autocreate Modul: die Funktionalitaet ist nicht hartkodiert, es reicht global:UNDEFINED zu ueberwachen.

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 23667
Antw:AutoCreate versus "New discovered Devices"-Liste
« Antwort #5 am: 21 Januar 2021, 10:12:11 »
Zitat
Es sollte im AutoCreate einen Schnellcheck über einen (Hash-)Key geben: "Habe ich Dir den schon gemeldet?", um zu verhindern, dass die komplexe Struktur für das Anlegen regelmäßig neu geschrieben wird.
Das ist nicht die Aufgabe von AutoCreate, sondern des Moduls, das die Roh-Signale interpretiert.
Und genau deswegen sollte das Geraet immer angelegt werden.

Offline gvzdus

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 720
Antw:AutoCreate versus "New discovered Devices"-Liste
« Antwort #6 am: 21 Januar 2021, 11:33:01 »
Gut, dann lass' uns doch noch einmal "beim Groben" bleiben:
Meine Vorstellung ist, dass ein erkanntes Gerät 3 Zustände haben kann:
  • Normal eingerichtet
  • Erkannt, aber noch der Nutzerentscheidung über die Einrichtung harrend
  • Erkannt, und der Benutzer hat "ignore" entschieden (muss die Entscheidung aber rückgängig machen können)

Du sagst nun, "bitte in jedem Fall als Gerät anlegen - wir können über Attribute (o.ä.) nachdenken, wie 2) und 3) ausgedrückt werden können" Richtig?. Das führt aber in jedem Fall dazu, dass ein Funkrülpser / Fehler / Nachbar ein Gerät anlegt, wenn auch in Gruppe 2. Inklusive ggf. AutoSave u.s.w. Ich will jetzt nicht über den Betrieb von FHEM in einem public Hotspot / freifunk spekulieren, aber eventuell kommt auf MultiCast eine Menge Musik rein, wenn KölnSolar schon beim DLNA-Modul über Performance-Verbesserungen nachdenkt. Außerdem sollte die TTL mit rein - also auch das automatische Löschen, wenn das Gerät sich als transient erweist. Bist Du Dir da sicher, dass in jedem Fall das Ganze ein Gerät sein sollte?

Punkt 2) Ich habe mir bei ShellyMonitor mit dem Cache und Co. ja bis vorgestern gehörig die Karten gelegt. Deswegen die Überlegung: Das einzelne gerätedetektierende Modul sollte diesen Cache inkl. Expiry möglichst zentral delegieren können.

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 23667
Antw:AutoCreate versus "New discovered Devices"-Liste
« Antwort #7 am: 21 Januar 2021, 12:08:28 »
Zitat
Das führt aber in jedem Fall dazu, dass ein Funkrülpser / Fehler / Nachbar ein Gerät anlegt, wenn auch in Gruppe 2.
Wenn Funkruelpser beim Protokoll ueblich sind, dann kann man autocreate_threshold setzen.

Ich versuche es anders zu formulieren, offensichtlich war ich vorhin zu kurz oder ich habe was nicht verstanden.

Wenn wir per autocreate _keine_ FHEM-Instanzen anlegen wollen, dann muessen wir:
- eine zentrale Datenstruktur schaffen, die diese Daten enthaelt
- eine Moeglichkeit schaffen, diese Datenstruktur vom Benutzer zu manipulieren (list, rename, delete, etc)
- _ALLE_ Module erweitern, damit bei eingehenden Nachrichten diese Datrenstruktur geprueft wird, da nur die Module koennen entscheiden, ob eine FHEM-Representation existiert oder nicht.

Alternativ sammelt ein manual-autocreate Modul die "global:UNDEFINED" Zeilen, um diese vom Benutzer genehmigen zu lassen, bzw. TTL zu spielen.

Das manuelle Anlegen bereitet manchen Modulen Kopfschmerzen: bei ZWave wird die Inklusion vom Benutzer initiiiert, beim Funkaustausch erst das Geraet angelegt, und dann "befragt", um die notwendigen Eigenschaften zu bekommen. Nach manuellen Anlegen muesste der Benutzer alle diese Fragen selbst durchfuehren, oder es muesste ein "delayed initialization" aufgefuehrt werden. Machbar, aber aufwendig. Bei Geraeten, die sich nach der Inklusion schlafenlegen (und nicht zuhoeren) wird noch bunter, mit vielen "eigentlich ja, aber".


Offline gvzdus

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 720
Antw:AutoCreate versus "New discovered Devices"-Liste
« Antwort #8 am: 21 Januar 2021, 12:48:46 »
Ja, bis auf zwei Bemerkungen:
  • Nicht alle Module unterstützen heute autocreate. Natürlich müsste "Delayed creation on user permission" nicht zwingend von allen Modulen unterstützt werden.
  • "list, rename, delete": Ich dachte da eher an GUI, und statt "rename" wäre es eher "create with name", und statt delete ein "Status ignore"
Und ja: Eine Alternative wären GLOBAL:UNDEF-Events wie heute, allerdings eben als Super-Struktur mit vorgeschlagenen Attributen / attrTemplates, einer TTL, u.s.w.

Offline Adimarantis

  • Developer
  • Full Member
  • ****
  • Beiträge: 250
Antw:AutoCreate versus "New discovered Devices"-Liste
« Antwort #9 am: 23 Januar 2021, 12:18:07 »
Hallo,

Ich fände eine zentrale Sammelstelle für neue Devices statt autocreate durchaus interessant.
Mein Nachbar bombardiert mich z.B. mit massig Devices die von meinem rfxtrx433 empfangen werden. Da habe ich jetzt schon eine recht lange Exclude Liste, mit der Gefahr, dass ich das ich irgendwann mal ein gewolltes Device verpasse (und neugierig was in der Nachbarschaft so läuft bin ich irgendwie auch). Der threshold hilft auch nicht viel, da ich diese sehr zuverlässig empfange. Und bei manchen scheint mir fast so, als würden sich IDs manchmal ändern.
Anstatt jetzt ungenutzte Devices im Autocreate Ordner aufzusammeln (was relativ unübersichtlich ist), wäre eine konsolidierte Liste ähnlich des ShellyMonitor schon schick.
Da sollte dann Device Name, Device Typ, Zeitstempel zuletzt gesehen, Eventzähler und z.B. ein Button "Create" und einer "Ignore" stehen.
Create nutzt dann die (gecachten) Daten die auch Autocreate verwendet hätte um das Device zu erstellen, Ignore versteckt den Eintrag in der Liste (mit der Möglichkeit irgendwo mit "show ignored entries" wieder dran zu kommen. Genauso wäre ein Cleanup ("delete devices not seen for xx days") interessant.
Falls es beim Create noch Nutzerinteraktion geben soll, könnte man hier ein (optionales) Callback anbieten.

my 2 cents...
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL
70+ Homematic/HMIP, Diverse 433Mhz Sensoren und Schalter
Module: 52_I2C_ADS1x1x (offiziell), 50_Signalbot, 50_SPI_MAX31865

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 20558
Antw:AutoCreate versus "New discovered Devices"-Liste
« Antwort #10 am: 23 Januar 2021, 15:13:27 »
ich hatte hier: https://forum.fhem.de/index.php/topic,67368.msg880001.html#msg880001 schon mal etwas in dieser richtung angefangen. komme aber leider nicht dazu damit weiter zu machen.

die idee dahinter ist das suchen von geräten und das automatische oder manuelle anlegen zu trennen. die suche wäre zentral implementiert und über modul spezifische plugins erweiterbar, module können sich dann für bestimmte gefundenen geräte anmelden und der benutzer kann dann entscheiden welche davon automatisch angelegt werden sollen und welche nur manuell nach dem auch noch variable parameter gesetzt werden können.

die zentrale suche kann z.b. von haus aus ssdp/upnp und bonjour und die module melden über eine art client liste an fhem für welche gefunden geräte sie zuständig sein wollen. wenn die devices keinen solchen generellen mechnismus unterstützen kann ein modul code in die zentrale suche einhängen auch ohne das das betreffende modul schon geladen ist weil es ein passendes device schon gibt.

im anderen thread ist dazu schon etwas mehr erklärt.
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 gvzdus

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 720
Antw:AutoCreate versus "New discovered Devices"-Liste
« Antwort #11 am: 23 Januar 2021, 17:47:18 »
Wow!! Ja, so ziemlich genau das!

Du hast das Modul aber nie irgendwo schon mal publiziert, damit nicht wieder wie bei alexa-fhem so ein Hans-Wurscht daher kommt, sagt "ich forke das jetzt und mache daraus einen allgemeinen FHEM-Skill für Alexa"?
:-)

Ich habe mich noch nicht intensiv mit UPnP befasst. Die Shellys könnte man genauso gut auch über mDNS erkennen, und auf Port 5353 ist halt mehr zu finden.