Fronthem - Eine FHEM-Schnittstelle für Frontends

[der-Lolo]

Ich hatte ja begonnen einen Dashboard Multimedia Tab zu erstellen, mithilfe von einigen Dummys und rGs kann man da schon einiges machen...
Ich schrieb auch ein bisschen Howto mässig mit und bastelte an einer 99_myAudioUtils.pm
Aktuell rutscht mir aber ein anderes, wichtigeres Projekt dazwischen - ich werds wohl an den Nagel hängen müssen.

Falls jemand weiter basteln möchte versorge ich Ihn gerne mit dem bereits stehendem Grundgerüst / Konzept.

[herrmannj]

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 fußt auf fhemweb und das ist in Bezug auf Stabilität, Performance etc Dauerausstellung. Ich kann die ganzen workarounds schon garnicht mehr zählen.

Das ist jetzt nicht despektierlich gemeint, aber genau da schreist doch nach alternativen

Vg
Jörg

[justme1968]

ich sehe longpoll nicht fest mit fhemweb verheiratet sondern aus mehreren teilen bestehend:

1. den mechanismuss events zu sammeln und die für einen raum unwichtigen weg zu schmeissen bzw. nur bestimmte zu abonnieren
2. das socket auf dem die events raus geschickt werden
3. die verarbeitung durch js code

1. ist nicht fhemweb spezifisch
2. eigentlich auch nicht
3. ist nicht fhemweb spezifisch sondern *ist* fhemweb

1. + 2. ohne blocking probleme + neues frontend wäre z.b. die smart visu anbindung
1. + 2. ohne blocking probleme + 3. wäre ein 'besseres' fhermweb

neben den blocking problemen in 2. wäre es noch schön wenn die codierung der nachrichten verbessert wird.

aber vielleicht reden wir auch aneinander vorbei wenn du von alternativen sprichst.

gruss
  andre

[herrmannj]

longpoll wird ganz konkret in 01_FHEMWEB beantwortet, mit ganz konkret den gleichen Mechanismen die fhemweb als frontend ausliefern.

Die performance / Zuverlässigkeit wäre also genau mit dem Teil verknüpft wo es aktuell "hängt". Das macht schon daher keinen Sinn. Dazu kommen "Folgekosten" wie

* wenn Rudi irgendwas am longpoll ändert, funktionieren Aufsätze nicht mehr. In der Vergangenheit so geschehen mit floorplan, webview.
* Das Konzept der Räume (-> longpoll) ist eine fhem Konzept, kein smartVisu Konzept.
* Eine Kommunikation die auf fhemweb get/set aufsetzt setzt sofort voraus das port 8080 (oder Vergleichbar) offen ist.
* Benutzer und Rechte können dann (wieder) nur von fhemweb erbracht werden.
* Die smartVisu widgets erwarten GAD Adressen. Die Umsetzung auf fhem device muss clientseitig erbracht werden.

Wenn Du Dir die smartVisu treiber anschaust siehst Du verschiedene Konzepte die dort umgesetzt werden, beispielsweise eine Websocket Implementierung. Im Augenblick ist genau das, mit einem passenden fhem device als counterpart mein Favorit.

Bevor ich das schreibe (im Kern ja überschaubarer Aufwand) würde ich gern noch mehr in Bezug auf smartVisu verstehen und auch ein Konzept haben wie eine zukünftige user/device/rechte Verwaltung dafür funktionieren könnte. Das sollte in dem fhem device zumindest in der Architektur bereits angelegt sein.

vg
jörg

[herrmannj]

Für die meisten Bastler würde es schon reichen wenn sie ein Werkzeug an die Hand bekommen mit dem sie
eine Oberfläche bekommen das auch den "Hausfrauen"-Test besteht - und das bei aller liebe, und nein, da braucht sich jetzt keine Dame
im Forum angegriffen fühlen,  aber PGM1-X sind hier bei den meisten Leuten gnadenlos durchgefallen. Sprich hier reicht es schon wenn man
quasi ein Frontend fürs Frontend bekommt - und ja - mir fehlt hier definitiv noch eine Menge technisches Wissen der FHEM internas.

Hi,

ich hab das jetzt so verstanden das Du fhemweb erweitern möchtest. Mach das, das ist aber nicht Thema dieses threats  Es geht auch nicht darum fhemweb irgendwie generell zu ersetzen sondern um die Möglichkeit auch (!) smartVisu verwendet zu können. Wer möchte kann, keiner muss 

