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

[Joker]

die richtigen Schritte, auch zur Diagnose. Wenn es dann nicht geht liegts am vpn, der braucht den 2121 offen. Von Routern kenne ich es das sie mit dem ws niicht  können (vmtl irgendeine Form von shaping). Der vpn an einer fb7390 funktioniert in der beschriebenen Konstellation...

Sorry, kann Dir grad nicht folgen... welche Schritte? Wie, wenn es "dann" nicht geht?
Meine Fritzbox ist übrigens eine 7390.

[herrmannj]

Logs aus dem Treiber nach fronthem schicken ist eine gute Idee. Ich könnte console.log abfangen und alles was da kommt zu fronthem schicken, dann könnte man das dort nachlesen.

ok, dann baue ich das ein. Zeitmessung auch ?

Temp-Verzeichnis löschen. Da sehe ich nicht, warum das über fronthem laufen sollte. Ich schalte in SV den cache ab und will das temp verzeichnis automatisch leer haben. Das ist doch etwas, das rein SV intern ablaufen kann / soll.

das "via fronthem" ist ein wenig davon getrieben das ich die Einstellungen (bei mir) eigentlich komplett raus nehme. Wozu auch, die Tab sollen an der Wand hängen und laufen, da muss man ja nicht ständig was umstellen - im Gegenteil: stört mich eher. Deine Argumentation ist aber absolut schlüssig, da bin ich dann gefragt weil es das config system betrifft. Wenn der cache abgeschaltet wird einmal ein "rm -R *" ausführen. Baue ich ein.

Zum Thema "widgets einbinden":
Zurück zu meinem widgets use-case von oben. Für mich ist es eigentlich OK, wie es ist, aber schön wäre, wenn man die bilder und widgets aus unserem repo einfach irgendwo auschecken könnte und sie dann wie die internen verwenden könnte. Nur sehe ich den richtigen Weg zur Erfüllung dessen noch nicht so recht.

Ja genau. Nimm dei uzsu. Der js muss in die visu.js kopiert werden. So richtig automatisch wird schwer - zumal das beim nächsten widget dann wieder anders ist...

vg
jörg

[HCS]

ok, dann baue ich das ein. Zeitmessung auch ?

Halt halt. Lass uns erst klären, was wo wie.

Ich bereite es im Treiber gerade vor.
Wahlweise könnte ich so etwas (analog zu monitor, series) liefern:

Code Auswählen Erweitern

{
  "cmd": "info",
  "type": "console.log",
  "data": "[io.fhem]: run (readyState=0)"
}
type könnte sein: "console.log" / "exception" / "timing")

oder so etwas:

Code Auswählen Erweitern

{
  "cmd": "info",
   "severity": "info",
  "data": "[io.fhem]: run (readyState=0)"
}
severity könnte sein: "info" / "warning" / "error"

Was findest Du besser?

Würde fronthem das dann irgendwo in ein logfile wegschreiben und einen Viewer für das log anbieten, oder wie ist Dein Plan?

Nachtrag: evtl. sollten wir das Protokoll zwischen fronthem und dem Treiber noch erweitern. Da es im "Normalbetrieb" keinen Sinn macht, ständig log-Infos an fronthem zu schicken, sollte man es irgendwo konfigurieren können. Nach Deiner Devise "das Tablet an der Wand rühre ich nicht an" wäre das dann eine Einstellung (attribut enableLogging)im fronthemdevice.
fronthem könnte direkt nachdem die ws connection aufgebaut wurde und bei Änderung der Einstellungen (da kommen bestimmt noch weitere) so etwas an den Treiber schicken, dass er weiß, wass er tun soll:

Code Auswählen Erweitern


{
  "cmd": "settings",
  "data": [
    {
     "setting": "enableLogging",
      "value": "true"
     },
    {
     "setting": "measureTimes",
      "value": "true"
     }
  ]
}


[herrmannj]

Hi,

naja, Idee wäre den bestehenden GAD mechanismus dafür zu nehmen und auf alle GAD die mit "internal." (meinetwgen system.* whatever) anfangen als reserved zu betrachten.

Dann zb internal.log.info (.warning, .error ... ) die Meldungen drauf und ich zieh die im fronthem device aus der message Verarbeitung. Danach kann ich die ins log schreiben (abhängig von verbose). Extra anzeigen (so als reading oder so) würde ich eher nicht - die Meldungen sind ja flüchtig. Evtl könnte ich noch events draus machen, dann würde man die im eventmonitor sehhen können, finde ich aber inkonsistent zu der Art wiie das sonst in fhem läuft, system-log würde ich als den richtigen Platz sehen.

Möglich wäre auch das fronthem auf einem GAD (internal.verbose) das fhem verbose an den driver schickt - dann brauchen nur msg losgetreten werden die im loglevel höher sind. (soart traffic sc-> fhem)

