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/ (//code.google.com/p/fhem-java-api/)
The Open Transporter:
http://www.theopentransporter.de/ (//www.theopentransporter.de/)
Mit besten Grüßen,
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.
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
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!
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.
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
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.
Sorry für Spam, aber:
Update: Im Wiki sind Erklärungen und Tutorials zur Installation, Nutzung und Weiterentwicklung zu finden!
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
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?
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 (//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 :-).
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, (//localhost/HW,) da bekomme ich lediglich ein 404-Fehler
Gruß,
Thomas
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 (//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).
Ja, hab es bereits gefunden, war unter Mac OS allerdings unter Eclipse-> Einstellungen
Jetzt habe ich nur das oben beschriebene 404-Problem.
Geh mal auf http://localhost/HWC (//localhost/HWC) .. kann sein dass in der OSGI Version noch das C hinten dran hängt :-).
Leider ebenfalls ein 404. In der console steht:
osgi> VaadinOSGiApplicationManager.start: org.eclipse.equinox.internal.ds.impl.ReadOnlyDictionary
Sagt dir das was?
Danke und Gruß,
Thomas
Naja.. du hast ja den Port auf 1024 gesetzt. Diesen musst du ja auch im Link verwenden, also:
http://localhost:1024/HWC (//localhost:1024/HWC)
bzw.http://localhost:1024/HW
Genau das habe ich getan und das sehe ich als Ergebnis:
HTTP ERROR 404
Problem accessing /HWC. Reason:
ProxyServlet: /HWC
Powered by Jetty://
Mh.. seltsam. Ich hab mal einen Screenshot meiner Konsole beigefügt. Da steht also der von dir genannte Eintrag ebenfalls. Welche Bundles werden dir aufgelistet, wenn du in der Konsole "ss" bzw. "ps" (bei Felix OSGI) eingibst?
So sieht es aus:
osgi> ss
Framework is launched.
id State Bundle
0 ACTIVE org.eclipse.osgi_3.7.1.R37x_v20110808-1106
1 ACTIVE javax.servlet.jsp_2.0.0.v201101211617
2 ACTIVE org.eclipse.equinox.common_3.6.0.v20110523
3 ACTIVE org.eclipse.equinox.cm_1.0.100.v20090520-1800
4 ACTIVE org.vaadin.osgi.staticres_1.0.1
5 ACTIVE org.eclipse.osgi.services_3.3.0.v20110513
6 ACTIVE javax.servlet_2.5.0.v200910301333
7 ACTIVE org.eclipse.equinox.http.jetty_2.0.100.v20110502
8 ACTIVE org.eclipse.equinox.http.registry_1.1.100.v20110502
9 ACTIVE org.eclipse.equinox.ds_1.3.1.R37x_v20110701
10 ACTIVE com.vaadin_6.8.3
11 ACTIVE org.eclipse.equinox.registry_3.5.101.R37x_v20110810-1611
12 ACTIVE org.eclipse.equinox.http.servlet_1.1.200.v20110502
13 ACTIVE org.vaadin.osgi_1.0.1
14 ACTIVE org.mortbay.jetty.util_6.1.23.v201012071420
15 ACTIVE org.mortbay.jetty.server_6.1.23.v201012071420
16 ACTIVE org.eclipse.equinox.util_1.0.300.v20110502
Da fehlen die Bundles der Java Schnittstelle. Hast du diese schon in Eclipse importiert? Wenn du das tust, sollten diese automatisch in den Run Configurations aufgelistet und aktiviert sein. Sind die in den Run Configurations bei "Bundles" nicht aufgelistet?
Ähm, wie und woher importiere ich diese?
Gruß,
Thomas
Nun.. im Wiki ist ja beschrieben, wie du die Sources der Schnittstelle bekommst. Diese sind in einem Git Repository gespeichert (inklusive Versionskontrolle). Dafür musst du dir einen Git-Client besorgen (beispielsweise SmartGit) und dann die Sources auschecken. Der Link dafür ist ja im Google Code.
Also sind die Schnittstellen-Ressourcen nicht Bestandteil der OSGI-Sourcen?
Danke für deine Hilfe.
Also, ich fasse kurz zusammen:
Zunächst sollte man sich meine Schnittstellen-Resources herunterladen. Diese sind im Git-Repository. Diese können entweder über die Konsole via Git-Clone oder über ein entsprechenden Git-Client mit graphischer Oberfläche heruntergeladen werden.
Sobald du das hast, sind dort 5 Ordner:
* api_doc: Die Dokumentation meiner Schnittstelle
* de.fzi.fhemapi Die Schnittstelle selbst
* de.fzi.fhemapi.view.vaadin Die graphische Oberfläche
* org.google.gson die Bibliothek "GSON", die mit reingeladen werden muss
* fhem-api-target die "Target Platform".. diesen Ordner solltest du in Eclipse als Target-Platform einstellen.
Die Ordner "de.fzi.fhemapi, de.fzi.fhemapi.view.vaadin, org.google.gson" solltest du über die Funktion Eclipse -> Import.. -> Existing Projects into Workspace in deinen Workspace laden. Dann hast du die Sources da. Diese sollten automatisch dann in der Run Configuration schon aktiviert sein, sonst aktivieren. Fertig :-).
OSGI ist ja wie bekannt ein bekanntes Java Framework.
Vaadin ist das Framework, auf der meine GUI basiert.
Hallo!
Kann jemand mit dem entspr. Sachverstand mal aus dieser Perspektive was zu der Zusammenführung von KNX und fhem über openhab sagen?
Das sollte doch nun möglich sein, nachdem alles im osgi Framework läuft...
Danke, Gruß
Bernd
FHEM hat eigentlich ein eigenes KNX Modul, ich hab das selbst nie verwendet. Ist das problematisch? Ansonsten gehe ich in meinem Framework davon aus, dass die Geräte von FHEM angelegt und verwaltet werden, der "Rückweg" ist nicht vorgesehen.
Meine Idee sieht so aus:
Fhem ist eines von mehreren Produkten in einem Haussteuerungsystem.
Auf dem OpenHab Bus kommen diese Systeme zusammen und sind über die gemeinsame Oberfläche von OpenHab bedienbar.
Da die Kommunikation aller Komponenten über den gemeinsamen Bus läuft, ist ein device State Polling nicht nötig.
Möglich?
Das sollte sehr gut funktionieren - für einen ähnlichen Fall (Nutzung mit universAAL, das hat eine zu openHAB ähnliche BUS-Struktur) habe ich diese Schnittstelle konzipiert. Ich nehme an, dass du für openHAB eine kleine Zwischenstufe als Bundle schreiben musst - quasi Interfaces als Ebenenschnittstelle. Das Thema interessiert mich persönlich sehr, also halte mich bitte auf dem Laufenden, falls du in die Richtung etwas unternimmst. Das kann ich auch gut in meine Diplomarbeit aufnehmen (ich schreibe bis Ende April noch daran).
Grüße
Hallo Zusammen
Hat schon jemand OpenHAB in Kombination (TCP/IP bzw. FHEM-Binding) am Laufen ?
Gruss Peter
Wir die Schnittstelle noch weiterentwickelt (aktuell gehalten) oder hat sie das typische Uni-Projekt-Schicksal?