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

[HCS]

im Augenblick laufen alle Systemmeldungen (error, debug) im Systemlog auf. Die devicelogs sind ja (fhem-style) eher für Messwerte zuständig. Ist aber nur eine nachgelagerte Formalie - beides geht.

Der use-case, den ich da im Kopf hatte:

Anwender: "hilfe, bei meinem neuen iPhone8XXXL" zeigt der basic.value als Wert immer nur Apfelmuß an!"
Supporter: "Setze mal beim fronthem-device 'iPhone' das Attribut 'logging' auf 'all', navigiere etwas auf Deiner Page rum und klicke danach beim fronthem-device auf 'Log anzeigen' und den Inhalt schickst Du mir mal, dann schaue ich, was da passiert.

Wenn das im FHEM log zerstückelt evtl. noch von mehreren devices gemixt und vergraben ist, macht das keinen Spaß.

[herrmannj]

war mir klar, bricht aber eben mit fhem Konventionen.

Schaun mer mal, ist ja erst step 3 ...

vg
jörg

[HCS]

Ja, wobei ein vernünfiges Hilfsmittel zur Analyse von Problemen einges erleichtern würde.

Die Variante, dass ich mir die page von bgewehr (ist keine Kritik oder Reklamation, alles gut) installiere, um das Problem zu suchen, kann nicht der default sein.
So was können wir im Anfangsstadium mal machen, um zu sehen, was in verschiedenen Szenarien denn passiert, aber natürlich nicht auf Dauer und bei jeden Problemchen.

"step 3" verstehe ich so, dass Du mit Prio die charts auf der agenda hast und das hier erst danach konkret wird?

[herrmannj]

"step 3:"

#1 Strategie entwickeln, testen, POC (heute, morgen und so)
#2 in den driver und in fronthem einbauen, testen, tunen (kommende Woche)
#3 Ausgabe zur Analyse  (kommende Woche + x)

Ich hab für #3 was im Hinterkopf. Thema: um schlagkärftig zu sein wäre es doch schön ein Gebinde aus SmartVISU log, fronthemDevice Meldungen und fronthem zu bekommen. Das könnte ich vmtl ins fronthemDevice komfortabel integrieren.

Plots ist ein anderes Projekt.

vg
jör

[vbs]

Die Änderung an SV. Ich hatte es ja für sinnvoll gehalten, Erweiterungen, die allegemein und nicht nur für uns hier Sinn machen, bei den SV-Leuten reinzubringen.
Ich habe irgendwie etwas Bedenken, ob wir in Salami-Taktik dann doch irgendwie ein spezielles Spezial-SV basteln und beim nächsten SV-Update Probleme bekommen.

Was mir nicht gefällt ist die erforderliche Unterscheidung von user-Bildern und SV-Bildern. Ich fände etwas wie einen Suchpfad, erst user, dann SV eigentlich schöner, da man dann bei der Definition auf den pages das nicht bestimmen muss.
Die erforderlichen css-Schnipsel, die verschieden Widgets benötigen, wäre auch noch ein offener Punkt.

Das sind (leider) ziemlich genau die Stellen, die ich auch als unschön empfinde.

Wie man es dreht und wendet: Man kommt mMn nicht umhin, mindestens Kleinigkeiten an SV und auch an den Widgets zu ändern. Ich hätte nochmal einen Vorschlag für einen etwas anderen Ansatz, der weniger Änderungen an SV nötig macht, aber dafür die Widgets mehr in die Verantwortung nimmt:
-man legt ein paar neue twig-Funktionen an. Das würde bedeuten, dass man in SV nur ein weiteres PHP-File includen müsste und mit "$twig->addFunction" die gewünschten Funktionen laden müsste. Das halte ich zumindest für überschaubar und pflegeleicht.

Man würde zB folgende twig-Funktionen anlegen:
"addWidgetRepo" - fügt ein Verzeichnis-Pfad mit User-Widgets hinzu (zB addWidgetRepo("smartvisu-widgets"))
"importEx" - analog zu "import", sucht jedoch das Template auch in den User-Repos
"iconEx" - generiert einen Icon-Pfad. Sucht das Icon auch in den User-Repos.
"fileEx" - generiert Datei-Pfad. Sucht das File auch in den User-Repos (z.B. für CSS-Dateien)

Also der User würde "importEx" anstatt "import" benutzen, um die Widget-Templates zu laden. Die Widgets selber wiederum müssten zum Einbinden von Icons "iconEx" und zum Einbinden von CSS-Files "fileEx" benutzen. Der Haken ist mMn, dass dadurch die User-Widgets etwas speziell werden und nicht ohne die twig-Erweiterungen funktionieren. Auch hier denke ich jedoch, dass man es leider nicht hin bekommt, ohne Änderungen an Widgets vorzunehmen.

