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

cruser1800 · 15 März 2015, 13:01:16

Hallo HCS,

Deine Vermutung mit der visu.js und den Änderungen von Bernd waren richtig. Die Seiten halten mit dem letzten Fehler in der visu.js Zeile 85 an. Habe diese mal in der Anlage beigefügt. Vielleicht hast du einen Tipp.

Weiterhin erhalte ich folgende Fehler

Code Auswählen


 [io.fhem]: basic.lbutton: Handler not found io_fhem.js:128
 [io.fhem]: basic.button: Handler not found io_fhem.js:128

Aber die Sache mit den Handler habt Ihr ja schon auf dem Schirm.

Danke

herrmannj · 15 März 2015, 13:56:15

Zitatauf ein statement von Dir bezüglich charts warten

schon klar ...

Ich habe noch keine zündende Idee wie ich das aufbaue, speziell in Bezug auf den Editor.

Die series teilt sich ja in "historische" Daten (Quelle filelog, dblog) und aktuelle entstehende Daten. Sprich, ich rufe ein Temperaturplot in sv auf. Fhem bekommt den Zeitraum (minus 4h bis now), muss non-blocking die Werte aus dem filelog|dblog holen, abliefern und dann intern den mode umschalten um die aktuellen auflaufenden Messwerte "nachzuschieben" (der Plot läuft dann "mit").

Überlegung: wie finde ich eine Benutzerfreundliche Möglichkeit um im Editor die Datenauswahl darzustellen. Ich benötige eine Datenquelle aus dem Filelog|DBLog und eine Quelle für die "live daten".

Klar kann man da jetzt die große regex Schlacht anfangen. Führt dazu das der Kreis der user die damit umgehen können eher begrenzt ist (vorsichtig formuliert) - was schlussendlich hier den support Aufwand beträchtlich erhöht (und bei denen bei vielen zu Frust führt).

Ergo: will nicht.

Am Ende muss der user eine option im Editor an die Hand bekommen bei der er sagt: "Temperatur von sensor x, Zeitraum, Auflösung".

Lass mal Gedankenspiel machen:

Ich wähle ein device und habe ein reading. (soweit keine thema, TODO: was machen wenn das reading state ist und die Daten dann zb so aussehen (temp,hum): "T:24 H:60")

Ich muss wissen wo die Daten stehen (logfilename). Landen sie dort immer im gleichen Format wie sie im reading stehen ? Ich habe den Namen des readings. Taugt der (ohne Ausnahme) um damit die gewünschten Daten aus dem logfile zu ziehen ? Was passiert mit dblog ? Wie geht man mit logfile um wo vom user "händisch" (also per {} ) Daten reingeschrieben werden ?

Für die GAD Editor hatte ich ursprünglich einen Standard mode geplant und einen erweiterten mode (regex). Das hat sich dann als unnötig erwiesen. Mglw ist es bei den logs (plots) aber angesagt ...

Lasst mal Ideen zusammenwerfen:

vg
jörg

bgewehr · 15 März 2015, 15:54:44

Erstmal einfach gedacht:
Wenn ich angegeben habe, wo die historischen Werte herkommen, warum sollen dann die aktuellen Werte nicht auch daher kommen? Dann reicht es jedenfalls, eine Quelle abzugreifen und zu überwachen! Die meisten Charts müssen ja nicht ereignisgesteuert aktualisiert werden, weil eine definierte Aktualität ausreichend ist (1h oder 60s oder 5s).

HCS · 15 März 2015, 16:03:55

Zitat von: cruser1800 am 15 März 2015, 13:01:16
Code Auswählen Erweitern
[io.fhem]: basic.lbutton: Handler not found io_fhem.js:128 [io.fhem]: basic.button: Handler not found io_fhem.js:128

Das mit dem basic.lbutton habe ich anlysiert. Das ist ein Widget, das gar keinen Update-handler hat. Somit kann man natürlich auh keinen aufrufen. Da sollte aber mit der letzten Treiber-Version das Laden der Seite nicht mehr anhalten, da das abgefangen ist. Steht nur als info in der Konsole.

Zitat von: herrmannj am 15 März 2015, 13:56:15
Die series teilt sich ja in "historische" Daten (Quelle filelog, dblog) und aktuelle entstehende Daten. Sprich, ich rufe ein Temperaturplot in sv auf. Fhem bekommt den Zeitraum (minus 4h bis now), muss non-blocking die Werte aus dem filelog|dblog holen, abliefern und dann intern den mode umschalten um die aktuellen auflaufenden Messwerte "nachzuschieben" (der Plot läuft dann "mit").