Da könnte ich mir auch gut vorstellen das die GAD Zeiten mit gesendet werden um das immer wieder mal fühlbare Mess-Problem zu lösen. Könnte man vielleicht so lösen das der driver eine Durchschnitt führt und 50ms (100??? whatever) nach dem das letzte GAD gekommen ist wird das per "internal.performance.gad" an fhem geschickt - entweder log oder Anzeige.

Das mit den internal GAD hat auch noch einen zweiten Bereich: ich hab einen POC gebaut wo sv via native App auf mobil device geladen wird und Sonderfunktionen wie geo-location, tts, battery, display Helligkeit auch ohne explizit einegerichtete GAD transportiert werden müssen. Da würde die App (zukunft) selber ein GAD erzeugen (internal.app.battery) und zB den Batterieladezustand an fronthem melden.

Im Prinzip isses Wurscht, wir können auch weitere cmds (cmd setting) einführen, bräuchten wir aber mMn nicht wenn wir internal.* dafür deklarieren. Das hätte mMn auch den Vorteil das man die bei Bedarf auch besser in sv integrieren könnte. Beispiel: log Anzeige als widget. Muss man nicht - könnte man dann aber.

vg
jörg

[HCS]

Ich würde das lieber von einander trennen (GADs für Daten und sonstige Kommunikation zwischen fronthem und Treiber). Sonst kämpft man mit GADs, die man irgendwo wegfiltern muss, weil man sie da nicht berücksichtigen darf usw.
Wenn wir es trennen, dann besteht weniger Gefahr, dass es Seiteneffekte gibt.
Es würde auch generel so nicht funktionieren, monitor frägt ja nur mit den Namen der GADs an, gibt aber keine Werte dazu.
Um Werte an fronthem zu schicken, benötigen wir ein Format.

Hier die Beispiele zu Deinen Punkten. Diese Struktur wäre auch aufwärtskompatibel erweiterbar.

Code Auswählen Erweitern

{
  "cmd": "info",
  "type": "battery",
  "data": "80%"
}

{
  "cmd": "info",
  "type": "console.log",
  "data": "[io.fhem]: run (readyState=0)"
}

{
  "cmd": "info",
  "type": "exception",
  "data": "nu isses futsch in visu.js Zeile 12 einhalb"
}

{
  "cmd": "info",
  "type": "performance",
  "data": "Average GAD Update time: 12.4ms"
}

Die Gegenrichtung (fronthem -> Treiber) entsprechend erweitert:

Code Auswählen Erweitern

{
  "cmd": "settings",
  "data": [
    {
     "setting": "enableLogging",
      "value": "true"
     },
    {
     "setting": "measureTimes",
      "value": "true"
     }
    {
     "setting": "display",
      "value": "15%"
     }
     {
     "setting": "tts",
     "value": "Guten Morgen Jörg"
     }

  ]
}

[herrmannj]

na, da versuche ich Dich noch zu überzeugen

bisher haben wir ja auch GADs die ungefragt geliefert werden - und die keine Probleme machen. Überschneidungen (unschärfe ) habe wir zum Beispiel bei solchen Konstellation:

display Helligkeit, wäre schöön die via fhem programatisch anpassen zu können -> intern. ABER: wäre ja auch nett zwei Tasten dafür auf der Oberfläche zu haben -> normales GAD verhalten.

Lautsärke: dito, Wecker gesteuert über fhem wird langsam lauter (oder Abends sleep, you name it) - Tasten auf der Oberfläche: würden da gut passen.

Im Augenblick filtern wir doch auch ohne Nebenwirkungen ... ich hätte da jetzt keine Bedenken und argumentiere dass das besser skaliert einen namespace in dual use zu nehmen. Wer weiß was später noch dazu kommt. So würde man einen fiilter auf internal.* legen (haben wir ja schon) schauen ob die Funktion implementiert ist  - sonst einfach an sv weiterreichen und sv verwirft die sowieso wenn unbekannt.

Das würde zukünftig auch ermöglichen einfach ein plugin auf fronthem zu legen um zB hardware spezifische Funktionen abzubilden ohne das Protokoll dafür anfassen zu müssen.  Auf der frontend Seite könnte ich die Funtionen (zB screen) in der App abbilden ohne den driver dazu anfassen zu müssen oder, schlimmer noch, unterschiedliche driver brauche abhängig davon ob sv in einem container läuft der brightness unterstützt oder nicht.

vg
jörg

[HCS]

schlimmer noch, unterschiedliche driver brauche abhängig davon ob sv in einem container läuft der brightness unterstützt oder nicht.

Warum unterschiedliche driver? Der io_fhem wird es können, spielt doch keine Rolle, ob es dann in einem Container verwendet wird oder nicht.

