Neues FHEM-Modul für smarthomatic

Begonnen von rr2000, 02 Juni 2014, 20:06:55

Vorheriges Thema - Nächstes Thema

rr2000

Hi,

smarthomatic ist ein Open Source / Open Hardware Projekt, welches eine Alternative zu kommerziellen Heimautomatisierungs-Systemen bieten soll (http://www.smarthomatic.org). Ich habe dazu die FHEM-Module geschrieben und möchte Sie hier zum Code Review vorstellen. Die Module befinden sich auf https://github.com/Roadyweb/smarthomatic/tree/fhem_integration/host_software/fhem oder im Anhang zum Download.

Files:

  • 37_SHC.pm: Modul für Basisstation
  • 37_SHC_Dev.pm: Modul für verschiedenen Sensoren, momentan werde EnviromentSensoren, Dimmer und PowerSwitches unterstützt
  • SHC_parser.pm & SHC_datafields.pm: Bibliotheken um aus der XML-Beschreibung die Telegramme zu erzeugen bzw. zu dekodieren
  • SHC_packet_layout.xml: XML-File mit der Beschreibung der Telegrammdaten

Reifegrad:

  • Das Projekt smarthomatic selbst ist vor 2 Jahren von Uwe Freese gestartet worden und seit ca. 1 Jahr unter http://www.smarthomatic.org erreichbar.
  • Die FHEM-Module wurden von mir seit Januar 2014 entwickelt. Sie entstanden als ein Klon von 36_JeeLink.pm und 36_JeeLink.pm (Danke justme1968) und wurden sukzessive angepasst.
  • Seit April 2014 sind sie im Repository von smarthomatic (https://github.com/breaker27/smarthomatic/) enthalten und wurden im Mai zum ersten Mal in ein smarthomatic-Release (v0.6) aufgenommen.
  • Dokumentation wurde mit contrib/commandref_join.pl gecheckt, momentan ist die englische Version verfügbar.

Offene Fragen:

  • Welchen Namen sollen die Module bekommen? Ist 37_SHC.pm und 37_SHC_Dev.pm OK?
  • Die Bibliotheken heissen SHC_datafields.pm, SHC_parser.pm und SHC_packet_layout.xml, auch OK?
  • In 37_SHC_dev.pm werden die Fähigkeiten der verschiedenen Device-Klassen ("EnvSensor", "PowerSwitch", "Dimmer") als Eintrag ("devtype") in den Internals verwaltet. Passt Internals oder sollte das besser ein Attribut des Devices sein?
  • Ist die Lizenz OK, momentan ist es GPLv3 da smarthomatic auch GPLv3 ist?
  • Justme1968 möchtest Du als Author in 37_SHC.pm und 37_SHC_Dev.pm erwähnt werden?
  • Könnte es in diesem Zustand (und den Änderungen aus diesem Review) ins FHEM Repo übernommen werden?

Über Anregungen und Verbesserungsvorschläge würden ich mich freuen, egal ob hier im Forum oder auf Github.

Gruß,
Stefan


Dr. Boris Neubert

Hallo Stefan,

Danke für Deinen Beitrag.

Zwei Dinge dazu von mir:

  • Obwohl es nicht verboten ist und wohl auch funktioniert, würde ich keine Unterstriche im Device-Namen machen wollen, also besser SHCDevice.
  • FHEM ist unter der GPLv2. M.W.sind v2 und v3 inkompatibel. Ob Du dann die Module als v2 beim Smarthomatic haben kannst, weiß ich nicht. Es gibt aber auf der Gnu-Seite eine Kompatibilität Übersicht - wenn Du die gelesen und verstanden hast, hast Du vermutlich anschließend keine Lust mehr  ;) 

Hast Du einen Sourceforge-Account? Bitte an mich per PM.

Viele Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

rudolfkoenig

ZitatPasst Internals oder sollte das besser ein Attribut des Devices sein?

Es sollte ein Attribut sein, falls der Benutzer es aendern soll, ein Reading, falls es gespeichert werden soll, sonst Teil von Internals. Falls der Benutzer es normalerweise nicht sehen soll, dann sollte es mit einem . anfangen.

rudolfkoenig

ZitatHast Du einen Sourceforge-Account? Bitte an mich per PM.

Boris (und Martin und Olaf): falls Ihr neue Benutzer zum SVN hinzufuegt, bitte hier erwaehnen, und folgende Standard-Belehrung auch anfuegen:

Standard Belehrung:
========
- nur die eigenen Module modifizieren, sonst dem Maintainer Patches schicken.
- nach FHEM kommen nur die Module, die dokumentiert und im Forum betreut sind
  (siehe MAINTAINER.txt), sonst nach contrib.
- falls das Modul nach FHEM kommt, dann bitte das betroffene Forum (wg.
  Support) und Developer (wg. allgemeine API-Aenderungen) abonnieren.
- vor dem Einchecken alles (auch Doku, mit contrib/commandref_join.pl &
  Browser) testen, und die letzten Aenderungen mit "svn diff FHEM/MyModul.pm"
  pruefen.
- neue Verzeichnisse duerfen nur nach Ruecksprache mit mir angelegt werden, das
  gleiche gilt fuer das Einchecken von fremden Dateien wie Bibliotheken, usw.
========

rr2000

Danke schon mal.
Ich werde 37_SHC_Dev.pm entsprechend umbenennen und den DeviceType als Attribute eintragen.

Gruß,
Stefan

rr2000

Hi,

die Module sind inzwischen im Repository und lassen sind mit "update force" installieren. Allerdings fehlt die xml-Datei. Scheinbar kopiert das Deployment-Skript aus dem Verzeichnis /FHEM nur Dateien mit der Endung *.pm. Um das Problem zu umgehen sehe ich drei Möglichkeiten:

  • Verschieben der Datei SHC_packet_layout.xml nach /lib. Dort befinden sind unter /lib/SWAP einige xml-Dateien die richtig deployed werden.
  • Anpassen des Deployment-Skripts
  • Umbenennnen der Datei SHC_packet_layout.xml in SHC_packet_layout.xml.pm, was aber IMHO die unschönste Lösung ist.
Was ist der beste Weg?

Gruß,
Stefan

rudolfkoenig

Ich faende es gut, wenn solche Dateien nicht in fhem/FHEM sind.
Ich habe fhemupdate.pl erweitert, damit es fhem/FHEM/lib/.*.xml zum update bereitstellt.


rr2000

Werde die Datei verschieben!

Danke und Gruß,
Stefan