Zukunft von Smartvisu

Begonnen von drdownload, 04 Mai 2016, 07:06:09

Vorheriges Thema - Nächstes Thema

drdownload

CUL 868 Slow-RF (FS20 Aktoren, Sender, FHT8V), CUL 868 (WMBUS-Empfang), Jeelink (PCA301), WS3600 (WH3080 über USB-Basis), Bewässerung mit ESP-Easy und Proplanta, RFXTRX433 Home-Easy Empfang und Senden, Oregon TH, WS001 TH), Blackbean IR, Mopidy-Snapcast MR Audio, Kodi, Forum-LED-Controller,

HCS

Das stimmt mich schon etwas bedenklich. Das ist schon lange so.
Anfang 2015 hatten wir schon mal eine Diskussion, ob wir einen fork aufziehen sollten und ob wir kompatibel bleiben müssen, als wir sehr aufwändig nach Performance gesucht haben. Ich glaube, der wesentliche Grund, es nicht zu tun, war, kompatibel zu bleiben um von neuen SV Versionen zu profitieren.
Der zieht, wie man sieht, nicht so richtig.

Die Variante, SV in unserem (FHEM) Sinne weiterzuentwickeln würde aber voraussetzen, dass sich ausreichend Entwickler finden, die das tun, auch können und auch dran bleiben.

Was aber dazu kommt ist, dass sich ja auch an fronthem seit einem Jahr nichts mehr tut.

Mit all dem werfe ich niemandem etwas vor, dass er hätte müssen oder sonst was, es ist einfach nur der aktuelle Stand.
Ich habe auch an dem FEHM-Treiber seitdem nichts mehr gemacht.

Die Frage, wann es sich totgelaufen hat, muss man sich trotzdem stellen.
Ich selbst habe aktuell zwar einige Topics (Performance, twig-Cache, Charts, ...) die ich als verbesserungswürdig sehe, aber noch den Zustand, dass es im Wesentlichen funktioniert und meine Anforderungen (mit Abstrichen) erfüllt.

Meiner Ansicht nach besteht aktuell noch kein dringender Handlungsbedarf, aber die Frage, wie das längerfristig wohl weiter gehen wird, geistert auch mir durch den Kopf.

drdownload

Ich denke auch dass man eine zeit noch mit dem aktuellen Stand auskommt. (ich musste noch nicht mal den bessere performanden Treiber ausprobieren)

Das smarthome.py commercial gegangen ist und nicht mehr smartvisu verwendet ist wohl das stärkste Argument für einen fork.

Leider werde ich auch mit der fhem tablet Ui nicht wirklich warm und warum die meisten neueinsteiger tabletui und nicht smartvisu starten ist mir schleierhaft.
CUL 868 Slow-RF (FS20 Aktoren, Sender, FHT8V), CUL 868 (WMBUS-Empfang), Jeelink (PCA301), WS3600 (WH3080 über USB-Basis), Bewässerung mit ESP-Easy und Proplanta, RFXTRX433 Home-Easy Empfang und Senden, Oregon TH, WS001 TH), Blackbean IR, Mopidy-Snapcast MR Audio, Kodi, Forum-LED-Controller,

Cybers

