+ Antworten
Ergebnis 1 bis 2 von 2
  1. #1
    Registriert seit
    Feb 2017
    Beiträge
    1,317

    Standard Feinheiten der Modul-Reviews

    Dieser Beitrag soll all die Kleinigkeiten sammeln, welche uns bei Reviews auffallen, die nicht direkt in den Richtlinien stehen, die uns allerdings bei Reviews auffallen und welche wir auch in Reviews einfließen lassen möchten. Diese "Kleinigkeiten" möchte ich hier vorstellen und mit euch diskutieren. Nach einiger Zeit, hoffentlich nachdem hier ein Konsens erreicht wurde, werden diese dann auch mit in die Dokumentation übernommen. Weitere Punkte werden hier also hinzugefügt, wenn uns im Reviewprozess mögliche Komplikationen auffallen, welche allerdings noch nicht von den Richtlinien abgedeckt sind oder zumindestens nicht ausreichend abgedeckt sind.

    Wenn euch hier auch Punkte auffallen, dann schreibt gerne. Wir nehmen dazu dann gerne Stellung und passen bei Bedarf die Richtlinien an.


    Das erste Thema hier soll das Configurator-Element sein. Üblicherweise hat dies nur etwas in Discovery- und Konfigurator-Instanzen zu suchen. Dies liegt daran, dass Benutzer hier einen Erwartungswert haben. Die komfortable Erstellung von Instanzen erfolgt erfahrungsgemäß über diese Instanztypen, daher sollte dies auch möglichst so umgesetzt werden.

    Im Zusammenhang mit Untergeräten kann dies möglicherweise ein wenig aufgelockert werden. Hier gehen wir von einem Gerät aus, welches eines oder mehrere Untergeräte hat. Dies kann beispielsweise eine Basisstation mit dazugehörigen Aktoren und Sensoren sein. Soll hierfür das Configurator-Element genutzt werden, so sehen wir hier zwei Möglichkeiten:

    1. Die Untergeräte funktionieren (zumindest funktional) ohne Basisgerät
    In diesem Fall sollte der Konfigurator als eigene Konfigurator-Instanz angelegt werden. Hier können dann alle Geräte erstellt werden, sowohl die Basis- als auch die Untergeräte. Möchte man hier die Zugehörigkeit von Basis- und Untergeräten verdeutlichen, so kann man den Konfigurator beispielsweise baumartig darstellen. Diese Möglichkeit trifft auch dann zu, wenn die Funktionen ohne Basisgerät eingeschränkt sind oder es auch einfach "keinen Sinn ergibt ohne Basisstation zu arbeiten", so lange dies nur rein funktional möglich ist

    2. Die Untergeräte funktionieren nicht ohne Basisgerät
    Wenn die Untergeräte ohne dazugehörige Basis überhaupt nicht funktionieren, so kann man auch innerhalb der Basisgeräte einen Konfigurator anbieten, welcher die Untergeräte erstellen kann. Dies darf dann passieren, obwohl es sich beim Basisgerät nicht um eine Discovery- oder Konfigurator-Instanz handelt. Hier ist es allerdings schön, einen übergeordneten Konfigurator anzubieten, welcher die Basisgeräte erstellt. Ein aktuelles Beispiel hierfür wären die Z-Wave-Geräte mit SubChannels. Tritt dieser Fall ein, so sollte allerdings noch einmal geprüft werden, ob es nicht Sinn ergibt, alle Funktionen innerhalb einer Instanz zusammenzufassen.

  2. #2
    Registriert seit
    Feb 2017
    Beiträge
    1,317

    Da hier nachgefragt wurde: Bei Basisgeräten meine ich Geräten, die auch von sich aus Funktionalität anbieten. Ein reiner "Vermittler" als Basisstation ist ein Splitter und sollte somit keinen Konfigurator beinhalten.

Ähnliche Themen

  1. Modul zur Nutzung der Raspberry Pi GPIO
    Von JPaeper im Forum PHP-Module
    Antworten: 1165
    Letzter Beitrag: 07.09.19, 17:09
  2. Antworten: 5
    Letzter Beitrag: 09.12.18, 16:56
  3. RaZberry2-Modul in der SymBox
    Von harry28 im Forum Z-Wave
    Antworten: 2
    Letzter Beitrag: 02.02.18, 17:51
  4. Probleme bei der Modul Installation
    Von Alexxx2005 im Forum Entwicklung mit PHP-SDK/Delphi-SDK
    Antworten: 4
    Letzter Beitrag: 01.06.17, 20:28