Was würdet ihr von dem Ansatz halten?

[herrmannj]

ich willl da jetzt echt keine Spaßbremse sein - für mich persönlich stellen sich die Fragen so nicht.

Der Endzustand soll fpr mich sein das es läuft, ganz vorne Plots, die Tabletts sind an die Wand geschraubt die Handys eingerichtet, SSL Zugang. Fire and forget ...

Wenn da jetzt wirklich neue widgets auftauchen dann (die für mich dann spannend sind) dann muss ich die sowieso erst einmal evaluieren, verstehn, auch lernen mit den Grenzen umzugehen. Das macht so ein zwei Abende, ja nach komplexität. Das dann davon vielleicht 1:30min darauf entfallen das ich das händlich reinkopieren muss spielt für mich da keine grosse Rolle.

Zumal ja die widgets auch alle unterschiedlich aufbegaubt sind. Bei dem einen muss man den css in die visu.css kopieren (js genauso) bei anderen sind es komplette Dateinen die eingebunden werden müssen. Vielleicht passe ich dann js und css an - ich bin mir nicht sicher ob ich das einer Autlomatik übertragen würde - auch nicht ob die das überhaupt könnte ?

Aber nochmal: ein bischen Demokratie haben wir schon hier

vg
jörg

[HCS]

#2 in den driver und in fronthem einbauen, testen, tunen (kommende Woche)

Du gehst aber nicht an den Treiber ran, oder?, sonst haben wir einen Konflikt und müssten mergen.

Aber nochmal: ein bischen Demokratie haben wir schon hier

Oh. Welches Unterschriftenquorum haben wir hier für ein Volksbegehren? 
@herrmannj: Du könntest ein Umfrage starten, wie viele User eine Notwendigkeit sehen, in die Richtung etwas zu verbessern (ernst, kein Scherz).
Das wäre dann gelebte Demokatie, momentan beschränkt es sich auf drei Meinungen.

Wenn nicht im größeren Stil ein Wunch nach so etwas besteht, kann zumindest ich auch gut mit dem aktuellen Stand leben.

Aktuell glaube ich, dass charts ganz oben auf der Wunschliste stehen.

[herrmannj]

Du gehst aber nicht an den Treiber ran, oder?, sonst haben wir einen Konflikt und müssten mergen.

Doch geht an den driver ran. (dont panic). Wenn das System so funktioniert wie ich plane siehst Du aber die Funktion sofort so genau das Du das mit wenigen Zeilen einbauen kannst. Bereite ich auch gern vor, muss es ja eh testen. Wenn (!) es so passt fügt sich das soooo geschmeidig ein das es flutscht ... alles easy

vg
jörg

[HCS]

OK, ich arbeite nämlich gerade an Deinem Herzenswunsch, dass die originalen SV plot.* widgets auch verwendbar werden, und nicht nur meine neuen chart widgets.

Wenn (!) es so passt fügt sich das soooo geschmeidig ein das es flutscht ... alles easy

Gut, hast meine Panik runtergeregelt. Wollte nur sicher sein, dass wir nichts fabrizieren, das nicht mehr zusammengeht.
Wenn Du höchstpersönlich am Treiber was machen willst / musst, dann gib Bescheid, ansonsten gehe ich generell davon aus, dass ich die Code-Hoheit habe.
Deine Erweiterung geschmeidig reinflutschen lassen ist kein Thema.

[herrmannj]

ansonsten gehe ich generell davon aus, dass ich die Code-Hoheit habe.

So isses. Ich schlage Dir den code (nur grob) vor und hoffe das Du den gut findest.

vg
jörg

[vbs]

Wenn da jetzt wirklich neue widgets auftauchen dann (die für mich dann spannend sind) dann muss ich die sowieso erst einmal evaluieren, verstehn, auch lernen mit den Grenzen umzugehen. Das macht so ein zwei Abende, ja nach komplexität. Das dann davon vielleicht 1:30min darauf entfallen das ich das händlich reinkopieren muss spielt für mich da keine grosse Rolle.

Mir geht es da weniger um den Zeitaufwand, sondern mehr um die Wartbarkeit. Nicht böse gemeint, aber ich finde so ein Vorgehen unsauber. Wenn ich Code aus verschiedenen externen Quellen für mich zusammen kopieren und ablegen muss, dann hab ich erstens Code dupliziert und ich weiß zum Beispiel vier Wochen später nicht mehr, welche Codeschnipsel ich mal aus welcher Quelle und welchem Stand kopiert habe und wo ich welche Änderungen eingebaut habe. Geschweige denn, dass ich bei den Widgets dann Updates händisch im Quellcode einpflegen muss.