vg
jörg

[justme1968]

@herrmannj: longpoll setzt auf den inform mechanismus auf. und der ist nicht fhemweb spezifisch sondern geht z.b. auch per telnet. diese inform daten auf ein socket/websocket zu schieben und zwar nicht smartvisu spezifisch sondern so generell das auch andere frontends (und irgendwann auch fhemweb) daran hängen können ist die idee. ob man das raum konzept dann nutzt oder sozusagen (implizit) den raum everything aboniert wäre dann frontend abhängig.

fhemweb get/set über port 8080 habe ich nie gemeint.

werden die gad Adressen wirklich auf ein komplettes device gemapped? ich dachte noch feinkörniger auf ein device:reading bzw. device:kommando.

@h0ly0ne: ich glaube über die db zu gehen ist der falsche ansatz. und selbst wenn du über die db gehst sollte es nicht über fhemweb sein...

gruss
  andre

[herrmannj]

ah, verstehe. Sehe ich dann ähnlich. 

Der genaue Transportweg ist ja auch schon sekundär. Das mit den GAD hab ich noch nicht komplett verstanden (Wenn sich jemand zu einem crashkurs berufen fühlt, sehr gerne  ). Device/reading würde auch Sinn machen, irgendwo muss es ja ein mapping geben.

Beispiel RGB LED, da geht ja von white (kelvin) über nur RGB bis HSV alles und das muss ja

a: in den Möglichkeiten die das widget bietet (bieten kann) und dem was
b: die lampe bietet

irgendwo ge-matched werden. Bzw im Idealfall erfährt das widget was die lampe kann und stellt seine visu darauf ein. Bei HVAC, Securiity selbst Wecker siehts ja auch so aus.

Wichtig ist ja das die Umsetzung dann auf fhem Seiten und auf der visu Seite die Kompatibilität beibehält, sonst wird das nicht angenommen werden.

vg
jörg

[justme1968]

ja. genau. aber nicht nur kann es widgets für unterschiedlich aspekte eines device geben wie in deinem beispiel sondern es können auch unterschiedliche (oder gleiche) aspekte aus mehreren devices in einem widget kombiniert werden. siehe z.b. heizungssteuerung mit ist- und soll temperatur aus unterschiedlichen sensoren.

[herrmannj]

ja. genau. aber nicht nur kann es widgets für unterschiedlich aspekte eines device geben wie in deinem beispiel sondern es können auch unterschiedliche (oder gleiche) aspekte aus mehreren devices in einem widget kombiniert werden. siehe z.b. heizungssteuerung mit ist- und soll temperatur aus unterschiedlichen sensoren.

yepp, genau. Dann macht eigentlich nur GAD == reading Sinn

Nun müsste man halt erst einmal verstehen ob es Regeln für die GAD gibt die man einhalten muss (bzw sollte, siehe Kompatibiltät), ob es Regeln für Formate bzw Einheiten gibt. Danach könnte das mapping im fhem-treiber-device (so ala Floorplan editor) gemacht werden oder in end device (bsp FHT) als attr liegen.

Ersteres würde ich eigentlich bevorzugen weil es ja die Möglichkeit eröffnen würde von dort aus ein Layout in Richtung smartVisu zu exportieren.

Zusätzlich hätte ich gerne noch einen Plan bzgl user/device etc. Bei der Variante 1 könnte man Regeln im Editor anpassen das wäre eigentlich ganz charmant. (Also: Eltern können Alarmanlage scharfschalten, Kind nicht. Wohnzimmer Tablett steuert Heizung alle, Kinderzimmer nur Kind, Eltern können überschreiben. Mobiler zugrif kann x ... usw)

Dafür müsste man auf Treiber Seite erkennen wer / womit zugreift .

vg
jörg
     

[herrmannj]

je mehr ich darüber nachdenke umso mehr sehe ich die Editor Variante:

Im Idealfall lädt fhem die Liste der verwendeten widgets aus der visu (ich meine da eine cfg gesehen zu haben, bin mir nicht sicher).

