erste beta - fronthem, smartVISU (closed, Bitte die Anschlussthreads benutzen)

[Cybers]

@HCS: Danke, jetzt läuft es.

Gruß, Sascha

[HCS]

@HCS: Danke, jetzt läuft es.

@all: würde sich jemand erbarmen und ein widget schreiben, mit dem man den page cache ein/ausschalten kann und das dabei automatisch das temp-Verzeichnis leert?
oder einen config page Ersatz im cleaninstall bauen, der das macht?

Das ist echt lästig. Und wenn man es vergisst, dann steigt die Verwirrung bis zum Anschlag.

[herrmannj]

Du: was hältst Du von dieser Idee:

ich hab doch in fronthem den filter für GAD internal.*. Was hältst Du davon die dafür zu nehmen. Ich bau was in fronthem ein (internal.cache-delete = 1) und der driver löscht den cache (via ajax call auf eine *.php). Bei dieser Gelegenheit könnte man evtl auch die Zeitmessung rückwärts via internal GAD an fronthem schicken, dort anzeigen und loggen. Evtl vielleicht sogar einieg js Fehlermeldungen via internal an fronthem zurückschicken. Dann hätten wir auch das Thema iphone hat keine console weg.

vg
jörg

[vbs]

ne, ne. Das geht nicht um Mist oder so - ich sehe Sachen die dafür sprechen (die icons) aber eben auch die zusätzlich Konfiguration optionen die das ja normalerweise komplizierter machen. Aber ich kenne eben auch nicht jeden use case und will auch niicht im Weg stehen. Daher die Frage auch @all

Also meine Idee bzw. mein persönlicher use-case ist, dass man das smartvisu-wigets-Repo (bzw. auch andere Widget-Sammlungen) direkt 1:1 einbinden, nutzen und updaten kann. Out-Of-The-Box sozusagen. Also so dass man keine Dateien händisch irgendwo hinkopieren oder anpassen muss  (abgesehen von pages natürlich). Evtl. habt ihr diesen use-case ja gar nicht bzw. ich bin der einzige, der das Feature haben möchte. Kann ja sein. Ich fände das einfach sehr elegant und vor allem modular.
Ich will nicht bestreiten, dass ich in der Sache bestimmt etwas parteiisch bin, da ich halt ein paar Stunden in den Patch gesteckt habe. Trotzdem versuche ich das objektiv zu beurteilen und wenn es eine schon bestehende Lösung (die nicht zu "hackish" ist) bzw. andere, bessere Lösung für diesen use-case gibt, dann bin ich gegen meinen Patch 

Bei den komplexeren widgets mache ich das so

lib / <DIR> / *js und *css
widgets / <bla>.html

Im <bla>.html hab ich dann ein "once" mit dem *js damit bei mehrfachem widget Einsatz die js nur einmal geladen wird.

Ok, aber das setzt ja voraus, dass ich die Widgets händisch in das "<SV>/widgets"-Verzeichnis kopiere, oder? Und wenn es später mal Updates für die Widgets gibt, muss ich mich händisch darum kümmern, die upzudaten. Das gleiche für js und css-Dateien. Das wäre eigentlich genau das, was ich gerne vermeiden würde, ehrlich gesagt.

Btw, Du kannst auch base oder root zusätzlich in das page Verzeichnis legen und damit die defaults aus base überschreiben. Das benutze ich für spezielle mobil pages um cordova einzubinden ohne die pages anfassen zu müssen.

Das würde ich ungern machen, da ich dabei ja einen Teil von SmartVISU "forke" sozusagen. Muss gestehen, dass ich bei solchen Sachen aber auch recht pedantisch bin... :/

Mit dem Wissen bzgl. dem "once" bzw. dass man auch ruhig js-Dateien im body-Bereich einbinden kann, würde ich jedoch gerne zumindest den js-Teil meines Patches nochmal überarbeiten. Natürlich nur, wenn der Mechanismus generell überhaupt Zustimmung findet.

[herrmannj]

Hi,

