Weiterentwicklung von Smartvisu -> Visual Display for Fhem

[Pythonf]

Ich muss hier sagen, dass ich beides Verwende:
TabletUI hab ich aktuell auf einem RaspberryPi Touchscreen und steuer damit mein Squeezebox-Radio und SV verwende ich für alles andere. Was mir besonders an SV gefällt ist, dass es sich besser auf verschiedene Displaygrößen anpasst. So kann ich Sowohl vom Tablet, als auch vom Handy und PC auf das selbe SV zugreifen wo hingegen ich bei FTUI für jedes Endgerät eine seperate Oberfläche zusammenbasteln müsste - wenn sich hier nichts maßgeblich geändert hat (Bin allerdings recht unefahren mit HTML und CSS [Copy-Paste-Learning)).

Grüße
Fabian

[dev0]

Websockets sind auch so eine Sache, die zB nicht geschaut für einen Zugriff von unterwegs ohne VPN funktioieren.
...
Dass per Default erstmal die Devices authorisiert werden müssen auf Basis der IP ist finde ich auch für viele eine Hürde (ich habe die mit einem Websockets-Proxy umgangen)

Die beiden Themen sind anscheinend bei herrmannj in arbeit. Ist nur die Frage wann und ob diese Änderungen tatsächlich öffentlich werden, damit sie uns weiter bringen.

[HCS]

Schön wäre für SV zB, dass man bei Devices einfach ein Attribut "smartvisu" setzen kann und es wir automatisch pro Raum eine Seite mit verknüpften Elementen erzeugt nach gewissen Standards.

Das wäre jetzt etwas, das ich nicht bräuchte. Gerade die Unabhängigkeit von FHEM und SV bezüglich Darstellung und Gestaltung ist für mich wertvoll. FHEM ist für mich das Konfigurations-Frontend und SV das Frontend für die Benutzung und das bedeutet, dass ich in SV Dinge habe will, die ich in FHEM nicht brauche und auch nicht definieren will.

Da ich TabletUI nicht kenne, kann ich es nicht abgrenzen, aber ich kann mal darlegen, warum SV damals genau das war (und heute noch ist), was ich gesucht habe. Ich brauche ein Frontend, das:
- Unabhängig von FHEM-Räumen oder sonstwas nach meinen Anforderungen gestaltbar ist
- In das ich mein damaliges Intranet, das nichts mit Automatisierung zu tun hat (Bücherliste, ToDo-Liste, ...) integrieren konnte (mit einheitlichem Design)
- In das ich Daten aus einer anderen Steuerung, die ich nicht in FHEM habe und brauche, natlos integrieren konnte
- Das eine ansprechende Oberfläche hat, die ich ggf. auf mein persönliches "ansprechend" trimmen kann
- Ein technisches Konzep hat, das mir zusagt (Widgets, Treiber zur Datenbeschaffung, ...)
- Auf Smartphone, Tablet, PC, Mac und allem, was einen Browser hat, läuft

Und das gilt auch heute noch. Auch wenn mich die Abgrenzung zu TabletUI aus purer Neugier interessieren würde, kann ich mir nicht vorstellen, von Sv zu etwas Anderem zu wechseln. Dafür habe ich zu viel in SV investiert und es funktioniert viel zu gut.

Ich stimme aber mir drdownload überein, dass der Einstieg in SV für viele eine echte Hürde ist. Da muss man viel lernen und viel aus den unterschiedlichsten Quellen zusammenbauen und konfigurieren und dann auch noch HTML, JS, JQM, TWIG,  das Konzept und sonstwas lernen, um eigene Dinge umsetzen zu können.

Ich denke, dass man jetzt nicht ein völlig neues SV erfinden muss. Wichtig ist, dass es mal technisch auf einen aktuellen Stand gebracht wird, einige Unschönheiten beseitigt werden und die Pflege sichergestellt ist. Damit sind vermutlich alle, die es momentan verwenden und generell zufrieden sind, erst mal glücklich.

Wenn man es dann noch so hinbekommt, dass Einsteiger es einfacher in Gang bekommen, ist schon viel erreicht.
Und da helfen selbst so triviale Dinge wie fronthem mal in FHEM einchecken.

[Pythonf]

Schön wäre für SV zB, dass man bei Devices einfach ein Attribut "smartvisu" setzen kann und es wir automatisch pro Raum eine Seite mit verknüpften Elementen erzeugt nach gewissen Standards.

