Fronthem - Eine FHEM-Schnittstelle für Frontends

[leisure64]

Hallo,
ich bin sozusagen "brandbeu" in diesem Forum, möchte aber trotzdem meinen Kommentar abgeben weil ich das Thema total spannend finde.
Bei mir im Haus läuft smarthome.py/smartvisu. Die Kombination ist schon ziemlich spannend. Aber FHEM finde ich auch sehr interessant.
Leider spricht mich das/die Frontend's nicht so richtig an, smartvisu könnte eine wirklich gute Erweiterung sein (und würde mir {und meiner besseren Hälfte;-)} den Umstieg schmackhaft machen.

Für smartvisu spricht der einfache Einstieg. Vorausgesetzt es gibt einen passenden Treiber wäre die Anpassung auf eigenen Bedürfnisse mit kleinen Kenntnissen wie man einen Editor betätigt leicht machbar.
HTML, PHP, Javascript, jscript etc -  Kenntnisse sind NICHT erforderlich. Bestehende Beispiele, die es ausführlcih gibt, sind leicht anpassbar und dadurch bekommt man schnell ein lauffähiges System.
(Mit den o.g. Kenntnissen kann man die Oberfläche natürlich noch viel feiner Anpassen.)

Ich denke, einen Treiber für smartvisu zu schreiben lohnt sich.
Leider kenn ich mich in FHEM noch gar nicht aus und weiss nicht wie groß der Aufwand ist. Meine native Annahme ist, das es möglich sein sollte. Gerne trage ich dazu bei. Z.B. beim Testen bzw. mit meinen (vielleicht kleinen) Kenntnissen über smartvisu.
Meine Annahme ist, dass man im Verzeichnis samrtvisu/driver eine neue Datei erstellt, als Muster dienen die anderen Treiber in diesem Verzeichnis. Thats all.

Gruss Jonah
 

[herrmannj]

Hi Jonah,

vielen Dank 

Wo findet man eigentlich den Editor ? Hast Du evtl screenshots (vom editor) ?

Ich versteh auch das knx System noch nicht so genau. Was ich aus der doku zu erkennen glaube ist das die Adressierung auf GADs basiert (?). Eine der Fragen für mich ist die Adressierung fürs Frontend. Irgendwie muss man ja eine Übereinstimmung zwischen den fhem device und dem was smartvisu erwartet bekommen. Da fehlt mir Verständnis. Ich habe gelesen das smartvisu von einigen als langsam beschrieben wird, hast Du Erfahrungen dazu ?


Danke  und Grüße
Jörg

[leisure64]

Wo findet man eigentlich den Editor ?

Sorry, da hast Du mich missverstanden.
Mit Editor meinte ich einen beliebigen Texteditor. Smartvisu hat von haus aus keinen eingebauten Editor.

[drdownload]

Ich habe mir das Thema gestern auch angesehen und Domotiga beispielsweise geht den Weg ein eigenes Modul für Smartvisu zu haben dass einen Websockets-Server hat, der die Kommunikation macht.

Die Plots verwenden glaube ich RRD was natürlich toll von der Geschwindigkeit her ist und warum das RRD-Projekt in FHEM eingeschlafen ist weiß ich auch nicht.

Im Fall von FHEM wäre es vor allem wichtig einen performanten Weg zu finden zu Readings etc. zu kommen.

Telnet + Websockets hätte natürlich den Vorteil dass man die Bridge zu Smartvisu in einer beliebigen Sprache auch abseits von Perl schreiben könnte

import cherrypy
from ws4py.server.cherrypyserver import WebSocketPlugin, WebSocketTool

[justme1968]

eine kurze frage wegen der plots: beim demo zugang bauen sich die plotz sehr sehr langsam auf. ich vermute fast das es absicht ist. kann man das auch ändern? meine fhem plots sind auch ohne rrd deutlich schneller als die plots dort.

die demo seiten sind bei mir noch an einigen anderen stellen sehr langsam und zäh. liegt das an dem server dort oder ist das bei einer lokalen installation auch so ?

gruss
  andre

[drdownload]

Das würde mich auch interessieren, auf dem iPad1 und dem HP Touchpad die ich als Displays verwende war die GUI beinahe unbenützbar langsam, allerdings insg. nicht nur die Plots

[drdownload]

Wobei ich das Konzept von Smartvisu sehr ansprechend finde, global Widgets zu definieren denen die zugrundeliegende Device eigentlich recht egal ist solange alles sauber gemappt wird. Das kommt meinen Vorstellungen einer hauptsächlich als Touch GUI verwendbaren Oberfläche bei der ich je nach Raum/Display auf einem Dashboard Widgets platziere sehr nahe.

Wobei natürlich auch FHEM Ansätze in diese Richtung hat, aber das Lösen des Widgets von der Device und die Platzierung auf einem Dashboard mit Grid sind noch sehr in den Anfängen ( wenn Floorplan ein Grid DND nachrüsten würde wäre schon mal ein großer Schritt gemacht denke ich) http://forum.fhem.de/index.php/topic,22491.0.html

[justme1968]

ja. genau das konzept lässt sich aber auch mit fhem mitteln schon umsetzen.

