Hallo zusammen,
in den letzten Wochen/Monaten haben betateilchen und Ich an einer Überarbeitung der FHEM Statistik gearbeitet. Da wir an Grenzen mit der bestehenden Lösung gestoßen sind, haben wir uns für eine komplette Überarbeitung entschieden. Nun sind wir an dem Punkt angelangt, wo wir die neue Statistik euch vorstellen möchten:
https://fhem.de/stats/statistics.html
Folgende Hinweise zur neuen Statistik möchte ich hier nochmal explizit geben:
- Die Statistik wird bei jedem Aufruf direkt generiert. Sie ist daher stets aktuell und zeigt den Zeitpunkt der letzten Übertragung an.
- Es werden nur die Datensätze der letzten 12 Monate angezeigt.
- Da die IP Auflösung zum entsprechenden Ort sehr ungenau ist (insbesondere bei Unity-Media) haben wir uns lediglich für eine Visualisierung der Bundesländer in Deutschland entschieden.
- Es werden keine IP-Adressen in der Datenbank gespeichert sondern nur die regionale Zuordnung.
- Die Europa- & Welt-Karte zeigt primär an, in welchen Ländern FHEM genutzt wird. Mit einem Mouse-Over kann man die exakten Zahlen einsehen. Eine farbliche Abstufung wurde bewusst entfernt.
- Es gibt bewusst keinen Chart über die verwendete Architektur, da diese eine zu große Vielfalt ist und man nicht daraus ableiten kann, ob es sich um ein NAS/FritzBox/Raspberry/etc. handelt.
- Die Modultabelle zeigt alle verwendeten Module an. Auch inoffizielle Module, die nicht über den Update-Mechanismus verteilt werden, werden angezeigt.
- Es werden nur Module angezeigt, die auf mehr als einer Installation verwendet werden. Hintergrund ist, dass nicht jedes Modul was man gerade entwickelt/testet sofort hier aufgeführt werden soll.
- Es werden die Anzahl der FHEM Installationen angezeigt, auf denen ein Modul eingesetzt wird, sowie die Anzahl der gesamten Definitionen auf allen Installationen. Sofern ein Modul verschiedene Gerätemodelle unterstützt (Attribut "model" / Reading "model" / Internal "MODEL"), wird die Anzahl der verschiedenen, bekannten Modelle angezeigt.
- Bei Modulen, die Gerätemodelle unterscheiden, kann man durch Klick auf die Zahl die einzelnen Modelle mit deren Verteilung einsehen.
- Da die Modelle erst mit dem neuen fheminfo-Befehl zu dem jeweiligen Modul zugeordnet werden, gibt es hier noch geringe Zahlen, da diese Infos erst seit wenigen Wochen via fheminfo send" übertragen werden. In der bisherigen Statistik wurden die Modelle nicht mit dem zugehörigen Modul verknüpft, weswegen wir die Altdaten für die Modelle nicht verwenden können.
- Die Modultabelle bietet eine Suchfunktion für Modulnamen, sowie Sortierung durch das Klicken auf die Spaltenüberschriften an.
Fragen/Anmerkungen/Wünsche können gerne in diesem Thread geäussert werden.
Viele Grüße
Markus
Ich aktiviere das sofort. Wie macht man das schon? ;)
Ich finde die Modul Statistiken irgendwie... nicht brauchbar / uninteressant. Die Module, die kommen, sind nicht bedeutend. Kann man die gängliche Modulen wie FHEMWEB, at, autocreate, filelog, notify, usw nicht ausblenden? Die sind bei jeder standard Installation da.
Dass sie da sind, heißt nicht, das sie benutzt werden. Man kann FHEM tatsächlich noch flexibler verwenden, als viele denken.
Hallo Amenomade,
natürlich könnte man bestimmte Module aus der Statistik ausschließen. Wir haben uns erstmal für die Anzeige aller Module entschieden ohne irgendwelche Sonderbehandlungen.
Gruß
Markus
Naja, das ist allerdings unwichtig. Man kann durchblättern, um sinnige Informationen zu finden. Ich finde z.B. die HM Statistiken interessant. Anscheinend nutzen viele FHEM Benutzer Homematic ;)
Du kannst die Tabelle ja auch nach den Spalten sortieren und die Anzahl der angezeigten Zeilen verändern.
Dann steht CUL_HM bereits an 12. Stelle - siehe Screenshot.
Hier noch ein paar Zusatzinfos
- Bitte an alle Entwickler: wir sollten uns im Developerbereich darüber abstimmen, wo künftig "model" Informationen einheitlich (!!!) im device abgelegt werden.
- ab dem morgigen Update wird die Information übertragen, ob das System configDB oder fhem.cfg nutzt
- Bei der Modulinformation zu configDB wird unter Models der verwendete Datenbanktyp (sqlite, mysql, ...) ausgewertet
- Bei der Modulinformation zu DbLog wird unter Models der verwendete Datenbanktyp (sqlite, mysql, ...) ausgewertet
Danke. :)
Anmerkung zum Reading model bei 10_ZWave.pm:
Der Readingwert "model" ist nicht "langzeitstabil", d.h. davon abhängig, wann das Device in FHEM per autocreate angelegt wurde.
Das Reading wird durch meine manuelle Zuordnung in https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/openzwave_manufacturer_specific.xml anhand des vom Endgerät gelieferten Readingwertes von modelId mitbestimmt. Wenn ich noch keine Zuordnung in der genannten Datei vorgenommen habe, bekommt das Reading model den Hexwert vom Reading modelId.
model hatte bisher keine funktionale Bedeutung im Modul/FHEM und ich habe die Benennung immer laufend an neue Erkenntnisse und an openzwave als Hauptlieferant der Infos angepasst. Aktualisiert wird das Reading model nach der Ersteinrichtung des Devices durch autocreate regelmäßig nur, wenn der User manuell "get <device> model" abruft. Macht vermutlich keiner.
Führt dazu, das gleiche Geräte in der Statistik mehrfach aufgeführt sind:
FIBARO System FGWPE Wall Plug 1 2
FIBARO System FGWPE/F Wall Plug 1 1
Und von mir bisher noch nicht eingepflegte Geräte mit dem Hexwert von modelId angezeigt werden:
0x0175 0x0100 0x0102 1 1
Um das Problem zu verhindern, müsste die Statistik das Reading modelId nutzen. Das gibt es bei ordnungsgemäßer Device-Einrichtung immer und ändert sich nie. Der Hexwert ist aber recht nichtssagend.
Für mich ist der derzeitige Weg auch vollkommen ok.
Immer dieses Sonderlocken :P Aber noch schlimmer als ZWave ist KNX...
Genau deshalb in meinem vorherigen Beitrag die Bitte, dass wir uns als Entwickler darüber abstimmen. Aber bitte nicht hier im Thread.
Gefällt mir sehr gut. Vielen Dank für das Update und die Arbeit, die ihr reingesteckt habt.
Vielleicht mal noch ein paar technische Details am Rande:
Die alte Datenbank...
- ... hatte eine Größe von ca. 58 MB
- ... bestand aus 5 Tabellen
- ... mehrere der Tabellen hatten Strukturen mit mehreren Hundert Feldern
- ... wurde bei jedem "neuen" Modul und/oder Modell strukturell komplett geändert (ALTER TABLE... für mehrere Tabellen)
Die neue Datenbank...
- ... hat (inkl. der migrierten Daten aus der alten DB) aktuell eine Größe von ca. 8 MB
- ... besteht nur noch aus einer einzigen Tabelle mit vier Feldern
- ... muss bei neuen Modulen und/oder Modellen nicht mehr geändert werden
Hallo,
vielen Dank für die Entwicklung und die Informationen, sehr gut und sehr interessant!
Kann man euch eigentlich irgendwie mal ein Teambier oder ne Chipstüte spendieren?
Gruß Otto
Zitat von: krikan am 01 Juli 2017, 12:53:01
Anmerkung zum Reading model bei 10_ZWave.pm:
...
Um das Problem zu verhindern, müsste die Statistik das Reading modelId nutzen.
Das habe ich jetzt mal so als Sonderbehandlung in 98_fheminfo.pm eingebaut. Gefallen tut mir das nicht, aber wenn es einer Verbesserung der Datenqualität dient, soll es erstmal so sein.
Zitat von: Otto123 am 01 Juli 2017, 13:24:29
Kann man euch eigentlich irgendwie mal ein Teambier oder ne Chipstüte spendieren?
Vielen Dank, Otto!
Ich bin vom 16.-23.09. in Leipzig. Da liese sich was machen ;)
Gruß
Markus
98_fheminfo.pm zählt ab dem morgigen Update keine devices mehr, die als TEMPORARY oder VOLATILE gekennzeichnet sind.
Und "Global" wird nicht mehr als Modultyp ausgewertet.
Zitat von: Markus Bloch am 01 Juli 2017, 14:21:41
Ich bin vom 16.-23.09. in Leipzig. Da liese sich was machen ;)
Dann bin ich mal so frei und habe unser nächstes Treffen in Leipzig (https://forum.fhem.de/index.php/topic,52727.msg654702.html#new) für den 21.9. vorgeschlagen.
Ich würde mich freuen wenn das klappen würde! Mal sehen was die anderen sagen.
Man möge mir den OffTopic verzeihen ;D
Gruß Otto
Zitat von: amenomade am 01 Juli 2017, 12:12:40
Ich finde z.B. die HM Statistiken interessant. Anscheinend nutzen viele FHEM Benutzer Homematic
Wobei hier die Betonung auf "anscheinend" liegen muss. Denn der Schein trügt.
In der Datenerfassung der alten Statistik wurde jedes in FHEM definierte device vom TYPE=CUL_HM als eigenes device gezählt. Das macht nicht immer Sinn. Eine 20-Kanal Fernbedienung von Homematic legt 20 devices für die einzelnen Channels an + 1 device selbst. Damit erhöht sich der Zähler für CUL_HM auf einen Schlag um 21 - obwohl nur ein einziges physisches Gerät vorhanden ist.
In der neuen Statistik werden einzelne Channels nicht mehr mitgezählt. Damit taucht beispielsweise auch ein Heizungsregler oder ein Wandregler nur noch einmal in der Statistik auf und nicht mehr mit all seinen Kanälen.
Super Sache, danke euch!
Mir ist aufgefallen, dass z.B. bei "notify" 5371 Installationen angezeigt werden und 6934 Definitionen. Ist das realistisch? Das würde heißen, im Schnitt hat jede FHEM-Installation nur 1,3 notify-Instanzen? Da hätte ich jetzt deutlich mehr erwartet, oder?
Hallo vbs,
da hast du durchaus recht. Die aktuelle Statistik benutzt noch die alten Daten der vorherigen Statistik. Da ist mir dieses Problem auch schon aufgefallen. Hier gabe es immer schon diese Diskrepanz
Ich habe mal in meiner lokalen Entwicklungsumgebung den Zeitraum zur Visualisierung von 12 Monate auf 12 Tage gestellt. Da sieht das direkt gleich anders aus.
Viele Grüße
Markus
Zitat von: betateilchen am 01 Juli 2017, 12:56:33
Immer dieses Sonderlocken :P Aber noch schlimmer als ZWave ist KNX...
Die KNX models in der Statistik sind seltsam:
HASH(0x20a3410) 1 1
HASH(0x20a39e0) 1 1
Genau das meinte ich :)
Solche Einträge werden künftig dadurch unterbunden, dass die Model-Information darauf geprüft wird, ob es sich um einen scalar handelt. Falls nicht, wird die model-Information ignoriert.
Aber auf sowas kann man natürlich erst reagieren, wenn das in der Datenbank auftaucht (und jemandem auffällt).
Ich habe soeben ein neues Pie-Chart angelegt, welches anzeigt, wann FHEM-Installationen zuletzt geupdated wurden (sowohl per FHEM-Befehl "update", als auch via SVN-Update).
Evtl. ist ein Reload im Browser notwendig, bevor man das neue Chart sieht.
Viele Grüße
Markus
sieht gut aus :) Eigentlich müsste es "<= 1 day" heißen.
Vielleicht sollte man noch erwähnen, dass die Daten erst seit kurzem gesammelt werden, weshalb Installationen, die "älter" sind als einen Monat, in diesem Kuchen noch nicht auftauchen. Es sollte irgendwann ein viertes Kuchenstück auftauchen, in dem die Installationen zwischen einem Monat und einem Jahr gezählt werden.
Frage in den OS Statistiken: ist "darwin" = Mac ?
@Markus: Danke. Waere es moeglich die Zahlen auch in der Legende anzuzeigen? Ich habe vergeblich versucht den Anzahl von "other" in der OS-Ansicht rauszufischen. Das wuerde auch das "flimmer" Problem loesen.
@amenomade: ja.
Hallo Rudi,
ja, das Anzeigen der Zahlen in der Legende ist möglich. Ich habe mal ein Beispiel aus meiner lokalen Umgebung angefügt.
Zu "Other": Es handelt sich hierbei um ein Feature von Google, welches Datensätze mit werten die kleiner als ein halbes Grad (0,14%) zum Pie-Chart beitragen würden, in "Other" zusammenfasst. Ich bin aktuell eher dazu geneigt aufgrund der nachwievor hohen Vielfalt im Perl-Chart, diesen Threshold etwas anzuheben um etwas Ordnung da rein zu bringen. Da aktuell noch sehr viele wenige Datensätze angezeigt werden, möchte ich den Threshold gerne erhöhen auf 0,5%. Das bedeutet, alle Datensätze, die nicht über diesen relativen Wert kommen, werden in "Other" zusammengefasst.
Das im Anhang gezeigte Perl-Chart ist mit einem Threshold von 0,5% erzeugt worden. Die genaue Anzahl von "Others" gibt Google nicht aus. Auch ein Tooltip für "Other" existiert nicht, weswegen ich hier keine genaue Anzahl anzeigen kann. Einzige Möglichkeit ist die Nutzung vom Legendentyp "labeled". Das habe ich als zweiten Screenshot mal angefügt. Gefällt mir aber optisch gerade bei dem Perl-Chart nicht wirklich.
Was meinst Du / der Rest?
Viele Grüße
Markus
Minimum anzuheben ist ok, es wird fuer Entscheidungen benutzt, wie: darf ich ein perl Feature verwenden, oder verwenden noch zu viele eine zu alte Perl-Version. 0.5% als Grenze finde ich ok.
Bei der Anzeige der Werte bin ich unentschlossen. Die label Variante ist leider schwer zu lesen (schlecht fuer Anfaenger), zeigt aber immerhin eine Zahl an (gut fuer die, die gelernt haben die Zahlen zu lesen).
Ich habe nun das Minimum auf 0.5% angehoben und die Anzahl in der Legende hinterlegt.
@Udo: Ich habe auch das kleiner-gleich-Zeichen bei dem Update-Chart eingefügt.
Ich finde die Lösung gut. Die Label-Variante wäre m.E. sehr unübersichtlich.
Zitat von: Markus Bloch am 09 Juli 2017, 15:10:14
Ich habe nun das Minimum auf 0.5% angehoben
Bei der Auswertung der Betriebssysteme finde ich 0,5% sehr unglücklich, weil damit nur noch Linux und Windows übrig bleiben.
Zitat von: betateilchen am 10 Juli 2017, 19:12:01
Bei der Auswertung der Betriebssysteme finde ich 0,5% sehr unglücklich, weil damit nur noch Linux und Windows übrig bleiben.
Vorschlag: 0,4% Schwelle, dann wird MacOS mit 24 Installationen wieder angezeigt. Bei Perl kehrt damit 5.18.4 mit 24 Installationen ins Chart zurück.
wäre es möglich die OS Auswertung auszubauen (zb welches Windows zb XP/7/10 , Linux etwas genauer, ggf Plattform)?
Ansonsten top (nur das man ggf hätte die alten Datenstände hääte einfach weg lassen sollen)
Die Plattform-Informationen haben wir bewusst ausgebaut (siehe Eingangsbeitrag)
Eine Auswertung, welches Windows oder welches Linux ist nicht vorgesehen. (Die perl Variable $^O gibt einfach nicht mehr her)
Die alten Datenbestände sind nicht wirklich alle falsch. Es fehlen komplett die Modellinformationen. Und spätestens in 12 Monaten werden diese Daten ohnehin nicht mehr berücksichtigt.
Zitat von: betateilchen am 11 Juli 2017, 08:48:14
Die Plattform-Informationen haben wir bewusst ausgebaut (siehe Eingangsbeitrag)
Eine Auswertung, welches Windows oder welches Linux ist nicht vorgesehen. (Die perl Variable $^O gibt einfach nicht mehr her)
da könnte Win32::GetOSVersion helfen...
Du willst doch nicht 99% aller FHEM Anwender (die nicht Windoof nutzen) dazu zwingen, ein zusätzliches Perl Modul zu installieren, das sie überhaupt nicht benötigen, nur um fheminfo nutzen zu können? Noch dazu, wo eine weitere Aufschlüsselung für FHEM selbst überhaupt keinen zusätzlichen Nutzen bringen würde.
Deshalb wird es keine weitere Aufschlüsselung der Betriebssystemversionen geben.
Zitat von: Markus Bloch am 10 Juli 2017, 23:09:40
Vorschlag: 0,4% Schwelle, dann wird MacOS mit 24 Installationen wieder angezeigt. Bei Perl kehrt damit 5.18.4 mit 24 Installationen ins Chart zurück.
Kannst Du die Schwelle nur für alle Charts gleichzeitig ändern?
Zitat von: betateilchen am 11 Juli 2017, 14:06:53
Kannst Du die Schwelle nur für alle Charts gleichzeitig ändern?
Nein, ich könnte sie natürlich auch pro Chart verändern. Halte ich aber nicht für den richtigen Weg unterschiedliche Schwellen in jedem Chart zu haben. Ich würde es gerne wenn einheitlich haben. 0,4% führt bei OS zum gewünschten Ergebnis (MacOS), bei dem Perl-Chart rutscht damit eine einziges Kuchenstück nach, was ich durchaus verkraften kann.
Viele Grüße
Markus
Naja, dann lass es uns mal mit 0,4% probieren. Wobei ich eine einheitliche Schwelle grundsätzlich nicht für den "goldenen Weg" halte.
Bei den Perl Versionen könnten wir uns überlegen, auf die Hauptversionen (5.18, 5.20 usw.) zu reduzieren, denn es wäre sicher auch interessant, zu sehen, wieviele Anwender noch mit historischen Perl Versionen wie z.B. 5.10 arbeiten, die aktuell in der Statistik gar nicht mehr auftauchen. Gerade bei den vielen verschiedenen Perl Versionen besteht bei der Programmierung die größtmögliche Chance, durch Verwendung von features, die in bestimmten Versionen noch nicht bzw. nicht mehr vorhanden sind, Probleme zu verursachen.
Ich hab die Schwelle 0,4% nun gesetzt. "MacOS" taucht damit wieder auf.
Bitte nicht wundern. Ich habe bei OS eine Umsetzung der Daten vorgenommen:
linux => "Linux"
MSWin32 => "Windows"
darwin => "MacOS"
Viele Grüße
Markus
Zitat von: Markus Bloch am 12 Juli 2017, 23:05:19
darwin => "MacOS"
macOS schreibt sich mit kleinem m am Anfang ;)
Die Informationen zu
- FHEM release
- FHEM featurelevel
- upTime
wurden aus der Sammlung von fheminfo entfernt. Warum?
- FHEM release - hatte bisher wenig Aussagekraft, da immer die Werte VOR einem Update mit anschliessender Datenübertragung ausgewertet werden. Stattdessen wird jetzt die Aktualität der FHEM Installation anhand der SVN revision number NACH einem Update ausgewertet und das Alter dargestellt.
- FHEM featurelevel - war bisher ohnehin rein informativ angezeigt und wurde für die Statistik nicht gebraucht. Als Alternative bei nicht explizit gesetztem featurelevel wurde die release Information verwendet, die nun nicht mehr exisitiert.
- upTime - rein informell, wurde nicht an den Statistikserver übertragen. Wer die uptime seiner FHEM Installation seit dem letzten (re-)Start wissen möchte, kann den neuen FHEM Befehl "uptime" verwenden. (ab dem morgigen Update verfügbar)
Hallo zusammen,
auch von meiner Seite ein herzliches Danke an die updater, das ist wirklich informativ.
Bei der Interpretation der Daten habe ich aber gewisse Verständnisschwierigkeiten, vor allem, wenn ich mir exemplarisch zwei zweistufige Modulkonzepte anschaue (Milight und MySensors).
An sich würde ich annehmen, dass bei 2-stufigen Modulen
- eigentlich immer die Zahl der Devices die Zahl der Bridges übersteigen sollte und
- mindestens gelegentlich mehrere Bridges in einer Installation vorhanden sind.
Bie Milight stellt sich das aber lt. Statistik so dar, dass auf 215 Installationen genau auch 215 Bridges vorhanden sind, die in 214 Installationen 220 Devices steuern. Schaue ich mir meine eigene Installation an, habe ich 4 Bridges definiert, die 14 (?) Devices steuern; ist sicher eher viel, aber so ganz plausibel erscheinen mir die Daten nicht...
Ähnliches gilt für MySensors. Da hier die Bridge standardmäßig auch noch als Device angelegt wird, erscheinen mir die Verhältniszahlen hier noch irritierender: 169:171/143:150. Eigene Werte wären hier ca.: 1:2/1:6.
Ist das ein Problem bei der Datenübergabe aus der alten Datenbank, oder eine Fehlinterpretation der Daten meinerseits?
Gruß, Beta-User
Zitat von: Beta-User am 13 Juli 2017, 11:35:37
Ist das ein Problem bei der Datenübergabe aus der alten Datenbank,
Ja. Schau Dir die Statistik einfach in ein paar Wochen nochmal an, wenn mehr aktuelle Datensätze vorhanden sind.
Zitat von: betateilchen am 08 Juli 2017, 21:13:12
Es sollte irgendwann ein viertes Kuchenstück auftauchen,
q.e.d. 8)
Darüber hinaus sind in der Auswertung noch die Fälle "6 Monate - 1 Jahr" und "älter als 1 Jahr" vorgesehen.
Hi Leute,
ich finde die Bundesland-Statistik super interessant. Dazu habe ich allerdings eine Anmerkung / einen Vorschlag. Ich fände es sinnvoller, die Anzahl an fhem Installationen nicht als Absolutwerte darzustellen, sondern als "fhem Installationen pro Einwohner". Im Moment korrelieren die Farben der Karte sehr stark mit den Einwohnerzahlen der jeweiligen Bundesländer, was mMn nicht wirklich aussagekräftig ist. Ich fände es interessanter zu sehen, in welchen Regionen eine überdurchschnittlich hohe "fhem User zu normale Menschen-Ratio" existiert.
Gruß,
Mathea
Dann kommt man aber auf viele Nullen hinter dem Komma.
Bsp:
NRW hat 17.865.516 Einwohner (Stand: 2015 / Quelle: https://www.destatis.de/DE/ZahlenFakten/LaenderRegionen/Regionales/Gemeindeverzeichnis/Administrativ/Aktuell/02Bundeslaender.html)
Die FHEM Statistik listet in NRW 521 Installationen
Das entspricht 0,0000291 Installationen pro Kopf (hab mich hoffentlich nicht mit den Nullstellen vertan). Das sind nicht gerade optimale Werte für eine grafische Darstellung, weil man sich schlecht etwas drunter vorstellen kann.
Sonntag ist offenbar Update-Tag :)
Es gab noch an keinem Tag so viele Installationen mit einem Alter <= 1 Tag wie am heutigen Sonntag, und das schon um 12 Uhr mittags...
Und manche Dinge verstehe ich nicht...
Wie kommt eine Modellinformation aus FS20 in ein Homematic device?
Zitat von: Markus Bloch am 16 Juli 2017, 10:31:59
Dann kommt man aber auf viele Nullen hinter dem Komma.
Man könnte es ja pro 100.000 Einwohner angeben... ;)
Man könnte auch einfach damit zufrieden sein, wie es seit vielen Jahren umgesetzt und akzeptiert ist.
Es würde keinen Sinn machen, das auf Installationen pro xxx Einwohner umzurechnen, denn man sollte die Zahlen aus den Bundesländern ohnehin nicht überbewerten. Ein Großteil aller FHEM Installationen in NRW, die bei Unitymedia-Kunden stehen, werden anhand ihrer IP nämlich Hessen zugeordnet und eben nicht NRW. Deshalb wäre eine Umrechnung auf Einwohner noch problematischer (da noch weniger richtig) als die jetzige absolute Zählung der Installationen.
bei den 4 Installationen hier in Ungarn stellt sich die Frage ohnehin nicht...
Die Einleitung "FHEM statistics [...] number of installations (last 12 months): 5577, usw." ist mAn irrefuehrend, es werden naemlich nur die Installationen gezaehlt, bei denen jemand die Statistikerfassung explizit aktiviert (opt in). Ich wuerde eher schreiben "FHEM statistics, based on opt-in submissions". Hat jemand einen besseren Vorschlag?
P.S.:
Evtl. koennte man gleich einen Link zu https://fhem.de/commandref.html#fheminfo hinterlegen.
Zitat von: rudolfkoenig am 16 Juli 2017, 12:45:09
Ich wuerde eher schreiben "FHEM statistics, based on opt-in submissions". Hat jemand einen besseren Vorschlag?
Ich würde vorschlagen
Zitat
FHEM statistics
last submission: 2017-07-16 11:44:49 UTC
created in: 0.265 seconds
number of submissions (last 12 months): 5577
total number of submissions (since : 2012-12-02): 20326
Infos on contributing data: <hier kommt der Link zu fheminfo>
Zitat von: betateilchen am 16 Juli 2017, 13:54:24
Ich würde vorschlagen
Habe ich soeben übernommen.
Gruß
Markus
gefällt mir :) (die Generierungsdauer können wir m.E. irgendwann wegfallen lassen, die war nur während der Entwicklung interessant)
Und was meint Rudi?
Ich meine, dass der Satzbau bei "Infos on contributing data, see fheminfo command" irgendwie hinkt. Wollte eigentlich nicht reinreden, aber wenn man mich fragt... :)
Aber ich finde die Formulierung "number of submissions" deutlich besser als "number of installations", weil ich vermeiden will, dass ein Neuling auf die Idee kommt, dass es nur 5575 FHEM-Installationen gibt.
[/size]
Ich wollte Markus nicht schon wieder wegen Satzbau und Zeichensetzung im Englischen anmeckern, wir hatten dazu neulich schon eine Diskussion ... 8)
ZitatYou can help us increase the quality of FHEM statistics data. Please check fheminfo command for details.
Zitat von: betateilchen am 16 Juli 2017, 17:29:45
Ich wollte Markus nicht schon wieder wegen Satzbau und Zeichensetzung im Englischen anmeckern, wir hatten dazu neulich schon eine Diskussion ... 8)
Für mich ein klares Zeichen, dass 3 Jahre Gruppenuntericht in Englisch bei Eiffert nichts bringt...
In meinem letzten Beitrag habe ich gerade noch einen Vorschlag für die Formulierung gemacht.
Vermutlich kannst Du dafür besser Russisch als ich :)
Habs geändert. Meine rudimentären Englischkenntnisse suggerierten mir jedoch noch ein fehlendes "to increase" in deinem Vorschlag. Ich war mal so frei, das noch mit einzufügen.
Viele Grüße
Markus
Da gehört kein to rein...
Ich hadere immer noch mit der pauschalen 0,4% Grenze für alle pie-charts, die für mich so keinen wirklichen Sinn macht.
Man sollte diese Schwelle pro Chart definieren und davon abhängig machen, wieviele mögliche Varietäten im Chart auftreten können.
In der Darstellung der Update-Alter ist nun der Bereich 1-6 Monate rausgefallen, obwohl selbst eine einzige Installation eine durchaus interessante Information darstellt.
Hallo Udo,
das kann ich so nicht bestätigen. Was (wieder) weg gefallen ist, ist der Teil "< 1 Tag". Der Teil "1 Monat - 6 Monate" ist nachwievor sichtbar. Es hat hier also nichts mit der 0,4% Regel zu tun, sonst würde "Other" in Grau in der Legende erscheinen.
Gruß
Markus
Ja, Du hast Recht. Mir ist nur aufgefallen, dass plötzlich nur noch drei Einträge vorhanden waren.
Aber davon abgesehen: Wir sollten uns darum kümmern, warum die Installationen <= 1 Tag plötzlich rausgefallen sind...
(und das "to" ist immer noch falsch...)
Zitat von: betateilchen am 17 Juli 2017, 21:05:06
Aber davon abgesehen: Wir sollten uns darum kümmern, warum die Installationen <= 1 Tag plötzlich rausgefallen sind...
Durch das Runden auf 0 Nachkommastellen sind plötzlich alle Installationen älter als 36 Stunden heute im 20 Uhr in den Bereich 1-7 Tage gefallen.
Kannst Du bitte mal folgende Änderung einbauen:
$countAll{'system'}{'age'}{'0'}++ if ($age <= 2);
$countAll{'system'}{'age'}{'7'}++ if ($age > 2 && $age <= 7);
Zitat von: betateilchen am 17 Juli 2017, 21:05:06
Aber davon abgesehen: Wir sollten uns darum kümmern, warum die Installationen <= 1 Tag plötzlich rausgefallen sind...
Das ist relativ einfach. Die Revision wird aus controls_fhem.txt genommen. Diese Revision ist die letzte Änderung bis 05:45. Wenn nun also die letzte Änderung am Vortag um 19:00 erfolgte, dann ist dies auch der Zeitstempel, der in der Statistik benutzt wird. Das bedeutet also, dass um 19:00 des aktuellen Tages alle Installationen "< 1Tag" nun wegfallen und ab dann in "1 Tag - 1 Woche" aufgehen.
EDIT: Vielleicht sollten wir hier die gemeldete Revision + 1 nehmen (controls_fhem.txt Check-In). Dann hast du immer den Zeitpunkt des Release eines Updates, was ja am selben Tag um 05:45 ist.
Zitat von: betateilchen am 17 Juli 2017, 21:05:06
(und das "to" ist immer noch falsch...)
Habe ich bereits gefixt.
Zitat von: betateilchen am 17 Juli 2017, 21:13:49
Kannst Du bitte mal folgende Änderung einbauen:
$countAll{'system'}{'age'}{'0'}++ if ($age <= 2);
$countAll{'system'}{'age'}{'7'}++ if ($age > 2 && $age <= 7);
Ist aktiv.
Gruß
Markus
Wenn man die Counter für das Update-Alter mit 0 initialisiert, dann behalten die entsprechenden Kuchenstücke ihre Farbe:
$countAll{'system'}{'age'}{'0'} = 0;
$countAll{'system'}{'age'}{'7'} = 0;
$countAll{'system'}{'age'}{'30'} = 0;
$countAll{'system'}{'age'}{'180'} = 0;
$countAll{'system'}{'age'}{'365'} = 0;
$countAll{'system'}{'age'}{'999'} = 0;
Gruß
Markus
Zitat von: Markus Bloch am 17 Juli 2017, 21:24:45
Vielleicht sollten wir hier die gemeldete Revision + 1 nehmen
Schau ich mir an.
Zitat von: Markus Bloch am 17 Juli 2017, 21:33:48
Wenn man die Counter für das Update-Alter mit 0 initialisiert,
Das auch.
Und ich will das Runden auf 1 Nachkommastelle ändern. Nach meinem Urlaub.
@Markus: Eine überarbeitete Version der statistics2.cgi wurde heute eingecheckt.
Ist soeben aktiv geschaltet.
Gruß
Markus
Zitat von: betateilchen am 17 Juli 2017, 21:05:06
(und das "to" ist immer noch falsch...)
Hab mal jemanden gefragt, der sich damit auskennen sollte. Die Antwort ist
ZitatYou can help us to increase the quality... would be correct [emoji846]
Zitat von: vuffiraa am 20 Juli 2017, 22:27:53
Hab mal jemanden gefragt, der sich damit auskennen sollte.
Das habe ich auch gemacht,
bevor ich den Textvorschlag gemacht hatte... Wenn Dein Auskenner recht hat, müssen jetzt zigtausende englischsprachige Webaeiten geändert werden.
Zitat von: betateilchen am 21 Juli 2017, 12:14:52
Das habe ich auch gemacht, bevor ich den Textvorschlag gemacht hatte... Wenn Dein Auskenner recht hat, müssen jetzt zigtausende englischsprachige Webaeiten geändert werden.
Naja, nur weil die Seiten behaupten englischsprachig zu sein, müssen sie ja nicht recht haben. Die Treffer bei Google scheinen aber auch auf deiner Seite zu sein.
Mal sehen, ob mein Auskenner dafür eine Erklärung hat [emoji6]
Es dürfte beides richtig sein, hängt aber vermutlich davon ab, was man genau aussagen will:
http://context.reverso.net/übersetzung/englisch-deutsch/You+can+help+us+increase+the+quality (http://context.reverso.net/%C3%BCbersetzung/englisch-deutsch/You+can+help+us+increase+the+quality)
Zurück zum eigentlichen Thema:
Zitat von: betateilchen am 17 Juli 2017, 20:45:21
Man sollte diese Schwelle pro Chart definieren und davon abhängig machen, wieviele mögliche Varietäten im Chart auftreten können.
Ich nehme an, Dir schwebt vor nur für Perl eine Schwelle zu definieren und bei alle anderen Pie-Charts keine Schwelle zu setzen. Geh ich richtig in der Annahme?
Gruß
Markus
Lieber würde ich nochmal die Idee in den Raum stellen, bei den perl Versionen die Auswertung nicht bis auf die letzte Stelle auszuführen, sondern nur auf die Hauptversionen, also 5.24 zu zählen anstatt 5.24.0 + 5.24.1
Dadurch würde sich die Anzahl der Varietäten automatisch reduzieren (aktuell von 9 auf 6) und man bräuchte vermutlich auch dort gar keine Schwelle mehr.
Habe ich soeben aktiviert und die Schwellen entfernt. Wenn man die Schwelle direkt auf 0 setzt, werden auch die Kuchenstücke beim Update-Alter mit "0" in der Legende angezeigt. Das würde ich aber noch korrigieren durch Angabe der Schwelle pro Chart.
Gruß
Markus
Auf meinem iPad mit IOS 9.x zeigt Safari und aktueller Firefox nur die kreisenden Punkte der Statistikseite an. Bug, Feature, iPad kaputt? ;)
Feature, definitiv ein Feature! ;D
vermutlich ein iPad im paranoia-Modus, der JavaScript blockiert?
Auf meinem iPad mit iOS 10 funktioniert die Statistik jedenfalls problemlos.
Zitat von: betateilchen am 23 Juli 2017, 11:38:01
vermutlich ein iPad im paranoia-Modus, der JavaScript blockiert?
Ich habe es noch nicht kontrolliert, aber bis zur Umstellung hat es funktioniert und ich habe definitiv nichts an den Einstellungen geändert - nutze es nur zum Lesen...
js ist nicht deaktiviert und funktioniert auf anderen Seiten.
ok, auf meinem Galaxy S4 mini habe ich jetzt das gleiche Problem
Ich habe es bei mir nochmal explizit getestet mit iPad mini 1. Generation (iOS 9.3.6) und iPad 3. Generation (iOS 10.3.3) sowie iPhone (10.3.3) und konnte keine Probleme feststellen.
Wenn der Kreisel am dauerkreiseln ist, wird der JS-Code nicht ausgeführt bzw. aufgrund eines Fehler abgebrochen.
Habt ihr evtl. weiterführende Informationen?
Gruß
Markus
Zitat von: Markus Bloch am 24 Juli 2017, 10:04:45
Ich habe es bei mir nochmal explizit getestet mit iPad mini 1. Generation (iOS 9.3.6)
Genau diese Kombination funktioniert bei mir nicht. Damit sollte klar sein, dass es ein lokales Problem bei mir ist und ich suchen muß.
Danke für's Testen.
Auf meinem NEXUS 5 mit Android 6.0.1 funktioniert alles bestens mit dem "eingebauten" Google Browser und auch mit Chrome.
Gruß Otto
Zitat von: dev0 am 24 Juli 2017, 10:56:41
Genau diese Kombination funktioniert bei mir nicht. Damit sollte klar sein, dass es ein lokales Problem bei mir ist und ich suchen muß.
Danke für's Testen.
Kommando zurück. Ich habe es soeben nochmal geprüft, geht auch bei mir nicht. Ging es denn zuvor mal mit der neuen Statistik?
Gruß
Markus
Hallo Markus, nur so ein Hinweis: bei mir kommt nichtmal die timeout-Fehlermeldung. Das Problem muss also an einer ziemlich frühen Stelle auftreten. (nach meinem JS-Hasser-Verständnis)
Hab das Problem soeben gefunden. Bitte probiert nochmal. Auf meinem iPad geht's nun.
Auf meinem Android Handy alles gut - jetzt kommt die Statistik an. Danke.
Auf dem iPad tuts auch wieder, danke. Ich hatte schon wieder meinen FTTH Anschluss im Verdacht, dort gab es anfangs Probleme mit der tcp packet size, die der Provider falsch konfiguriert hatte.
Schön zu sehen, dass laut Statistik 99,5% aller FHEM Installationen, die Statistikdaten senden, einen Versionsstand von maximal 6 Monaten Alter haben :)
Ältere FHEM Installationen können ja auch keine Infos mehr senden, sondern blockieren einfach nur für 60s.
Viel interessanter finde ich, dass knapp 1200 Installationen spaetestens nach eine Woche auf dem aktuellen Stand sind.
Ich habe mal in access.log geschaut: /fhemupdate/controls_fhem.txt wird taeglich etwa 43000-mal abgeholt, leider sind davon fuer 30.000 zwei IP-adressen verantwortlich, einer davon scheint eine statische Adresse zu sein, die andere wird dynamisch vergeben. Ich meine sowas schonmal unterbunden zu haben, finde die Stelle aber nicht mehr. Kann mir jemand bitte helfen, die Diskussion zu finden, oder gleich eine Loesung vorschlagen?
Ich kenne den angesprochenen Thread, aber ich konnte ihn auch nicht mehr finden.
Aber selbst wenn...
... vor vielen Jahren konnte man anhand der solcher Zugriffe noch halbwegs seriöse Statistiken ableiten, heute geht das mAn nicht mehr: cgn, transparent proxies, etc... Um User/Installationen zu identifizieren müßte man cockies oder ähnliche Techniken verwenden.
... sollten Zugriffe von einer handvoll "Anwendern" sich störend auswirken, dann kann man abuse@<provider> anschreiben und hat damit, zumindest im westlichen Europa, meistens direkt Erfolg.
... sollten diese Anfragen in einen DOS oder ähnlich ausarten, dann hilft zB. Akamai open source Projekten auch kostenlos mit Proxies weiter.
Als "Selbstschutz" ist mir gerade noch fail2ban in den Sinn gekommen. Seit Version 0.10 (https://github.com/fail2ban/fail2ban/blob/0.10.1/ChangeLog) sollen auch IPv6 Adressen ohne zusätzlichen Patch unterstützt werden.
Bei den Zahlen .. da wird jemand alle 5 Minuten nach einem Update prüfen ... würde, vor anderen Maßnahmen, auch über die IP versuchen, den "Schuldigen" höflichst an die Updateregeln erinnern ....
Sorry .. hatte mich verrechnet, deshalb gelöscht.
Zitat von: Wernieman am 08 November 2017, 13:22:20
höflichst an die Updateregeln erinnern
Das könnte fail2ban auch automatisiert (über den Provider) erledigen, aber es wird langsam sehr offtopic hier, da es hier eigentlich um die Statistiken...
Zitat von: dev0 am 07 November 2017, 10:47:46
Ältere FHEM Installationen können ja auch keine Infos mehr senden, sondern blockieren einfach nur für 60s.
Dem ist nicht so. Die alte Schnittstelle für ältere Systeme existiert weiterhin, die Daten werden aber ignoriert.
Wie erhält man denn solche schicken Grafiken in fhem ?
https://forum.fhem.de/index.php/topic,73792.msg659560.html#msg659560
Das kommt nicht in FHEM sondern aus der FHEM Homepage Seite Statistik
Zitat von: CoolTux am 21 März 2018, 09:16:46
Das kommt nicht in FHEM sondern aus der FHEM Homepage Seite Statistik
https://fhem.de/stats/statistics.html
und das funktioniert sogar ganz ohne fratzenbuch und Cambridge Analytica 8)
Zitat von: betateilchen am 21 März 2018, 09:18:43
und das funktioniert sogar ganz ohne fratzenbuch und Cambridge Analytica 8)
Woher wusste ich nur das Du was dazu sagen wirst ;D
Aber ich stimme Dir da zu 100% zu. Habe auch kein Facebook.
Zitat von: betateilchen am 13 Juli 2017, 13:33:15
Ja. Schau Dir die Statistik einfach in ein paar Wochen nochmal an, wenn mehr aktuelle Datensätze vorhanden sind.
Hat jetzt zwar etwas länger gedauert, bis ich die Statistik mal wieder angesehen habe, aber m.E. sind die Daten nach wie vor nicht so richtig plausibel:
Zitat von: Beta-User am 13 Juli 2017, 11:35:37Bei der Interpretation der Daten habe ich aber gewisse Verständnisschwierigkeiten, vor allem, wenn ich mir exemplarisch zwei zweistufige Modulkonzepte anschaue (Milight und MySensors).
An sich würde ich annehmen, dass bei 2-stufigen Modulen
- eigentlich immer die Zahl der Devices die Zahl der Bridges übersteigen sollte und
- mindestens gelegentlich mehrere Bridges in einer Installation vorhanden sind.
Aktueller Stand sieht wie folgt aus: Milight - Bridge => 182 Installationen, Device => 180MySensors - Bridge => 174 Installationen, Device => 157 (Es wird per Autocreate eigentlich immer sofort beim Anlegen einer bridge auch ein Device angelegt, damit müßte die Anzahl der Installationen immer genau übereinstimmen...)
Die einzige Erklärung wären "Leichen", also Installationen, auf denen zwar die Devices gelöscht wurden, nicht aber die zugehörigen Bridges. Aber in dieser Zahl?!?
Na ja, nicht das wichtigste Thema auf dieser Welt.
Gruß, Beta-User
Was denkt ihr, was ist der Prozentsatz der FHEM-Nutzer, die an der Statistik teilnehmen?
Da es default deaktiviert ist tippe ich auf 30 Prozent rum.
Viel spannender finde ich, wieviele der Nutzer, die ihre Statistikdaten senden, mehr als eine Installation haben und melden.
Statistiken sind eh fürn
Glaube niemals einer Statistik, die Du nicht selber gefälscht hast ...
(c) ich glaube Adenauer ..
Zitat von: Wernieman am 07 Mai 2019, 18:38:10
Glaube niemals einer Statistik, die Du nicht selber gefälscht hast ...
(c) ich glaube Adenauer ..
Eher Göbbels
Zitat1946:
"Was nutzt es also, wenn gewisse deutsche Regionen versuchen, die Welt zu überzeugen, sie seien an dem nazistischen Unheil ,,weniger" schuld als ihre Brüder jenseits des Flusses? So viel haben sie schon gelernt, daß sie nur den Statistiken glauben, die sie selbst gefälscht haben."
Hanns-Erich Haack: "Ameisenstaat oder Sintflut." Deutsche Rundschau, 1946, S. 139
https://books.google.de/books?id=2zcaAAAAMAAJ&q=%22selbst+gef%C3%A4lscht%22
Weder Winston Churchill noch von Joseph Goebbels.
Zitat von: CoolTux am 07 Mai 2019, 17:12:36
Da es default deaktiviert ist tippe ich auf 30 Prozent rum.
Vielleicht könnte man die Nutzer an prominenter Stelle vor die Frage stellen?
Irgendwie bei der Installation oder so?
Zitat von: buennerbernd am 07 Mai 2019, 19:30:14
Vielleicht könnte man die Nutzer an prominenter Stelle vor die Frage stellen?
Der Hinweis kommt beim Update.
Zitat von: CoolTux am 07 Mai 2019, 19:14:30
Weder Winston Churchill noch von Joseph Goebbels.
Tatsächlich. Unglaublich, was man auf dem FHEM-Forum lernen kann ;)
https://books.google.de/books?id=bXl3DwAAQBAJ&pg=PT99
Wenn man
fheminfo send
aufruft, bekommt man ja eine Auflistung, welche Daten übertragen werden. Entweder sind die übertragenen Daten fehlerhaft oder die anschließende Auflistung.
Bei mir z.B.
Following statistics data will be sent to server:
(see Logfile level 4 for server response)
System Info
ConfigType: configFile
SVN rev: 19022
OS: linux
Perl: 5.22.1
uniqueId: c86...
Modules Model Count
BRAVIA
KD-55X8505B 1
CUL_HM
HM-TC-IT-WM-W-EU 1
DOIF
FHEM 9
FHEMWEB 1
FileLog 22
HMLAN 1
HMinfo 1
HTTPMOD 1
INDEGO
1000 1
KLF200
0.2.0.0.71.0 1
KLF200Node
VELUX SSL Roller Shutter 5
PRESENCE
lan-ping 2
SD_WS07 2
SIGNALduino 1
SVG 18
Twilight 1
Weather
DarkSkyAPI 1
autocreate 1
dewpoint 4
dummy 28
eventTypes 1
notify 8
readingsGroup 1
remotecontrol 1
structure 1
telnet 1
weblink 2
Da fehlen ein Haufen CUL_HM Geräte z.B. 7 HM-LC-Bl1PBU-FM, aber noch weitere.
Gruß, Stefan.