Ausgehend davon kann man dann in fhem via fw_detail-Editor den verwendeten GADs (der widgets) das entspechende fhem reading (get, etc) zuordnen. Kombiniert mit regex oder Makro-Definition würde das auch gleich das Problem der vielen individuellen fhem device lösen. Der "Übersetzer" für "was auch immer" wäre dann universell. Rückwärts (set) genauso.

Wie man das mit logs macht müsste ich noch prüfen. Im Idealfall soviel Infos wie möglich aus den gplot.

Na, ich denke das kann was werden. 

Ergänzungen ?

vg
jörg

[justme1968]

das klingt nicht schlecht.

[herrmannj]

Ola an alle smartVisu Interessenten,

kurze Wasserstandsmeldung:

bzgl Driver und Websockets habe ich keine Showstopper gefunden, erste kleine Test positiv.

Zur Autorisierung:
mir erscheinen Zertifikate (X509) hier als geeignetes Mittel.

Das würde dann in etwa so ablaufen:
die display device (zb ipad) benötigen ein selbst erzeugtes Zertifikat.
smartVisu (lamp + smartvisu) prüfen das Zertifikat und liefern die visu für dieses device aus.
fhem prüft das zertifikat (auf websocket), ordnet sie einem device zu und nimmt nur whitelist Befehle dazu an, respektive schickt readings dazu weg (wenn verbunden).

Innerhalb fhem wird jedes device (iphone gg, iphone wuki, tablet wohnzimmer ...) als eigenes device angelegt. Dann sind user und device miteinander verknüpft. Iphone wuki bekommt nur wecker wuki usw.

Das löst noch nicht das Problem zb des Tablett im Flur über das sich zB die Alarmanlage ausschalten lässt. (GG darf, Einbrecher lieber nicht  ). Das liese sich aber zb so lösen das ein smartVisu keypad widget erstellt wird. Widget sendet pin an fhem, fhem prüft und gibt spezielle settings, (Alarm) für xx minuten frei. Prüfung dafür findet in fhem statt, logischerweise nicht im client.

Hat jemand Vorschläge/Einwände/Hinweise zu diesem Konzept ?
Passt soweit für alle ?

vg
Jörg

[herrmannj]

Hi @all,

kurze Info:
das Projekt läuft soweit, ich denke im Lauf der kommenden Woche eine alpha hier rein stellen zu können (bin im Augenblick short-of-time).

Hatte auch einen netten Kontakt zu Martin vom smartVisu team. Die Hoffnung das er mir noch mehr Doku zur Verfügung stellt hat sich zwar nicht erfüllt - darüber hinaus sehr hilfsbereit.

Wer also möchte kann durchaus schon ein wenig mit smartVisu "spielen" -> also üben wie man eigene Seiten gestaltet, aufbaut. Krönung wäre wenn jemand ergründet wie man eigene widgets schreibt. (smartVisu.de)

Die final wird pro device ein eigenes Unterverzeichnis benutzen. Dazu kommt in die index.php eine Weiche. Eine Anleitung zum installieren der Zertifikate werde ich für nginx erstellen.

vg
Jörg

[Tropaion]

Hi @herrmannj

Ich melde mich jetzt auch mal wieder zu Wort.
Deine Idee mit den Zertifikaten halte ich für sehr gut. Aber wenn du z.B auf einem iPad das mit einem Zertifikat löst, geht das doch wahrscheinlich nur mit einem gejailbreakten, oder liege ich da falsch, kann man bei iOS ohne Jailbreak ein Zertifikat erstellen? (vll. wie wäre es, wenn man die Deviceerkennung über die Mac-Adresse macht? Oder wäre das zu unsicher?).

Was für eine Doku brauchst du denn?
Die für die man einen Zugang braucht? Weil eine "Leseprobe" gibt es ja auch. Wenn ich es richtig verstanden habe, hast du auch schon einen Teil bekommen, oder liege ich falsch?

Ich finde es jedenfalls sehr toll, das du einen Treiber schreibst.
Wenn ich irgendwie helfen kann, stehe ich gerne zur Verfügung. Meine Programmierkentnisse beschränken sich zwar auf C, HTML und PHP da ich nur in der Freizeit mit programmieren zu tun habe und Elektroniker in Ausbildung bin.

mfg,
Tropaion

[jody]

Hi herrmannj,

finde Klasse was du da machst. Wenn du Mithelfer brauchst kannst gerne nen Aufruf machen.

Gruß jody