Das wäre jetzt etwas, das ich nicht bräuchte. Gerade die Unabhängigkeit von FHEM und SV bezüglich Darstellung und Gestaltung ist für mich wertvoll.[...]
Ich stimme aber mir drdownload überein, dass der Einstieg in SV für viele eine echte Hürde ist. Da muss man viel lernen und viel aus den unterschiedlichsten Quellen zusammenbauen und konfigurieren und dann auch noch HTML, JS, JQM, TWIG,  das Konzept und sonstwas lernen, um eigene Dinge umsetzen zu können.

Gerade hier würde ich einen Vorteil vom "Attribut smartvisu:Widget_Type und attr smartvisu:room" sehen. Es würde sicherlich einige presets z.B. für die Thermostate, Lichter, RGB, etc.. brauchen - die man eventuell sogar mit den Widgets verbinden könnte und am Ende hätte man dann ein vorkonfiguriertes FHEM/Fronthem sowie die SV Config und ebenfalls die passenden HTML-Datein um bereits mit SV arbeiten zu können ohne sich groß einarbeiten zu müssen (sowohl bei FTUI und SV braucht man ja von Beginn an HTML-Kentnisse). Das würde m.M. nach die Lernkurve gerade zu Beginn extrem steigern. Ich stimme euch aber absolut zu, dass die Individualität von SV erhalten bleiben sollte, da das gerade ein sehr wichtiges Kernfeature darstellt.

Grüße
Fabian

[drdownload]

Wenn man es hingekommt, dass man mit ein paar packages installieren Fronthem läuft und ein Grundgerüst mit ein paar attr angezeigt werden kann hat man schon gewonnen (und man das auch ohne IP config bedienen kann )

Wer mehr will muss sich in jedes System erst einarbeiten.

[fhem_cgn]

Gerade die Unabhängigkeit macht diese VISU doch erst für viele Leute interessant; und je größer die Community ist um so eher wird es damit weiter gehen.
Ich habe mit SmartVisu und Fhem gerade erst angefangen. Was es jedoch "aufwendig" macht, ist dass Homematic Komponenten teilweise nur recht schwer vernünftig eingebunden werden können.
Für die Rollos habe ich mir deswegen ein neues Widget erstellt; es müssen nur 3 GADs übergeben werden und alles funktioniert. Ein "komplettes" homatic widget auf Fhem zugeschnitten, würde es sicher für viele einfacher und attraktiver machen.

[dev0]

Gerade hier würde ich einen Vorteil vom "Attribut smartvisu:Widget_Type und attr smartvisu:room" sehen.

Eine Diskussion mit Rudi gab es hier bereits zu diesem Thema: https://forum.fhem.de/index.php?topic=39236.0
Um einen Attribut-Wildwuchs zu vermeiden, sollte man sich mMn erst einmal an den vorhandenen Möglichkeiten orientieren.

[justme1968]

aus meinem erfahrungen mit dem genericDeviceType attribut für homebridge: das attribut funktioniert und mann kann damit einfache standard fälle abdecken. durch die zum teil großen und zum teil sehr subtilen unterschiede zwischen unterschiedlichen device typen ist es aber bei weitem nicht ausreichend. es funktionier vor allem zur unterstützung um automatisch zwischen 'ähnlichen' geräten zu unterscheiden.

ich habe dann zusätzlich ein komplett frei konfigurierbares mapping von fhem kommandos und readings zu homekit services, characteristics und werten eingebaut sowie das ganze auch wieder rückwärts. erst damit (und ein paar defaults für die häufigsten device typen) war es dann wirklich flexibel genug.

ich denke damit kann man alles abdecken (bis hin zu eigenem node.ja code für hartnäckige sonderfälle), das ist dann aber leider oft nicht mehr plug&play. so lange nicht jemand das mapping schon mal gemacht hat und eine vorlage liefert.

die wirkliche vereinfachung für  hängt nicht an ein oder zwei attributen sondern an einer Installation auf knopfdruck und daran das alle seine devices automatisch funktionieren.

unabhängig wäre es schön wenn so viel frontends wie möglich die gleichen mechanismen verwenden. d.h. vorhandene attribute, generische einheiten, die gleichen authentifizierung und autorisierung, ...

gruss
  andre

ps: frontends müssen nicht immer grafisch sein. da gehört auch so etwas wie homebridge/homekit/siri dazu oder alexa oder sprachausgabe auch telnet.

[herrmannj]

Hierfür mache ich diesen neuen Thread auf um aktuelle Bugs und Erweiterungwünsche zu erfassen. Ebenso würde ich mich sehr über Feedback der Fronthem- & Fhem-Treiber-Entwickler freuen, ob wir diese Elemente in das neue "Smartvisu" integrieren oder als eigenen Teil belassen.
Gruß, Sascha

Hallo zusammen,

geht ja richtig ab !

