FHEM update mit Fehler am Ende

[betateilchen]

Im Anhang eine erste Version  "98_fheminfo2.pm" zum Testen, die Syntax ist die gleiche wie bisher "fheminfo2" bzw. "fheminfo2 send"

Die jeweils aktuelle Version befindet sich während der Entwicklung in ./contrib/statistics/ und kann per svn bezogen werden.

Das Konzept der Datensammlung und -übertragung wurde komplett umgebaut.

• es wird in allen Modulen nach einem "model" gesucht und ein entsprechender Zähler geführt
• die gesammelten Daten werden in einen json-String umgewandelt und an den Statistikserver übertragen
• die Datenbank auf Serverseite hat nun eine einfache und klar definierte Struktur (wobei man darüber sinnieren könnte, eine NoSQL Datenbank anstatt sqlite zu verwenden)
• es werden nur noch zwei Parameter für die Übertragung verwendet: die uniqueID und die json-Daten
• die Übertragung zum Server erfolgt nun nonblocking per HttpUtils
• die gesamte Auswertung der Daten (Unterscheidung nach "offiziellen" Module usw.) erfolgt künftig serverseitig.
• es wird kein lokales "controls_fhem.txt" mehr benötigt.

Die Übertragung bei "fheminfo2 send" erfolgt aktuell auf einen meiner Server bei Amazon, denn ich brauche ein paar "Testdaten" zum Weiterbasteln.
Wenn jemand, der möglichst viele Gerätetypen im Einsatz hat, einfach mal ein paar Daten schickt, würde mir das weiterhelfen

In der Datenbank werden folgende Informationen gespeichert

• uniqueID
• timestamp
• ip wird nicht gespeichert!
• json-data

Das sind die gleichen Daten wie bisher.

ToDo:

• einen Migrationsweg der bisher vorhandenen Statistikdaten schaffen. Das wird aber rein serverseitig passieren.
• commandref aktualisieren
• neue Auswertung in statistics.cgi bauen

[rudolfkoenig]

Aktuell sieht die Reihenfolge so aus:

Fuer mich ok.