Das "mitlaufen" und "nachschieben" von Werten ist erst mal nicht erforderlich. fronthem bekommt ja die Anfrage, alle x Sekunden die Serie für den Zietraum von t1 bis t2 zu liefern, wobei t1 und t2 relativ sind. Das bedeutet, dass SV mit jedem update die komplette Serie bekommt. Sonst würde das Zeitfenster, das man im Chart sehen will, nicht "wandern" sondern der Startpunkt bei t1 gleich bleiben und das Chart immer länger werden. Üblicherweise will man ja aber etwas wie "die letzten zwei Stunden" sehen. Und nach 1 Minute beginnen die letzten zwei Stunden eine Minute später.
Genau auf diese Strategie habe ich das Chart momentan implementiert.

Gerade beim tippen den Beitrag von bgewehr gesehen. Meinst Du das was ich meine?

Zitat von: herrmannj am 15 März 2015, 13:56:15
Am Ende muss der user eine option im Editor an die Hand bekommen bei der er sagt: "Temperatur von sensor x, Zeitraum, Auflösung".

Zeitraum muss man in fronthem Editor nicht festlegen, der wird von SV schon mitgeschickt.

Über den Editor ansich muss ich mal nachdenken, wie so was aussehen könnte. Kann man sich da nicht an den SVG-Editor anlehnen, den können die meisten vermutlich schon.

bgewehr · 15 März 2015, 16:17:59

Zitat von: HCS am 15 März 2015, 16:03:55

Gerade beim tippen den Beitrag von bgewehr gesehen. Meinst Du das was ich meine?

Ja, genau!

Als Stufe 0 eine gute Lösung, finde ich!

{{ Chart.linechart([gad_line1, gad_line2, ...], xperiod, refreshtime) }} oder so ähnlich?

herrmannj · 15 März 2015, 16:24:58

Zitat von: bgewehr am 15 März 2015, 15:54:44
Erstmal einfach gedacht:
Wenn ich angegeben habe, wo die historischen Werte herkommen, warum sollen dann die aktuellen Werte nicht auch daher kommen? Dann reicht es jedenfalls, eine Quelle abzugreifen und zu überwachen! Die meisten Charts müssen ja nicht ereignisgesteuert aktualisiert werden, weil eine definierte Aktualität ausreichend ist (1h oder 60s oder 5s).

Ja, das hab ich auch schon mal überlegt. Ich habe nur keine systemübergreifend kompatible Möglichkeit gefunden das als in Richtung push zu implementieren. Auf linux wäre inotify das Mittel der Wahl. Das muss aber im Kernel bereits kompiliert sein und mac und win machen das wieder ganz anders. Also Anlehnung an tail, wenn ihr wisst was ich meine. Alternativ müsste ich das pollen.

Wobei die Beschreibung von HCS jetzt anders ist. Ich bin bisher davon ausgegangen das ich einen Wert "nachschiebe" und sv aktualisisert das plot. Ich vertehe Dich (HCS) jetzt so das sv im Anstand von fix (Sekunden, Minuten) bei fhem um aktualisierte Daten bitten würde. Habe ich das richtig verstanden ? Dann wäre der von Bernd vorgeschlagene Weg gut (per poll)

Wie läuft das denn wenn ich zB ein Kardiogramm (nur um ein Beispiel zu illustrieren, nicht ernsthaft

) haben möchte. Da brauch ich doch dann 30 Werte pro Sekunde. Würde sv dann 30x pro Sekunde nachfragen ?

vg
jörg

herrmannj · 15 März 2015, 16:27:31

Zitat von: bgewehr am 15 März 2015, 16:17:59
Ja, genau!

Als Stufe 0 eine gute Lösung, finde ich!

{{ Chart.linechart([gad_line1, gad_line2, ...], xperiod, refreshtime) }} oder so ähnlich?

In der doku ist doch "refreshtime" gar nicht erwähnt ? Gibts das ? Btw, wir sollten auch gleich mal im Hinterkopf haben das sich charts-widgets auch ganz easy bauen lassen und Erweiterungen mit bedenken.

vg
jörg

rudolfkoenig · 15 März 2015, 16:28:29

Koennte jemand ein schoenes Beispiel (==Bild) und ein Link zum Doku hier posten, ich wuerde gerne dieses Frontend im fhem.de "Frontend Screenshots" Abschnitt erwaehnen.

