Weiterentwicklung von Smartvisu -> Visual Display for Fhem

[Cybers]

Hallo,

da sich bei Smartvisu nichts mehr tut und Martin Gleiß sich auch nicht auf Anfragen im KNX-Forum äußert, werde ich mich an die Weiterentwicklung von "Smartvisu" setzen.

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

[marvin78]

Hast du mit hermannj gesprochen (Fronthem Entwickler)?

[Cybers]

Mit hermannj habe ich nicht gesprochen. Auch ihn habe ich ja mit dem ersten Post angesprochen und ich würde mich sehr über seine Beteiligung freuen.
Grundsätzlich habe ich nichts gegen die eigenständige Fronthem-Schnittstelle. Mir geht es primär um die Visualisierung. Aber um über die verschiedenen Vorschläge und Ansätze diskutieren zu können, habe ich ja diesen Thread erstellt. Schön wäre es wenn am Ende eine vernünftige Idee entsteht die dann auch umgesetzt werden kann. Da aus diesem Forum schon viele an der bisherigen Smartvisu-Lösung mitgewirkt haben, möchte ich gerne viele mit ins Boot holen um keinen Alleingang zu machen.

Gruß, Sascha

[drdownload]

Interessant aber wenngleich mühsam wäre sicher in einem ersten Schritt mal alle Forks und Pull-Requests auf Github zusammenzusammeln und dann als erstes eine Roadmap zu erstellen.

Zusätzlich müsste man natürlich neben dem FHEM-Forum das auch beim knx-forum als auch bei Domotica bekannt machen.

zB https://github.com/ddtlabs/smartvisu/commits/develop

[HCS]

da sich bei Smartvisu nichts mehr tut und Martin Gleiß sich auch nicht auf Anfragen im KNX-Forum äußert, werde ich mich an die Weiterentwicklung von "Smartvisu" setzen.

Das ist mal eine Ansage. Super!.

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.

Ich habe damals den "FEHM-Treiber" geschrieben, im wesentlichen wegen Performance und einem automatische Reconnect und weil ich zusätzlich von einer "Nicht-FHEM-Steuerung" Daten einsammeln muss.

Zusätzlich müsste man natürlich neben dem FHEM-Forum das auch beim knx-forum als auch bei Domotica bekannt machen.

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?

Aus FHEM-Sicht wäre ein angepasstes SV sicher ideal, incl. Treiber und auf FHEM angepasste widgets.
Wenn man auf nichts weiter Rücksicht nehmen muss, ist es sicher auch einfacher.

Zum Treiber: kann gerne irgendwie integriert werden, wenn es etwas dran anzupassen gibt, gib Bescheid, darfst aber, wenn es Dir lieber ist, auch gerne selbst dran ändern. Sehen wir dann, wenn die Anforderungen klar sind. Wenn ich etwas dran tun soll, muss ich die Zeit dafür irgendwo ausgraben, weil ich mit dem LaCrosseGateway noch etwas im Stress bin. Wird aber schon irgendwie gehen.

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.

[drdownload]

Ich glaube in Schwung kommt es nur wenn man sich auf ein SV-FHEM konzentriert.Sprich wenn Entscheidungen anstehen, die vielleicht die Kompatibilität mit anderen Systemen einschränken für ein SV-FHEM entscheiden.

[vbs]

Aus meiner Sicht ist gerade diese Generizität die Stärke von SmartVisu. Wenn man auf eine saubere Schnittstelle achtet, könnte man die mMn auch beibehalten (auch wenn man es jetzt primär für FHEM entwickelt).
Mal eine andere Frage: TabletUI scheint ja mittlerweile sehr verbreitet und hat auch (gefühlt) viele Anhänger. Ist denn klar, wie man SmartVisu ggü. TabletUI abgrenzen möchte? Also was wäre die Zielstellung von SmartVisu? Welche Anforderungen würde man mit SmartVisu erfüllen wollen, die man mit TabletUI nicht erfüllen kann?

Ich hab mich damals auch recht viel mit SmartVisu beschäftigt, aber das ganze Projekt ist irgendwie an so ziemlich allen Fronten irgendwie eingeschlafen. Ich wollte mir jetzt irgendwann mal TabletUI ansehen, daher die Frage bzgl. der Abgrenzung.

[Cybers]

- mein erster Gedanke war auch die Entwicklung auf Fhem zu beschränken. Zu Domotiga kann ich nichts sagen, da habe ich absolut keinen Einblick drin. KNX wäre ja nicht wirklich außen vor, da das soviel ich weiß ja auch mit Fhem läuft, oder nicht.

