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

[HCS]

Also ich hatte da auch drüber nachgedacht, aber ich würde das lieber einmalig zentral im Converter lösen anstatt an mehreren Stellen in FHEM userreadings anlegen zu müssen. Passt mMn auch zur bisherigen Marschrichtung: OnOffConverter z.B. ist vom Vorgehen ja sehr ähnlich.

Das entspricht meiner generellen Ansicht.
Wenn man ein Anzeigeproblem im frontend hat, dann sollte man es auch da lösen, und nicht im backend. Das entspricht dann auch den Zuständigkeiten der Komponenten.

Ob ein Konverter oder ein passendes Widget dann der richtige Weg ist, kann man diskutieren. Eher ein Widget, kann ja sein, dass ich den Wert selbst irgend wo anzeigen will und ein "Ventil zu" Icon.

Mit dem Widget wäre es wohl wirklich richtig. Es liegt eine Information einmal vor, und wie die in verschiedenen Varianten visualisiert wird, ist alleinge Zuständigkeit vom Frontend.

Ich will aber niemanden mit Architektur gängeln, das darf natürlich jeder machen, wie er es gerne möchte.

[marvin78]

Ich sehe es aber nicht als Anzeigeproblem im Frontend. Es ist ja nicht wirklich ein Bool-Wert, um den es hier geht, sondern ein Fake-Bool. Aufbereitung der Daten gehört aber meiner Ansicht nach ins Backend. Jedoch soll es mir wirklich egal sein.

[vbs]

Zwei Sachen, die mir an fronthemEditor.js aufgefallen sind:

Bei AJAX-Anfragen, die an FHEM gesendet werden, werden die Daten vor dem Absenden nicht URL-kodiert. Aufgefallen ist es mir in Funktion sveGADEditorSave. Da werden alle Daten in einen String kopiert. Sollten aber mMn URL-kodiert werden. Ich vermute, dass das aber auch bei allen anderen Sendefunktion der Fall sein wird.
Zum Beispiel hier:

Code Auswählen Erweitern

var dataString ='dev.' + device + '=' + device + '&cmd.' + device + '=get&arg.' + device + '=webif-data&val.' + device + '=' + JSON.stringify(transfer) + '&XHR=1';

Zum anderen werden bei von FHEM empfange Daten die Gänsefüßchen beim Zusammenbau der HTML-Seite nicht escapet. Zum Beispiel hier:

Code Auswählen Erweitern

$('#gadeditor').append('<tr><td>' + 'converter' + '</td><td align="right"><input id="gadEditConverter" type="text" size="55" value="' + gad.converter +'"/></td></tr>');
Wenn nun "gad.converter" seinerseits ein Gänsefüßchen enthält, dann wird dadurch das HTML-Attribut nicht richtig geschlossen.

EDIT:
Aufgefallen ist übrigens das erste Problem als ich mal ein +-Zeichen als Converter-Parameter übergeben wollte und beim zweiten Problem war es ein Gänsefüßchen. Kann damit auch reproduziert werden.

EDIT2:
Beim zweiten Problem geht es ja gar nicht nur um Gänsefüßchen, sondern wahrscheinlich ja darum, dass alle Daten HTML-enkodiert werden sollten.

[herrmannj]

jepp, Danke. Bin da sowieso plot technisch unterwegs - ich schau da mal rein. Das hat imho nicht so sehr mit dem Transprt zu tun sondern mit dem insert, bzw mit dem javascript.

vg
jörg

[HCS]

Ich möchte nochmal das Thema "die originalen plot widgets von SV" aufmachen.
Wir sollten ernsthaft nachdenken, ob wir sie wirklich benutzen können müssen.

Zur Unterscheidung: meine nennen sich chart, die originalen von SV nennen sich plot.

Nachdem ich nun Tage mit den plot widgets gekämpft habe und versucht habe, mit diesen
das Update der Serien hinzubekommen, bin ich noch mehr der Ansicht, dass wir sie nicht verwenden sollten.
Die Routinen dafür werden immer abgefahrener.

