Fronthem - Eine FHEM-Schnittstelle für Frontends

[herrmannj]

Ich hätte da mal eine grundsätzliche Frage:

Kann ich smartvisu eigentlich schon installieren um damit zu spielen?

Bzw. wie werden Smartvisu Seiten erstellt? Die Homepage schweigt sich dazu leider aus...

Hi,

kannst Du, bekommst halt noch keine Reaktionen von fhem dazu. Ich habe mir dort das raspi image geladen und teste ausschließlich mit den Demo Installationen (sind mehrere drauf)

Zu smartVisu (wie mache ich Seiten), kann ich bisher kaum was beitragen. Ich habe mir das genau so tief angeschaut wie notwendig für die fhem Anbindung.

Wenn Du da Lust hast Dich damit zu beschäftigen dann wär das cool. Bitte auch Erkenntnisse hier in den thread. Außerdem glaub ich das know how zum Thema "wie erstelle ich da ein widget" sehr hilfreich wäre. Wenn das erstmal läuft wird es nicht lange dauern bis wir da irgendwas anbinden wollen wo es kein widget für gibt.

vg
jörg

[Tropaion]

@hermannj
Mit dem erstellen von Seiten hab ich mich jetzt schon etwas beschäftigt. So schwer ist es gar nicht eine kleine Seite hinzubekommen für denn Anfang. Vll. kann ich ja mal am WE etwas dazu schreiben. Da bin ich auch bei einem Freund der dieses System im Dauerbetrieb verwendet. Was genau wollt ihr denn wissen/braucht ihr denn?

Mfg,
Tropaion

[herrmannj]

Hallo zusammen,

vielen Dank für die zahlreichen device list, war gut. So Geschichten wie den Stufenschalter hätte ich nicht sofort in meine Denke parat gehabt  . Da kommen dann sicher im laufenden Betrieb noch die eine oder andere "exotische" Geschichte dazu.

Resume so weit ist das sich die Sachen die wir jetzt hier hatten mMn alle abbilden lassen (und das galt es ja zu verifizieren). Die Hoffnung das man am Ende auch gar nicht so viele unterschiedliche converter braucht scheint sich auch zu bestätigen:

#1 die Heizungsgeschichten über die verschiedenen System (also ist-temp, soll temp-etc) lassen sich mit einem converter abbilden: Zahl rein, ein wenig umwandeln, Zahl raus. Vielleicht noch auf 0.5° anpassen. Geht dann auch für Thermometer
#2 on/off und an/aus in 1/0 (entweder als ein converter mit parameter, vielleicht auch zwei wegen "on" vs. "an")
#3 muss dann ein reading / event auf einen string testen, wenn vorhanden dann "1" sonst "0". Den braucht man bei Heizung (in einem reading stehen entweder night/comfort/frost etc - in sv sind das drei getrennte gads. Der würde auch beim Stufen-Schalter-Beispiel zum Einsatz kommen sowie Motion detector etc)
# 4 die RGBs. Alle die ich jetzt gesehen habe scheinen zu passen, RGB rein, Kanäle trennen auf 3 gads raus. Da muss ich nochmal ein wenig denken weil der Rückweg (sv -> fhem) etwas tricky ist. sv schickt alle drei Kanäle getrennt und nacheinander. Das würde erst mal bedeuten das für einmal Farbe setzen nacheinander erst r dann g dann b auf die Lampe geschickt wird. Das wäre optisch ein wenig doof, da muss ich nochmal schauen wie man das intelligent lösen kann.
#5 wären die dimmer also 0..100 auf der fhem seite
#6 Sonderlocke FS20 dimmer wegen der doofen dimsteps.

Das soll und muss jetzt keine vollständige Liste sein (weil, der user kann ja selber converter in die 99_myUtils schreiben und die Liste wird auch wachsen), aber ist schon mal eine Richtschnur.

Was ich dadurch noch gelernt habe ist das die Situation 1 reading / mehrere gad öfter auftaucht als ich dachte. Das umgekehrte Beispiel ( 1 gad gehört zu verschiedenen fhem readings) habe ich noch nicht gefunden.

Wenn jemand noch was anderes hat, gerne rein damit.

vg
jörg

[herrmannj]

@hermannj
Mit dem erstellen von Seiten hab ich mich jetzt schon etwas beschäftigt. So schwer ist es gar nicht eine kleine Seite hinzubekommen für denn Anfang. Vll. kann ich ja mal am WE etwas dazu schreiben. Da bin ich auch bei einem Freund der dieses System im Dauerbetrieb verwendet. Was genau wollt ihr denn wissen/braucht ihr denn?

Mfg,
Tropaion

Hi, danke.

