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

[fhainz]

Nein, leider selbes Problem.

Mit der v1.09 funktioniert auch mein selbstgebautes toggleElement widget nicht mehr richtig. Beim laden ist alles ok, nach einem klick auf eine andere Seite werden alle Icons aufgeblendet. Muss dem aber erst auf den Grund gehen.

[vbs]

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?

Freut mich. Ja, damit ist BoolConverter eigentlich überflüssig. Man kann sich damit natürlich theoretisch alle Converter bauen, die man haben möchte. MMn sollte man sich trotzdem überlegen, welche anderen, oft benutzten Converter man aus Convenience-Gründen fertig anbieten will. So dass der normale Benutzer im Normalfall nicht selbst Converter-Code schreiben muss.

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

Keine Panik, war wirklich nicht als Wink mit dem Zaunpfahl gedacht oder so Eilt ja nicht.

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.

Ok, wichtiger Punkt! Ich hab mal etwas rumgespielt und im Moment kann das offenbar durchaus passieren. Aber ich habe mir das jetzt mal näher angesehen. Vorweg: Ich habe großen Respekt vor diesen Sicherheitsfehlern und bin da kein großer Experte. Wäre gut, wenn da noch jemand anders etwas zu sagen könnte.
Vorschlag wäre, dass man die Variable $VALUE, die von SV rein kommt, mit String::Escape::backslash und mit String::Escape::quote bearbeitet. Damit sollte aus der Variable in jedem Fall ein richtiger String werden, der nicht mehr als Code interpretiert werden kann.
Sagen wir, der Converter sieht so aus {$VALUE + 5}. Wenn eine Zahl kommt, sagen wir 3.17, dann wird daraus {"3.17" + 5} und passt damit. Wenn ein String kommt, sagen wir 'system("reboot");3+', dann wird daraus {"system(\"reboot\");3+" + 5}. Also wurde da der Code korrekt in einen String gewandelt.
Oder?

Setzt natürlich dann Modul String::Escape vorraus.

Euch frohe Ostern übrigens!

[herrmannj]

Hi,

frohe Ostern zurück.

MMn sollte man sich trotzdem überlegen, welche anderen, oft benutzten Converter man aus Convenience-Gründen fertig anbieten will. So dass der normale Benutzer im Normalfall nicht selbst Converter-Code schreiben muss.

Sehe ich genauso. Zumal der Aufwand einen converter zu bauen ja wirklich minimal ist.

Vorschlag wäre, dass man die Variable $VALUE, die von SV rein kommt, mit String::Escape::backslash und mit String::Escape::quote bearbeitet. Damit sollte aus der Variable in jedem Fall ein richtiger String werden, der nicht mehr als Code interpretiert werden kann.

