fronthem Modulthread

[vbs]

Klar doch, keine Hektik. Sorry, wusste nicht, dass das noch in der Queue ist...

[herrmannj]

Hi,

ich bin von beiden nicht so recht überzeugt. Den ersten (binmode) bau ich Dir etwas anders nach (regex) dann wird er universeller verwendbar. Die intention verstehe ich und setze die um. Bei #2, dem perler, meine ich das er in den utils besser und sicherer umgesetzt werden kann. Hoffe das ist ok.

vg
jörg

[vbs]

Zu #1: klar, universeller ist immer besser

Zu #2: ok ist es sowieso, ist ja euer Projekt. In "utils" heißt, dass du das nicht in der Standard-Installation haben möchtest und dass man es sich in der 99_xxx selbst eintragen sollte, oder? Da ich natürlich dann auch die aktuelle Version selbst nicht nutzen möchte, wenn sie unsicher ist: Könntest du mir sagen, wie ich das in der Utils sicherer umsetzen kann?

[herrmannj]

99_xxx selbst eintragen sollte, oder? Da ich natürlich dann auch die aktuelle Version selbst nicht nutzen möchte, wenn sie unsicher ist: Könntest du mir sagen, wie ich das in der Utils sicherer umsetzen kann?

Ja genau. Ich möchte das Fass mit perl onliner als Argument für converter nicht so gern öffnen.

In den 99ern lassen sich ja sehr einfach eigene converter schreiben: einfach einen bestehenden nehmen, reinkopieren und anpassen. Ich sehe aber durchaus den need das noch weiter zu vereinfachen. Das ist ja letztendlich auch der Wunsch hinter den Perl onlinern.

Idee wäre das dahingehend zu vereinfachen das ich einen converter schreibe dem man als Argument den Namen einer sub mitgibt die der converter dann selber im namespace main aufruft. Beipiel: ich möchte einen Wert von Minuten in Sekunden konvertieren und habe keine Lust mich mit dem converter gesamt zu befassen (warum auch immer). Converter name "myUtils".

Eintrag im Editor, converter: "myUtils min2sec"

Eintrag in die normalen 99_myUtils.pm, komfortabel über die fhem web UI:

Code Auswählen Erweitern


sub min2sec_reading {
  my (m) = @_;
  return m * 60;
}

sub min2sec_set {
  my (s) = @_;
  return s / 60;
}


Auf diese Art und Weise würde man mMn den gewünschten Effekt der hinter den perl Onlinern steht komfortabler erreichen und man vermeidet das Sicherheitsloch das durch die evals aufgerissen wird. Ich meine auch das man damit besser skaliert: solche "Dinger" tendieren ja im Lauf der Zeit komplexer zu werden. Das geht mMn damit recht einfach, ist gut editierbar und auch wartbar. Ich könnte mal eben Zeilen zum loggen ein bauen, usw .

Jetzt hätte man die fertigen converter (die weiter ausgebaut werden), für komplexere Dinge (siehe uzsu) das Sytem über die frontheUtils und simple Sachen die nicht fertig geliefert werden könnte man so lösen. In den subs hätte man dann Zugriff auf alle fhem Funktionen und alle perl Bibliotheken ohne das es Überschneidungen mit dem namespace der converter gibt.

Wäre das ein gangbarer, komfortabler Weg ?

vg
Jörg

[vbs]

Also prinzipiell fände ich es schon gut zu wissen, ob das denn nun überhaupt unsicher ist oder nicht. Wenn da ein Perl-Experte etwas zu sagen könnte, wäre es klasse. Und wenn es am Ende nur aus Neugier ist. Da wir das aber im Moment nicht wissen, finde ich deinen Kompromiss ziemlich gut! Die Grundfunktionalität ist damit erhalten nur eben über einen kleinen Umweg.

[herrmannj]

Das Sicherheitsrisiko "eval" stelle ich hiermit amtlich fest ! 