herrmannj · 15 März 2015, 16:32:53

ja gern, bei doku sind wir (glaub ich) noch ziemlich blank

edith: da könnten wir doch gleich mal einen thread "Deutschland sucht den SuperSmartVisuScreenshot" (DSDS) aufmachen

HCS · 15 März 2015, 18:09:50

Zitat von: herrmannj am 15 März 2015, 16:24:58
Wobei die Beschreibung von HCS jetzt anders ist. Ich bin bisher davon ausgegangen das ich einen Wert "nachschiebe" und sv aktualisisert das plot. Ich vertehe Dich (HCS) jetzt so das sv im Anstand von fix (Sekunden, Minuten) bei fhem um aktualisierte Daten bitten würde. Habe ich das richtig verstanden ? Dann wäre der von Bernd vorgeschlagene Weg gut (per poll)

Schau nochmal hier: http://forum.fhem.de/index.php/topic,30909.msg267334.html#msg267334
Da habe ich es mit Beispielen erläutert.

Zitat von: herrmannj am 15 März 2015, 16:24:58
Wie läuft das denn wenn ich zB ein Kardiogramm (nur um ein Beispiel zu illustrieren, nicht ernsthaft ) haben möchte. Da brauch ich doch dann 30 Werte pro Sekunde. Würde sv dann 30x pro Sekunde nachfragen ?

Nein. Das funktioniert immer sinngemäß wie "monitor" für "normale" GADs.
SV fragt einmal beim Seitenwechsel mit cmd": "series" die Charts an. Darauf hin liefert fronthem im gewünschten Intervall jeweils die komplette Serie, die dem Wunsch entspricht, solange, bis mit cmd": "series" ein neuer Wunsch geäußert wird.

Ich wage auch zu behaupten, dass man den Fall "weitere Werte hinten anhängen" so gut wie nie will (was nicht bedeutet, dass man ihn nicht auch noch irgendwann haben darf) .
Man hat eine page mit einen Chart, das einen Temperaturverlauf der letzten zwei Stunden darstellt. Mit "nur anhängen" hätte man dann morgen einen Tag und zwei Stunden im Chart und in einer Woche ... usw.
Man will aber immer die letzten zwei Stunden.

Zu den Erweiterungsmöglichkeiten: siehe meinen verlinkten Beitrag, soweit es die Konfiguration des Charts angeht.
Da wir zw. SV und fronthem ein object übergeben, ist das auch beliebig erweiterbar.
Ob wir den von SV geerbten Mode (AVG, MIN, MAX) brauchen, ist mir noch unklar, aber kannst ihn ja einfach mal ignorieren.

mele · 15 März 2015, 19:33:13

Hallo,

ich bin ein wenig weiter gekommen, wobei ich meinen Reserve-Rpi neu aufgesetzt habe, um SmartVISU zu testen.

Ich habe die Config dort hinbekommen inkl. Config meiner TestConfig über das SmartVISU-Configmenü.

Code Auswählen

update force https://raw.githubusercontent.com/herrmannj/fronthem/master/controls_fronthem.txt
habe ich auch ausgeführt inkl. Neustart.

Ich bekomme bei dem Versuch zu definieren (define meinfronthem fronthem) aber immer folgenden Log-Eintrag (Rechte auf 777):

Code Auswählen

Attempt to reload fhwebsocket.pm aborted.
Compilation failed in require at ./FHEM/01_fronthem.pm line 30.
BEGIN failed--compilation aborted at ./FHEM/01_fronthem.pm line 30.

Danach habe ich auch schon gesucht und nochmal sudo cpanm Net::WebSocket::Server ausgeführt. Ergebnis:

Code Auswählen

Net::WebSocket::Server is up to date. (0.003001)

Kann mir jemand sagen, wie ich fortfahren sollte/könnte?

Danke!!!!

herrmannj · 15 März 2015, 19:41:40

@HCS : ah ok, aber kurzer break.

Bei dem Beispiel hast Du ja schon ein customized chart - da würde ich einen kurzen step auf die eingebauten zurückgehen wollen (erst mal)

http://www.smartvisu.de/docu/2.7/index.php?page=plot/widget_plot.period