ja verstehe, das ist immer doof wenn man Arbeit reinsteckt, und dann denkt man sich ja auch was bei - logisch.

Bevor Du noch tiefer eintauchst, geh mal von von der widget js wo die buttons und so drin liegen weg und schau Dir mal die komplexeren 'a la clock oder weather an.

Die bestehen aus 3 Teilen die ohnehin individuell eingebunden werden müssen, html, js und css. (Muss man ja bei mit patch auch)

Jetzt geh mal gedanklich noch weiter und nimm an das Du unterschiedliche pages (mit komplett unterschiedlichen widgets) zum Beispiel für desktop, tablet und phone erstellst. Nicht unwahrscheinlich (habe ich zB) das Du dann zB für das phone ein anderes Weather widget nimmst als für das tablet. Geh noch weiter und nimm die cordova Unterstützung: gleiche Seiten, manchmal soll das geladen werden oder auch nicht. Das passiert ja alles auf Ebene der page dirs (eben nicht zentral)

Da meine ich eigentlich das die Unterstützung die schon eingebaut schon richtig fetten (sic) support für bietet. Zum Beispiel durch die base im page-dir. Der Sinn ist ja genau das Du das nicht "forken" musst. Entweder die Vererbungshierarchie (root->base-> ...) nutzen *oder* pro page-dir eine eigene Vererbung. Die ist nämlich dann auch updatesicher - anders als das was der patch bewirken würde.

Btw, selbst die icons dirs kannst Du so (fast) out-of-the-box relisieren. Das "icon1~" ist ja am Ende des Tages nur eine twig Variable für das icon-dir (im Quelltext macht twig ein replace).

Ich weiß Deine Arbeit sehr wohl zu schätzen, ich glaube aber das Du da in die falsche Richtung läufst, möglicherweise die "Macht" von der twig engine und der Vererbungs struktur in den pages noch unterschätzt.

Ich meine, wenn ich Deinen case richtig verstehe, das sv das (und mehr) schon out-of-the box kann. Ich bitte daher mein Zögern zu entschuldigen   ...

Ma schauen, gibt es weitere Meinungen ?

vg
jörg

[herrmannj]

edtih und Nachtrag um da ganz transparent zu sein:

Ich, so wie ich sv einsetze, hätte keine Verwendung für die Funktionen die der patch bereitstellt und würde den patch dann als zusätzliche Fehlerquelle ohne Zuwachs an Nutzen nicht einchecken wollen. Sprich, ich sehe / erkenne den Nutzen nicht.

Wenn es jetzt aber mehrere user gibt die sagen "brauch ich / will ich" (es also nicht um einen Einzelpatch von & für vbs geht ) dann check ich den natürlich (flott!) ein.   

vg
jörg

[bgewehr]

Wir müssen berücksichtigen, dass SV von anderen Autoren weiterentwickelt wird. Je mehr wir ändern, desto mehr müssen wir nachpflegen und desto mehr Fehler müssen wir bei einem Update von SV reparieren. Von mir ein Nein aus vorgenannten Gründen. Ich lege die custom files mit in die original Verzeichnisse, dann kann ich aus einem GIT clone Verzeichnis neue Versionen über meine Installation kopieren ohne dass ich sonst was ändern muss. Mir reicht das (meistens, manchmal wünsche ich mir auch eine stärkere Automation dieser Dinge - aber nur ganz selten!)

[vbs]

@herrmanj:
Also das ist sicherlich die nettes Abfuhr, die ich je für einen Patch bekommen habe Aber mal ernsthaft: Wenn ihr das nicht haben wollt (und das sehe ich jetzt mal als Fakt an), ist das natürlich voll ok. Ich finds auch richtig, dass man als Projekt-Leader (so seh ich dich jetzt erstmal), keine Sachen rein nimmt, die entgegen dem eigenen Konzept laufen (halte ich sogar für deine Pflicht, um "deinen Laden sauber zu halten"). Außerdem hab ich da "nur" ein paar Stunden dran gesessen und nicht Tage oder Woche und zweitens hab ich dabei sehr viel über SmartVISU/twig gelernt, was auch sowieso mit die Motivation war. Und wenn ich dieses Feature weiterhin haben will, steht es mir natürlich eh frei euer FHEM-SmartVISU zu forken und da meinen Patch einzubauen.

