Hallo zusammen,
ich habe an meinem Modul YAMAHA_AVR bei mir privat ein Attribut "model" erzeugt, indem der Modell-Name meines Receivers beinhaltet ist. In fheminfo ist dieser Wert auch gelistet und wird erfolgreich an fhem.de übertragen.
Dennoch wird er in der Statistik nicht angezeigt, obwohl er schon seit mehreren Tagen dort enthalten ist und auch schon durch mehrfache FHEM updates mit übertragen wurde.
Der Wert wird in YAMAHA_AVR wie folgt gefüllt, sobald die Modellbezeichnung abgefragt wird:
$attr{$name}{"model"} = $hash->{MODEL};
Muss ich noch etwas besonderes beachten, damit dieser Wert in der Statistik auftaucht?
Vielen Dank
Gruß
Markus
ich glaube das liegt daran, dass die Statistiken aktuell nicht verarbeitet werden:
1169 survey submissions until 2013-12-19
Ueber welche Statistiken reden wir? Di manuelle, wo ich die Eintraege selbst kontrolliere, und alle zwei Wochen oder so auf fhem.de hochlade, oder das automatische, was taeglich einmal berechnet und hochgeladen wird? Beim ersteren gibt es kein "model", und die Liste der Module muss ich manuell in contrib/survey.pl Pflegen. Das automatische steckt in contrib/statistics, ist urspruenglich von Martin, wird z.Zt. mehr schlecht als recht und kommissarich von mir betreut. Wenn jemand da Bugs eliminiert, bitte melden, ich check das gerne ein.
Hallo Rudi,
ich rede von der automatischen Statistik, welche durch Martin erstellt wurde und sich selbst aktualisiert.
Genau wie Loredo habe ich den Eindruck, dass sich die Statistik nicht mehr aktualisiert, bzw. regelmäßig generiert wird.
Woran das liegt, kann ich natürlich nicht sagen, daher wollte ich fragen, ob du etwas genaueres weist.
Gruß
Markus
Ich habe die automatische Erstellung manuell angestossen: es funktioniert, da es von 5446 auf 5469 gesrpungen ist. Details bitte selbst debuggen, das ist fuer mich genauso fremd, wie fuer euch.
Vielen Dank, jetzt ist mein Model auch sichtbar. Kann es sein, dass der automatische Start des Skriptes nicht mehr funktioniert (cron, at, ...)?
Leider kann ich das selber nicht prüfen, da es dein Server ist ;-)
Viele Grüße
Markus
ZitatKann es sein, dass der automatische Start des Skriptes nicht mehr funktioniert (cron, at, ...)?
Nein, heute steht der Zaehler bei 5485, ohne manuellen Eingriff, pruefen kann das jeder: http://fhem.de/stats/statistics.html
Und falls jemand ernsthaft die Statistik debuggen/erweitern will, kann ich auch mit der DB dienen.
Ich würde mich gerne mal mit den statistiken befassen ...
- ich würde gerne die farbigen Balken in den regioncharts unten links wieder sichtbar machen
- die Module eventTypes und dummy aus den Statistiken rauslassen
- man könnte überlegen, das ohnehin schon vorhandene, aber bisher unberücksichtigte Feld "lastseen" auszuwerten, um die Statistik beispielsweise nur über Installationen zu fahren, die sich innerhalb der letzten 12 Monate einmal per fheminfo gemeldet haben
- usw.
Um das Ganze zu testen, würde ich gerne auf das Angebot mit der Datenbank zurückkommen :)
ich würde mich freuen, wenn die Models nochmal nach Modul unterteilt werden. das ist aktuell ein heilloses durcheinander.
Ich sammle gerne mal neue Features, aber primär geht es mir erstmal darum, das Bestehende zu bereinigen.
ZitatUm das Ganze zu testen, würde ich gerne auf das Angebot mit der Datenbank zurückkommen
Kommt per PM, ca 4mb komprimiert.
Du kannst sie mir auch irgendwo zum download ablegen. Wir haben ja immerhin einen gemeinsam genutzten Server :)
ZitatWir haben ja immerhin einen gemeinsam genutzten Server.
Jetzt, wo du es sagst...
Habe gerade die Tabellenstruktur zum ersten mal angeschaut, und ich wuerde es instinktiv ueberarbeiten, 960 Spalten ist irgendwie nicht so mein Ding. Immerhin kann sqlite per default 2000 pro Tabelle, d.h. wir haben noch etwas Zeit :)
Meine Güte ist das ein Krampf... aber zumindest die farbigen Balken in der Legende habe ich inzwischen wiedergefunden 8)
(http://up.picr.de/21313803ps.jpg)
@Rudi: Die base Zeile auskommentieren (oder löschen), dann sollten die Farbbalken wieder auftauchen.
print start_html(
-title => 'fhem.de - Statistics',
-author => 'm_fischer@gmx.de',
# -base => 'true',
-style => {-src => $css},
-meta => {'keywords' => 'fhem houseautomation statistics'},
-script => [
Aber irgendwie hab ich noch Datenbankfehler beim Auswerten der Top10-Balken.
Das kommt dann morgen dran, damit ich anschließend weiterbasteln kann.
Hab dein Patch eingebaut, jetzt gibts ein Verlauf.
Die Erstellung dauert bei mir 2 Minuten, eine Online-Variante ist also z.Zt. auch aus diesem Grund nicht realistisch.
Ein Online-Betrieb ist m.E. auch nicht notwendig, es dürfte reichen, die Statistik einmal pro Tag zu generieren.
Die lange Verarbeitungszeit ist aber auch nicht verwunderlich, wenn man mal eben grob rechnet:
13000 submissions * 1000 Spalten = 13 Mio auszuwertende Felder
Das ganze wird bisher mindestens vier mal durchlaufen und dabei wird gezählt und aufsummiert. Zwischendurch müssen auch noch für 13000 Einträge aus IP Adressen die Geodaten ermittelt werden.
Das Statistikmodul war unbestritten einmal eine gute Idee, aber ich denke, über ein solches Datenvolumen hat sich nie jemand Gedanken gemacht - und das ist jetzt ausdrücklich KEIN Vorwurf gegen irgendjemanden. Man muss einfach schauen, wie man das Ganze "zeitgemäß" lösen und verbessern kann.
Im Moment bin ich dabei, das Skript soweit zu verändern, dass es bei Verwendung der bisherigen Datenstruktur erstmal auf meiner aktuellen Plattform läuft, es scheint da derzeit auch noch Versionsabhängigkeiten von perl und/oder sqlite3 zu geben, die das aktuell verhindern.
Ausserdem will ich das Modul in die Lage versetzen, eine aktuelle Geo-Datenbank zu benutzen und nicht die bisherige, die zwei Jahre alt ist.
Sobald ich diese Punkte abgehakt habe, werde ich die statistics.cgi einchecken, dann kannst Du sie gegen die Datenbank auf Deinem Server testen.
Zitat von: betateilchen am 18 März 2015, 11:42:31
Sobald ich diese Punkte abgehakt habe, werde ich die statistics.cgi einchecken, dann kannst Du sie gegen die Datenbank auf Deinem Server testen.
https://git.fhem.de/bugzilla/show_bug.cgi?id=14
- habe zwei weitere Dateien (admin.cgi + mkpasswd.pl) eingecheckt, weiss nicht, ob sie benoetigt werden, sie lagen aber herum auf dem Server.
- habe den Zugriff auf stats/data/* untersagt, es ist mir unheimlich, wenn jeder die sqlite DB runterladen kann
- deswegen habe ich stats/data/style.css nach stats/style.css geschoben.
- bei der Verwendung von style.css war das Logo weg (das Bild ist nicht im stats Verzeichnis), deswegen habe ich erstmal wieder das alte style.css aktiviert. Es waere mir lieber, wenn statistics.html Anpassungen durch einen zusaetzlichen css (stats/style.css) erfolgen wuerden, der nur die Unterschiede zum alten enthaelt.
- habe eine aktuelle GeoLite db heruntergeladen und verwendet.
- Wie kan ich in bugzilla etwas aendern? Ich habe nur ein .ssh Zertifikat, aber kein Passwort. Muss ich mein Passwort zuruecksetzen?
Zitat von: rudolfkoenig am 22 März 2015, 14:05:51
- Wie kan ich in bugzilla etwas aendern? Ich habe nur ein .ssh Zertifikat, aber kein Passwort. Muss ich mein Passwort zuruecksetzen?
Über den "Passwort vergessen" Link ein Passwort anlegen. Das ssh Zertifikat ist für git, nicht für bugzilla.
Interessant... wenn man die Statistik nur über die Daten der letzten 12 Monate fährt, reduziert sich das Datenvolumen um fast 50%.
Und die Ergebnisse sehen - vor allem, was die Verwendung von fhem Versionen angeht - erwartungsgemäß etwas anders aus:
(http://up.picr.de/21371210uv.jpg)
Schoen waere diesen Filter einstellen zu koennen. Geht natuerlich nur, wenn es online laeuft.
Im Moment bin ich dabei, die bestehende Statistik generell auf die letzten 12 Monate zu filtern. Mit der derzeitigen Datenstruktur ist ein online-Modus jedenfalls nicht denkbar.
Im Offline-Modus könnte man natürlich einfach drei Statistiken fahren (1-Monat, 12-Monate, Ewigkeit) und diese per Link in der Navigation bereitstellen. Einem cronjob ist es egal, ob er in der Nacht eine oder drei Auswertungen erstellt. Allzuviele Filterstufen machen eh nicht sonderlich Sinn.
Wenn ich im nächsten Schritt über ein Redesign der Auswertung nachdenke, werde ich auch prüfen, ob sich ein online-Modus sinnvoll realisieren lässt. Immer schön einen Schritt nach dem anderen :)