Hier die Punkte, warum ich die plot.* widgets direkt vom Start weg nicht nehmen würde:

gilt für plot.period und plot.rtr:
- GAD/Parameter parserei ("hcs.data.OilLevelPlot.avg.5y 6m.0" also konkret das ".avg.5y 6m.0")
- Die Aktualisierung mit neuen Daten ist fast unmöglich. fronthem müsste bei plots, die mehrere Serien
  haben, alle Serien von einem Plot gleichzeitig und in der richtigen Reihenfolge liefern und für jede
  Serie die passenden neuen Werte. Anders bekommt es das original widget nicht hin.
- Es kann kein Intervall festgelegt werden, in dem das Chart aktualisiert werden soll
- SV kann an ein initialisiertes plot nur Plotpunkte hinten anhängen, Szenerien, bei denen
  die Serie ersetzt werden muss, sind nicht möglich
- Ein plot mit mehreren Serien erscheint erst dann, wenn alle Serien Daten geliefert haben
- Solange ein Plot keine Serie bekommen hat, ist er komplett unsichtbar
- Es gibt keinerlei Konfigurationsmöglichkeiten. Viele der coolen Highchart-Features wie z.B. Export des Chart nach png oder pdf, Titel, Tooltips deaktivieren, Zoom-Varianten und vieles mehr lässt sich nicht steuern
- Man sollte die Klasse vom chart div als Parameter im widget setzen können, dass man unterschiedliche Höhen usw. haben kann.
- Der plot.rtr ist ein völlig starres Ding, da kann man noch nicht mal die Farben usw. konfigurieren. Im Prinzip ist er aber ein plot.period, nur dass da noch der Ventil-Stellung-PacMan mit drauf sitzt. Somit würde ich erwarten, dass man den für die Soll- und Istkurve so konfigurieren kann, wie den plot.period
- Ich bin mir absolut sicher, dass man sich bei den plots mehr wünschen wird, als aktuell in SV geht, und dann entstehen so oder so neue widgets, mit dem Nachteil, dass man sich dann mit zwei Sorten, die auch noch vom Treiber unterschiedlich angesteuert werden müssen, rumschlagen muss.
- comfortchart und temprose kann ich in meinen Varianten auch deutlich einfacher ansteuern
- Die restlichen Details lasse ich weg, sonst wird die Liste unendlich lang.

Eine generelle Unterstützung der plot widgets kann man durch einige weitere irre Routinen im Treiber noch hinbekommen, vieles aber ohne Änderung an den Widgets nicht.

Ich hätte in Kürze (aktuell fehlt nur noch der chart.rtr) einen kompletten Ersatz für die vier plot.* widgets:
chart.period, chart.rtr, chart.temprose und chart.comfortchart
bei denen diese Punkte alle erledigt sind.

Im Treiber könnte ich sicherstellen, dass die originalen plot.* widgets nicht verwendet werden und falls einer auf der page sitzt, so einen SV-Dreieck-Error einblenden, dass man die chart-widgets verwenden soll.

Die Parameter der chart.* widgets sind identisch zu den von plot.* nur der period ist unterschiedlich, aber auch den könnte ich Parameter-kompatibel machen, obwohl meine Reihenfolge schöner wäre.

Meine Empfehlung: wir unterstützen die plot.* nicht.

[herrmannj]

zu plot.* in Bezug auf driver und Alternative widgets bist Du viel tiefer im Thema, ich kann das aktuell nicht beurteilen. Wenn jedoch eine kompatible bessere Variante existiert wüsste ich nicht was dagegen spricht das so zu machen wie Du sagst.

vg
jörg

[HCS]

OK, ich baue den chart.period noch um, dass die Parameter sich mit dem plot.period decken, hinten raus sind die weiteren dann eh optional, so dass man sich, wenn man die zusätzlichen Features nicht nutzt, 1:1 an der SV-Doku orientieren kann.

[herrmannj]

gehs vielleicht noch etwas ruhiger an. Erfahrungsgemäß ergeben sich ja doch noch neue insights wenn wir näher rankommmen ...

