Hallo Rudi,
wenn man in fhem nicht mit dem internen update-Befehl arbeitet, sondern beispielsweise direkt 'svn update' verwendet (bei mir läuft das als cmdalias) braucht man die Datei controls_fhem.txt nicht zum updaten.
Allerdings funktioniert dann auch fheminfo nicht mehr, weil dort zwingend diese Datei vorhanden sein muss, um für die Statistikdaten festzustellen, welche Moduldateien "offiziell" sind.
Trotz der Verwendung des direkten svn updates in meiner Installation würde ich gerne weiterhin die fheminfo Statistikdaten übertragen, was ohne diese Steuerdatei nicht funktioniert. Momentan arbeite ich mit dem workaround, die controls_fhem.txt einmal pro Tag per cronjob und wget auf mein System zu laden.
Schöner (wenn auch zugegebenermaßen nicht lebenswichtig) fände ich es, wenn diese Datei einfach im svn repository enthalten wäre.
Bin unentschlossen:
Pro:
- keine schwerwiegende Aenderung
- du bist zufrieden.
Contra:
- ein zusaetzliches automatisiertes commit am Tag (kann bei Sourceforge leicht schiefgehen)
- das von dir geschilderte Problem sollte eigentlich in statistics.cgi geloest werden. Leider traut sich keiner so recht statistics.cgi anzufassen.
Noch 'ne Meinung?
Zitat von: rudolfkoenig am 23 Mai 2016, 09:19:14
- das von dir geschilderte Problem sollte eigentlich in statistics.cgi geloest werden. Leider traut sich keiner so recht statistics.cgi anzufassen.
Mit trauen hat das nichts zu tun, mir fehlt einfach die Zeit, die bereots umgesetzten Änderungen weiter fortzuführen. Aber das Thema steht bei mir nach wie vor auf der ToDo Liste.
Mit
meiner Zufriedenheit hat das Ganze wenig zu tun. Wir hatten nur am Samstag beim Usertreffen in Köln über Alternativen zu update-Szenarien gesprochen. Und im Nachgang zu dieser Diskussion bin ich dann auf das "Problem" gestoßen. Für mich selbst habe ich ja einen workaround. Und da jemand, der das update über svn macht, ohnehin manuell Hand anlegen muss, um "fheminfo send" aufzurufen, kann man dann auch gleich den cronjob einbauen.
Mir ging es nur um die Einfachheit. Man könnte natürlich auch fheminfo.pm so umbauen, dass die Datei grundsätzlich per GetFileFromUrl() geholt wird und auf jeden Fall zur Verfügung steht. Aber das wäre noch mehr Aufwand :)
Hallo Rudi,
ich würde die statistics.cgi gerne überarbeiten. Ich habe mich mit Udo geeinigt, dass wir uns das teilen wollen. Ich würde das Frontend-CGI übernehmen sobald die Datenbank-Grundlage stimmt. Mit dem alten Datenbank-Design macht das keinen Sinn.
Mit dem neuen Datenbank-Design von Udo geht das schon deutlich schlanker. Es gibt aber noch zwei Kleinigkeiten die geändert werden müssten (ich glaube das war direkt in fheminfo).
Gruß
Markus
Nur zu :)
wenn ihr das angeht wäre es im schön wenn man auf der karte wieder die regionale verteilung der installationen sehen könnte und wenn es wieder eine möglichkeit gäbe die model information zu sehen
vielleicht wäre es auch nützlich die tatsächliche nutzung einzelner attribute einzusammeln um ein gefühl dafür zu bekommen wie wichtig manche features sind. nicht den gesetzten wert sondern nur ob ein attribut verwendet wird.
etwas das zur zeit nicht geht ist informationen über die nutzung zu bekommen die nicht an ein device gekoppelt ist. z.b. lässt sich nur indirekt (über die anzahl der HTTPSRV devices) rausfinden wie gross die nutzung alternativer frontends wie FTUI ist. nur über telnet oder longpoll angebundene dinge wie homebridge oder andere frontend apps lassen sich gar nicht erfassen.
gruss
andre
Zitat von: justme1968 am 26 Mai 2016, 19:14:51
vielleicht wäre es auch nützlich die tatsächliche nutzung einzelner attribute einzusammeln um ein gefühl dafür zu bekommen wie wichtig manche features sind. nicht den gesetzten wert sondern nur ob ein attribut verwendet wird.
Dann lass uns mal ein S/4 HANA mieten, damit wir die anfallenden Datenmengen bewältigen. Und das Registrieren ohne Wert macht schonmal überhaupt keinen Sinn.
das geht ganz sicher noch ohne HANA. das schafft auch sqlite oder postgres noch locker.
auch ohne wert gibt es aufschluss darüber ob ein attribut überhaupt verwendet wird.
aber du hast recht. ich hatte mit dem nicht speichern die freitext attribute im auge weil die eventuell persönliche daten wie accounts oder passwörter enthalten. für alle attribute die eine auswahl der möglichen werte erlauben ist das aber kein problem und man kann man den wert mit aufnehmen.
Wir bewegen uns hier inzwischen abseits des eigentlichen Themas, um das es hier im Thread ursprünglich ging. Da das ursprüngliche aktuelle Anliegen vermutlich ausser mir niemanden interessiert, ist das Thema für mich durch.