Zumal ja die widgets auch alle unterschiedlich aufbegaubt sind. Bei dem einen muss man den css in die visu.css kopieren (js genauso) bei anderen sind es komplette Dateinen die eingebunden werden müssen. Vielleicht passe ich dann js und css an - ich bin mir nicht sicher ob ich das einer Autlomatik übertragen würde - auch nicht ob die das überhaupt könnte ?

Die Widgets im smartvisu-widgets-Repo sollten mMn einmalig, händisch so angepasst werden, dass sie im Kontext des "einbindbaren" Repos funktionieren. So dass genau nicht die Nutzer html/js/css-Dateien anpassen müssen, sondern out-of-the-box nutzen können.

Ist natürlich völlig ok, wenn du ein solches Feature nicht benötigst. Hatte dich eigentlich gestern so verstanden, dass du das Feature generell sinnvoll findest. Kann ich irgendwas tun, um euch zwei (?) bei einer Entscheidungsfindung zu unterstützen? Würde mich weiterhin dann gerne anbieten, eine technisch gute Lösung dafür zu finden, falls ihr das haben wollt.

[herrmannj]

Hatte dich eigentlich gestern so verstanden, dass du das Feature generell sinnvoll findest.

Ich befürchte da hast Du recht mir sind halt beim später-nochmal-drüber nachdenken Zweifel gekommen das man das ohne Nebenwirkungen umsetzen kann.

Denk mal an die widgets fürdie man code in die visu.js einsetzt oder css einfügt. Dann sollten updates später trotzdem zusätzlich eigene Anpassungen oder Änderungen , zb an der css, nicht überschrieben. Da habe ich offen gestanden einfach wegen evtl Nebenwirkungen Angst. Dazu kommt das Kalkül das Entwicklung, debuggen und warten von einer Autmoatik viel mehr Aufwand verursacht als das aktuelle von Hand einfügen.

Aber nochmal, ich will da auch nicht im Weg stehen.

vg
jörg

[bgewehr]

Ich glaube das Problem ist anders gelagert. Man kann vermutlich mit vertretbarem Aufwand eine solche Integrationslösung erstellen und damit das Spiel der Updates vereinfachen. Ich fürchte aber, dass dadurch implizit den Repository-Verantwortlichen die Aufgabe abverlangt wird, für alle Widgets für Update Kompatibilität zu sorgen, damit nicht jedesmal nach einem Update die Hälfte nicht mehr funktioniert... Also ich möchte diesen Job nicht haben, daher bleibe ich lieber bei der "jeder fummelt für sich" Denke...

[HCS]

Ihr erinnert euch? Ich habe mal eine dynamische Ladefunktionalität für die JSs der widgets gepostet. Aus diesem Grund hat bgewehr die ganzen JSs der widgets passend genannt. Und mit seiner Variante kann man sich die widgets irgendwo hin kippen und muss sie nur noch in die visu.js namentlich eintragen. Beim Update der widgets einfach aus dem Repo drüber kopieren und gut ist.

Verbleibt das css. Das muss man in seiner visu.css zusammenführen, aber da ist der Gedanke von Jörg nicht so falsch, dass man es evtl. dann eh anpassen will. Da müsste man mal schauen, was das so ist, ob man nicht im html defaults machen kann, so dass man das css nur braucht, wenn man anders formatieren will. Damit hätte man evtl. nur noch wenig mit den css zu tun.

@vbs: hast Du Dir diese Variante mal angeschaut oder ist die an Dir vorübergegangen?

[vbs]

@HCS:
Nee, sorry, ist an mir vorbei gegangen und ich konnte es auch gerade per Suche nicht finden. Klingt aber durchaus interessant. Hättest du evtl. einen Link für mich?

@bgewehr:
Also ich denke, dass der User ab und an etwas an seinen pages etwas anpassen muss, wenn sich Widgets ändern. Aber das ist mMn unabhängig von der Art wie die Widgets geupdatet werden. Der Vorteil wäre, dass der User nicht auch auf Widget-Seite anpassen muss, sondern eben nur auf seiner pages-Seite. Also ich denke einfach nicht, dass irgendwer garantiert bzw. erwartet, dass Widgets immer geupdatet werden können und 1:1 so aussehen/funktionieren wie zuvor.