FHEM update mit Fehler am Ende

[justme1968]

stimmen die daten wirklich?

wenn rudi zwei mal die gleichen daten von zwei unique ins geschickt hat und dann 4 mal daten aus hessen  angezeigt werden stimmt etwas nicht. oder hat noch jemand anders etwas geschickt?

[betateilchen]

Die Daten stimmen, es gibt auch Leute, die mehrere Testsysteme mit unterschiedlichen IDs haben.

Und da meine Unitymedia-IP immer zu "Pfungstadt" ausgewertet wird statt zu Mönchengladbach, sind meine Statistiksätze immer in Hessen zu finden. Ausser meinem Amazon-Server, der ist tatsächlich in Irland

[betateilchen]

Ich würde mich wie schonmal vereinbart um die grafische Umsetzung kümmern unter der Maßgabe, dass die Daten als JSON via HTTP abgerufen werden können. Darauf würde ich dann mit HTML/JavaScript aufsetzen.
...
Die Daten unter http://fhem.j65.de/stats/statistics2.cgi sind ja schon astrein zur Anzeige gedacht. Das sollte man nochmal mit der aktuellen Anzahl an Datensätzen prüfen zwecks Performance.

Hallo Markus,

Als nächstes werde ich mich um die Migration der bereits vorhandenen Daten kümmern, dann kann man auch Aussagen zur Performance treffen und entscheiden, ob es bei sqlite bleibt oder ob man eine andere Datenbank einsetzt. (ich mag DynamoDB...)

Auch die Aufbereitung in statistics2.cgi werde ich noch optimieren, da steckt im Moment einfach noch zuviel Spaghetti-Code drin, wie das eben so in Testphasen ist. Da ich in der nächsten Zeit noch mehr Bahnfahrten im Kalender stehen habe als bisher, habe ich genügend Zeit für das Weiterbauen.

Heute wurde auf besonderen Wunsch eines einzelnen Herrn auch die Verwendung des zusätzlich benötigten JSON-Moduls in fheminfo wieder ausgebaut... 

[betateilchen]

Es wäre übrigens schön, wenn mal noch ein paar Leute mehr ihre Statistikdaten schicken würden.
Das Modul 98_fheminfo2.pm in ./contrib/statistics ist aktuell.

Achtung: es muss dazu auch die aktuelle Version von fhem.pl verwendet werden!

[betateilchen]

Auch die Aufbereitung in statistics2.cgi werde ich noch optimieren, da steckt im Moment einfach noch zuviel Spaghetti-Code drin, wie das eben so in Testphasen ist.

Optimierung lohnt sich manchmal doch 

Code Auswählen Erweitern


Generation time: 0.096 seconds


(vor der Bereinigung: fast dreimal so lang)

[betateilchen]

Gedanken zur Migration der Altdaten

• Vorhandene Daten ab 01.05.2016 werden migriert, um einen vollen 12-Monats-Zeitraum für die Auswertung sicherzustellen
• Die Modell-Informationen werden nicht migriert, da diese bisher nicht sinnvoll den zughörigen Modulen zuordenbar sind
• Die Informationen über den Beginn der Aufzeichnung (2012) und die Gesamtzahl der Meldungen bleiben erhalten.

• es verbleiben für die Migration ca. 6000 Datensätze
• die Migration dauert ca. 15 Minuten
• die Summenbildung über diese 6000 Datensätze dauert aktuell ca. 6 Sekunden
• die Summenbildung über diese 6000 Datensätze dauert aktuell ca. 2 Sekunden

Meinungen?

[Markus Bloch]

Also 2 Sekunden für die Ermittlung der Daten finde ich absolut im Rahmen.

[betateilchen]

Je nach Serverauslastung geht das Ganze sogar noch schneller

Statistics database
created: 2012-12-02 16:20:20, updated: 2017-05-25 18:46:10
entries (total): 19612, entries (12 month): 5883
Generation time: 0.546 seconds

Das Migrationstool ist fertig. Wir könnten also in Kürze die Aufzeichnung von Statistikdaten wieder in Betrieb nehmen. Details klären wir vielleicht besser per email.

[betateilchen]

An diesem Wochenende wurde die neue Aufzeichnung der Statistikdaten in Betrieb genommen.

Am kommenden Wochenende wird an der grafischen Aufbereitung der gesammelten Daten gearbeitet.

[betateilchen]

Und dann gibt es da noch eine Server-Infrastruktur, die zwei Leute mehr als eine Stunde damit beschäftigt, herauszufinden, warum bestimmte Daten nicht vorhanden sind, bis man dann darauf kommt, dass externe IP Adressen verschwinden und es zu privaten IPs logischerweise keine Geo-Daten gibt...

<insider>
Das war übrigens auch der tatsächliche Grund, warum das ganze Statistikgedöns auf meinem Server problemlos funktionierte und nach der Portierung auf den FHEM Server nur 500er-Fehler entstanden.
</insider>