Hallo Leute,
ich habe schon länger einen FHEM-Server am laufen und er tut auch prima was er soll. Daher erstmal Danke für die viele Entwicklungsarbeit die da bisher reingeflossen ist.
Ich bin mir nicht sicher ob das eine Anfängerfrage ist, aber ich vermute es eigentlich.
Ihr könnte den Post aber gerne verschieben.
Ich frage mich schon seit längerem, wo und wie eigentlich die Status-Daten der einzelnen Geräte gespeichert werden.
Anscheinend nicht in einer Datenbank? Oder doch?
Ich weiß es gibt DBlog, aber das ist doch nach meiner Erkenntnis nur eine Möglichkeit Daten nicht in ein File zu loggen, sondern in eine Datenbank.
Was ich aber bräuchte wären die Status in einer Datenbank.
Wie werden die einzelnen Status getriggert? Also, wie bekommt FHEM eine Statusänderung mit und wo wird die dann verarbeitet?
Also im Prinzip bräuchte ich irgendwie/irgendwo eine Einführung in die FHEM Architektur. Ich habe trotz Suche da noch nichts gefunden.
Grund des ganzen:
- Ich würde zum einen gerne ein REST-Interface für das ganze haben um eleganter und mit Standard-Web-Methoden auf Fhem zugreifen zu können. Die XML/JSON-Liste finde ich nicht so toll und sie wirkt mir sehr langsam.
- Und/Oder ich würde die FHEM-Oberflächen gerne reaktiver umsetzen. Auf Basis von nodejs/meteorjs zum Beispiel. Ich bin halt mit den ganzen Frontends die es bisher hier gibt nicht so wirklich zufrieden.
Zu meinem Background:
Ich bin Android- und Webentwickler (RoR, PHP) und mit Perl stehe ich bisher eher auf Kriegsfuss, aber man ist ja immer lernbereit.
Wäre nett wenn mir, vor allem in Bezug auf Datenspeicherung, Statusspeicherung, Eventverarbeitung jemand weiterhelfen könnte.
Beste Grüße,
Marc
Während der Laufzeit von fhem steht alles im Haupspeicher des Laufzeitsystems Perl.
hier habe ich ein wenig dazu geschrieben:
http://forum.fhem.de/index.php?t=msg&goto=83983&rid=405#msg_83983 (//forum.fhem.de/index.php?t=msg&goto=83983&rid=405#msg_83983)
Wenn fhem heruntergefahren wird wird einiges in fhem.save gespeichert. Diese Informationen werden nach dem Neustart wieder eingelesen.
mit
{ at_exec( $defs{<atDevice>} ) }
wird ein at-Kommando ausgeführt.
daraus folgt: $defs{<atDevice>} greift auf das Gerät atDevice zu.
Ich glaube im hash $defs sind alle Geräte enthalten.
Hallo,
den aktuellen Status jedes Device findest du in der
Zitatfhem.save
.
Diese wird bei einem Start des FHEM-Servers, soweit vorhanden, eingelesen und die Stati entsprechend gesetzt.
Soweit ich weiß wird jedes Event eins Device dort hinterlegt.
Sprich, du hast in der fhem.save immer den letzten Status des Device.
Hoffentlich hab ich jetzt keinen Blödsinn erzählt :-)
Grüße
Edith:
ZitatWenn fhem heruntergefahren wird wird einiges in fhem.save gespeichert.
Also doch Blödsinn erzählt :-(
Hallo Dietmar63,
danke erstmal für die Erläuterungen.
Zitat von: Dietmar63 schrieb am Fr, 28 Juni 2013 14:39Während der Laufzeit von fhem steht alles im Haupspeicher des Laufzeitsystems Perl.
Das ist für mich schon mal ein Erkenntnisgewinn. Das ist natürlich sinnvoll weil schnell.
Bedeutet das, das im Prinzip für jedes Device das in FHEM angemeldet wird eine eigene Objektinstanz erzeugt wird? Und in dieser wird dann in den Instanzvariablen der Status verwaltet?
Und alle Instanzen sind dann im $defs-Hash?
Gibt es eine Möglichkeit allen Device-Klassen zu sagen, das sie bei Statusänderung ein Event triggern sollen, das dann den Status in z.b. einer Datenbank ändert?
Gäbe es aktuell irgendeine Möglichkeit, außerhalb von FHEM, auf diese Daten direkt zuzugreifen (was bei einer extra DB leicht wäre)?
Ich kenne die XML- und JSON-List Ansätze, aber das ist mir für meine Zwecke zu langsam.
ZitatBedeutet das, das im Prinzip für jedes Device das in FHEM angemeldet wird eine eigene Objektinstanz erzeugt wird? Und in dieser wird dann in den Instanzvariablen der Status verwaltet?
Und alle Instanzen sind dann im $defs-Hash?
im Prinzip ja. Leider aber nicht im OO-Sinne einer echten OO-Programmiersprache. In Perl wird alles in hashs gehalten.
ZitatGibt es eine Möglichkeit allen Device-Klassen zu sagen, das sie bei Statusänderung ein Event triggern sollen, das dann den Status in z.b. einer Datenbank ändert?
Alle Readings feuern Ereignisse, die mit notify abgefangen werden können. Das Abfangen mit notify ist aber nicht so ganz performant, weil jedes Ergeignis gegen jeden rexExp aller notify (in 91_notify ca. Zeile 65 ...) geprüft wird.
Damit sind aber dann nicht alle Statusänderungen abgedeckt.
Mit dem Befehl "list <device> kannst du viele Attribute eines device anzeigen. Die Funktion CommandList in fhem.pl realisiert diese Anzeige. Dort kann man vieles über die Speicherung im Hauptspeicher lernen.
ZitatGäbe es aktuell irgendeine Möglichkeit, außerhalb von FHEM, auf diese Daten direkt zuzugreifen (was bei einer extra DB leicht wäre)?
Ich kenne die XML- und JSON-List Ansätze, aber das ist mir für meine Zwecke zu langsam.
Aus meiner Sicht muss man in jedem Fall PerlCode erstellen, der die Ausgaben durchführt. Ich glaube, dass es aufwendig ist, eine solche db aktuell zu halten.
Mir ist noch folgende Funktion eingefallen:
CommandDefine in fhem.pl ist für die Definition eines Device zuständig.
Dort kann man sehen welche hashs mit welchem Inhalt versorgt werden.
ab Zeile 1314 wird das hash des device aufgebaut und in Zeile 1326 ins globale hash gespeichert.
(siehe Anhang / see attachement)
Danach wird die spezifische define-Funktion des Geräts ausgeführt.
> Ich würde zum einen gerne ein REST-Interface für das ganze haben um eleganter und mit Standard-Web-Methoden auf Fhem zugreifen zu können.
Nicht wirklich eine Anfaengerfrage.
Um alle Events (Status+Readings) per Push zu bekommen gibt es mehrere Moeglichkeiten, z.Bsp:
- HTTP/HTTPS ueber FHEMWEB, mit der longpoll Methode: http://fhemhost:8083/fhem&room=all&XHR=1&inform=1 (//fhemhost:8083/fhem&room=all&XHR=1&inform=1)
So funktioniert z.Bsp. der EventLog in FHEMWEB.
- telnet (bzw. plain socket), hier inform timer aufrufen
- TheOpenTransport Projekt, Details kenne ich nicht.
Danke nochmal für die ganzen Hinweise.
Werde ich mir bei Gelegenheit mal anschauen. Jetzt habe ich wenigstens ein Grundverständnis wie diese Dinge zusammenhängen.
Zitat von: rudolfkoenig schrieb am Sa, 29 Juni 2013 14:30>
Nicht wirklich eine Anfaengerfrage.
Ja, aber wo hätte es sonst hingepasst? Für den Developer-Teil muss man sich ja erst zulassen lassen.
Zitat von: rudolfkoenig schrieb am Sa, 29 Juni 2013 14:30>
- TheOpenTransport Projekt, Details kenne ich nicht.
Wo finde ich dazu was? Wenn ich dazu suche bekomme ich keine sinnvollen Ergebnisse.
Zitat von: willwach schrieb am Mo, 01 Juli 2013 09:47Zitat von: rudolfkoenig schrieb am Sa, 29 Juni 2013 14:30>
- TheOpenTransport Projekt, Details kenne ich nicht.
Wo finde ich dazu was? Wenn ich dazu suche bekomme ich keine sinnvollen Ergebnisse.
Rudi meint sicherlich: TheOpenTransporter - Die OpenSource-JSON-Schnittstelle für FHEM.
Infos gibt es rudimentär im FHEM-Forum, mehr gibt es unter
http://www.theopentransporter.de/dokumentation.htmlHelmut.