Du selbst hattest ja schon ein Beispiel genannt. Es gibt dutzend weitere "gefährliche" calls die ich kenne. Am meisten sorge ich mich aber um die ich nicht kenne oder an die ich nicht denke. So haben wir eine saubere, sichere und komfortable Lösung. Ich setze das um. lass uns weiter gehen, gibt ja noch viele weitere spannende Aufgaben

vg
jörg

http://perlhowto.com/executing_external_commands

[vbs]

Du hast recht, finde deinen Ansatz ja auch gut. Sorry, ich bin manchmal etwas pedantisch... 

[dev0]

Apropos Security: die config.ini aus dem cleaninstall repo lässt sich, im Gegensatz zur original config.php, im Browser aufrufen und anzeigen. Kann man bestimmt mit einer .htaccess verhindern, aber ob das alle Anfänger so hinbekommen? Ich würde vorschlagen die Datei wieder auf .php enden zu lassen und nur einen anderen Basename zu verwenden.

[herrmannj]

guter Hinweis, hatte das auch schon im Hinterkopf.

htaccess ist mMn das Mittel der Wahl (Anfänger fhem / sv mit web Background schafft das.)
Über die Alternative *.php habe ich noch gar nicht nachgedacht, bin mir auch nicht ganz sicher ob das geht. Wenn ja wäre es zugegebenermaßen eine gute Art.

vg
jörg

[Hardy74]

Hallo,

ich habe mir mittels fronthem eine Anbindung an fhem auf meinem Raspi geschaffen. Ich benutze nicht SmartVisu, da es für meine Anwendungsfälle völlig overdone ist, ich schreibe mir die benötigten Dinge selbst in Form von php Scripten.

Die Fronthemthreads habe ich partiell mitgelesen, die Probleme, die ich hatte, konnte ich durch geschicktes googeln lösen.. bis jetzt.

Ich habe nun eine FS20 ST-4 und möchte den off-till Timer betun.
Das Gad habe ich wie folgt verknüpft:
device:      Die Steckdose
reading:    state
converter: alle durchprobiert
cmd-set:    off-till

Schreiben/Lesen: erlaubt

Von meinem Frontend schlägt der Befehl auch bis ins fhem Log durch:
2015.04.24 11:44:31 5: ipc HardnDoerdnsFronthems:127.0.0.1:44353 (ws): receive {"connection":"conn-8XZoIgd4","sender":"192.168.178.253","identity":"unknown", "message":{"cmd":"item","id":"Waschmaschine_an_um","val":"11:46:00"}}

Passieren tut jedoch bei Erreichen der Uhrzeit ganz viel nichts.

Führe ich den set Befehl auf den off-till Timer in fhem aus, passiert auch ersteinmal nichts, so lange, bis die gewünschte Uhrzeit erreicht, dann tut die Steckdose, was sie soll. Dieses fhem Verhalten während der Laufzeit des off-till Timers gefällt mir auch noch nicht, das ist aber eine andere Baustelle.

Hat jemand eine Idee, wo der Kinken liegt?

Besten Dank, auch für die bisherige Arbeit an fronthem!!

Grüße
Hardy

[herrmannj]

Hi Hardy,

Willkommen.

Ich hab keine direkte Idee, leider an der Stelle auch kein logging drin.

Ich würde Dir vorschlagen mal anstelle der Steckdose die Funktion auf ein dummy los zulassen. Da kannst Du ja am dummy danach genau sehen was gesetzt wird. Vielleicht können wir das dann eingrenzen.

Beim converter nimm mal "direct" - soll ja 1:1 gesetzt werden.

vg
jörg

[Hardy74]

Moin Jörg,

vielen Dank für Deine Rückmeldung! 

leider habe ich mit Pearl noch nie Berührung gehabt. Ergo bin ich auch gescheitert, 'mal eben schnell' ein Log in Deinem Code zu platzieren. Genauer in fhconverter.pm in der Funktion sub Direct(@) ein Log1("blabla"); was aber dazu führte, daß nichts mehr ging.

