Charting Frontend und neues Modul DbUtils

[Johannes]

Hallo zusammen,

Ich würde demnächst gerne meinen aktuellen Stand zum Charting Frontend ins FHEM Development SVN stellen.
Ich habe dazu einige Fragen und möchte vorm Commiten einige Dinge lieber abgeklärt haben :-)

1.) Zu dem Frontend habe ich ein Perlmodul geschrieben, dass mir aus einer mittels DbLog angelegten Datenbank Werte ausliest und im JSON-Format ausgibt.
    Ich bin absoluter Perl Anfänger und würde jemanden, der Zeit und Lust hat, bitten, über das Modul drüber zu schauen und Feedback zu geben, denn ich möchte keinen totalen Mist einchecken :-)
    Das Modul kann hier eingesehen werden: https://github.com/w3stbam/FHEM_Frontend/blob/master/perlmodules/99_DbUtils.pm
    Ich werde das Modul noch entsprechend mit Doku versehen, so wie das bei den anderen Modulen der Fall ist.
    Die JSON Ausgabe erfolgt übrigens "per Hand", da der Aufwand dazu sehr überschaubar war und ich nicht neue Abhängigkeiten zu anderen Modulen einbringen wollte.

2.) Muss ich Zwecks Dokumentation noch etwas beachten? Reicht es aus, in dem Perlmodul die Doku unten anzuhängen?

3.) Die Neuerstellung der Commandref übernimmt jemand anderes, oder wäre ich dann dafür zuständig? Wenn ich, wie läuft das?

4.) Gehört das Modul ins SVN eher unter FHEM oder eher unter contrib?

5.) Sollte ich die Namengebung anpassen (99_DbUtils.pm) auf etwas sinnvolleres?

Sorry für die vielen Fragen, aber lieber vorher abgeklärt als nachher geärgert :-)
Besten Dank schonmal!
Johannes

[rudolfkoenig]

2.) Ja
3.) Bitte mit "perl contrib/commandref_join.pl" die Dateien docs/commandref.html und docs/commandref_DE.html erzeugen, und diese mit dem Browser pruefen, bevor die Doku eingecheckt wird.
4.) Falls es dokumentiert, gewartet und hier im Forum betreut wird, dann kann es nach FHEM, damit wird es automatisch mit update verteilt.
5.) Unbedingt, insb. kommt 99_ nicht mehr in Frage.

[Johannes]

Besten Dank schonmal, Jetzt bräucht ich nur noch Feedback zu Punkt 1, falls sich jemand dazu berufen fühlt..

Achja, zu Punkt 5.) Name und Zahl ist frei wählbar, solange noch ein Platz frei ist, oder wie sind die Vorgaben?

Grüße!

[Tobias]

ich hätte es besser gefunden wenn diese funktionlität ins dblog-Modul wandert.
Kannst du es besser da einbauen?
Am besten in eine sub-function dein Code legen und in der get function den parameter <outfile> auswerten und deine subfunction aufrufen.
Schick mir nen Patch gegen das aktuelle svn-dblog-modul, dann baue ich es ein und checke es ein.

IMHO gehört es da rein, sollte nix eigenes werden. Schon im sinne der übersichtlichkeit

[Markus Bloch]

Da muss ich zustimmen.

[rudolfkoenig]

>  Achja, zu Punkt 5.) Name und Zahl ist frei wählbar, solange noch ein Platz frei ist, oder wie sind die Vorgaben?

Falls es nicht ins Dblog Modul aufgenommen wird: da dieses Modul nur fuer das Charting Frontend da ist, sollte es also auch entsprechend benannt werden, DbUtils ist irrefuehrend. Als Zahl waere irgendetwas zwischen 91 und 98 sinnvoll, hier tummeln sich auch die anderen Hilfsfunktionen.

In beiden Faellen sollte die Doku fuer das Charting-Frontend in einem separaten Datei (docs/ChartingFrontend.pod) stehen.

[Johannes]

ich hätte es besser gefunden wenn diese funktionlität ins dblog-Modul wandert.
Kannst du es besser da einbauen?
Am besten in eine sub-function dein Code legen und in der get function den parameter <outfile> auswerten und deine subfunction aufrufen.
Schick mir nen Patch gegen das aktuelle svn-dblog-modul, dann baue ich es ein und checke es ein.

IMHO gehört es da rein, sollte nix eigenes werden. Schon im sinne der übersichtlichkeit

So hatte ich das zu Anfangs auch vor, habe mich dann aber dagegen entschieden, aus folgenden Gründen:
Ich wollte nicht meine ersten Perl Gehversuche in einem bestehenden Modul starten.
Mein Modul ist ausschließlich für das Charting Frontend zuständig und verwendet eigene / andere / zusätzliche Parameter beim Aufruf.
Das gesamte Errorhandling wird als JSON zurück an den aufrufenden Client gegeben, und das soll auch so bleiben.

Ich kann natürlich trotzdem eine Migration versuchen, allerdings wird dann das Modul sicherlich etwas durcheinander, da ein Teil Plain Ausgaben macht, ein anderer JSON liefert und die Funktionalität doch recht unterschiedliche Aufgaben erledigt. Ich will mich aber auch nicht dagegen sperren, wenn das die Merheit so sieht, dass es in ein Modul fließen soll, auch wenn es mir nur teilweise zusagt.

[rudolfkoenig]

Habe FHEMWEB so geaendert, dass ab www beliebige Dateien ausgeliefert werden koennen, d.h. um www/images/default/fhemicon.png zu bekommen kann man auch http://fhemhost:8083/fhem/images/default/fhemicon.png spezifizieren.

Ziel: das Charting Frontend sollte alle benoetigten Dateien in einem Verzeichnis einchecken und ausliefern koennen.

