Modulerstellung - zwei Grundsatzfragen (Z-Wave, HC3)

Hallo,

Ich habe zur Zeit meine ZWave-Geräte über ein Fibaro HC3 an IPS angebunden. Dazu habe ich einige Scripte geschrieben, die auch das Erstellen von Geräten im Baum und das Erkennen bereits erstellter Geräte handhaben. Auch wird die Kommunikation über REST-API und WebHook in diesen Scripten durchgeführt. So weit so gut und relativ einfach zu erstellen aber relativ aufwändig in der Wartung. Nun will ich mal versuchen ein Modul zu erstellen in der Hoffnung das ganze etwas komfortabler zu gestalten. Da ich aber nur ein Hobbyprogrammierer bin und da auch nicht so viel Zeit investieren kann, läuft das Ganze nur auf Sparflamme.
Vielleicht kann mir aber trotzdem jemand bei einigen Grundsatzfragen helfen (die Entwicklerwebinare habe ich mir schon angesehen).

Das erste Thema betrifft die Gestaltung der Geräte-Module. Ich bin am überlegen, ob ich ein einziges ZWave-Device erstelle (wie das auch im HomeMatic-Modul umgesetzt ist), welches alle Gerätevarianten darstellen kann, oder ob ich für jede Gerätevariante ein eigenes Modul erstelle (wie es z.B. bei Enocean umgesetzt ist).
Ich selbst tendiere zur zweiten Variante, da die Geräte hier kompakter sein können und besser zu pflegen sind. Ich sehe da aber auch noch Lernbedarf beim Datenfluss. Gibt es hier Präferenzen?

Das zweite Thema betrifft den Datenfluss. Ich arbeite zur Zeit mit einem zweigleisigen Datenaustausch. Geräte werden über die REST-API erkannt und die Daten der Geräte ausgelesen. Auch werden Schaltbefehle über die Rest-API gesendet.
Aus performancegründen habe ich für das Empfangen von Ereignissen und die Änderungen von Werten ein WebHook in IPS hinterlegt, der von einem virtuellen Gerät im HomeCenter (einem LUA-Programm) bedient wird.
Meine Frage nun dazu, benötige ich für diese zwei Kommunikationspfade auch zwei IO-Module / Splitter?

vielleicht kann mir ja jemand ein paar Tipps zu den Themen geben

viele Grüße und schon mal vielen Dank
cervicor

Das kommt immer stark auf die genutzten APIs an.
Wenn die Daten immer im gleichen Format eintreffen und sich z.b. aus einen Key/Value Paar eine Statusvariable und Wert ableiten lassen, dann nur ein generisches Device Modul wie HM.
Muss aber, wie bei Enocean, der Datenblock noch dedizierte nach Hardware zerlegt werden, dann machen mehrere Device Module Sinn.

Nein.
Der Webhook selbst steht außerhalb vom Datenfluss.
Somit kannst du einen IO bauen, welcher z.b. mit curl die Rest-API bedient und gleichzeitig einen Webhook nutzen um die Events in den IO zu bekommen.
Michael

Danke NAll-chan für die schnelle Antwort.

Ich bekomme vom HomeCenter ein JSON mit allen Daten für alle Geräte. Hier aber natürlich für jeden Gerätetyp andere Werte. Deshalb werden auch immer andere Werte in einem Device angezeigt. Gerade bei RGBW-Controllern sind hier manchmal auch noch spezielle Nachverarbeitungen notwendig. Deshalb habe ich auch in meinen Scripts verschiedene Geräte erstellen lassen. Es spricht also nichts dagegen das auch bei den Modulen so zu machen?

Das Thema „WebHook aus einem Modul ansprechen“ werde ich mir zu gegebener Zeit wohl nochmal genauer zu Gemüte führen müssen :face_with_monocle:

viele Grüße
cervicor

Nein, da spricht nichts gegen.
Wenn es aber viel redundanten Code gibt, kann über Vererbung der PHP-Klassen das effektiv gelöst werden.

Ist ja eher umgekehrt. Das Modul registriert nur den Hook und die Daten landen automatisch in der entsprechenden Methode.

Es gibt von Symcon ein SymconTest Repro auf GitHub. Da ist (fast) jede einzelne Funktion des SDK in einem Beispielcode aufgezeigt.
Michael

Super Danke für die Infos. Das hat mir echt weitergeholfen :+1:

viele Grüße
Oliver