automatisches erkennen von geräten im netzwerk

[Loredo]

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

[justme1968]

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:

Code Auswählen Erweitern

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.

[Loredo]

Hi André,

mit Bezug auf die Diskussion mit Heiko hier über weiterführende Informationen habe ich überlegt, wie man das sinnvoll auseinander dividieren könnte.
Generische Informationen, die alle gleichwertig sind (quasi eine Link-Sammlung mit Titel und Beschreibungstext) ist natürlich kein Problem.

Nun gibt es aber einige Infos, deren Vorhandensein etwas mehr Aussagekraft hätten. Ich denke da beispielsweise auch an API Infos (cloudfree, openapi - siehe hier), aber auch Informationen zu Hardware Modellen etc. Viele Module führen ja eine solche Liste im Code und arbeiten damit aktiv, aber man kann diese Informationen eben auch wieder nicht von außen über eine standardisierte Schnittstelle auslesen, besonders nicht, ohne ein Device zu definieren.

Um jetzt die Brücke zum Discovery Modul zu schlagen: Ich glaube wenn wes um die API Informationen geht, gehören da auch die Protokollsprachen mit rein, inkl der Info, ob das Device darüber "discoverable" ist. Ich glaube du sagtest, dass du noch keine Idee für eine Struktur in META.json für den Discoverable Bereich hast. Wäre es hier klug die Köpfe zusammenzustecken und mal zu schauen, ob wir das alles unter einen Hut bringen?

Ich blicke nämlich nicht mehr durch, was Models, Types, Subtypes, Characteristics, etc angeht und wann es ein Synonym ist und wann eine eigene Bedeutung... bei Homematic gibt es das ja ebenfalls zuhauf, und noch gleich in mehreren Modulen leicht unterschiedlich.

Bisher bin ich so weit gekommen:

Code Auswählen Erweitern


  "x_product": {
    "vendor": {
      "Stark Industries": {
        "web": "https://www.starkindustries.com",
        "mailto": "contact@starkindustries.com",
        "support_commercial": {
          "mailto": "support@example.com",
          "title": "Stark Support Team",
          "web": "https://support.starkindustries.com"
        },
        "support_community": {
          "title": "Stark Community Support",
          "web": "https://forum.starkindustries.com"
        }
      }
    },
    "api": {
      "cloudfree": true,
      "openapi": true,
      "web": "https://developer.starkindustries.com",
      "protocols": {
        "MQTT": {
          "proprietary": false,
          "discoverable": true
        }
      }
    },
    "types": {
      "typeA": {
        "subTypes": {
        }       
      }
    },
    "models": {     
    }
  }


Meine Absicht war es, dass es bei Type oder Model (so es denn gleichbedeutend wäre) nur eine kleine Standardstruktur gibt, der Modulautor dann aber dort eben auch alle anderen, technischen Spezifika hinterlegen kann, die er später auch im Modulbetrieb braucht, so dass eine doppelte Pflege entfällt. Ideal wäre, wenn (jetzt mal unabhängig vom Aufwand für den Umbau bestehender Module) dann im Quellcode keinerlei Typen/Model spezifischer Informationen mehr in einem internen Hash gespeichert werden müssten.


Comments?