ich bin gerade dabei das beispiel von weiter oben mit der heizungssteuerung beispielhaft umzusetzen. du gibst dann dem 'widget' die bis zu drei readings und das set commando das nötig ist und alles andere geht automatisch. das gleiche widget arbeitet dann mit max oder homematic oder fs20 heizungskomponenten. egal ob es ein wand thermostat für den ganzen raum oder ein heizungsthermostat für eine heizung ist. oder eine irgendwie selbst gestrickte heizungsteuerung mit dummys oder was auch immer. einzige voraussetzung ist das es readings für ist- und solltemperatur gibt und ein set für die soll temperatur. optional noch eine ventilstellung. egal in welchem device.

die syntax schaut etwa so aus:

Code Auswählen Erweitern

define myHeatingWidget rgHC <device>oder vollständig

Code Auswählen Erweitern

define myHeatingWidget rgHC actual=<device>:<reading> desired=<device>:<reading> valve=<device>:<reading> set=<device>:<set_command> ...wobei fast alles optional ist und aus defaults oder den vorher angegebenen werten abgeleitet wird.

das 'widget' kannst du dann in er raum übersicht, auf dem dashboard oder im floorplan verwenden.

das setzt genau diese möglichkeit die visualisierung und die steuerung logisch zu trennen um.

[drdownload]

Gerade bei potentiell umfangreicheren Widgets wie zB einer Audio-Player Steuerung (Sonos/Squeezeserver/XBMC/MPD) wäre es sicher interessant die Darstellung zu vereinheitlichen und zu bündeln.

@Heizungssteuerung: Da kann ich zB gleich beitragen, dass bei mir je nach Raum von FHT8v über PID, MAX! Stellantrieb und eine Structure die ein PID+Threshold bündelt und über ein Dummy gesteuert wird, von den Boost Dummys mal abgesehen - (ahja, 3 verschiedenen Sorten von Temperatur/Feuchte-Erfassung hätte ich noch zu bieten) + ein watchdog dass über den Taupunkt die Heizung unter den großen Dachflächenfenstern bei Bedarf hochfährt

[justme1968]

na das wäre ja der perfekte test um zu sehen ob es wirklich so device unabhäng ist wie ich es mir vorstelle

[drdownload]

@justme

wäre es für die lesbarkeit beim define nicht besser die einzelnen mappings in attribute auszulagern statt alle im define zu haben (nicht zuletzt für die lesbarkeit)

[justme1968]

das ist eine gute frage...

ich mag es wenn ich das device auf einen schlag anlegen kann. beim anlegen oder beim ändern jedes attribut einzeln durchzugehen finde ich unhandlich.

meine richtlinie ist immer: ins define kommt was nötig ist damit es im normalfall sinnvoll funktioniert. in attribute kommen dinge die das verhalten beeinflussen. manches kann man sicher so oder so sehen.

mit der = syntax ist es im define aber möglich völlig unabhängig von der reihenfolge zu sein. wenn man das ein paar mal gemacht hat ist es sehr praktisch.

[drdownload]

Da geb ich dir recht, außerdem kann man das define ja immer nachträglich bearbeiten.

Andererseits denke ich zB an das theoretische Audio-Player Widget, wo es dann vielleicht unübersichtlich werden kann.

Und dann hätten wir da natürlich noch das Homie-Frontend, wobei was ich so mitgelesen habe hier ja auch nicht wirklich eine strikte Trennung in Widgets vorhanden ist.

Ich glaube ich sollte mal die Kategorie Frontends durchsehen und zusammenschreiben, wer an was arbeitet

@justme, man könnte allerdings sagen, dass der thread derzeit streng genommen gehighjacked ist.

[herrmannj]

Den Weg über Set / get zu gehen halte ich für grundsätzlich falsch weil er

A: eine sofortige Abhängigkeit von konkreter fhem implementation schafft. Beispiel, das RGB Widget von fhem

B: eine Echtzeit Aktualisierung auf dem Frontend muss strukturiert werden, am jetzigen longpoll vorbei

C: Set und get dürfen nicht über fhemweb laufen.

Es macht doch keinen Sinn eine Kopie der aktuell verwendeten (Bezug Frontend) Umsetzung mit anderem Design zu schaffen, da erbt man doch die ganzen Probleme mit.

Vg
Jörg

[justme1968]

ja. die posts vorhin waren zum teil off topic. aber eben nur zum teil . ich werde das was nicht andere frontends betrifft in diesem thread: http://forum.fhem.de/index.php/topic,27353.0.html halten.

aber zurück zu smartvisu (oder einem anderen reinen frontend):

ich mag immer noch nicht glauben das longpoll irreparabel kaputt ist. auch wenn es nicht 1:1 übernommen wird wäre es schön wenn eine 'reparierte' longpoll anbindung unter welchem namen auch immer wieder in fhemweb einfliessen würde.

longpoll ist ist nicht unbedingt nur das was zur aktualisierung in fhemweb verwendet wird sondern auch der mechanismus der die daten für den event monitor und das inform kommando liefert. je nach frontend ist es ja durchaus sinnvoll nur die events die im aktuellen raum eine rolle spielen zu bekommen. das gibt es hier ja schon.

der rückweg sollte natürlich nicht über fhemweb sondern telnet oder irgend ein anderes socket das näher am kernel ist laufen.