fronthem Modulthread

[herrmannj]

Hallo @all,

nachdem der erste smartVisu thread jetzt knapp 2300 posts hat und ständig weiter wächst wird es Zeit weiter zu strukturieren.

Dieser thread soll sich daher rein mit fronthem Themen (bugs, feature requestes etc) beschäftigen.

Erste Schritte für Einsteiger:
http://www.fhemwiki.de/wiki/Fronthem

Next steps sind die Integration von plots

vg
jörg

Open Issues
* in seltenen Fällen blockiert fronthem ein shutdown restart
* converter (negative Vorzeichen bei NumDirect und NumDisplay)

Feature request
* sv plots (gmeinsam mit HCS implementieren)
* sv logging (gmeinsam mit HCS implementieren)

[vbs]

Find ich gut! Wenn Ostern wäre, dann würde ich mir für fronthem ein eigenes Subforum wünschen... 

[fhainz]

dann würde ich mir für fronthem ein eigenes Subforum wünschen... 

An das hab ich auch schon gedacht. Wäre klasse! Im Allgemeinen Forum gibt es gerade eine Diskussion. Vielleicht klinken wir und da ein? http://forum.fhem.de/index.php/topic,35842.0.html

Dieser thread soll sich daher rein mit fronthem Themen (bugs, feature requestes etc) beschäftigen.

Find ich auch super, dann quellt der alte nicht noch mehr über!

Dann will ich hier gleich mal mein "Neustart" Problem unter OS X zusammenfassen

Angefangen hat alles hier: http://forum.fhem.de/index.php/topic,30909.msg240461.html#msg240461
Hier Logs mit verbose 3 und 5: http://forum.fhem.de/index.php/topic,30909.msg243206.html#msg243206
Hier haben wir nochmal kurz gequatscht: http://forum.fhem.de/index.php/topic,30909.msg261604.html#msg261604

Vor kurzem habe ich zum testen ein jungfräuliches FHEM mit fronthem auf meinem MacBook Air installiert. Sobald fronthem definiert war funktionierte der Neustart nicht mehr.

Derzeit starte ich FHEM mittels Button und notify (das zuerst fronthem löscht) neu, also ist das jetzt nicht soo dringend.

Grüße

[herrmannj]

Danke. Da mache ich mal eine issue lis auf, dann haben wir auch eine struktur

vg
jörg

[HCS]

Danke. Da mache ich mal eine issue lis auf, dann haben wir auch eine struktur

Im git? Wenn die public wäre und ich die offenen Treiber tickets da auch reinpacken könnte, hätten wir einen Gesamtüberblick.

[dev0]

Zwei Kleinigkeiten sind mir an fronthem aufgefallen:

Das eine ist, dass mir die drei Images (desktop.svg, arrow-*.svg) im fronthemEditor nicht angezeigt werden. Grund ist, dass der Aufruf in fronthemeditor.js das FHEMWEB Attribut webname nicht (ausreichend?) berücksichtigt. Das betrifft wohl auch den Aufruf der jquery.min.js, aber hier sind mir keine negativen Auswirkungen aufgefallen.

Beispiel:
Aufgerufen wird vom Editor: xxx:8083/fhem/fhem/images/default/desktop.svg
Richtig wäre aber: xxx:8083/fhem/desktop/images/default/desktop.svg in meinem Fall, da webname für diese Instanz auf "fhem/desktop" gesetzt ist.

Das andere: die Datei 99_fronthemUtils.pm ist in controls_fronthem.txt (GitHub) nicht eingetragen. Absicht?

/Uli

