Modul(e) für INSTA Funkmanagementsystem

[maf]

Hallo,

erster Forumsbeitrag, volles Risiko

Wir benutzten privat das INSTA Funkmanagementsystem, das von Jung, Gira und Berker angeboten wird. Ich würde gerne auf unsere Komponenten per FHEM zugreifen und bin durchaus bereit, dafür Programmierarbeit zu leisten.

Aber da ich FHEM-Neuling und zugegebenermaßen kein Perl-Fanatiker bin, suche ich zunächst einmal Eure Unterstützung. Einerseits wenn es darum geht, die Aufgabe und den Aufwand einzuschätzen. Und andererseits, um vielleicht ein paar Mitstreiter zu finden.

Ich habe schon im Forum gelesen, dass es mit einer speziellen CUL Firmware möglich ist, auf INSTA Komponenten zuzugreifen. Von insta gibt es allerding ein spezielles Sende- und Empfangsmodul mit einer seriellen Schnittstelle. Testweise habe ich ein paar Python-Skripte geschrieben, die über dieses Modul auf instafunk Empfänger zugreifen. Mit geringem Hardware-Aufwand (USB zu TTL Converter) sollte auch Betrieb über USB möglich sein.

Mit den passenen FHEM-Modulen sollte sich dieses Sende- und Empfangsmodul auch in FHEM nutzen lassen. Allerdings vermute ich nach allem, was ich bisher zu FHEM gelesen habe (insbesondere die DevelopmentModuleIntro, dass man eigentlich ein zweistufigen Ansatz bräuchte: Eine physisches Modul für das eigentliche Sende- und Empfangsmodul sowie logische Module für die verschiedenen Aktoren. Und dieser zweistufige Ansatz wurde als "noch nicht so gut dokumentiert" und "Königsklasse" bezeichnet. Also eigentlich nicht das, womit man als Einsteiger beginnen sollte...

Was also sagen die Experten?

Schönen Gruß
maf

[rudolfkoenig]

- Aufwand: wenn man das Protokoll kennt, und sowas schon mal in FHEM gemacht hat, dann dauert das Erstellen einer ersten lauffaehigen Version der zwei Module etwa ein Tag.
- ich selbst wuerde einer meinen neueren Module (00_ZWDongle.pm/10_ZWave.pm oder 00_FBAHA/10_FBDECT) als Vorlage nehmen, und entsprechend anpassen. Als Leitfaden fuers Umbau kann man mit der XXX_Initialize Funktion anfangen, und die dort erwaehnten Funktionen eins nach dem anderen anpassen.
- Um FHEM2FHEM-Faehig zu bleiben darf das physische Modul Daten an das Logische nur via Dispatch weitergeben, und das Logische nur via IOWrite an das Physische.
- falls der Support in culfw noch nicht perfekt ist, dann wuerde ich mit dem Original-Modul anfangen, ueblicherweise ist das meiste im logischen Modul zu erledigen, und das kann man spaeter wiederverwenden.

[maf]

- Aufwand: wenn man das Protokoll kennt, und sowas schon mal in FHEM gemacht hat, dann dauert das Erstellen einer ersten lauffaehigen Version der zwei Module etwa ein Tag.

Bei mir dürfte es dann vermutlich etwas länger dauern . Trotzdem ist Abschätzung für mich hilfreich und ermutigend.

- ich selbst wuerde einer meinen neueren Module (00_ZWDongle.pm/10_ZWave.pm oder 00_FBAHA/10_FBDECT) als Vorlage nehmen, und entsprechend anpassen. Als Leitfaden fuers Umbau kann man mit der XXX_Initialize Funktion anfangen, und die dort erwaehnten Funktionen eins nach dem anderen anpassen.

Die Module werde ich mir anschauen.

- Um FHEM2FHEM-Faehig zu bleiben darf das physische Modul Daten an das Logische nur via Dispatch weitergeben, und das Logische nur via IOWrite an das Physische.

Danke für den Hinweis.

- falls der Support in culfw noch nicht perfekt ist, dann wuerde ich mit dem Original-Modul anfangen, ueblicherweise ist das meiste im logischen Modul zu erledigen, und das kann man spaeter wiederverwenden.

Da habe ich wohl noch Verständnisdefizite.

Ich stelle mir den instafunk Transceiver oder ein CUL konzeptionell wie eine Fernbedienung vor, mit deren Hilfe man andere Geräte bedienen kann. Deshalb habe ich die "zweistufige" Funktionsaufteilung zwischen logischem und physischen Modulen bislang so verstanden, dass das physische Modul den Transceiver kapselt und eine (in diesem Fall) instafunk-spezifische Schnittstelle zur Verfügung stellt. Diese Schnittstelle würden dann die logischen Module nutzen, wobei - zumindest ganz grob - für jede Art von Aktor (Schalter, Dimmer, ...) ein logisches Modul erforderlich wäre. Stimmt das so?

Ich möchte ja das INSTA-eigene Sende- und Empfangsmodul (das ich bereits besitze) statt einem CUL (das ich nicht besitze) verwenden. Aber natürlich wäre es gut, wenn "mein" Modul und das CUL-Modul für ein CUL mit INSTA-tauglicher Firmware die gleiche Schnittstelle unterstützen. Da die schon existiert, müsste ich versuchen, sie in meinem physischen Modul zu reimplementieren. Das ist vermutlich kein Einzelfall. Gibt es für diesen Aspekt empfehlenswerte Beispiele.

maf

[rudolfkoenig]

Deine Vorstellung von physischen Modul ist korrekt.
Man koennte zwar auch mehrere logische Module bauen, aber die meisten (ZWave, CUL_HM, EnOcean) machen das in einem Modul.

Reimplementieren muesste man nicht viel, wenn die beiden physischen Module die Daten logisch aehnlich senden. Beispiele fuer unterschiedliche physische Module, die die gleichen logischen bedienen sind FHZ/CUL -> FS20/FHT/HM/KS300, oder CUL/HMLAN -> CUL_HM. Auch CUL_RFR oder FHEM2FHEM nutzen das Prinzip, dass unterschiedliche physische Module das gleiche logische bedienen koennen.