FHEM Java-Schnittstelle

[Gekirou]

Sehr geehrte FHEM-Community,

im Rahmen meiner Diplomarbeit am Forschungszentrum für Informatik Karlsruhe habe ich eine Java-Schnittstelle für FHEM geschrieben, die das Gegenstück zu dem Projekt "The Open Transporter" bilden soll. Ich würde in naher Zukunft gerne das Projekt mit auf den FHEM-SVN stellen dürfen, da meine Diplomarbeit in etwa 2 Monaten abgeschlossen ist, ich mir allerdings vorstellen könnte, dass Interesse an der Nutzung und Weiterentwicklung dieser Schnittstelle besteht :-).

Innerhalb des nächsten Monats endet meine geplante Entwicklungszeit. Leider konnte ich mich in diesem Rahmen nur begrenzt in FHEM einlesen, weshalb ich mir bezüglich diverser Konzepte etwas unschlüssig bin. Ich würde deshalb um reges Feedback bitten, damit ich in dem mir möglichen Rahmen viel daran arbeiten und optimieren kann! Ferner würde ich mich sehr über weitere Teilnahme an dem Projekt freuen, sodass ich ggf. dem Google-Project weitere Teilnehmer und Admins hinzufügen kann. Ich weiß leider eben nicht, wie lange ich das Projekte noch selbstständig betreuen kann!

Das Google-Projekt:
http://code.google.com/p/fhem-java-api/

The Open Transporter:
http://www.theopentransporter.de/

Mit besten Grüßen,
Gekirou

[Gekirou]

So - hier leider als Doppelpost, wollte das aber vom ersten Post trennen.

Die bisher bekannten Bugs/TODOS:

* Die Hardware-Erstellung in FHEM ist noch etwas problematisch. Es muss noch konzeptionell Entscheidungen getroffen werden, wie Hardware eingebunden wird, die von FHEM über autocreate erstellt wird. Manuell geht das, ist aber etwas blöd.

* Einbinden aller Module in das Paket "actuatorparameters". Kein großer Aufwand aber nervig und wiederholt sich. Villeicht gibt es hier eine bessere Lösung, die mir nicht einfallen wollte.

* Weitere Listener definieren, das Konzept hier sollte klar ersichtlich sein. Neue Listener zu definieren ist super simpel!

* Die DeviceFactory richtig aufstellen - das Konzept steht, aber die tatsächliche Abfrage noch nicht sinnvoll. Momentan ist einfach jeder nicht-Sensor ein OnOffActuator. Das ist natürlich quatsch und zu restriktiv für weitere Geräte. Da ich nicht alle Ecken und Winkel von FHEM ergründet habe, mag es hier auch eventuell einen sehr einfachen Weg gehen. Der einzige Weg der mir bisher einfiel, war einen StructureType "deviceType" anzulegen, das würde allerdings bedeuten, dass jedes Device von der Schnittstelle generiert werden müsste und entsprechend die gesamte FHEM-Umgebung neu konfiguriert. Das ist entsprechend blöd.

* Die Deserialisierung des JSON-Strings ist bisher unvollständig, da ich bisher nichts anderes brauchte. Kann mir gut vorstellen, dass das umfangreicher wird, wenn andere Geräte hinzukommen (Kalender, Sensoren, etc..)

* Weitere Funktionalitäten in die anderen Manager einpflegen (bisher ist nur DeviceManager ausgereift)

* Ändern der fhem.cfg. Die Methoden dafür existieren, aber nach einem Upload und neustart bekomme ich Fehlermeldungen. Weiß nicht genau, was man da anders machen kann.

[C. Zimmermann]

Eine kleine Anleitung noch, für die die es testen wollen:

FhemAPI
- Git Clone von FhemAPI erstellt und in Eclipse importiert
- in FhemAPI.java den FHEMServer auf die Adresse meiner Testumgebung gestellt -> "server = new FHEMServer("192.168.178.40", 8090);"

TheOpenTransporter
- 98_TheOpenTransporter.pm von der obigen Adresse gezogen und in das Verzeichnis \FHEM kopiert, sowie Berechtigungen angepasst
- in fhem.cfg "define test TheOpenTransporter 8090" hinzugefügt
- per putty (root) "apt-get install libjson-any-perl" ausgeführt
- FHEM neugestartet

[Johannes]

Sehr interessante Ansätze, könnte ich durchaus gut gebrauchen. Schade dass die Weiterentwicklung noch etwas in den Sternen steht. Bei Gelegenheit schau ich mir das genauer an. Danke!

[Gekirou]