[moved from: http://forum.fhem.de/index.php/topic,35960.0.html]

[herrmannj]

HI

Danke. icons - nehm ich auf todo

99er ... : Absicht. Dort ist der Platz für selbstgeschriebene converter - soll also beim uppdate erhalten bleiben.

Danke und Grüße
Jörg

[dev0]

Hi Jörg,

schön wäre es, wenn man über IPv6 auf fronthem zugreifen könnte. Zur Zeit werden das nicht viele Benutzer benötigen, aber die Zeit wird kommen. Jetzt in der Betaphase sehe ich noch eine gute Möglichkeit das zu implementieren. Vielleicht sollte ich an dieser Stelle erwähnen, dass ich kein Programmierer bin, ich habe eher mit Infrastruktur zu tun... Aber wenn ich Frau Google richtig verstanden habe, dann sollte ein simpler Austuasch von IO::Socket:INET zu IO::Socket::IP das Problem lösen können ohne Klimmzüge über ::INET6 machen zu müssen.
Ob es wirklich so simple ist, wie ich mir das vorstelle oder ob wir dann in ganz andere Probleme hinein laufen, kann ich im Moment nicht beurteilen. Wenn Du interesse daran hast IPv6 zu implementieren, dann würde ich Dich gerne unterstützen.

/Uli

[herrmannj]

spricht nix gegen. Wobei ich das jetzt nicht vorn an stellen würde.

vg
jörg

[dev0]

99er ... : Absicht. Dort ist der Platz für selbstgeschriebene converter - soll also beim uppdate erhalten bleiben.

Macht sinn, dass die 99er dann nicht überschrieben/bezogen wird... Aber ich musste echt eine zeitlang suchen um sie zu finden. Sollten wir in der Release-Version abstellen oder besser dokumentieren (oder habe ich es wirklich überlesen?).

[dev0]

spricht nix gegen. Wobei ich das jetzt nicht vorn an stellen würde.

OK! Wenn Du/Ihr testen wollt, dann werde ich uns gerne unterstützen

[bgewehr]

Solange die UZSU Dinge in der 99_er sind, wird es dann mit Updates für die UZSU schwierig... Kann das perspektivisch auch in die fhconverter rein und damit in den Updatepfad?

[herrmannj]

yepp, mach ich. vg jörg

[vbs]

Darf ich nochmal nachfragen, was ihr von den Pull Requests haltet?
https://github.com/herrmannj/fronthem/pulls?q=is%3Aopen+is%3Apr

[bgewehr]

Ich bin sicher, dass Jörg sich das ansehen wird. Hab etwas Geduld!

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

[herrmannj]

Hi,

@herrmannj: wie sieht es denn aus? Kann ich Dir was helfen?

Bin "dran". Leider hält mich der job gut unter Feuer. Ich schau mal das ic die Plots forciere.

vg
joerg

[1of16]

Moin,

mit der Hoffnung, dass ich mich hier an den richtigen Thread anhänge: Ich habe ein kleines (für mich größeres) Problem mit dem fronthem bei der Nutzung von smartvisu festgestellt.
Wenn ich die Smartvisu-Seite über https aufrufe, kommt es zu folgender Fehlermeldung:

Code Auswählen Erweitern

io_fhem.js:166 [io.fhem]: init [V1.10] (address=192.168.1.3 port=2121)
io_fhem.js:423 Mixed Content: The page at 'https://example.com/smartvisu/' was loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint 'ws://192.168.1.3:2121/'. This request has been blocked; this endpoint must be available over WSS.io.open @ io_fhem.js:423
io_fhem.js:423 Uncaught SecurityError: Failed to construct 'WebSocket': An insecure WebSocket connection may not be initiated from a page loaded over HTTPS.
Das Verhalten ist aber wohl auch nicht unerwartet: https://developer.mozilla.org/en-US/docs/WebSockets/Writing_WebSocket_client_applications#Security_considerations
Ein Ändern auf wss:// bringt leider nicht den gewünschten positiven Effekt, obgleich das wohl möglich sein sollte: https://msdn.microsoft.com/en-us/library/windows/apps/hh761446.aspx?f=255&MSPPError=-2147217396
Ich vermute gerade, dass fronthem schlicht die wss-Anfrage nicht verarbeiten kann?!
Gibt es abgesehen von "deaktiviere die Verschlüsselung" irgendeine Lösungsidee, oder ist dies eher was für die to-do-Liste?

Grüße
1of16

[herrmannj]

Moin,

korrekte Diagnose: deaktiviere die Verschlüsselung (vorerst). Und ja: steht auf der To-do Liste !

Grundsätzlich bin sehr FÜR Sicherheit, Verschlüsselung gehört dazu. Freut mich das Du das sichtlich genau so siehst,

vg
joerg

[1of16]

Moin,

danke für die schnelle Antwort.
Dann bastel ich mir einen kleinen, schicken und unverschlüsselten Umweg, um den "waf" nicht unnötig zu senken
Für halbfertige Sachen zum Testen würde ich dir dann zur Verfügung stehen

Grüße
1of16

[HCS]

Hi,
Bin "dran". Leider hält mich der job gut unter Feuer. Ich schau mal das ic die Plots forciere.

vg
joerg

Hast Du das Thema inzwischen verworfen oder noch auf der Agenda?
Ich überlege inzwischen, ob ich mir eine Lösung baue, um die Charts rüber zu bekommen, so ähnlich wie ich sie von meiner Heizungssteuerung hole.
Mache ich aber nur, wenn Du jetzt nicht sagst "klar, in zwei Wochen ist es fertig"

[herrmannj]

Hi.

Alles gut. Auf der Agenda und in Arbeit. Auf zwei Wochen leg ich mich nicht fest.

Vg
Joerg

[bgewehr]

Ich habe einen Weg gefunden, den Webservice zu killen: per VPN zugreifen und das VPN im Autobahntunnel sterben lassen - das klappt fast immer! Ich mache dann immer einen fhem-Neustart, gibt es noch was besseres? Reanimation am Device oder so?

[herrmannj]

gibt es noch was besseres?

Brücke !!! 

Im Ernst, Danke. Mit der aktuellen Version fällt mir keine alternative Erste Hilfe ein. Steht was im log ? Konkret wäre es interessant ob der websocket stirbt. Wenn ja, steht was in fronthem.err ?

Mit der neuen Version wird das nicht mehr passieren, allerdings leg ich mich noch nicht ein Datum fest. Evtl machts also Sinn das noch patchen wenn möglich.

vg
joerg

[gravidi]

Die Logs würden mich auch intressieren, ich nutze Smartvisu auch über VPN, aber nach verlieren der Verbindung oder manuelles beenden der VPN Strecke bleibt mein Webserver und Fhem erhalten.

[dev0]

Die Logs würden mich auch intressieren, ich nutze Smartvisu auch über VPN, aber nach verlieren der Verbindung oder manuelles beenden der VPN Strecke bleibt mein Webserver und Fhem erhalten.

Bei mir funktioniert es nach einem VPN Verbindungsabbruch ebenfalls korrekt. Meine Vermutung ist, dass die Verbindung vom VPN Gateway zu Fronthem nicht sauber getrennt wird. Ich hatte vor Urzeiten so etwas in der Art schon mal mit einem openVPN beim Kunden.

/Uli

[herrmannj]

passt bei mir auch.

Ist doch aber schön wenn es bei bgewehr anders ist (nicht falsch verstehen) weil: ich möchte ja das fronthem tolerant gegen äußere Fehler ist. "Normal" sollte da ja nichts mehr sein, wenn doch und vlt sogar im log was steht (sprich ich die Ursache verstehe) kann ichs bekämpfen.

Macht fronthem also robuster, ergo ist gut.

vg
jörg

[Morluktom]

Hallo,

ich denke ich habe in 31_fronthemDevice.pm einen Fehler entdeckt:

falsch: (Zeile 465)

Code Auswählen Erweitern

   
$set =~ s/^state// if ($param->{reading} eq 'state');


richtig:

Code Auswählen Erweitern

   
$set =~ s/^state// if ($set eq 'state');


Hintergrund: ich will von einem beliebigen Reading lesen, aber auf ein state schreiben.

[dev0]

Dem kann ich zustimmen. Diese Änderung hatte ich vor längerer Zeit auch schon mal angeregt. Läuft bei mir seit dem ohne Probleme...

[karl0123]

Ich kann auch zustimmen. Der Fehler wurde schon mehrfach gemeldet. Eine Lösung aber für das große fronthem update Ende 2015 versprochen...

[herrmannj]

Ich kann auch zustimmen. Der Fehler wurde schon mehrfach gemeldet. Eine Lösung aber für das große fronthem update Ende 2015 versprochen...

ist wie beim BER 

Ich glaube ich kann das halbwegs nachvollziehen. @dev0: 2 Jahre kann man als ausreichend getestet ansehen. Wenn Du einen patch ins GIT stellst merge ich den.

[dev0]

Done. Ich hoffe nur, dass es keine/wenige Probeme mit den Anwendern gibt, die sich einen Workaround gebaut haben....

[herrmannj]

Dankeschön. Übernommen.