Habe bei einem FHEM Update gerade das hier am Ende bekommen:
2017.05.20 12:43:36 1 : update finished, "shutdown restart" is needed to activate the changes.
2017.05.20 12:43:36 1 :
2017.05.20 12:43:38 1 : fheminfo server response: <h1>Software error:</h1> <pre>DBD::SQLite::db prepare failed: too many columns on sqlite_altertab_models [for Statement "ALTER TABLE models ADD COLUMN '[LaCrosseITPlusReader.Gateway.1.30 (1=RFM69 f:868300 r:20000) (2=RFM69 f:868300 r:8842) SC16IS750 (0x90) {IP=192.168.31.209}]' INTEGER DEFAULT 0"] at /var/www/html/fhem.de/stats/statistics.cgi line 750. </pre> <p> For help, please send mail to the webmaster (<a href="mailto:webmaster@fhem.de">webmaster@fhem.de</a>), giving this error message and the time and date of the error. </p> <!-- warning: DBD::SQLite::db prepare failed: too many columns on sqlite_altertab_models [for Statement "ALTER TABLE models ADD COLUMN '[LaCrosseITPlusReader.Gateway.1.30 (1=RFM69 f:868300 r:20000) (2=RFM69 f:868300 r:8842) SC16IS750 (0x90) {IP=192.168.31.209}]' INTEGER DEFAULT 0"] at /var/www/html/fhem.de/stats/statistics.cgi line 750. -->
2017-05-20 12:43:38 Global global UPDATE
"[LaCrosseITPlusReader.Gateway.1.30 (1=RFM69 f:868300 r:20000) usw. usw." steht im internal "model" von meinen LaCrosseGateway devices.
Das ist bisher wohl nicht aufgetreten, wäre mir sonst bestimmt schon aufgefallen.
Konnte es auf einer zweiten FHEM-Installation auch gerade nachvollziehen.
*lach*
ok, wir sind an der natürlichen Grenze dessen angelangt, was sqlite als Tabellenstruktur zulässt.
@HCS: Du kannst den Fehler mit "attr global sendStatistics never" vorläufig vermeiden.
@Rudi: kannst Du bitte in 98_update.pm die Ausführung von "fheminfo send" (ab Zeile 427) bis auf weiteres auskommentieren?
@Markus Bloch: lass uns mal einen Workshop planen, um das lange vor uns hergeschobene Thema endlich anzugehen.
Zitat von: betateilchen am 20 Mai 2017, 13:26:24
@HCS: Du kannst den Fehler mit "attr global sendStatistics never" vorläufig vermeiden.
Ja klar, ist jetzt auch nicht so dramatisch, könnte nur zu Verwirrung führen, wenn das sonstigen Anwendern passiert
Zitat@Rudi: kannst Du bitte in 98_update.pm die Ausführung von "fheminfo send" (ab Zeile 427) bis auf weiteres auskommentieren?
Habs ueberlegt, aber dann mich dazu entschlossen lieber in statistics.cgi insertDb() auszukommentieren, und statt "==> OK" die Meldung:
ZitatNOTE: statistics collecting currently disabled, see https://forum.fhem.de/index.php?topic=72168.0 for details
zurueckzuliefern. Das hat mAn weniger Nebeneffekte, und wirkt schneller.
Ok, das ist auch eine gute Variante :)
Derzeit arbeite ich daran, die Zähl-Logik in fheminfo umzubauen, dabei ergibt sich folgende Frage:
@Rudi: kennst Du derzeit noch Module, die das "model" als Internal liefern und nicht als Attribut?
Zitat von: betateilchen am 20 Mai 2017, 17:37:54
... die das "model" als Internal liefern und nicht als Attribut?
36_JeeLink, 36_KeyValueProtocol und 36_LaCrosseGateway sicher
Falls meine Suche passt, dann weitere mögliche Kandidaten siehe Anhang.
Danke, ich habs befürchtet. Und dann auch noch unterschiedlich in Groß-/Kleinschreibung... *grummel*
Kann mir mal bitte jemand kurz beschreiben,
wie ich das am einfachsten auf nonblocking mit HttpUtils.pm umstricken kann?
sub _fi2_Send() {
my $json = encode_json \%fhemInfo;
Log3("fheminfo",4,"fheminfo: $json");
my $uri = $cmds{fheminfo2}{uri};
my $req = HTTP::Request->new("POST",$uri);
$req->content_type("application/x-www-form-urlencoded");
$req->content("uniqueID=".$fhemInfo{'system'}{'uniqueID'}."&json=$json");
my $ua = LWP::UserAgent->new(
agent => "FHEM/".$fhemInfo{'system'}{'release'},
timeout => 60);
my $res = $ua->request($req);
my $response = "server response: ";
$response .= $res->is_success ? $res->content : $res->status_line;
return $response;
}
Da ich deine Version nicht testen kann, habe ich die aktuelle 98_fheminfo.pm auf HttpUtils_NonblockingGet umgebaut, kurz getestet (d.h. auf dem Server die gelieferten Daten mit der alten Version verglichen), und diese umgebaute Version angehaengt. Hier ist der Diff:
165,166c165,166
< my $req = HTTP::Request->new("POST",$uri);
< $req->content_type("application/x-www-form-urlencoded");
---
> my %hash;
> $hash{url} = $uri;
175c175
< $req->content("uniqueID=$uniqueID&system=$contInfo&modules=$contModules");
---
> $hash{data} = "uniqueID=$uniqueID&system=$contInfo&modules=$contModules";
178c178
< $req->content("uniqueID=$uniqueID&system=$contInfo&modules=$contModules&models=$contModels");
---
> $hash{data} = "uniqueID=$uniqueID&system=$contInfo&modules=$contModules&models=$contModels";
181,191c181,190
< my $ua = LWP::UserAgent->new(
< agent => "Fhem/$release",
< timeout => 60);
< my $res = $ua->request($req);
<
< $str .= "\nserver response: ";
< if($res->is_success) {
< $str .= $res->content."\n";
< } else {
< $str .= $res->status_line."\n";
< }
---
> $hash{header} = "User-Agent: Fhem/$release";
> $hash{callback} = sub($$$) {
> my ($hash, $err, $data) = @_;
> if($err) {
> Log 1, "fheminfo: Server ERROR: $err";
> } else {
> Log 1, "fheminfo: Server RESPONSE: $data";
> }
> };
> HttpUtils_NonblockingGet(\%hash);
Kurz:
- es muss ein %hash mit url, data und callback(!) angelegt werden, Syntax von data ist identisch.
- HttpUtils_NonblockingGet kommt sofort zurueck (ist ja nonblocking :) ), Fehler oder Rueckgabewert bekommt man erst im callback.
Nachtrag: falls man asynchron (wg. callback) Daten via telnet/FHEMWEB ausgeben will, dann kann man asyncOutput verwenden. Das dafuer notwendige $cl wird jedem Befehl (wie fheminfo) direkt, SetFn/GetFn/DefineFn indirekt ueber $hash->{CL} mitgeteilt.
Zitat@Rudi: kennst Du derzeit noch Module, die das "model" als Internal liefern und nicht als Attribut?
ZWave: Da diese Daten das Geraet bei der Inklusion liefert, und der Benutzer sie nicht aendern soll, werden sie als Reading gespeichert. Dabei gibt es model als Klartext und modelId als Nummer. Beispiel: "Everspring AN158 Plug-in Meter Appliance Module" und 0060-0004-0002.
Nachtrag: in der mit FHEM ausgelieferten Liste (FHEM/lib/openzwave_manufacturer_specific.xml) sind 760 ZWave-Geraete aufgefuehrt.
Das Problem mit den "models" an verschiedenen Stellen (Internal und Attribut) habe ich schon abgefangen.
Wenn ich Dich richtig verstehe, sollte auch ein reading namens "model" entsprechend in die Statistik einfließen?
Es gibt auch Module, die schreiben eine Modellbezeichnung als "type" in die Readings. Das wird ein Faß ohne Boden.
Bezüglich HttpUtils_NonblockingGet() bin ich schon ganz schön weit, aber ich kriege die Daten einfach nicht vernünftig an (mein) statistics.cgi geliefert, damit statistics damit was anfangen kann. Mit LWP::Ua funktioniert es einwandfrei.
Naja, ich bastle mal weiter, ist ja schönes Wetter zum "im Cafe sitzen und programmieren" 8)
Erstmal Danke für die Unterstützung.
ZitatWenn ich Dich richtig verstehe, sollte auch ein reading namens "model" entsprechend in die Statistik einfließen?
Wenn wir Modelle sammeln wollen, dann ja.
Kaum macht man es richtig, schon funktioniert es auch nonblocking :)
Danke für Deinen obigen Codeschnipsel.
Zitat von: rudolfkoenig am 21 Mai 2017, 12:43:15
Wenn wir Modelle sammeln wollen, dann ja.
Dann sollten wir uns auf Prioritäten festlegen, falls eine Modellbezeichnung in einem device - warum auch immer - an mehreren Stellen vorkommt.
Aktuell sieht die Reihenfolge so aus:
my $model = 'noModel';
$model = defined($defs{$key}{model}) ? $defs{$key}{model} : $model;
$model = defined($defs{$key}{MODEL}) ? $defs{$key}{MODEL} : $model;
$model = AttrVal($name,'model',$model);
$model = ReadingsVal($name,'model',$model);
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
ZitatAktuell sieht die Reihenfolge so aus:
Fuer mich ok.
Zitat
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.
Zitat von: rudolfkoenig am 21 Mai 2017, 14:17:29
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.
Zitat von: betateilchen am 21 Mai 2017, 14:40:15
Aber ich werde noch einen entsprechenden Hinweis in die Ausgabe einbauen.
Reicht Dir das als Info? (siehe Anhang)
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.
Zitat von: justme1968 am 21 Mai 2017, 16:37:09
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.
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.
Das ist inzwischen schon entsprechend umgebaut, es wird nun statt der ip ein zusätzlicher json-String gespeichert:
{"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.
Lat/long mit 4 Nachkommastellen entspricht in unserem Gegend ca 78 x 111 m, damit kann man mancherorts schon was anfangen.
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.
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 8)
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.
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.
Zitat@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?
Das hatte ich Dir weiter oben schon beantwortet:
Zitat von: betateilchen am 21 Mai 2017, 14:40:15
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 :)
Huch, da habe ich diesen Thread ja wieder mal ganz übersehen.
Zitat von: betateilchen am 20 Mai 2017, 13:26:24
@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
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?
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 :)
Zitat von: Markus Bloch am 22 Mai 2017, 21:53:05
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... 8)
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!
Zitat von: betateilchen am 22 Mai 2017, 23:20:18
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 8)
Generation time: 0.096 seconds
(vor der Bereinigung: fast dreimal so lang)
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?
Also 2 Sekunden für die Ermittlung der Daten finde ich absolut im Rahmen.
Je nach Serverauslastung geht das Ganze sogar noch schneller :)
Zitat
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.
An diesem Wochenende wurde die neue Aufzeichnung der Statistikdaten in Betrieb genommen.
Am kommenden Wochenende wird an der grafischen Aufbereitung der gesammelten Daten gearbeitet.
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>