Ich finde das Super und begrüße das ausdrücklich. Für mich ist fronthem immer eine Schnittstelle für "irgendein" Frontend gewesen. SV bot und bietet sich an weil vorhanden und erwachsen.

Eine Weiterentwicklung von sv, mag sein das es ein fork wird, liegt genauso auf der Hand wie Neuentwicklungen. Das unterteilt sich ja dann in bugfixes (das gibt es aktuell mWn den IOS9 bug) sowie eine Weiterentwicklung die am Ende mMn bedeutet: neue coole widgets.

TabletUI lebt mMn von der sehr aktiven Entwicklung der Widgets und einem coolen Design, "krankt" (nicht böse gemeint) aber ein wenig an dem instabilen und wenig performanten Unterbau. Auch hier ist es mMn super möglich Synergien zu erzeugen. Auf Ebene der Widgets sind sv und TabletUI sogar recht ähnlich. TabletUI Widgets lassen sich mich überschaubarem Aufwand portieren. Das gilt sicher sogar für das Gesamtkonstrukt mit gridster.

Das bringt mich direkt zu der ersten Frage, die vermutlich das weitere Vorgehen elementar beeinflusst.
Soll es ein FHEM-Smartvisu werden, ohne Rücksicht auf Domotiga, KNX usw. oder eine Weiterentwicklung eines allgemeinen SmartVisu?

Ich meine hier (fhem) die aktivere community zu sehen. Bisher gibt es bei sv viele Leute die "was wollen" wenige "die was reinwerfen" Außnahmen sind genau hier in diesem thread!

Know how und manpower sind aber eigentlich genug im forum vorhanden. SV (TabletUI) etc setzen auf ganz verbreitete Webtechniken, da können haben mehr user skills als bei fhem/perl. Wenn also vlt aus diesem thread ein "viele packen an" entsteht ist das doch TOP!

Mein Wünsche (sind so simple Dinge dabei wie "TWIG-Cache-Verzeichnis löschen, wenn man den Cache im Frontend abschaltet") beschreibe ich dann später mal, wenn klar ist, wo es hin geht und es evtl. eine issues list gibt.

Das betrifft mich/fronthem und ist im "next" drin.

-Bei Smartvisu stimmt das Design und die Dynamik. Aber auch das sind ein paar der Punkte die ich dennoch auch Anfassen würde. Wenn man Smartvisu z.B. als Visualisierung für die zetrale Haussteuerung nutzt, muß man mit wenigen Bewegungen schnell und übersichtlich seine Infos, Schaltzustände oder was auch immer bekommen. Das ganze darf nicht überladen wirken und muß optisch leicht und elegant wirken

Yepp. Sehe ich ganz genauso. Hier ist es sicher sinnvoll zu trennen zwischen sv als framework (was kann man in bezug ui erstellen, so ala SDK) und "was ist mitgeliefert" also Navigationselemente, widgets, icons, designs. Ich schlage vor beides gedanklich strikt zu trennen.

Zitat von: drdownload am Gestern um 14:01:34

    Websockets sind auch so eine Sache, die zB nicht geschaut für einen Zugriff von unterwegs ohne VPN funktioieren.
    ...
    Dass per Default erstmal die Devices authorisiert werden müssen auf Basis der IP ist finde ich auch für viele eine Hürde (ich habe die mit einem Websockets-Proxy umgangen)

Die beiden Themen sind anscheinend bei herrmannj in arbeit. Ist nur die Frage wann und ob diese Änderungen tatsächlich öffentlich werden, damit sie uns weiter bringen.

Ja sind sie. Mir ist klar sonnenklar das es mehr als wünschenswert wäre das schnellere Ergebnisse zu sehen. Wünsche ich mir auch. Nichts desto trotz kommt erst die family, dann der Dayjob (der mir gern echte auch mal 80h Wochen abverlangt) dann fhem.

Der erste fronthem war "beta" oder POC.
Der nächste (aka "next") wird
* einen integrierten Webserver plus PHP enthalten. Empfehle daher bei PHP zu bleiben, er ist auch deutlich besser mit fhem verzahnt. Daher gehen eben so Dinger wie cache löschen etc.
* Der ws treiber ist komplett neu, mit dem alten gehen eben keine generischen device, mit dem "next" gehts.
* wss ist noch in Arbeit.

Sobald die Version zum testen taugt werde ich sie natürlich auch rausgeben. Alphas noch ohne wss.

Was auch immer aus diesem thread entsteht: an der strikten Trennung zwischen leerer UI die von einem Webserver ausgeliefert wird und Inhalten die dynamisch über einen WS geliefert werden möchte ich auf jeden Fall ganz strikt festhalten! Genauso wie an der Mandantenfähigkeit (nicht Zwang) und dem Konzept Security bei Design.