Nebeneffekte sollte keine geben, da es nach der Pruefung der vorherigen Pfade eingebaut ist.

[Johannes]

Super besten Dank, das erleichtert und vereinfacht doch die Sache etwas. Das ist denke ich so auch besser nachvollziehbar für andere.
Grüße!

[Johannes]

ich hätte es besser gefunden wenn diese funktionlität ins dblog-Modul wandert.
Kannst du es besser da einbauen?
Am besten in eine sub-function dein Code legen und in der get function den parameter <outfile> auswerten und deine subfunction aufrufen.
Schick mir nen Patch gegen das aktuelle svn-dblog-modul, dann baue ich es ein und checke es ein.

IMHO gehört es da rein, sollte nix eigenes werden. Schon im sinne der übersichtlichkeit

Hallo Tobias,

Ich habe meinen Code nun ins DbLog Modul portiert. Wie vorgeschlagen prüfe ich auf den outfile Parameter und biege auf meine eigene sub ab (Zeile 472 f).
Ich habe die Dokumentation auf englisch und deutsch erweitert und einen build davon gemacht, geprüft und für gut befunden.
Auch das Modul habe ich so einwandfrei im Einsatz getestet und keine Probleme.

Das Patchfile fällt etwas größer aus, da meine IDE gleich mal noch TABs und Spaces vereinheitlicht hat.

Eine Rückmeldung, wenn du es geprüft und eingecheckt hast, wäre super.
Danke,
Johannes

[Tobias]

Hi,
patch habe ich bei mir erstmal eingespielt. KEine Fehlermeldungen ;)
Muss allerdings noch alles wieder in UTF8 umwandeln, kein Problem. Da ich die Webcharts nicht kenne, falls es ein Modul ist sollte die Doku in der commandref auch noch auf dieses Modul im Text verweisen.
Ich zumindest kann mir unter webcharts (noch) nicht viel vorstellen.

Ich lasse es bei mir noch einige Tage laufen und dann checke ich es ein.
Für alle anderen im Anhang das komplette Modul zum testen.
Bitte zeitnah Rückmeldung ;)

[Johannes]

Hi,

Das mit UTF-8 wundert mich, mein System, die IDE, der oben angehängte Patch ist alles in UTF-8. Gute Frage wo das her kommt.
Zu den restlichen Dingen: Ich werde für das Charting Frontend noch eine eigene Dokumentation schreiben, weiss aber noch nicht wie die aussehen wird (Wiki Eintrag, Foreneintrag, falls dieser dann auch editiert werden kann, readme,....).
Sobald das klar ist werde ich auch wieder die Modul Doku aktualisieren und darauf verweisen.

Da ich in Zukunft an diesem Modul noch öfters arbeiten werde, frage ich kurz nach, ob du ein Problem damit hast, wenn ich mich selbst ums einchecken kümmere?
Die Änderungen werden nur meine Subs und die Doku betreffen.

Danke schonmal!

[Johannes]

@Tobias: Wie schaut es aus? Ich hätte bereits das nächste Update in den Startlöchern...

[Tobias]

ich wollte es am we machen, bin leider nicht dazu gekommen ....
Wenn du noch weiter dran entwickelst möchte ich es eigentlich nicht per update verteilen. Das modul sollte hier per forumsanhang erstmal ausgiebig getestet werden sodass nur eine stable-version verteilt wird.

Auch wenn man per updatefhem eine development-version installiert, viele haben damit eine produktivinstanz am laufen..

[Johannes]

Hallo Tobias,

Ich würde dafür gerne eine Lösung finden. Da das Frontend noch eine Weile in Entwicklung sein wird, wird zwangsweise auch das Modul häufiger geupdated werden müssen.
Das ganze als eigenes Modul zu betreiben wurde mir ja ausgeredet... :-)

Alle Änderungen, die von mir in das Modul einfließen werden, finden in meinen eigenen Subs statt.
Sprich, der einzige Change im ursprünglichen Code, der ja jetzt schon drin ist, ist die Auswertung des Übergabeparameters und das Weiterleiten an eigene Subs.
Probleme können also nur in meinen SUbs auftreten, wenn das Modul konkret mit dem Parameter für das Charting aufgerufen wird

Das das eigentlich DbLog durch meine Subs gestört wird, ist zwar nicht unmöglich, aber doch unwahrscheinlich, da ich die bisherige Logik und Funktionen unberührt lasse.
Natürlich teste auch ich meine Änderungen, aber wenn mal ein Bug durchgeht, so ist es doch wahrscheinlich, dass der meine eigenen Subs betrifft, oder nicht?

Meinungen dazu?

[Tobias]

Ich habe die aktuelle Version ins svn gestellt.
Meinetwegen kannst du Änderungen für webcharts selbst ins svn stellen.
Trotzdem meine Bitte, sicherlich im Einklang mit Rudi:
- Bitte erst ausgiebig testen durch verteilung hier im Forum. Auf Rückmeldung warten ;)
- Falls Bugs drin sind: erst diese ausmerzen bevor neue Funktionalität hinzukommt

Ich habs am Anfang auch falsch gemacht und vorher nicht ausgiebig getestet. Ich bin eines besseren belehrt worden und bin da jetzt stärker sensibilisiert.
Diese Regeln gelten auch bei eigenen Modulen ;)

PS: DbLog ist auch ursprünglich nicht "mein" Modul. Boris hats erstellt, ich aber erweitert, für die Welt chick gemacht und den Support übernommen.
Habe auch noch Erweiterungsideen (zb. Aggregate erstellen für historische Daten um das Datenvolumen zu verringern), momentan aber wenig Zeit, außerdem ist da kein Druck drauf.... funktioniert ja supi

[Johannes]

Alles klar, so machen wirs. Danke fürs Einchecken,
Johannes