Alternativ wäre es evtl mgl nur Zahlen durch zu lassen (regex \d, mit Komma und Vorzeichen natürlich). Ggf könnte man (um das install der Pakete zu vermeiden) auf das Hochkomma einen String replace legen. Da muss man aber immer extremst aufpassen um alle Varianten zu erwischen. Es gibt verschiedene Möglichkeiten system Befehle oder perl code auszuführen. Beispiel, den Code base64 codiert einschleusen und ein eval auf decode base64 (bla). Durch die base64 codierung werden auch pattern wie system('. und co schwer erkennbar.

Daher würde ich dafür voten das auf Zahlen zu beschränken was ja der Intention des converters durchaus gerecht wird. Möglich blieben dann Umrechnungen (Einheiten, Prozent auf 255 und zurück etc) genauso wie auch der Wertebereich bei Markisen (100-$value um den Wert zu invertieren). Das Risiko wäre mMn damit ausreichend reduziert.

vg
jörg

[vbs]

Hm, man könnte das schon so machen und den Converter auf Zahlen beschränken, aber ich kann mir schon einige Szenarien vorstellen, in denen auch das Konvertieren von Strings nützlich wäre. Prinzipiell fände ich es daher schon schöner, wenn das weiterhin möglich wäre.
Was genau spricht denn deiner Meinung nach gegen das Absichern durch String::Escape? Ich halte das erstmal für sicher und würde das einer selbstgebauten replace-Funktion in jedem Fall vorziehen (halte ich, wie du ja auch, für gefährlich). Zur Not könnte man natürlich den Code aus String::Escape rauskopieren.

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

Kann mir mal mit dem basic.shifter jemand weiterhelfen, da ist mir eine ganze Liste unklar.

1. mit Treiber V1.02 geht der Farbumschlag bei mir auch nicht

2. im widgets repo liegt diese Variante vom basic.shifter:
https://github.com/herrmannj/smartvisu-widgets/blob/master/basic/shifter/basic.html

Code Auswählen Erweitern

{% if pic_on|slice(0, 5) == 'icon.' %}
{{ attribute(icon, pic_on|slice(5), [id, gad_switch, gad_value, '', min, max]) }}
{% else %}
Welchen Zweck hat der Parameter nach gad_value mit dem Leerstring?

3. Wo ist den irgend ein code, der den Farbumschlag macht?
im update handler auf alle Fälle nicht:

Code Auswählen Erweitern

// ----- icon.battery ---------------------------------------------------------
$(document).delegate('svg[data-widget="icon.battery"]', {
'update': function (event, response) {
// response is: {{ gad_value }}, {{ gad_switch }}

var val = Math.round((response[0] - $(this).attr('data-min')) / ($(this).attr('data-max') - $(this).attr('data-min')) * 40);
fx.grid(this, val, [39, 68], [61, 28]);
}
});

Der wird ja am Ende zu einem "<svg ..." und das icon macht sich an class="icon icon0" fest.

Ich muss jetzt erst mal verstehen, wie und warum das überhaupt funktionieren kann, bevor ich dahinter kommen kann, was der Treiber damit zu tun haben könnte.


Ganz generell:
Wir sollten überlegen, ob es gut ist, dass wir Schnipsel haben, mit denen Anwender die original widget.js und die original widget htmls umbauen.
fhainz hat es zum Glück dazugeschrieben, aber es kann extrem verwirrend werden, wenn man ein Problem nachvollziehen will, und anders "zusammengebastelte" wigets hat.

Evtl. wäre es besser, für widgets, die einen Fehler haben, einen Ersatz zu schaffen und die originalen uverändert zu lassen.
Zumal dieses umgebaute widget hier auch noch dazu führt, dass man es anders aufrufen muss, als die SV-Doku beschreibt.

SV:
{{ basic.shifter(id, gad_switch, gad_value, pic_on, pic_off, min, max) }}

Aufruf für das umgebaute widget:
{{ basic.shifter('mba.ladedose', 'mbaLadedose', 'mba.akkuIcon', 'icon.battery', '', '', '0', '255' ) }}

[HCS]

... aber ich kann mir schon einige Szenarien vorstellen, in denen auch das Konvertieren von Strings nützlich wäre. Prinzipiell fände ich es daher schon schöner, wenn das weiterhin möglich wäre.

Kann mir auch welche vorstellen und fände es auch schöner, wenn er Strings könnte. Und man hat es auch mal mit einem Datum zu tun oder will aus 90 Sekunden 1:30 machen usw.

[fhainz]

1. mit Treiber V1.02 geht der Farbumschlag bei mir auch nicht

Bei mir ist mit 1.02 alles ok. Mit 1.08 funktioniert der Farbumschlag nicht mehr.

2. im widgets repo liegt diese Variante vom basic.shifter:
https://github.com/herrmannj/smartvisu-widgets/blob/master/basic/shifter/basic.html

Code Auswählen Erweitern

{% if pic_on|slice(0, 5) == 'icon.' %}
{{ attribute(icon, pic_on|slice(5), [id, gad_switch, gad_value, '', min, max]) }}
{% else %}
Welchen Zweck hat der Parameter nach gad_value mit dem Leerstring?

Das verstehe ich auch nicht ganz. Hab gerade gemerkt, dass ich den basic.shifter eigentlich falsch definiert habe.

Code Auswählen Erweitern

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

Wenn ich die überflüssigen '' rausnehme (das off icon hab ich jetzt auch mal eingetragen)

Code Auswählen Erweitern

{{ basic.shifter('mba.ladedose', 'mbaLadedose', 'mba.akkuIcon', 'icon.battery', 'icon.battery' ) }}
läuft anscheinend ein endlos prozess nach dem akualisieren. Die gads bis zum shifter werden geladen, ab den shifter nichts mehr. Browser reagiert nicht mehr, prozessor leistung geht auf 100%.
Ohne '0', '255' funktioniert es wieder.

Code Auswählen Erweitern

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

Anscheinend liegt es an dem min Wert.
-  Mit 0, 255 kommt sofort die Endlosschleife.
-  Mit 1, 255 kommt zwar keine Endlosschleife aber das die Striche zeichnen über das Batterie Icon raus.
-  Mit '', 255 läd die Seite, das Icon passt, nur die Farbe ändert sich unter 1.08 nicht. Mit 1.02 passt alles.

Kann das jemand bestätigen?

3. Wo ist den irgend ein code, der den Farbumschlag macht?
im update handler auf alle Fälle nicht:

Ich denke die Farumschaltung macht basic.shifter

Code Auswählen Erweitern

// ----- basic.shifter --------------------------------------------------------
$(document).delegate('span[data-widget="basic.shifter"]', {
'update': function (event, response) {
// response is: {{ gad_value }}, {{ gad_switch }}

var step = Math.min((response[0] / $(this).attr('data-max') * 10 + 0.49).toFixed(0) * 10, 100);

if (step > 0 && response[1] != 0) {
$('#' + this.id + ' img').attr('src', $(this).attr('data-pic-on').replace('00', step));
}
else if (step > 0 && $(this).attr('data-pic-off').substr(-7) == '_00.png') {
$('#' + this.id + ' img').attr('src', $(this).attr('data-pic-off').replace('00', step));
}
else {
$('#' + this.id + ' img').attr('src', $(this).attr('data-pic-off'));
}
},

'click': function (event) {
var items = $(this).attr('data-item').explode();

if (items[1]) {
io.write(items[1], (widget.get(items[1]) == 0 ? 1 : 0));
}
}
});

$(document).delegate('span[data-widget="basic.shifter"] > a > img', 'hover', function (event) {
if (event.type === 'mouseenter') {
$(this).addClass("ui-focus");
}
else {
$(this).removeClass("ui-focus");
}
});

Evtl. wäre es besser, für widgets, die einen Fehler haben, einen Ersatz zu schaffen und die originalen uverändert zu lassen.

Sehe ich auch so.

Zumal dieses umgebaute widget hier auch noch dazu führt, dass man es anders aufrufen muss, als die SV-Doku beschreibt.
..
Aufruf für das umgebaute widget:
{{ basic.shifter('mba.ladedose', 'mbaLadedose', 'mba.akkuIcon', 'icon.battery', '', '', '0', '255' ) }}

Siehe oben. Ist eindeutig ein Fehler von mir, falsch definiert. Aber warum diese definition funktioniert hat ist mir immer noch ein Rätsel.

[HCS]

Das verstehe ich auch nicht ganz. Hab gerade gemerkt, dass ich den basic.shifter eigentlich falsch definiert habe.

Du hast ihn so definiert, dass er mit dem umgebauten widget funktioniert.
Der Effekt mit der Endlosschleife tritt genau dann auf, wenn man ihn so wie in SV beschrieben definiert und das umgebaute widget verwendet
Dann kommt als max im update handler 0 an und die Division durch 0 führt zur Endlosschleife.

Wenn Du einen min Wert angibst, dann kommt der als max an und darum malt es drüber raus.

Irgend wer muss doch das widget so umgebaut haben und eine Erklärung haben, was der Grund dafür ist.

Bei mir ist mit 1.02 alles ok. Mit 1.08 funktioniert der Farbumschlag nicht mehr.

Das Problem ist, dass ich noch nicht verstehe, durch was es mit dem Farbumschlag überhaupt funktionieren kann.

Ich denke die Farumschaltung macht basic.shifter

In diesem Fall wird doch ein icon.battery draus, und es ist am Schluss gar kein basic.shifter mehr, oder verstehe ich das falsch.

Auf der fertig gerenderten page wir das draus:

Code Auswählen Erweitern

<svg id="room_test-basic_shifter_test" data-widget="icon.battery" data-item="hcs.data.counter, switch_dummy" data-min="0" data-max="999" class="icon icon0" xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 100 100">
  <g>
    <rect x="44" y="21" width="12" height="3"></rect>
    <rect rx="3" x="35" y="25" width="30" height="45" fill="none"></rect>
  </g>
</svg>

Und das ist nun eindeutig ein data-widget="icon.battery" und kein shifter mehr, somit kann auch kein update code vom shifter laufen und icons ändern.

[fhainz]

Stimmt, da gibts keinen basic.shift mehr, das hab ich übersehen 

Kann es das sein? ein paar Zeilen über icon.battery

Code Auswählen Erweitern

$(document).delegate('svg[data-widget^="icon."]', {
'update': function (event, response) {
// response is: {{ gad_value }}, {{ gad_switch }}

if (response instanceof Array) {
this.setAttributeNS(null, 'class', 'icon' + (response[0] && response[1] ? ' icon1' : ' icon0'));
}
},

'click': function (event) {
if ($(this).attr('data-item')) {
var items = $(this).attr('data-item').explode();

if (items[1]) {
io.write(items[1], (widget.get(items[1]) == 0 ? 1 : 0));
}
}
}
});


Edit:

Ich hab mir mal mit v1.02 die Konsolen Meldungen angesehen die beim aus/einschalten entstehen.

Code Auswählen Erweitern

[Log] [icon.battery] update 'room_wohnzimmer-mba_ladedose': [150.4, 0] (base.js, line 678)
[Log] [icon.battery] update 'room_wohnzimmer-mba_ladedose': [150.4, 1] (base.js, line 678))