Ich habe Deine Idee aufgegriffen und einen Dummy definiert, dessen verbose mal auf 5 gestellt und ihn im Gad als Device eingestellt, ansonsten habe ich das Gad unverändert gelassen.

Das Ergebnis ist fast unverändert. 'Fast' meint, daß im 'ws send to' Eintrag des Logs bei der Steckdose zu lesen ist '["Waschmaschine_AN_um","off"]', beim Dummy steht an der Stelle '["Waschmaschine_AN_um",""]'. Das Form macht aus drei '?' offensichtliche einen Smiley

Ich habe zum Testen noch den on-till probiert. Hierzu habe ich am Gad das Device auch auf Küchenlicht (FS20 S4U) geändert. Warum? Weil die Waschmaschine ein notify hat, was bei 'on' zuschlägt und ein 'on-for-timer' draus macht, damit sie nach Waschende wieder abgeschaltet wird. Ich möchte Nebeneffekte damit vermeiden. Ergebnis: Auch hier funktioniert weder der on-till noch der off-till Timer.

Händisch in fhem eingegeben (set Waschmaschine off-till 12:34:00) funktioniert wie gewollt, sie geht an und nach der gewünschten Zeit wieder aus.

Ich hatte schon die ':' in der übergebenen Zeit unter Wind, nur um das zu eruieren, fehlen mir schlicht die Pearlkenntnisse. Probiert habe ich an der Stelle Delimiter vor die ':' zu setzen, doppelte ':' und ein komplettes Datum der Form '2015-04-25 09:33:00'. Die Tests blieben ebenfalls erfolglos. Im fhem Logfile erscheint die Zeit so, wie ich Sie in meinem PHP Script losgeschickt habe, als mit '\' davor oder mit '::' oder eben das ganze Datum.

Der on-for-timer funktioniert mit meinen Rolladenschaltern via fronthem übrigens wie gewollt. Aber leider gibt es keinen off-for-timer und diese Timer haben ja auch keine ':' im Parameter.

Grüße
Hardy

[HCS]

Der GAD-Editor hat noch eine kleine Unschönheit: wenn man GADs löscht, dann wird die fhserver.fronthem.cfg nicht geschrieben, passiert nur wenn man etwas ändert und speichert.

Hat den Effekt, dass man, wenn man nur GADs löscht und sonst nichts ändert, sie nach einem shutdown restart wieder hat.

[Jojo11]

Der GAD-Editor hat noch eine kleine Unschönheit: wenn man GADs löscht, dann wird die fhserver.fronthem.cfg nicht geschrieben, passiert nur wenn man etwas ändert und speichert.

Hat den Effekt, dass man, wenn man nur GADs löscht und sonst nichts ändert, sie nach einem shutdown restart wieder hat.

Das ist mir auch schon aufgefallen. Und ich dachte schon ich werde vergesslich und habe die überflüssigen Karteileichen doch nicht gelöscht

Ansonsten läuft smartVISU bei mir seit Monaten produktiv und ohne Probleme. Muss ja auch mal gesagt werden 
Nachdem ich nun auch per VPN zugreifen kann hat es die normale Oberfläche fast komplett überflüssig gemacht. Einzig die logfiles und Plots schaue ich mir noch damit an.

schöne Grüße
Jo

[HCS]

Ansonsten läuft smartVISU bei mir seit Monaten produktiv und ohne Probleme

Bei mir auch.

Und ich dachte schon ich werde vergesslich...

Genau so ging es mir auch 

Einzig die logfiles und Plots schaue ich mir noch damit an.

Tja, die Plots ...
@herrmannj: wie sieht es denn aus? Kann ich Dir was helfen?
Nicht dass ich auf der Suche nach Arbeit wäre, aber wenn es was zu tun gibt, um die Sache vorwärts zu treiben ...