kann da nur für mich sprechen. Mir fehlen die Grundlagen wo ich beim Seitenaufbau starten müsste. Ich habe gelesen man soll die base Seiten in ein neues Verzeichnis kopieren und die dann anpassen. Das ist der Punkt wo es für mich anfängt und ich lernen muss   

vg
jörg

[Tropaion]

Ja, das stimmt schon so, aber Anhand der Beispiele kann man sich recht gut herleiten, wie es funktioniert.

[Grimm80]

Hi,

bis wann kann man denn mit dem Treiber rechnen? Würde diesen auch gern testen. Benutze HomeMatic (Intel Nuc - Server) und GPIO vom Rasp (Slave).

[herrmannj]

Hi,

bin leider im Augenblick anderweitig recht eingespannt. Zum Glück ist der Stand in dem Projekt schon ganz passabel -> Antwort "in Kürze"

vg
jörg

[thoweiss]

Das klingt gut.


Ich habe mal ein wenig mit smartVISU gespielt - das erstellen von Seiten ist relativ einfach.

Mal sehen ob ich dazu etwas zusammenschreiben kann.

Gruß,
Thorsten

[ntruchsess]

Hallo Jörg,

ich habe mir Deine Implementation gerade mal genauer angesehen und sehe jetzt klarer. Du ganze ist ein Websocket-server für den bestehenden io_smarthome.py.js treiber, richtig? Ich bin gerade genau den anderen Weg gegangen - generischer WebSocket-server im fhem + Javascript-library zur Adaption für die Gegenseite. Die library funktioniert schon soweit, dass man connecten, die komplette Config abholen, auf Events reagieren und readings per get/set manipulieren kann. Habe ich auch schon in einen irudimentären io_fhem.js-treiber gewrappt, allerdings noch ohne weitergehendes Mapping für Devices, die nicht ausschließlich über den state manipuliert werden. Da ist mir auch klar geworden, wozu Dein smartVisuEditor gut ist - irgendwie muss man ja die Ganzen Readings auf simple 'items' im smartVisu-kontext abbilden und das machst Du nicht über fhem-attribute, sondern legst es in einer separaten config-datei ab, richtig?

- Norbert

[herrmannj]

Hallo Norbert,

hatte Deinen anderen post auch gesehen, Stand aber den ganzen Tag unter Dauer Feuer und komme daher erst jetzt dazu.

Kurz: genau! 

Etwas detaillierter: ich verwende aktuell den domotiga treiber - der smarthome.py würde vmtl. genauso gehen.

Deswegen meinte ich auch das wir auf anwendungs Ebene wahrscheinlich keine Synergien fiinden, bei ws server selbst könnte das aber sein.

Das mapping/editor: richtig  . sv bündelt in den widgets die grafische Darstellung, funktionell sind das aber zum Beispiel beim Thermostat 6 einzelne Buttons und zwei Anzeigen die erst einmal von konkreter Funktion (im Sinne von "ich bin ein Thermostat") losgelöst sind. Das macht auch Sinn, nach dem gleichen System funktioniert ja auch jeder HM Lichtschalter an der Wand. Damit jetzt der user nicht 2 Millionen notifys erstellen muss kapselt der editor die notifys plus Spezialfunktionen.

Technisch fragt sv nach dem laden per "monitor" die Liste der items (heissen dann gad) bei fhem an die es auf dem Display hat. svServer (zusammen mit svDevice) sendet dann initial den Zustand (per "item", übersetzt in das sv Format. Aus zB "on" wird "1") und aktualisiert (ebenfalls per "item") den Zustand wenn fhem passende Events erzeugt.

Der Nutzen, ich bleib beim Beispiel Thermostat: wenn ich zB von "comfort" auf "night" schalte muss ich ja sowohl in die readings als auch spezielle sets gehen, state reicht da nicht. Noch spezieller wird es wenn ich zB ein "at" oder eine "notify" auf "enable" oder "disable" setze, dann muss ich sogar in die attribute. Das wird eben komplett damit abgedeckt.

Dazu macht der Editor noch folgendes: ich lasse den ws port nicht für "alle" offen sondern ein device muss sich autorisieren. Im Augenblick per IP (was für ein internes Netz auch ok ist) später per certifikat. Der editor bestimmt also auch welches device welchen set lesen oder ändern darf. Plus special: erst pin eingeben dann darfst Du schalten. (Anwendung zB Alarmanlage auf Tab im Eingangsbereich).

Damit ich jetzt aber nicht für jedes device (iphone mama, papa, kind, oma  tab hier, tab da...) das mapping jedesmal aufs neue erstellen muss liegt das mapping global in einer config, nur die berechtigungen muss ich per device vergeben.

Ansonsten gibt es noch "dialog" (zeige eine Meldung auf dem display), "trigger" (macht das gleiche wie fhem - trigger), "plot" und "log". Die sind noch tbd.