Plots in sv gehen langesam voran - noch ist aber nicht zum vorzeigen. vg jörg

[vbs]

Hier noch ein Vorschlag für einen neuen Converter: UserCode-Converter. Analog zu vielen Stellen in FHEM, kann man damit eigenen Perl-Code angeben, der die Hin- und die Rückkonvertierung durchführt. Der erste Parameter konvertiert FHEM->SV, der zweite SV->FHEM. Wird der zweite Parameter weg gelassen, dann handelt sich um einen read-only-Converter.

Beispieldefinition:

Code Auswählen Erweitern

UserCode {sprintf("%.1f", $VALUE / 1000.0)}, {$VALUE * 1000}

PS.
Der Converter funktioniert leider nur, wenn die Bugs aus http://forum.fhem.de/index.php/topic,30909.msg282089.html#msg282089 gefixt sind.

PR:
https://github.com/herrmannj/fronthem/pull/8

[HCS]

Den finde ich praktisch. Der erspart evtl. dann auch unzählige weitere Converter.
Damit lässt sich doch dann auch das "bin" beim NumDisplay erledigen, bzw. der BoolConverter, oder?

[herrmannj]

Beispieldefinition:

Code Auswählen Erweitern

UserCode {sprintf("%.1f", $VALUE / 1000.0)}, {$VALUE * 1000}

PS.
Der Converter funktioniert leider nur, wenn die Bugs aus http://forum.fhem.de/index.php/topic,30909.msg282089.html#msg282089 gefixt sind.

PR:
https://github.com/herrmannj/fronthem/pull/8

Das ist kein bug - das ist ein feature Ich kann mir das leider iA nicht im Detail ansehen (morgen erst)

Ich übernehme den gerne die converter - die Idee ist sehr gut. Folgende Bitte dazu: schau Dir (Ihr, wie auch immer) das Ding bitte nochmal sehr genau auf folgenden Aspekt hin an:

Kann ich via $value über sv (bzw den websocket) code einschleusen der dann im eval mit fhem rechten ausgeführt wird ?

Ich meine damit das Äquivalent zu sql injections. Das müsste bitte unbedingt vermieden werden. Wenn das unmöglich ist würde ich den Bernds Vorschlag folgend in der 99 er sehen. Hintergrund: in der Standard Installation möchte ich keine Einfallstore haben, was der user dann hinterher damit macht liegt in persönlicher Verantwortung jedes Einzelnen.

vg
jörg

[fhainz]

Hallo HCS!

Mir ist noch Problem mit dem icon.battery widget in Verbindung mit dem fhem-Treiber v1.08 aufgefallen. Den js Code von icon.battery hab ich mit dem aus dem widget git ersetzt. Da gabs anscheindend im original Code einen Bug?

Das widget zeigt zwar den Wert mit den Füllungs-Balken an geht aber nicht mehr in den "on state", sprich es wird nicht mehr grün. Hab das bei mir wie folgt defieniert und funktioniert bei v1.02 problemlos.

Code Auswählen Erweitern

{{ basic.shifter('mba.ladedose', 'mbaLadedose', 'mba.akkuIcon', 'icon.battery', '', '', '0', '255' ) }}

mbaLadedose ist mit dem OnOff Converter verknüpft,
mba.akkuIcon liefert einen Wert zwischen 1-255 und ist mit NumDirekt verknüpft.

Konsole liefert keine ausergewöhnliche Meldungen.

Hast du dazu eine Idee?

Grüße

[HCS]

Mir ist noch Problem mit dem icon.battery widget in Verbindung mit dem fhem-Treiber v1.08 aufgefallen.

wenn ich irgendwann alle Eier gefunden habe, dann schaue ich mir es mal an

Frohe Ostern @all

[fhainz]

Klar, kein Stress!

Frohe Ostern!

[HCS]

@fhainz: Auf die Schnelle, probier mal die 1.09, die ich ein Stück weiter oben gepostet habe.