on:

Code Auswählen Erweitern

<svg id="room_wohnzimmer-mba_ladedose" data-widget="icon.battery" data-item="mba.akkuIcon, mbaLadedose" data-min="0" data-max="255" class="icon icon1" xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 100 100">

off:

Code Auswählen Erweitern

<svg id="room_wohnzimmer-mba_ladedose" data-widget="icon.battery" data-item="mba.akkuIcon, mbaLadedose" data-min="0" data-max="255" class="icon icon0" xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 100 100">

Die Klassen werden in 1.02 richtig gesetzt.

[herrmannj]

Hi,

Bernd hatte den basic.shifter angepasst weil der max Wert ignoriert wurde.

vg
jörg

[HCS]

Prima, Du (fhainz) leitest mich gerade in die richtige Richtung.

Ich glaube, ich beginne zu verstehen. Es gibt mehre verschieden Update-Handler, von denen mal der eine und mal der andere und mal mehrere gleichzeitig laufen müssen.

Der Treiber ruft nach der neuen Methode aber genau einen auf. Es müssten aber zwei laufen, der vom icon.battery und der delegate, den Du gerade gepostet hast.

Der Treiber geht mom. fälschlicherweise davon aus, dass er genau einen update handler aufrufen muss.
Da lässt sich dran arbeiten.