- meiner Meinung nach sehe ich in dem Fhem-Treiber aktuell auch keinen Handlungsbedarf. Könnte man daher auch eigenständig lassen

Interessant aber wenngleich mühsam wäre sicher in einem ersten Schritt mal alle Forks und Pull-Requests auf Github zusammenzusammeln und dann als erstes eine Roadmap zu erstellen.

Aktuell sitze ich dran die einzelnen Änderungen in einer quasi "Smartvisu-New-Master" zusammen zu basteln um eine aktuelle Basis zu haben.

Der weitere Fahrplan soll ja hier erstmal zusammen getragen werden.

[dev0]

werde ich mich an die Weiterentwicklung von "Smartvisu" setzen

Respekt, finde ich gut!
Was aus meiner Sicht gefixed werden müsste, ist der IOS9/Popup Bug. Scheint an einer veralteten jqm Version zu liegen, für neuere Versionen sind aber Anpassungen an sv nötig. Highcharts läßt sich hingegen ohne Problem auf den aktuellen Stand bringen.

Aus meiner Sicht ist gerade diese Generizität die Stärke von SmartVisu.

Sehe ich auch so. Um so größer sind auch die Chancen, dass sich Entwickler der anderen System beteiligen. Interesse scheint es zugeben.

- meiner Meinung nach sehe ich in dem Fhem-Treiber aktuell auch keinen Handlungsbedarf. Könnte man daher auch eigenständig lassen

Der könnte ruhig mit ein, ich finde man sollte nur darauf achten, dass die anderen System durch Änderungen oder Erweiterungen nicht ausgeschlossen werden.

Ich wollte mir jetzt irgendwann mal TabletUI ansehen

Kicher... ich habe heute morgen damit angefangen.

[drdownload]

Ich hab mich damals auch recht viel mit SmartVisu beschäftigt, aber das ganze Projekt ist irgendwie an so ziemlich allen Fronten irgendwie eingeschlafen. Ich wollte mir jetzt irgendwann mal TabletUI ansehen, daher die Frage bzgl. der Abgrenzung.

Was mich bis jetzt immer von TabletUI abgehalten hat ist der unprofessionelle Look&Feel oder dass es zB kein sinnvolles Thermostat Widget gibt das mit dem von SV mithalten kann. Sonst merkt man finde ich bei TabletUI deutlich was für einen Dynamik eine ausreichend große User-Basis reinbringt.

Wie man User von einem FHEM-Smartvisu überzeugt: möglichst automatisches Setup. TabletUI braucht mWn derzeit keine händischen Eingriffe um mal grundsätzlich installiert zu sein. 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.

[Cybers]

- ja, den IOS9-Bug habe ich auch schon auf dem Schirm.

- zu TabletUI kann ich nicht viel zu sagen. Das machte mir von Anfang an einen sehr steifen, altbackenen und wenig ansprechenden Eindruck. Mir persönlich gefällt es nicht und der WAF ist meiner Meinung nach auch nicht sehr hoch.

-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

[dev0]

ein Attribut "smartvisu" setzen kann und es wir automatisch pro Raum eine Seite mit verknüpften Elementen erzeugt

So ein Attribut gibt es schon für Homebridge:

Code Auswählen Erweitern


attr global userattr genericDeviceType:switch,outlet,light,blind,speaker,thermostat,occupancy,thermometer


Bei Smartvisu stimmt das Design und die Dynamik.

Fande ich anfangs auch, mittlerweile kommt MIR sv eher altbacken vor, vielleicht habe ich aber einfach zu lange drauf gestarrt

[RoBra81]

Hallo,

Ich finde es gut, wenn es bei Smartvisu weiter geht, da ich nach dem ausprobieren von TabletUI auf Smartvisu umgestiegen bin - Grund: Smartvisu ist aus meiner Sicht deutlich performanter als TabletUI auf meinen alten Tablets...

Ronny

[drdownload]

Was mir noch einfällt: Stärkere Mobile-Optimierung, derzeit brechen die Standardelement nicht sehr gut um auf Mobilen Devices bzw. wäre es gut komplett Smartphone optimierte Widget-Versionen zu haben die angezeigt werden.

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)

Zusammengefasst lässt sich sagen, dass es einige Dinge gibt die derzeit recht kompliziert sind um schon mal zu starten und auch recht schwer sind jemanden zu erklären (insbesondere warum es so sein muss)

[drdownload]

So ein Attribut gibt es schon für Homebridge:

Code Auswählen Erweitern


attr global userattr genericDeviceType:switch,outlet,light,blind,speaker,thermostat,occupancy,thermometer


Das ist doch schon mal eine Idee zum klauen