vg
joerg

[HCS]

Zitat
Mein Wünsche (sind so simple Dinge dabei wie "TWIG-Cache-Verzeichnis löschen, wenn man den Cache im Frontend abschaltet") beschreibe ich dann später mal, wenn klar ist, wo es hin geht und es evtl. eine issues list gibt.

Das betrifft mich/fronthem und ist im "next" drin.

Dann habe ich das Konzept verlernt
Ich stelle mir mal vor, dass ich ein SV so ganz ohne FHEM und fronthem habe und den TWIG-Cache auf der config page abschalte. Dann sollte (aus den bekannten Gründen) das Cache-Verzeichnis geleert werden. Das ist doch pur SV intern?

Kannst Du generell ein wenig das Konzept, wie "next" arbeitet, beschreiben?
Speziell die Anbindung von SV (Treiber, WebSocket, Einbindung Charts, ...)
Bleibt das Konzept bezüglich Treiber wie bisher?

[Cybers]

wenn ich das jetzt alles richtig interpretiere würde ich es wie folgt zusammenfassen:

1) die Schnittstelle von Smartvisu zu Fhem bleibt mit Fronthem wie bisher als getrenntes Modul bestehen. Hermannj arbeitet an der nächsten Version die er in naher Zukunft (?) veröffentlicht.

2) der Fhem-Treiber von HCS bleibt ebenfalls bestehen um Smartvisu auch für andere Plattformen unabhängig nutzen zu können

3) alle Forks und Pull-Requests werden in einer "Smartvisu-New-Master" zusammengefasst -> ist fast abgeschlossen

4) Smartvisu wird so angepasst, daß es mit der aktuellen Jquery-Version läuft. Hiermit sollte der IOS 9 Bug behoben sein und Smartvisu ist wieder updatesicher.

5) einfache und automatisierte Smartvisu-Installation inkl. der Fhem tauglichen Widgets

Gruß, Sascha

[dev0]

Find ich gut.

[drdownload]

Widgets die mir bis jetzt abgehen (ich fantasiere da teilweise von heißen Eislutschern + die Ideen müssen nicht alle Zusammenpassen bzw. fehlen da öfter auch noch FHEM devices dazu)
Wetterstation - Informationen
Markisen-Steuerung
Wettervorhersage (wie beim TabletUI)
flexible Kalendereintragsanzeige (calview)
Wecker
Generelles Radio-Widget inkl. Library-Browser
Floorplan als alternative Ansicht
Flexibleres Reagieren auf ein Ändern der Ausrichtung bzw. Anzeigefläche

[herrmannj]

wenn ich das jetzt alles richtig interpretiere würde ich es wie folgt zusammenfassen:

1) die Schnittstelle von Smartvisu zu Fhem bleibt mit Fronthem wie bisher als getrenntes Modul bestehen. Hermannj arbeitet an der nächsten Version die er in naher Zukunft (?) veröffentlicht.

2) der Fhem-Treiber von HCS bleibt ebenfalls bestehen um Smartvisu auch für andere Plattformen unabhängig nutzen zu können

3) alle Forks und Pull-Requests werden in einer "Smartvisu-New-Master" zusammengefasst -> ist fast abgeschlossen

4) Smartvisu wird so angepasst, daß es mit der aktuellen Jquery-Version läuft. Hiermit sollte der IOS 9 Bug behoben sein und Smartvisu ist wieder updatesicher.

5) einfache und automatisierte Smartvisu-Installation inkl. der Fhem tauglichen Widgets

Gruß, Sascha

Yepp, finde ich auch gut.

Was ich evtl ergänzen möchte wäre ein loader für die widgets.
-Zum ersten fände ich es gut wenn widgets die in einem bestimmten Verzeichnis liegen automatisch geladen werden, also nicht mehr händisch. In die Seiten müssten sie natürlich trotzdem eingetragen werdem. Da gab es schon einen code Vorschlag.
-Zum zweiten wäre es möglich (ich könnte das schreiben) auch das laden von widgets aus repos von fhem aus anzustoßen. Ein Befehl install-widget <repo>|<name> oder so
- schön wäre ebenfalls wenn sich weitere Autoren fänden um das in eine mobile app zu gießen. (Webview, IOS, Android). WP10 gab es schon einen Ansatz

vg
joerg 

[dev0]

-Zum ersten fände ich es gut wenn widgets die in einem bestimmten Verzeichnis liegen automatisch geladen werden, also nicht mehr händisch. In die Seiten müssten sie natürlich trotzdem eingetragen werdem. Da gab es schon einen code Vorschlag.

Meinst Du mit dem Codevorschlag das "includen" von js und css oder wirklich automatisch?