Wenn jemand, der möglichst viele Gerätetypen im Einsatz hat, einfach mal ein paar Daten schickt, würde mir das weiterhelfen (https://forum.fhem.de/Smileys/default/smiley.gif)

Ich habe ein fheminfo2 send mit der Kopie meiner "Produktion" und mit einer grossen "test.cfg", was ich zum Geschwindigkeitsoptimieren bekommen habe, durchgefuehrt. Faellt mir gerade auf: ich habe beide Saetze mit der gleichen unique-id geschickt. Und ich sehe keinen Unterschied bei der Ausgabe von fheminfo2 bzw "fheminfo2 send", das ist verwirrend.

[betateilchen]

Und ich sehe keinen Unterschied bei der Ausgabe von fheminfo2 bzw "fheminfo2 send", das ist verwirrend.

Den Unterschied siehst Du derzeit nur im Logfile, dort wird das Ergebnis des "send" protokolliert.
Aber ich werde noch einen entsprechenden Hinweis in die Ausgabe einbauen.

Die uniqueID ist der primäre Schlüssel, insofern überschreibt Dein zweites "send" den ersten Eintrag.

[betateilchen]

Aber ich werde noch einen entsprechenden Hinweis in die Ausgabe einbauen.

Reicht Dir das als Info? (siehe Anhang)

[justme1968]

eine ip zu speichern halte ich für keine gute idee. ganz abgesehen davon das ich nicht wüsste was wir damit wollen könnte es datenschutzrechtliche und sonstige konsequenzen haben denen man von vorn herein aus dem weg gehen sollte.

[betateilchen]

ganz abgesehen davon das ich nicht wüsste was wir damit wollen

Hallo Andre,

ich muss mich korrigieren. Die ip wird bisher nicht gespeichert. Aber die IP wird direkt beim Senden der Statistikdaten dazu verwendet, über GeoIP eine Lokalisierung durchzuführen, um in Landkarten darzustellen zu können, wo es wieviele FHEM Installationen gibt. Dazu werden die GeoDaten direkt bei der Übertragung ermittelt und die GeoDaten gespeichert.

Man kann das natürlich auch weiterhin so machen, man bläht damit die Datenbank auf.

Ich werde das in meiner neuen Modulversion auch so umsetzen und darauf verzichten, die ip abzuspeichern.

[justme1968]

hallo udo,

das klingt gut. ich denke man sollte es auf jeden fall so machen. und auch darauf achten die ip nicht zu loggen. vor allem wenn man sie über einen timestamp oder anderes wieder mit den restlichen daten zusammenführen kann.

die auswirkungen auf die db sollten doch recht überschaubar sein. zwei floats für die koordinaten statt der ip ist im verhältnis zu den restlichen daten doch nicht wirklich problematisch.

für die performance der karten sollte es auch besser sein die kordinaten nur aus der db zu holen statt immer wieder von einer ip auszugehen.

[betateilchen]

Das ist inzwischen schon entsprechend umgebaut, es wird nun statt der ip ein zusätzlicher json-String gespeichert:

Code Auswählen Erweitern


{"continentcode":"EU","longitude":"-6.2595","city":"Dublin","countryname":"Ireland","countrycode3":"IRL","latitude":"53.3389","regionname":"Dublin","region":"07","countrycode":"IE","timezone":"Europe/Dublin"}


Aus den einzelnen Elementen kann wie bisher eine Visualisierung für verschiedene "Maßstäbe" erfolgen (City, Region, Country). Auf timezone könnte man an dieser Stelle vermutlich verzichten, aber das tut letztendlich auch nicht weh.

[rudolfkoenig]

Lat/long mit 4 Nachkommastellen entspricht in unserem Gegend ca 78 x 111 m, damit kann man mancherorts schon was anfangen.

[justme1968]

da die zuordnung von ip zu geokoorindaten schon ungenau ist trügt die scheinbare genauigkeit der nachkomma stellen. auf der anderen seite würde es vermutlich auch nichts schaden wenn man sich auf 2 oder 3 nachkommastellen beschränkt.

[betateilchen]

Ich schreibe die Daten einfach so weg, wie sie von Geo::IP zurückgeliefert werden.

Klar kann man die auch auf 2 oder 3 Nachkommstellen verkürzen. Aber man sollte die Daten ohnehin nicht überbewerten. Nach Meinung dieses Moduls befindet sich meine aktuelle IP ja auch im hessischen Pfungstadt anstatt in Mönchengladbach 

Man sollte sich grundsätzlich überlegen, ob man die Lokalisierung auf Kontinent/Land/Region beschränkt und gar nicht weiter runterbricht.
Zum einen würde das die performance bei der Auswertung und grafischen Aufbereitung verbessern, zum zweiten reicht das für eine "Verbreitungsdarstellung" sicher auch schon aus. Wobei in vielen Fällen (z.B. bei unitymedia-Kunden) selbst die ermittelte Region schon falsch ist.

[betateilchen]

Wen es interessiert: Eine grundlegende Auswertung der gesammelten Daten habe ich testweise implementiert.

http://fhem.j65.de/stats/statistics2.cgi

Ich hoffe, es findet sich jemand, der sich um die grafische Aufbereitung der Daten kümmert, da ist mir einfach viel zu viel JavaScript im Spiel.

@Rudi: kannst Du Deine Beispieldaten bitte nochmal übertragen? Da ich die Datenbankstruktur nochmal geändert habe, sind die Daten nicht mehr vorhanden.

[rudolfkoenig]

@Rudi: kannst Du Deine Beispieldaten bitte nochmal übertragen? Da ich die Datenbankstruktur nochmal geändert habe, sind die Daten nicht mehr vorhanden.

Habe sie beide nochmal geschickt, in umgekehrter Reihenfolge. Werden sie eigentlich bei gleicher unique-id ueberschrieben?

[betateilchen]

Das hatte ich Dir weiter oben schon beantwortet:

Die uniqueID ist der primäre Schlüssel, insofern überschreibt Dein zweites "send" den ersten Eintrag.

Wenn es zwei Systeme mit identischer uniqueID gibt, dann ist die ID ja nicht mehr unique

[Markus Bloch]

Huch, da habe ich diesen Thread ja wieder mal ganz übersehen.

@Markus Bloch: lass uns mal einen Workshop planen, um das lange vor uns hergeschobene Thema endlich anzugehen.

Ja, dass können wir gerne machen. Ich hatte mich schonmal mit Martin/Rudi ausgetauscht und mir das OK für eine Überarbeitung geholt. Wir hatten das auslösende Problem der max columns reached bereits vor ein paar Wochen. Da habe ich nochmal die DB ein wenig aufgeräumt, aber das reicht anscheinend nicht.

Wie ich sehe, hast Du bereits gut Arbeit reingesteckt und ein neues DB-Konzept umgesetzt.

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. Aktuell ist ja der Sommer und das Motorrad ruft, aber dazwischen würde ich das gerne machen. 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.

Generell kann ich Dir auch eine MySQL-DB auf dem Server anbieten, welche dann über Rudi oder mich erstellt werden kann.

Viele Grüße

Markus