AutoCreate versus "New discovered Devices"-Liste

[gvzdus]

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

Code: [Auswählen]

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.

[betateilchen]

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?

[gvzdus]

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.

[betateilchen]

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.

[rudolfkoenig]

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.

[rudolfkoenig]

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.

[gvzdus]

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.

[rudolfkoenig]

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

[gvzdus]

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.

[Adimarantis]

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

[justme1968]

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.

[gvzdus]

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.

[Adimarantis]

Hi,

Nachdem ich gerade eine zweite Instanz mit einem RFXTRX433 in Betrieb genommen habe, bin ich wieder auf das Problem gestossen das einerseits über autocreate ein Haufen Spam reinkommt, ich aber andererseits schon Interesse habe das zu sehen (vielleicht hat der Nachbar ja was Interessantes).

Meine konkrete Erweiterungsidee für autocreate wäre eine Art "autocleanup"

Dazu müsste man zuerst mal in der Lage sein, zu erkennen welche Devices überhaupt von Autocreate erzeugt wurden.

Möglichkeiten:
-Attribute "autocreate" mit Datum der Erstellung welches dann aber der Anwender löschen müsste wenn ein Device übernommen wird, damit es bei Inaktivität nicht versehentlich gelöscht wird
-device_room nutzen (alles da drin wäre dann betroffen) - braucht aber dann trotzdem zumindest ein INTERNAL "created" mit Datum - sobald man den Raum ändert wäre das Device dann sicher

Dann braucht es ein Attribut für die maximale Inaktivität (in Tagen?), womit der cleanup eingeschaltet wird.

Autocreate müsste dann über Timer täglich einen Cleanup triggern. Alle betroffenen Devices werden überprüft auf
-"state" reading seit X Tagen nicht mehr aktualisiert
-kein "state" reading vorhanden und seit dem autocreate mehr als X Tage vergangen

Zugegeben, finde ich beide Varianten nicht perfekt, aber zumindest einfacher zu implementieren als ein kompletter Autocreate-Manager wie eingangs beschrieben.

Ich wäre aber erstmal auch zufrieden wenn autocreate zumindest ein "created" Datum erzeugen würde, was unerlässlich ist um alte Devices zu finden die noch nie einen gültigen "state" hatten.
Dann könnte ich mir einen eigenen Löschprozess schreiben.

Jörg

[KölnSolar]

Irgendwie verstehe ich die Problematik nicht so ganz. 

Mein autocreate-device hat das attr device_room gesetzt. Dort landen dann sämtliche neuen devices. Das ist doch sehr übersichtlich und eindeutig. So erkenne ich z.B. die longid von Funksensoren nach einem Batteriewechsel und kann mein device entsprechend anpassen.

Problematisch wird es vielleicht beim save config. Das mache ich aber nie, so dass beim restart dieser Raum erst einmal leer ist. Wer es braucht, kann ja vor dem save ein delete room=device_room machen.

wenn KölnSolar schon beim DLNA-Modul über Performance-Verbesserungen nachdenkt.

Das hat aber mit einer autocreate-Thematik nichts zu tun. Bei DLNA(UPNP) ist das Problem, dass HTTP-Zugriffe blockierend in einem Standardmodul stattfinden.

Grüße Markus

[Adimarantis]

So ähnlich mache ich es derzeit auch. Möchte aber geziehlt manche Devices weiter "beobachten" und alten Schrott bei dem schon ewig keine Daten gekommen sind löschen (und da eben nicht in Handarbeit).

Da würde ich so ein "created" Datum jetzt als einen guten Kompromiss sehen - das tut niemandem weh, könnte aber allgemein interessant sein um zu sehen, wann das Autocreate stattgefunden hat.

Jörg