bisher haben wir ja auch GADs die ungefragt geliefert werden - und die keine Probleme machen.

Der Treiber frägt momentan eine Liste von GADs an, für die er Daten benötigt. Aber nur die Namen. Bisher gibt es nichts, das Werte von GADs an fronthem liefern würde oder könnte.

Kannst Du mal für ein konkretes Beispiel so wie ich oben die Kommunikation zw. fronthem und Treiber aufschreiben, mit konkreten JSONs, die hin und her gehen, vielleich verstehe ich dann, wie Du Dir das vorstellst.

[herrmannj]

Warum unterschiedliche driver? Der io_fhem wird es können, spielt doch keine Rolle, ob es dann in einem Container verwendet wird oder nicht.

Ja, hier ist der springende Punkt. Die Funktion "verstelle mal die lautstärke" wird vom container bereitgestellt. Im Falle von cordova lautet das " media.setVolume". Jetzt müsste der driver diese Funktion also selber unterstützen (aufrufen) und wenn es nicht cordova ist oder andere Funktionen bereitgestellt werden dann das auch - anders ..

Woher soll der driver jetzt aber wissen ob der host (container) das unterstützt, wenn ja welche Variante, abgestuft auf platformen (IOS, Android etc.)

Wenn es aber als GAD normal "durchgereicht" wird kann ich in dem container ein widget "faken". So isses jetzt ja auch - der driver weiß nichts um die Funktion des widgets. Der kennt den Namen und wenn was reinkommt gibt er das dort ab, aus die Maus.

Will sagen: der driver muss sich im Zweifel dann nicht damit beschäftigen was das GAD kann, bewirkt etc - er reicht das transparent durch. Lediglich im Fall der logs und evtl der zeitmessung muss er selber intelligenz erbringen. Wobei er das nicht müsste, ein Stück javascript in der root (was nach aussen als widget mit "update" auftritt, aber eben keinerlei gui hat)  könnte das ja genauso erledigen. Das meine ich auch mit skalierbarkeit - alles was sich wie ein widget verhält kann beliebige Funktionen übernehmen. Die Konvention naming "internal.*" stellt nur sicher das man keine eigenen GAD definiert - weil auf der anderen Seite fronthem lauscht und wenn was mit dem namen "internal.log.info" reinkommt wird aus dem normalen flow rausgekommen und in das log geschrieben.

Besser verständlich ?

[HCS]

Besser verständlich ?

Nö. Kannst Du nicht einfach mal ein Beispiel aufschreiben, was der Treiber tun sollte, wenn er z.B. einen console.log loswerden will, oder wenn er eine exception gefangen hat und sie an fronthem loswerden will, oder wenn er Ergebnisse für eine Zeitmessung hat, die er loswerden will.
Und, woher er weiß, dass er logs, Zeitmessung usw. schicken soll.

[vbs]

Zu Teil 2,
- widgets (repo) einbinden: ja, nützlich !
- geht mit dem patch nicht einfacher als out-of-the box.

Hm ok. Sorry, ich muss gestehen, dass ich jetzt etwas auf dem Schlauch stehe. Um es einfach zu halten: Könntest du mal kurz sagen, wie ich ein Widget-HTML-Template einbinden könnte, wenn es in einem
Unterverzeichnis von SV liegt (zB "smartVISU/smartvisu-widgets/homematic/homematic.html")? Ich habe deine bisherigen Beispiele so verstanden, dass es da um Widgets im pages- bzw. widgets-Ordner ging. Vielleicht kenne ich da einfach irgendwelche twig-Kniffe nicht und bin daher in der falschen Richtung unterwegs.

Zurück zu meinem widgets use-case von oben. Für mich ist es eigentlich OK, wie es ist, aber schön wäre, wenn man die bilder und widgets aus unserem repo einfach irgendwo auschecken könnte und sie dann wie die internen verwenden könnte. Nur sehe ich den richtigen Weg zur Erfüllung dessen noch nicht so recht.

Könntest du sagen, was dich an dem Patch konkret stört? Bzw. könntest du sagen, was deine Anforderungen an so einen Mechanismus wären, die noch nicht erfüllt sind bzw. nicht hinreichend erfüllt sind? Vielleicht kann ich da noch etwas nachbessern.


Falls ihr gerade andere Sachen im Kopf habt, dann könnte ich mich auch in einen separaten Thread zu dem Thema verkrümeln oder wir verschieben die Diskussion...

[HCS]

Könntest du sagen, was dich an dem Patch konkret stört? Bzw. könntest du sagen, was deine Anforderungen an so einen Mechanismus wären, die noch nicht erfüllt sind bzw. nicht hinreichend erfüllt sind? Vielleicht kann ich da noch etwas nachbessern.