Nun, ich plane diese Schnittstelle bis zu einem gewissen Grad der Reifheit weiterzuentwickeln, auch für meine Diplomarbeit. Insbesondere bin ich nun auf Leute angewiesen, die sich gleichermaßen mit Konzepten in FHEM und Java gut auskennen, um gegebenfalls ein paar Tipps zu bekommen.

[Gekirou]

Neuigkeiten! Unter dem oben genannten Link kann nun die neuste Version der API gezogen werden. Ich habe eine bereits kompilierte Version im Downloadbereich zur Verfügung gestellt, sowie die neuste Version des "TheOpenTransporter", die ich selbst modifiziert habe.  Mittlerweile besitzt die nicht-kompilierte Version eine Beispielhafte graphische Oberfläche. Diese basiert auf Vaadin 6 und entsprechend hübsch umsetzbar. Für Kosmetik hatte ich bisher keine Zeit, begrüße aber jeden, der mit vaadin ggf. etwas schöneres zaubern kann.

Grüße,
Gekirou

[Gekirou]

Auf besonderen Wunsch gibt es hier noch einige Screenshots. Bitte beachtet, dass vaadin ein recht mächtiges UI-Tool ist, entsprechend kann man viel für die Kosmetik und die usability tun.

[Gekirou]

Sorry für Spam, aber:

Update: Im Wiki sind Erklärungen und Tutorials zur Installation, Nutzung und Weiterentwicklung zu finden!

[UliM]

Hi,
cool!
Ist die Oberfläche dann AJAX-mäßig, sprich wird zB der angezeigte Status eines device refresh-ed, ohne dass man im browser ein refresh ausführen muss?
Ich kenne Vaadin nicht und habe daher keine Vorstellung, wie aufwändig darin der Bau einer fhem-Oberfläche ist... kannst Du da Anhaltspunkte geben?
Gruß, Uli

[Johannes]

wäre es nicht vielleicht sinnvoll, mein aktuelles ExtJS Oberfläche hier einzubringen?
Da müsste man nicht bei 0 anfangen und hätte ebenfalls eine sehr mächtige Bibliothek zur Hand.
Meinungen?

[Gekirou]

Gerne kann ich Anhaltspunkte geben:

@UliM
Vaadin kann man sich vorstellen als Swing für Web. Jeder der Java Swing kann, kann auch in Vaadin arbeiten. Die Grundkonzepte sind sehr Ähnlich, obwohl Vaadin deutlich mehr sogenannte "rich-components" anbietet. Schau dir doch mal die Komponenten unter http://demo.vaadin.com/sampler an. Da bekommt man schnell ein Gefühl dafür. Denkbar wäre auch so 'nen Fensterbasierter Ansatz, statt fullscreen links und rechts :-).

@Johannes
Tatsächlich sehr sinnvoll. Tatsächlich würde ich mich sehr freuen, wenn diese Java Schnittstelle einen weiteren Gebrauch in der Community findet, da ich selbst - wie schon gesagt - nicht mehr viel Zeit in Entwicklung stecken kann. Das Ganz lässt sich mit Sicherheit gut an die ExtJS Oberfläche anschließen :-).

[thomilla]

Hi

ich habe jetzt die OSGI-Sourcen in Eclipse mal importiert und konnte den Server auf einem Port >1024 starten mit einer Portangabe >1024 über das VM-Argument -Dorg.osgi.service.http.port=
Leider klappt der Verbindungsversuch wie im Wiki beschrieben nicht unter http://localhost/HW, da bekomme ich lediglich ein 404-Fehler

Gruß,
Thomas

[Gekirou]

Hey Thomas!

Ich kann mir nicht vorstellen, dass dein Eclipse keinen "Einstellungen" Menüpunkt hat. Mein Eclipse-Juno hat soetwas :-). Ich habe dabei diese Version geladen: http://www.eclipse.org/downloads/packages/eclipse-ide-java-ee-developers/junosr2 ). Keine Ahnung, ein Screenshot wäre hilfreich.

Was ich allerdings im Wiki vergessen hatte zu erwähnen: Die Eclipse-Version muss Plug-In Development im OSGI Fall unterstützen. Das bedeutet zum Beispiel, dass eben die "Eclipse IDE for Java EE Developers" geladen wird und nicht "Eclipse Classic" (sofern ich weiß, wird das dort nicht unterstützt).

[thomilla]

Ja, hab es bereits gefunden, war unter Mac OS allerdings unter Eclipse-> Einstellungen
Jetzt habe ich nur das oben beschriebene 404-Problem.

[Gekirou]

Geh mal auf http://localhost/HWC .. kann sein dass in der OSGI Version noch das C hinten dran hängt :-).