#3
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 einen neuen Thread (https://forum.fhem.de/index.php/topic,53881.0.html) 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
FHEM 6.2 auf Raspberry PI 4 / Smartvisu
Eltako Serie 14: FAM14, FGW14-USB, FSB14, FSR14-4x, FSR14-2x, FDG14, FTS14-EM in Kombination mit Jung F50 24V Tastern
1-Wire Temperatursensoren
aus alter Zeit:
Gott sei Dank nur noch 3 Homematic Jalousie- & Schaltaktoren! Wer sich mit Funk auskennt, legt Kabel

Thargor


hermann258


Tom Bombadil

Hallo,

es hat ein bisschen gedauert, aber heute wurde von der Community im 'offiziellen' smartVisu-Forum ein Fork geschaffen, um die smartVISU weiterzuentwickeln.

Als ersten Schritt gibt es seit heute einen Patch, der den Seitenaufbau der SV drastisch beschleunigt (siehe https://knx-user-forum.de/forum/supportforen/smartvisu/977608-patch-zur-massiven-performancesteigerung). Da es sich um den Austausch einer einzelnen, systemunabhängigen js Datei handelt, dürften auch die FHEM-User daraus sofortigen Nutzen ziehen.

Es wäre schön, wenn auch die FHEM-Entwickler und -user sich an dieser Weiterentwicklung der smartVISU beteiligen würden - eine zweigleisige Entwicklung würde zwangsläufig in doppelten Features und somit in 'Blindleistung' enden. Ihr seid somit hiermit herzlich eingeladen! Details werden zur Zeit unter https://knx-user-forum.de/forum/supportforen/smartvisu/977954-neuer-fork-smartvisutng-es-geht-weiter diskutiert.

Bis bald und auf frohes gemeinsames Entwickeln,
/tom

marvin78

Das mit "on" statt delegate ist hier schon vor (gefühlt) ein paar Jahren angekommen und wurde auch von vielen eingesetzt, wurde dann aber obsolet, da es Treiber gab, die die Performance Probleme weitesgehend behoben haben. Ich empfehle ersteinmal keinem der FHEM smartVisu User den Austausch der js-Datei.

So weit ich weiß, wird auch hier an einem Fork gearbeitet. Hier ist also Kommunikation erforderlich:

https://forum.fhem.de/index.php/topic,53881.0.html

dev0

Zitat von: marvin78 am 19 August 2016, 07:30:58
Ich empfehle ersteinmal keinem der FHEM smartVisu User den Austausch der js-Datei.
Zumindest hat ein erster Test bei mir keine negativen Auswirkungen gezeigt.

marvin78

Es wird alles funktionieren. Aber ich denke, die Gimmicks aus dem Treiber greifen nicht bei "on" (soweit ich das noch in Errinnerung habe). Ich glaube, dass das am Ende Performance kostet.

smai

Hallo marvin78

Als Entwickler des Performance Patchs würde mich interessieren, welche Gimmicks der Treiber denn hat, die nicht funktionieren werden.
Ich muss gestehen, dass ich FHEM nicht kenne und dies deshalb nicht beurteilen kann.

Ein Problem, welches in der ersten Version aufgetreten ist, war das mehrfache Binding. Also derselbe Update-Event wurde unter gewissen Umständen mehrmals angewendet, wodurch die Performance tatsächlich wieder schlechter wurde. Dies habe ich aber in den Griff bekommen.

Bald wird übrigens die Version 2.8 der smartVISU released. Da Martin Gleiß wieder dabei ist, wurden die Änderungen des Forks gemerged und es geht "offiziell" aber mit neuen Contributoren weiter.

Gruss
Stefan

herrmannj

Hallo Stefan,

wir haben damals lange gemessen und getueftelt. Der fhem sv driver liefert das update (durch Zugriff auf jq interne strukturen) direkt beim widget ab. Das funktioniert eben sehr direkt.und
sauschnell. Der weg ist quasi der kürzeste der möglich ist.

Wir haben uns für diesen weg entschieden weil er ohne Modifikationen von SV auskommt. Gedanke, dahinter ist das es damit möglich bleibt Widgets aus allen Quellen zu verwenden ohne die modifizieren zu müssen.

VG
Joerg



smai

#12
Hallo Joerg

Ok, ich verstehe.

Allerdings ist dies auch ein riskanter Weg für die Zukunft bzw. ihr könnt nicht einfach so zukünftige Versionen der smarTVISU verwenden.
So ist z.B. ein Update von jQuery mobile geplant, dadurch ändert sich die Struktur einiger Widgets. Dann muss euer Driver auch angepasst werden.
Auch sonst kann natürlich jederzeit ein Widget geändert werden, wegen einem Bugfix.

Aber natürlich dürft ihr diesen Weg gehen, wenn ihr das wollt.

Mein Plan für den nächsten Release ist übrigens eine Modularisierung der Widgets, so dass einfacher eigene Widgets eingebracht werden können.

Gruss
Stefan


EDIT:

Ich habe mir den FHEM-Driver, welchen Julian Pawlowski eingereicht hat, nun kurz angeschaut.
Wenn ich das richtig gesehen habe, implementiert dieser die Widget-Update-Funktion der smartVISU neu. Er ruft dabei aber durchaus die Update-Events der Widgets auf und greift nicht direkt die Widgetstruktur zu.
Wahrscheinlich ist diese Implementation besser als die orginale und deshalb schneller. Im Moment erkenne ich aber keinen Konflikt mit dem Performance Patch. Und weil die Update-Events genutzt werden, würde auch euer Driver von der Performanceverbesserung profitieren.

Aber ich sehe nicht, weshalb damit fremde Widgets leichter eingebunden werden könnten.

Der einzige Vorteil an diesem Vorgehen war wohl, dass keine Änderungen am smartVISU Code gemacht werden musste.
Es wäre aber doch viel netter, wenn alle von diesen Optimierungen profitieren dürfen und diese Implementierung in den Core übernommen wird.

Entschuldigt, falls ich mich irre, ich habe den Code nur kurz überflogen. Gerne lasse ich mich korrigieren, falls ich falsch liege.

herrmannj

Hi

Ja genau so ist es. Es wird ein pointer auf update ermittelt und die dann direkt aufgerufen. Dadurch entfällt das bubblen im Dom komplett und SV, bzw andere Widgets, benötigen keine Anpassungen. Im test war das auch nochmal schneller als on-..., da muss die JS engine ja auch suchen.

Wenn sich an den Widgets was grundlegendes ändert muss man das neu anschauen, logisch. Das hat man ja immer. Gegen bugfixes etc ist das immun, ist ja getafe der sinn.

Da ist irgendwo noch ein bug drin, glaube bei den icons. Schau dir den patch von Julian evtl nochmal an und mach vielleicht einige eigene Messungen vs on-... Das system erklärt sich aus dem patch recht gut, sonst gerne fragen.

Modulare widgets, im Idealfall self-containing, finde ich super!!! Würde mich freuen wenn wir da die Gemeinde der widgetschreiber größer bekommen. Klappt bei anderen GUI auch sehr gut.

Btw, keiner sagt dass das on- system schlecht ist. Aktuell passt es halt so sehr gut (messtechnisch war es sogar besser) und es besteht keine Notwendigkeit SV oder Widgets zu patchen)

Das kann morgen und mit einer Entwicklung SV anders sein

VG
Joerg

Franky1992

Also ich habe den Performancepatch nun ein paar Tage getestet und kann nur positives berichten.
Ist wirklich Sau schnell !!!

@smai
Bin echt Froh das ihr mit der Smartvisu weitermacht ich habe am Rechner echt eine große Menge Arbeit investiert um dann Festzustellen das es auf iPad und iPhone nicht akzeptabel läuft.
Und war kurz davor mit der Tablet UI von vorn anzufangen.

Also nochmal ein großes Danke und bleibt dran der Smartvisu zum 3.0 schritt zu verhelfen :)

Gruß
Franky