Die Änderung an SV. Ich hatte es ja für sinnvoll gehalten, Erweiterungen, die allegemein und nicht nur für uns hier Sinn machen, bei den SV-Leuten reinzubringen.
Ich habe irgendwie etwas Bedenken, ob wir in Salami-Taktik dann doch irgendwie ein spezielles Spezial-SV basteln und beim nächsten SV-Update Probleme bekommen.

Was mir nicht gefällt ist die erforderliche Unterscheidung von user-Bildern und SV-Bildern. Ich fände etwas wie einen Suchpfad, erst user, dann SV eigentlich schöner, da man dann bei der Definition auf den pages das nicht bestimmen muss.
Die erforderlichen css-Schnipsel, die verschieden Widgets benötigen, wäre auch noch ein offener Punkt.

Ich habe mich aber auch nicht extrem detailliert mit Deinem Patch auseinandergesetzt sondern wollte eher meine allgemeinen Gedanken zu dem Thema wiedergeben.
So richtig dagegen bin ich nicht, eher unschlüssig 

[herrmannj]

Nö. Kannst Du nicht einfach mal ein Beispiel aufschreiben, was der Treiber tun sollte, wenn er z.B. einen console.log loswerden will, oder wenn er eine exception gefangen hat und sie an fronthem loswerden will, oder wenn er Ergebnisse für eine Zeitmessung hat, die er loswerden will.
Und, woher er weiß, dass er logs, Zeitmessung usw. schicken soll.

Ja, mach ich

[herrmannj]

Ja, mach ich

Aktennotiz an mich: nicht immer die Klappe auf reisen!

Offizielles Protokoll:

damit das auch so funktioniert wie ich gesagt habe (uneingeschränkt skaliert) braucht es "körperlose" widgets. Ich hatte das um einige Stunden Arbeit unterschätzt habe jetzt aber ein Erfolg versprechendes Konzept gefunden. Ich teste da morgen noch weiter, sieht aber gut aus soweit.

vg
jörg

[HCS]

damit das auch so funktioniert wie ich gesagt habe (uneingeschränkt skaliert) braucht es "körperlose" widgets. Ich hatte das um einige Stunden Arbeit unterschätzt habe jetzt aber ein Erfolg versprechendes Konzept gefunden. Ich teste da morgen noch weiter, sieht aber gut aus soweit.

Es sind ja zwei use cases:
1. Lautstärke, Helligkeit, Sprachausgabe usw.
2. Logging, Exceptions, Zeitmessung.

Zumindest 2. würde ich nicht in einem Widget abhandeln. Ich glaube nicht, dass ich irgendwo in der Page ein widget vergraben haben möchte, das exceptions global wegfängt. Loggen kann es auch nur, wenn es irgendwie erst mal zum Leben erweckt wurde. Alles, was bis da hin nicht klappt, kann nur der Treiber berichten. Infos, z.B. wie viele GADs gefunden wurden, was bei fronthem angefragt wird usw. weiß auch nur der Treiber. Und die Zeitmessung kann auch nur der Treiber machen.
Oder anders formuliert: der Treiber weiß, was er macht und was im System vor sich geht. Ein widget hat keine Ahnung, was der Treiber macht oder nicht machen konnte.

Der Treiber ist der Chef im (widget update)-System, der darf die Überwachung auf Fehlverhalten nicht seinen Untergebenen überlassen.


Was mir auf fronthem-Seite gut gefallen würde:
Ein Attribut im fronthem device, in dem man festlegen kann, ob und wie dieses device berichten soll (Nichts, log, Zeitmessung usw.).
Für jedes fronthem device wird ein logfile geschrieben, mit dem Namen des device, in dem alles, was von diesem device als log gesendet wird, einfach Zeile für Zeile reinläuft.
Einen "Log anzeigen" button beim fronthem device, um das log anzusehen

[herrmannj]

Der Treiber ist der Chef im (widget update)-System, der darf die Überwachung auf Fehlverhalten nicht seinen Untergebenen überlassen.

Absolut check!

Der Punkt ist das beide, driver oder page-widget, es *könnten*. Log und time gehören, Du sagst es, systematisch in den driver. Kein Zweifel!

Ein Attribut im fronthem device, in dem man festlegen kann, ob und wie dieses device berichten soll (Nichts, log, Zeitmessung usw.).

Absolut! passt!

Für jedes fronthem device wird ein logfile geschrieben, mit dem Namen des device, in dem alles, was von diesem device als log gesendet wird, einfach Zeile für Zeile reinläuft.

hmm, ... im Augenblick laufen alle Systemmeldungen (error, debug) im Systemlog auf. Die devicelogs sind ja (fhem-style) eher für Messwerte zuständig. Ist aber nur eine nachgelagerte Formalie - beides geht.

vg
Jörg