Aber nochmal kurz zur Sache: Ich weiß, wir haben jetzt schon hin- und her diskutiert, aber sorry, ich verstehe eine grundsätzliche Sache noch nicht ganz: Bist du der Meinung, dass man das Feature, dass man Widget-Repos direkt ohne Änderungen einbinden und benutzen kann nicht braucht? Oder sagst du, dass das doch jetzt eh schon mit Bordmitteln möglich ist?

@bgewehr
Die Argumentation unterschreibe ich auch sofort. Meiner bescheidenen Meinung nach, ist dieser FHEM-SmartVISU-Fork-Status ja auch nicht unbedingt ideal. Ich hatte ja auch deshalb schon einmal vorgeschlagen, dass man versuchen sollte, die nicht-fhem-spezifischen Änderungen in dem FHEM-SmartVISU möglichst bald nach Upstream zu bekommen (so wie ich gerade versuche, meinen Patch bei euch rein zu bekommen). Das ist erstes technisch mMn gut und wichtig, damit der Fork möglichst nahe am Original bleibt (im Idealfall würde man FHEM mit dem original SmartVISU benutzen können und müsste nur einen FHEM-Treiber hinzufügen, oder?). Zweitens ist es auch nur fair dem Original-Projekt ggü., da man natürlich von deren Vorarbeit enorm profitiert (wobei man da auch argumentieren könnte, dass es denen ja ihrerseits frei steht, sich beliebig bei FHEM-SmartVISU zu bedienen).

[bumbumb]

Hallo wie koennen reading werte als text ausgeben werden kann jemand mal beschreiben wie das geht. Werte vom buderus km 200 kommen rein und sollen an smartvisu als text uebergeben und ausgewertet werden. Hat jemand ne idee

[vbs]

Sollte hiermit funktionieren:
http://www.smartvisu.de/docu/2.7/index.php?page=basic/widget_basic.value

[herrmannj]

@vbs

ja, soll eben auch genau keine "Abfuhr" sein. Ist ein Stück weit eine Gratwanderung: viele machen mit und das Projekt lebt davon das sich alle ein Stück weit wiederfinden. Aber deshalb ist es auch ein Ruderboot auf dem jeder ein klein wenig an einen anderen Strand will und das ist für ein Boot in Summe auch nicht gut.

Zu Teil 2,
- widgets (repo) einbinden: ja, nützlich !
- geht mit dem patch nicht einfacher als out-of-the box.

imho besser:

ein updater wie er in fhem vorhanden ist:
einbinden der widgets wie gehabt (individuelle page).
der updater (php?) aktualisiert die widget - files (mit backup, overwrite vielleicht einzelne ausschließen?) anhand einer repo liste die man hinterlegt. Vielleicht sogar rollback oder so ?

vg
jörg

[Joker]

Hi

ich habe auch nochmal ne Frage: Auf fhemweb greife ich öfter via VPN "von außen" zu, z.B. um Einstellungen zu machen oder Status anzuschauen. Jetzt würde ich gerne auch von außen auf smartVISU zugreifen wollen. Ein Test heute hat ergeben, dass das irgendwie nicht geht. Ich bekommen dann zwar meine Seiten angezeigt, aber die ganzen Werte fehlen- also so, wie wenn man mit einem Device zugreift, das nicht als fronthemDevice definiert ist.

Da dachte ich mir dann, ist ja klar, vermutlich habe ich von außen eine andere IP-Adresse, und habe ein fronthemDevice mit eben dieser erstellt. Leider geht es aber trotzdem nicht. Und ein Blick ins Logfile hat auch keinerlei Fehlermeldungen von fehlenden Rechten gezeigt, wie das sonst kommt wenn man mit einem "nicht autorisierten" Device zugreift.