Interval ist doch (richtig?) hier die kleinste Auflösung, nicht das Aktualisierungs interval. Die driver versuchen doch Daten an bestehende plots anzuhängen. Nach meinem Verständnis sende ich initial eine Serie (geordnet über die Zeit, Auflösung min zoom size). Dann schiebe ich Daten hinterher und das plot hängt die rechts ran (und links fällt einer raus).

ZitatIch wage auch zu behaupten, dass man den Fall "weitere Werte hinten anhängen" so gut wie nie will (was nicht bedeutet, dass man ihn nicht auch noch irgendwann haben darf) .

Doch, ich schon aber vielleicht meinen wir etwas unterschiedliches. Wunsch lautet: ich hab (zB) auf meiner Seite einen plot mit temp der letzten 24h. Der läuft mit, aktualisiert sich fortlaufend.

mode: the mode: 'avg', 'sum', 'min', 'max'

Sehe ich auch, die logik müsste in fronthem liegen. Beispiel plot: tiefst- und höchsttemperaturen der letzten 30 Tage ... Bei sum bin ich mir unsicher wie ich das implementieren muss. Wozu könnte man das brauchen ? Energie, kumuliert ...

Ich hab nochmal Bernds Vorschlag weitergdacht - ich glaub das könnte funktionieren. Idee: Man gibt an um welches device/reading es sich handelt, welches logfile und wie (regex?) die Daten im logfile liegen. Fronthem öffnet das log in einem child prozess (weil evtl langsam), und liefert die Daten, file bleibt offen. Das device/reading wird überwacht (gleiche logik wie jetzt item/GAD). Wenn ein passendes event reinkommt gebe ich dem child einen ping, der liest weiter die quelle (filelog) und schickt das an fronthem, das weiter an sv. So brauch ich nicht ständig zu pollen und die Signale werden trotzdem in realtime produziert. Im Idealfall kann aus device/reading sogar abgeleitet werden WIE das im log liegt, das wäre dann schon in etwa die Art des user comforts den ich ggern sehen würde (user braucht nicht mehr rum-regexen)

Ideen? Einwände? Vorschläge? Whatever ?

vg
jörg

herrmannj · 15 März 2015, 19:53:42

Hi Mele,

fhwebsocket ist bestandteil im git. Ich vermute das bei Dir das update nicht korrekt arbeitet. Frag mich nicht warum

aber schau mal ins git und schau mal ob Du die files alle hast. fhem ist aktuell ? Wenn nein, updaten bitte läuft sonst eh nicht.

vg
jörg

cruser1800 · 15 März 2015, 20:27:56

Zitat von: HCS am 15 März 2015, 16:03:55
Das mit dem basic.lbutton habe ich anlysiert. Das ist ein Widget, das gar keinen Update-handler hat. Somit kann man natürlich auh keinen aufrufen. Da sollte aber mit der letzten Treiber-Version das Laden der Seite nicht mehr anhalten, da das abgefangen ist. Steht nur als info in der Konsole.

Danke für die Handler funktioniert es jetzt.

Ich hatte aber noch 3 andere Fehler behoben! Jetzt läuft es wieder vernünftig! Bei mir ist es aber nur mit Pagecach richtig schnell.

Bei den Fehlern wundert mich einiges. Folgende Funktionen funktionieren jetzt nicht mehr

Code Auswählen

response[0].replace(/ÃÂ¼/g, "ü")
response[0].match(/prog[123]/g)

Das mit den Umlauten ist ja glaube ich gelöst. Nur warum es nicht mehr funktioniert würde mich interessieren.

Weiterhin nimmt der Treiber jetzt fehlende Bilddateien übel. Ich hatte auf meiner Wetterseite ein Platzhalter n_Ersetzen_S.png eingefügt. Jetzt wurden meiner Bilder aber nicht mehr angezeigt. Erst als ich entsprechende Dateien im Ordner erstellt habe hat diese Seite wieder funktioniert und ich konnte den Dummi ersetzen.

Gruß Lutz

mele · 15 März 2015, 20:44:32

Zitat von: herrmannj am 15 März 2015, 19:53:42
Hi Mele,

fhwebsocket ist bestandteil im git. Ich vermute das bei Dir das update nicht korrekt arbeitet. Frag mich nicht warum aber schau mal ins git und schau mal ob Du die files alle hast. fhem ist aktuell ? Wenn nein, updaten bitte läuft sonst eh nicht.

vg
jörg

Leider keine Veränderung. Habe die Files aus dem git übernommen. Rechte 777, chmod für user fhem. Update check: nothing to do ...

Noch eine Idee?