Das ändert aber nichts an dem Thema, dass das widget so nicht bleiben kann und an meiner Eingabe, die original SV widgets unverändert zu lassen.

[herrmannj]

an meiner Eingabe, die original SV widgets unverändert zu lassen.

Bsp eine LED mit Helligkeit 0 .. 100 wird vom original basic.shifter falsch dargestellt (der shifter geht von 255 max aus und stellt 100 als "kurz vor halb" dar")

vg
jörg

[vbs]

Ich würde die Verzeichnisnamen im widget-Repo als Namespace verstehen wollen, also zB "basic". "basic" wiederum "gehört" SV und das sollten wir nicht editieren, sehe ich auch so. MMn sollten wir unsere von von basic geforkten Widgets in einen eigenen Namespace/Verzeichnis packen, zb "basic_mod" o.ä. Dann kann man weiterhin das Original als "basic/shifter" verwenden oder eben unseren Fork als "basic_mod/shifter".
Ich habe mich auch schonmal an zwei kleineren neuen Widgets versucht. Die habe ich dann zB nach "basic_extra" gepackt.

[HCS]

Bsp eine LED mit Helligkeit 0 .. 100 wird vom original basic.shifter falsch dargestellt (der shifter geht von 255 max aus und stellt 100 als "kurz vor halb" dar")

Ich meinte auch nicht, dass man den Fehler nicht korrigieren sollte, sondern dass man ein neues Widget machen sollte, dass korrekt funktioniert.
Versuch mal mit den "umgebastelten" original widgets einen Fehler von jemandem anderen zu finden.
Der eine hat dies eingebaut, der andere jenes, der nächste nichts davon und das Original in Betrieb und dann versuch mal dahinter zukommen, was warum bei wem passiert.

Wenn man davon ausgehen kann, dass die SV-Grund-Installation bei allen gleich ist und man den gleichen Stand eines widgets aus unserem repo verwendet, hat man auch sicher die gleichen Bedingungen und es wird deutlich einfacher.

[herrmannj]

Hi,

Ich meinte auch nicht, dass man den Fehler nicht korrigieren sollte, sondern dass man ein neues Widget machen sollte, dass korrekt funktioniert.

ne, das macht ja keinen Sinn. Ziel vom clean-install ist ja das man dort eine definierte Basis findet. Wenn wir jetzt anfangen jedesmal für einen Fehler ein neues widget from scratch zu bauen dann werden wird das ja nie erwachsen.

Im clean-install soll der sv Lieferzustand liegen, inkl der notwendigen bugfixes und in höchster Qualität.

Im widget repo landen dann die Erweiterungen.

btw: ich mach jetzt endgültig diesen thread hier zu, sonst werden wir ja wahnsinnig (wenn wir das nicht schon sind ) und eröffne mal

fronthem Modulsthread
fronthem nextgen driver
smartVisu erste Schritte
smartVisu Widgets

(erste Schnritte und widgets haben wir eigentlich schon)

wenn ich was vergessen habe macht die zusätzlich auf - Ziel ist es wieder etwas mehr Struktur reinzubekommen

vg
jörg