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

[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?

[dev0]

- Apollo hatte angefangen ein Color Parameter bei den Widgets einzuführen. Ich hatte das mal für weitere Widgets fortgeführt. Kann ich gerne auf github einpflegen und einen PR stellen. Wohin eigentlich?
- Ich hatte vor einiger Zeit mal den Account "smartvisuNG" (next generation) als Organisation registriert. Macht es Sinn ggf. solch einen Organisationsaccount für das Projekt zu nutzen (muss nicht dieser sein)? Verderben viele Köche den BreiCode oder macht das aus eurer Sicht auch Sinn?

[herrmannj]

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

Automatisch laden.

Idee so: man hat jeweils pro "pages" ordner (damit nicht alles überall geladen wird -> performance) Unterordner wo eben die *.js, *css, *.html für ein widget liegen.

base (oder einer seiner Nachfolger) schaut einfach ob da was drin liegt (wie gesagt, pro "pages" ordner").
Wenn da was liegt dann wird es direkt automatisch eingebunden.

Die Idee:
ich muss für eine widget nicht mehr die user.js und user.css editieren und das umständlich includen.
Dadurch kann man widgets bequem per (fhem?) cmdline installieren. Der Installer muss wissen wo die source des widgets liegen (svn zb) und in welchen Pages das widget verwendet werden soll. Das lies sich (später) sogar bequem mit einem update kombinieren.

Das wäre imho ein guter Startpunkt für ein Ecosystem von user widgets. Müsste man für devs dann (halbwegs) vernünftig dokumentieren.

vg
joerg

[herrmannj]

Verderben viele Köche den BreiCode oder macht das aus eurer Sicht auch Sinn?

persönliche Meinung:

Es ist gut wenn einer den Hut auf hat und sagt wo es lang geht. (an der Position sind auch Nehmerqualitäten gefragt).

Warum? Sonst (alles persönliche Ansicht!) ist es sehr schwer eine Strategie und Architektur nachhaltig durchzusetzen.

Man kann eine gegebene Aufgabenstellung ja meist mit a,b oder c umsetzen - führt in der Regel alles zu akzeptablen Ergebnissen. Nach einer Weile stellt sich dann aber raus das neue Aufgaben, die auf vorhergehenden Aufgabenstellungen aufbauen, sich nicht mehr zufriedenstellend lösen lassen weil die bereits verwendeten Ansätze 'A' und 'B' (c,d,e---) sich "unter der Haube" doch so unterscheiden das man keine weiteren, zusätzlichen Lösungen (einfach, stabil etc) darauf aufsetzen kann.

Das braucht (mMn) eben einen "Kapitän" der auch Ansagen macht _wie_ etwas umgesetzt wird. Das ist, zugegebenermaßen, langsamer als die "Feuer freu" taktik, aber eben am Ende nachhaltiger.

Idealerweise (siehe vorhergehender Post) findet man eine Architektur in der die Domänen so getrennt sind das sich (zB) eine Gruppe gleichdenkender um den Core kümmert und andere Teile (zb Widgets) komplett getrennt entwickelt und gewartet werden können (ohne den core zu tangieren).

Das ist (meiner Erfahrung nach) dann der reichhaltigste Ansatz wo sich eben auch jeder einzelne gut Wiederfinden kann.

but: just my 5cc

vg
joerg

[Cybers]

ich hatte für die Weiterentwicklung von Smartvisu den Account SmartViDi auf Github angelegt.
Alle Forks und Pull Requests habe ich eingebunden. Aktuell sitze ich an der Aktualisierung von Jquery. Sobald ich das fertig habe werde ich die neue Version auf Github uploaden

Gruß, Sascha

[joshi04]

Hallo Zusammen,

ich würde gerne das Wiki ein wenig überarbeiten (https://forum.fhem.de/index.php/topic,54506.msg460917.html#msg460917).

Damit ich dort nichts falsches hineinschreibe wäre ich dankbar, wenn jemand diese Übersicht kommentieren würde? Ich bin noch am Einlesen und hoffe, ich liege nicht ganz falsch.
Hinzu geplant kommt natürlich noch erklärender Text, der ist aber noch in Arbeit.

Ich habe die Hoffnung, dass sich der Einstieg zu fronthem/smartVISU dadurch noch weiter erleichtern lässt und auch die Dokumentation im Wiki weiterwachsen wird.

Den Entwicklern bis hierher für das Projekt in jedem Falle schon jetzt vielen Dank!

Schöne Grüße,
John

Edith: Das Diagramm wurde aufgrund der folgenden Posts aktualisiert.

[dev0]

Die Zeichnung ist nicht ganz richtig: Ein Smartvisu Browser greift auf 2 Datenquellen zu. Die (statischen) Webseiten werden vom Webserver (apache, http) geliefert, der dynamische Inhalt kommt vom Websocket Server (fronthem, ws). Eine Verbindung zwischen Webserver und ws server gibt es nicht. Die ws IP, die in Smartvisu konfiguriert wird, wird nur in die ausgelieferten Webseiten geschrieben, damit der Client darauf zugreifen kann.

[drdownload]

Und die plots in smartvisu gehen direkt auf den MySQL

[joshi04]

Danke, genau wg, dieser Detail habe ich das hier gepostet.

Habe im obigen Post die Grafik geändert. Die Übersichtlichkeit hat leider durch die zusätzlichen Details etwas gelitten. Wenn man das im Text im Wiki aber näher beschriebt, sollte man das auffangen können.

Wusste nicht, wie und dass Plots überhaupt schon gehen, daher kann ich das nur auf Zuruf einfügen. Wenn der smartVISU Browser vom Endgerät direkt auf den MySQL Server zugreift, vermutlich dann über port 1433, oder?
Das könnte für Firewall- und VPN-Benutzung wichtig sein.

[dev0]

Nicht der browser greift auf den sql server zu, sondern der webserver mit hilfe von php.

[joshi04]

Next try (siehe post #34).

Sorry, wie erwähnt, Plots kenn ich noch nicht.

Aber eigentlich hab ich mir das schon gedacht, hab das von drdownload nur falsch gedeutet.

[dev0]

"Inhalte für Diagramme" ist mMn auch zu weit gefasst. Genau 1 Widget benutzt diese Verbindung zur DB derzeit. Auf Dauer würde ich davon ausgehen, dass das auch über die ws Schnittstelle läuft. Andere Plots (ohne historische Werte) funktionieren jetzt schon so.

[herrmannj]

Auf Dauer würde ich davon ausgehen, dass das auch über die ws Schnittstelle läuft

Yepp!

[joshi04]

Ich denke, dann werde ich für das allgemeine Diagramm, dass die Zusammenhänge zum allgemeinen Verständnis darstellen soll, die Geschichte mit dem Datenbankserver und dem "Inhalt für Diagramme" lieber ganz weg lassen. Es soll ja auch Anwender geben, die anstatt DbLog Filelogs verwenden. 

Solche Details/Sonderfälle (derzeit nur von einem Widget verwendet) gehören mM dann nicht auf eine solche Übersicht und sollten besser als Ausnahme dann spezifisch beim Widget beschrieben sein. Vor allen Dingen, wenn langfristig sowieso Anderes geplant ist.

Euch bis hierher erstmal vielen Dank. Wenn Ihr noch was für die Darstellung habt, natürlich immer gerne (letzte Version in #34).

Ich plane das Diagramm im Wiki-Artikel "smartVISU" verwenden.

[joshi04]

Ich bin bei der Beschreibung der Treiber-Funktion und noch nicht ganz sicher, ob meine Interpretation richtig ist. Würde mich freuen, wenn Ihr noch einmal drüber schaut:
Endgerät -> Anfrage an Webserver (Port 80)
Antwort vom Webserver -> Statische Inhalte + Information woher die dynamischen Inhalte kommen
dynamische Inhalte werden vom Endgerät beim WS angefragt und geliefert (Port 2121) 

[dev0]

Der Treiber ist ein Stück Software (js), das in die ausgeliefertern Webseiten per Link eingebettet ist, auf dem Client ausgeführt wird und die Kommunikation zwischen Client und Websocketserver (fronthem) übernimmt und anpasst.

Weiterhin finde ich, dass in der Graphik der Kasten mit dem Frontend (pgm2,...) sich ebenfalls auf der Höhe der Module befinden sollte, da pgm2 alias FHEMWEB auch "nur" ein Modul ist.

[joshi04]

Treiber: Verstanden, vielen Dank.

Grafik aktualisiert und hab nochmal über die Kästen nachgedacht. Aber irgendwas is immer 
Was meinst Du?

[herrmannj]

Hallo joshi04,

vielen Dank, ich sehe das so als sehr gut !

Speicher Dir das Schaubild mal weg - später ;( wird der Apache wegfallen.

vg
joerg

[dev0]

später ;( wird der Apache wegfallen.

Wird es eine Option geben, die es zuläßt einen externen Webserver zu benutzen ohne sich zu verrenken?

[herrmannj]

Guter Hinweis, Danke!

Ne, hab ich bisher nicht auf der Uhr. Eigentlich sollte sich diese Frage auch so nicht stellen weil dar eingebaute Server ja dafür da ist das alles viel schöner zu integrieren. Btw, der externe war für einige user auch der Grund die Finger davon zu lassen weil sie Vorbehalte bei dem Mehraufwand der Konfiguration hatten.

Der (als fhem modul) integrierte Server soll zum Beispiel sorgen das die Config (driver, host, port, design, pages-dir, Zertifikate, user) zentral, sprich einmal, verwaltet wird.

Hast Du einen speziellen Grund zu der Frage, bzw Befürchtungen (sprich erwartete Nachteile) ?

vg
Joerg

[joshi04]

Überarbeitet Artikel im Wiki sind online.

Komplex bleibt das ganze Zusammenspiel mM natürlich auch, wenn die Seiten im Root des FHEM-Webservers liegen, gespannt bin ich natürlich trotzdem.
Zwischenzeitlich habe ich die Hoffnung, dass mit den Artikeln die Einrichtung auch für Anfänger ein wenig einfacher wird - und ich nicht zu viele Kinken eingebaut habe.

Eine Frage nun wirklich zur Weiterentwicklung:
Ich habe festgestellt, dass die fronthem.err bei mir im Basisverzeichnis der fhem-Installation liegt (/opt/fhem/). Wäre es sinnvoll den Pfad zu ändern, so dass die Datei bei den anderen Logs von FHEM landet (opt/fhem/log/)?

Schöne Grüße,
John

[dev0]

Hast Du einen speziellen Grund zu der Frage, bzw Befürchtungen (sprich erwartete Nachteile) ?

Kurz:
Bei mir würden sich wahrscheinlich Performancenachteile zeigen, da der Webserver (der auch für Anderes genutzt wird) auf wesentlich potenterer Hardware läuft als FHEM. Meine FHEM/SV Installation läuft aber auch innerhalb einer recht komplexen Infrastruktur.

Lang:
Generell wäre meine Idealvorstellung von einem FHEM/SV Setup dreigeteilt:
* Fronthem als reines Websocket Gateway
* Smartvisu incl. Treiber als reines Frontend
* Tool/Mechanismus um Widgets automatisiert in SV einzubinden und mit FHEM Devices zu verknüpfen.

Die Vor- und Nachteile, die ich gegenüber einem gemeinsamen Paket sehe, sind:
+ Ein Höchstmaß an Flexibilität bei der Installation um z.B. die vorhandene Infrastruktur (Security, HA, LB, CA) zu berücksichtigen.
+ Die Entwicklung der einzelnen Bestandteile wäre unabhängiger voneinander: um fronthem beispielsweise mit einem anderen Frontend einzusetzen oder auch einen Fork eines der Pakete einfacher nutzen zu können.
+ Den Ausfall eines der Entwickler(teams) einfacher kompensieren zu können.
- Komplexere Installation, die man sich mit dem Mehr an Flexibilität erkauft.

Die Antwort geht etwas über die eigentliche Fragestellung hinaus, gehört aber aus meiner Sicht doch dazu. Ich weiß auch nicht, ob die angesprochenene Flexibilität überhaupt von mehr als 0.001% der Anwender benötigt/gewünscht wird oder nicht der einfachste Installationsweg das Hauptzeil seinen sollte, um massentauglicher zu werden. Sofern das mit FHEM überhaupt möglich ist...

[HCS]

Bei mir würden sich wahrscheinlich Performancenachteile zeigen, da der Webserver (der auch für Anderes genutzt wird)

Eine ähnliche Situation habe ich auch. Wobei ich bei mir weniger (aber auch) Bedenken wegen der Performance und mehr wegen der Machbarkeit und dem Konzept habe.
In SV habe ich mein komplettes ehemaliges Intranet integriert und gerade die Möglichkeit, außerhalb von FHEM das alles plus die Visualisierung der FHEM-Daten zusammenzuführen war für mich ein wesentlicher Aspekt.

Zumindest in dem Fall, wo man in SV weitere Dinge hat, die nichts mit FHEM zu tun haben, ist es nicht so toll, wenn das alles unter dem Kontext von FHEM läuft.

Wie dev0 schon geschrieben hat, es könnte ja sein, dass er und ich die Ausnahme sind, keine Ahnung, aber seine restlichen pro/contras kann ich ebenfalls unterschreiben.

Ich denke es gibt zwei Grund-Use cases:
1. Man möchte ein FHEM mit einer anderen Oberfläche als dem Standard-Frontend
-> Dann ist voll integriert sicher ideal

2. Man hat ein Intranet in dem FHEM "nur" eine Datenquelle von mehreren ist
(das "nur" sitzt in Anführungszeichen, weil ich es keinesfalls abwertend meine)
-> Dann möchte man es lieber getrennt

[herrmannj]

ok, aufgenommen.

Ich halte das zwar für "corner"-case, behalte das aber im Hinterkopf !

Danke, vg
joerg

[joshi04]

Befürchte, ich gehöre auch in die "Ecke" da beim mir der Webserver ebenfalls Wiki, phpmyadmin und noch ein paar andere Dinge beheimatet. Wäre daher ebenfalls froh, wenn Möglichkeit 2 erhalten bliebe. Den Webserver brauche ich eh.
Schöne Grüße, John

[marvin78]

Ich betreibe zwar akutell FHEM und Webserver auf einer Maschine aber mein Plan war auch, meinen "großen" Webserver demnächst auch für smartVisu zu verwenden. Trotzdem würde ich ggf. die Variante ohne externen Webserver zunächst testen.

[michael.winkler]

ich gehöre auch eher zu denen die ihren SmartVISU Server auf einem eigenen Webserver betreiben.

[herrmannj]

ich gehöre auch eher zu denen die ihren SmartVISU Server auf einem eigenen Webserver betreiben.

Im Augenblick ist das ja auch der einzige Weg. Lasst uns das mal anschauen wenn es soweit ist. Ich habe abgespeichert das es den Wunsch gibt den Webserver stand alone (apache, nginx etc) zu betreiben.

vg
joerg

[joshi04]

Hallo zusammen,
versuche gerade, das Wiki etwas weiterzubringen und dabei sind 2 Fragen aufgekommen:
Soweit ich verstanden habe, basiert das derzeitige cleaninstall von herrmannj auf v2.7. v2.8 ist derzeit nur alternativ beschrieben, offiziell noch nicht released und daher auf eigene Gefahr, greift aber auch auf Bestandteile von cleaninstall zu (Installationsbeschreibung wurde von dev0 bereitsgestellt). Welche smartVISU Version sollte derzeit am ehesten für die Installation beschrieben werden? Passt es derzeit so, wie im Wiki beschrieben?

Soweit ich verstanden habe, wurde im Mega-Fred bereits Konsens erzielt, dass man versuchen sollte, alle Widgets in einem Repository zu sammeln. Wäre das das smartVISU-widgets-Repository von herrmannj, bzw. welches sonst?

Ich würde das Wiki dementsprechend anpassen.

Schöne Grüße,
John

[dev0]

Soweit ich verstanden habe, wurde im Mega-Fred bereits Konsens erzielt, dass man versuchen sollte, alle Widgets in einem Repository zu sammeln. Wäre das das smartVISU-widgets-Repository von herrmannj, bzw. welches sonst?

Ich glaube, dass die Frage aufgrund dieser Antwort im Forums Thread aufgekommen ist:

Im ersten Mega Fronthem Thread gab es bereits eine Diskussion, wie man Widgets am Besten einbindet. Konsens war, dass wir includen wollen. Darauf hin wurden die Widgets im herrmannj Repo auch entsprechend umbenannt. So kann man sie einfach downloaden und in den pages Ordner kippen. Man muss sie dann nur einmal includen. Bei einem Update einfach die vorhandenen Dateien überschreiben.

Mit "includen" meinte ich die technische Art und Weise: Die Widget Dateien sind nach dem Schema widget_<name>.<ext> benannt und sollen in die SV Konfig nur eingebunden/verlinkt werden und nicht in die visu.css/visu.js kopiert werden. Daurch kann man bei einem Update die Dateien einfach kopieren und muss die visu.* nicht bearbeiten. Beschrieben habe ich das hier: https://github.com/ddtlabs/smartvisu-widgets/wiki/HowTo-Install-Widgets

Davon abgesehen wurden die Widgets tatsächlich im herrmannj Repository gesammelt. Meine Widgets liegen dort nicht, da sie nicht mit der 2.7er Version kompatibel sind. Ich würde alle Repositories im Wiki angeben, die bekannt sind, da z.B. Weiterentwicklungen nicht zwangsläufig bei herrmannj landen (zur Zeit beispielsweise UZSU).

v2.8 ist derzeit nur alternativ beschrieben, offiziell noch nicht released und daher auf eigene Gefahr

So wie es im Moment aussieht (KNX Forum), wird es auch keine offizielle SV 2.8 von Martin Gleiss mehr geben. Forks werden aber mit Sicherheit nicht auf der 2.7er Version basieren -> Zukunft 2.8. Die Umstellung auf ein 2.8er-cleaninstall ist mMn nie umgesetzt worden, da Jörg sein next Release wiederholt verschoben hat und ihm niemand mit einem eigenen 2.8-pre-cleaninstall dazwischen funken wollte (zumindest ich nicht).
Um aber konkret auf Deine Frage bzgl. Wiki zu antworten: Ich würde das Wiki in diesem Zusammenhang so lassen wie es ist und das nächste Release von herrmannj oder Cybers abwarten. Wer jetzt schon die 2.8 benutzt und Widgets aus dem herrmannj Repo nutzt, muss damit rechnen, dass diese Widgets angepasst werden müssen, wenn sie pngs verwenden.

Mal schauen was die Anderen dazu sagen, ich würde aber vorschlagen diese Diskussion im Forums Thread weiterzuführen, da es hier um das Forken von SV geht.

@Cybers @herrmannj:
Gibt es bei Euch schon was neues in bezug auf sv fork bzw. next release?

[herrmannj]

work in progress. Wobei ich, als Empfehlung, bei neuen install gleich das 2.8er installieren würde.

vg
joerg

[joshi04]

Mit "includen" meinte ich die technische Art und Weise: Die Widget Dateien sind nach dem Schema widget_<name>.<ext> benannt und sollen in die SV Konfig nur eingebunden/verlinkt werden und nicht in die visu.css/visu.js kopiert werden. Daurch kann man bei einem Update die Dateien einfach kopieren und muss die visu.* nicht bearbeiten. Beschrieben habe ich das hier: https://github.com/ddtlabs/smartvisu-widgets/wiki/HowTo-Install-Widgets

Mist, da haben wir schon aneinander vorbeigepostet 

Hatte Deine Beschreibung schon gesehen und wollte die zentral neben 2 weiteren Möglichkeiten aufnehmen. Bin aber noch nicht dazu gekommen, das durchzuprobieren.

Davon abgesehen wurden die Widgets tatsächlich im herrmannj Repository gesammelt. Meine Widgets liegen dort nicht, da sie nicht mit der 2.7er Version kompatibel sind. Ich würde alle Repositories im Wiki angeben, die bekannt sind, da z.B. Weiterentwicklungen nicht zwangsläufig bei herrmannj landen (zur Zeit beispielsweise UZSU).

Das leuchtet ein.

Je mehr wir drüber diskutieren, desto mehr komme ich zu dem Schluss, die Quelle des nur im Forum veröffentlichten Widgets dort zu belassen, wo es liegt und nur den Post zu verlinken + ggf. eine Beschreibung im Wiki hinzuzufügen.

So wie es im Moment aussieht (KNX Forum), wird es auch keine offizielle SV 2.8 von Martin Gleiss mehr geben.

Den Eindruck habe ich leider ebenfalls gewonnen

...niemand mit einem eigenen 2.8-pre-cleaninstall dazwischen funken wollte (zumindest ich nicht).

Ich definitiv ebenfalls nicht.

Wer jetzt schon die 2.8 benutzt und Widgets aus dem herrmannj Repo nutzt, muss damit rechnen, dass diese Widgets angepasst werden müssen, wenn sie pngs verwenden.

Wobei ich, als Empfehlung, bei neuen install gleich das 2.8er installieren würde.

Ich versuche da mal etwas zusammen zu klöppeln im smartVISU-Installations-Artikel, dass den Gegebenheiten gerecht wird. Hinweis auf das Update gibt es dann wieder im anderen Thread ->

ich würde aber vorschlagen diese Diskussion im Forums Thread

[dev0]

werde ich mich an die Weiterentwicklung von "Smartvisu" setzen.

@Cybers: Arbeitest Du noch an dem Projekt oder hast Du aufgegeben?

[dev0]

Es tut sich etwas tun
https://github.com/Martin-Gleiss/smartvisu/pull/60
https://knx-user-forum.de/forum/supportforen/smartvisu/977954-neuer-fork-smartvisutng-es-geht-weiter/page6

[marvin78]

https://forum.fhem.de/index.php/topic,53000.msg482834.html#msg482834