Eine Idee, was hier das Problem ist?

[herrmannj]

Hi,

die richtigen Schritte, auch zur Diagnose. Wenn es dann nicht geht liegts am vpn, der braucht den 2121 offen. Von Routern kenne ich es das sie mit dem ws niicht  können (vmtl irgendeine Form von shaping). Der vpn an einer fb7390 funktioniert in der beschriebenen Konstellation...

vg
jörg

[HCS]

Auf Android mit Dolphin werden 2 meiner Widget nicht angezeigt. Einmal Timecounter und imgweather mit dem ich img austausche.

Den timecounter habe ich auf meine Testseite gebaut. Ging heute Mittag nicht. Heute Abend ging er.
Ob das an dem Android 5.1 Update liegt, das ich gerade bekommen habe? Da kam bestimmt ein neues WebKit mit und da basieren die doch alle drauf, oder?

[HCS]

Du: was hältst Du von dieser Idee:

ich hab doch in fronthem den filter für GAD internal.*. Was hältst Du davon die dafür zu nehmen. Ich bau was in fronthem ein (internal.cache-delete = 1) und der driver löscht den cache (via ajax call auf eine *.php). Bei dieser Gelegenheit könnte man evtl auch die Zeitmessung rückwärts via internal GAD an fronthem schicken, dort anzeigen und loggen. Evtl vielleicht sogar einieg js Fehlermeldungen via internal an fronthem zurückschicken. Dann hätten wir auch das Thema iphone hat keine console weg.
Ich schaue mir das mal an und mache einen Vorschlag, was ich schicken würde, so in der Art wie bei monitor oder eher wie bei angefragten serien.
Was würde fronthem dann damit machen? Irgendwo wegschreiben und einen Viewer dafür anbieten?

vg
jörg

Logs aus dem Treiber nach fronthem schicken ist eine gute Idee. Ich könnte console.log abfangen und alles was da kommt zu fronthem schicken, dann könnte man das dort nachlesen.

Temp-Verzeichnis löschen. Da sehe ich nicht, warum das über fronthem laufen sollte. Ich schalte in SV den cache ab und will das temp verzeichnis automatisch leer haben. Das ist doch etwas, das rein SV intern ablaufen kann / soll.

Zum Thema "widgets einbinden":
Ich erkenne in der bisherigen Diskussion verschiedene use-cases. Meiner ist: ich habe eigene widgets, die ich nicht veröffentliche, weil sie eh keinem helfen, die habe ich im page Verzeichnis. Es gibt widgets von SV, die sind eh da und sollten nicht verändert werden. Und dann gibt es noch die widgets der fronthem comunity im git. Die, die ich davon verwende, habe ich momentan auch im page Verzeichnis und sie mit der Nachlade-Methode in der visu.js eingebunden (siehe x posts weiter oben).

An SV sollten wir so wenig wie möglich ändern (meine page läuft aktuell mit dem original 2.7 SV download, da ich keine Mandanten benötige), sonst basteln wir uns bei einer kommenden 2.8 einen ab, bis das wieder geht. Sinnvoll wäre, Dinge wie Mandanten usw. in SV reinzubringen. Ich kann mir nicht vorstellen, dass ein SV Benutzer, egal ob er KNX, Domotiga oder FHEM verwendet, es cool findet, was passiert, wenn man den cahce nach dem Entwickeln wieder einschaltet und dann das Chaos hat.

Dann könnte man auch versuchen, dort eine Lösung für zusätzliche widgets und Bilder einzubringen.

Ein klein wenig forken bringt es nicht, wenn wir uns für forken entscheiden würden, dann könnten wir auch richtig loslegen. Ich würde aber eher den anderen Weg gehen.

Zurück zu meinem widgets use-case von oben. Für mich ist es eigentlich OK, wie es ist, aber schön wäre, wenn man die bilder und widgets aus unserem repo einfach irgendwo auschecken könnte und sie dann wie die internen verwenden könnte. Nur sehe ich den richtigen Weg zur Erfüllung dessen noch nicht so recht.