vg
jörg

[ntruchsess]

Ich denke, das kann man durchaus gut verheiraten. Meine Anbindung kann mittlerweile das komplette fhem-remoting und ist dynamisch einfach um eigene Message-typen erweiterbar. Was noch fehlt ist ein Security-konzept (das sehe ich als unabhängig von smartVisu, es hat für mich - auch wenn ich es für produktiven Einsatz für unverzichtbar halte - zeitlich aber erst mal relativ niedrige Priorität) und eben das smartVisu-spezifische Mapping. Da hast Du ja schon einiges implementiert, das schaue ich mir jetzt mal ganz genau an. Wenn ich es richtig Verstanden habe soll es die Widgets (item in smartVisu) mit den zugehörigen fhem-readings beliebiger Devices (inklusive Mapping der Werte) zusammenbringen? Die Aggregationsebene darüber (z.B. 'Thermostat') ist dann doch nur ein 'optisches' Gruppieren (ggf. mit gemeinsamen Zugriffsrechten versehen) individuell gemappter Items, wobei die eigentliche Steuerungsfunktion in fhem verbleibt, richtig?

Übrigens: da meine Implementierung auf den TCPServerUtils basiert (ich bin ein Freund von Wiederverwendung) gabs das SSL 'für lau' dazu

Gruß,

Norbert

[herrmannj]

Dir ist schon klar das du bei deinem nächsten Post einen ausgeben musst ?  (1000)

Die Security ist nicht verhandelbar, wenn du die hinterher "ranbappst" wird das zu 99% flickschusterei. Aber die steht ja soweit auch n Framework, das zeit Argument entfällt also

Das mit Widget gleich item stimmt so nicht. Ein Widget besteht meist aus mehreren items.

Du hast glaub ich jetzt Änderungen drin die ich noch kenne. (?) verstehe ich richtig, du ziehst quasi die fhem device komplett als Abbildung in das js. ?

Vg
Jörg

[ntruchsess]

ich habe Widget mit Item synonym benutzt. Das ist im SmartVisu-kontext offensichtlich anders gemeint - also 'item'.

Die Security ist bei mir auch nicht verhandelbar, und das wird auch keine Flickschusterei, das ist aber (bzw. muss) ortogonal zu der übrigen Funktionalität des Frameworks (= websocket.pm + fhem.js) sein, damit es für alle Verwender einheitlich zur Verfügung steht. Daher kann sie weitestgehend unabhängig von dieser entwickelt werden.

Grundsätzlich stelle ich mir das so vor: Unmittelbar nach dem Connect wird js-seitig ein Callback aufgerufen, der Credentials abfragt, in einen Token verschlüsselt und mit jeder Message an den Server schickt. Messages ohne gültigen Token werden nicht akzeptiert. Security auf z.B. reading-ebene kommt dann 'on top', das wird plugable mit Callbacks vor ausführung des jeweiligen Commands auf der Serverseite realisiert.

im websocket.html, onConnected() rufe ich 'fhem.list()' auf, das sagt dem websocket-modul, dass es alle details der fhem-devices als 'listentry'-events schicken soll. Anschließend hat man die komplette fhem-konfig im js. Wenn man das Reading/Item-mapping in Attributen untergebracht hätte, wäre es also schon da
Damit kann man jedenfalls schon beim Connect alle items mit aktuellen Werten befüllen. (Auch an der Stelle kommt dann ein security-callback rein, der die Sichtbarkeit der Listentries regelt).

[ntruchsess]

@Jörg: kurze Verständnisfrage: hat es einen besonderen Grund, warum du die 'webif-data'-requests aus smartVisuEditor.js über die get-methode abwickelst und nicht über den sowieso zur Verfügung stehenden Websocket?
Was hälst Du davon an dem Modul zu kooperieren (die Sache mit der Mapping-definition über den Editor gefällt mir recht gut das würde ich nicht noch mal schreiben wollen ). Solange noch nichts released ist könntest Du z.B. meinen fhem-mirror clonen und Deine Changes dorthin committen, dann könnte man sich patches gegenseitig als 'pull-request' zukommen lassen bzw. sich einfach bei Bedarf per pull selber abholen (Ich hab schon mal einen branch 'smatVisu' mit deinem aktuellen Arbeitsstand angelegt). Wenn Du nicht möchtest, dass Deine Dateien schon auf github liegen (Du hast noch keine Lizenz festgelegt, ich habe daher angenommen, dass so wie fhem selbst unter GPLv2 stehn soll), gib Bescheid, dann lösche ich den Branch wieder.

- Norbert

[pole23]

Hallo,

gibt es schon eine Version zum Testen?