Hallo @all,
am 31.10.2012 habe ich eine Meinungsbildabfrage zu einer angedachten
Erweiterung der update-Funktion gestartet.
Ich bedanke mich an dieser Stelle nochmals bei allen Teilnehmern und auch für
die eine oder andere hilfreiche Anregung.
Hier nochmal zur Erinnerung die Beschreibung der Erweiterung:
Die update-Funktion soll dahingehend erweitert werden, das im Rahmen eines
Updates anonymisiert Daten zu der installierten Fhem Version gesammelt werden.
Diese Daten sollen dazu dienen um Entwicklern aber auch dem interessierten
Anwender einen Überblick über die eingesetzte Hardware, Perlversion sowie die
jeweilge Anzahl der definierten Module zu verschaffen.
Die Statistik liefert ein ziemlich genaues Bild der Fhem-Umgebung um ggf.
Schwerpunkte im Rahmen der Entwicklungen abzuleiten.
Ich habe nun die letzten Tage genutzt um alles soweit umzusetzen, der
"Prototyp" ist so gut wie fertig.
Im Rahmen der ersten Abfrage haben einige von Euch den Wunsch geäussert, diese
Daten nicht ungefragt zu versenden. Andere haben widerum geäussert, das sie
damit kein Problem hätten.
Da natürlich eine statistische Erhebung nur dann sinnvolle Rückschlüsse
zulässt, wenn möglichst viele daran teilnehmen, möchte ich heute nochmals
final ein abschliessendes Meinungsbild abfragen.
Konkret: Übermittlung der Daten per default _an_
Ich würde mich freuen, wenn jeder der seine Meinung kundtun möchte, bitte nur
kurz und knapp seinen Standpunkt schildert. Eine "Grundsatzdiskussion" möchte
ich nach Möglichkeit an dieser Stelle vermeiden. Rein rechtlich gesehen, ist
die Erhebung der Daten unproblematisch, da keinerlei personenbezogenen Daten
erfasst werden.
Bevor Ihr nun aber Eure Meinungen kundtun, will ich Euch kurz den aktuellen
Stand und die Funktionsweise erklären:
fheminfo
"fheminfo" wird ein neuer Command in Fhem. Durch den Aufruf von "fheminfo"
kann der Anwender jederzeit die Informationen einsehen, die im Rahmen eines
Updates übertragen werden. Hier die aktuelle Ausgabe von fheminfo von einem
Produktivsystem:
fhem> fheminfo
Fhem info:
Release : 5.3
Branch : DEVELOPMENT
OS : linux
Arch : i686-linux-gnu-thread-multi-64int
Perl : v5.14.2
uniqueID : 2a5212a53f8c5c11771a973315213bfe
Defined modules:
ACU : 1
CUL : 1
CUL_FHTTK : 12
CUL_HM : 66
CUL_WS : 4
FHEM2FHEM : 1
FHEMWEB : 3
FHT : 9
FHZ : 1
FS20 : 23
FileLog : 31
Global : 1
HCS : 1
HMLAN : 1
HMS : 3
IPCAM : 4
KS300 : 1
OWAD : 1
OWCOUNT : 4
OWID : 1
OWMULTI : 1
OWSWITCH : 2
OWTHERM : 8
OWX : 1
Twilight : 1
Weather : 1
at : 4
autocreate : 1
dummy : 23
notify : 54
structure : 3
telnet : 2
watchdog : 9
weblink : 17
Defined models per module:
CUL : CUN
CUL_FHTTK : FHT80TF
CUL_HM : HM-CC-TC,HM-CC-VD,HM-LC-DIM1T-CV,HM-LC-DIM1T-FM,HM-LC-SW1-
PL,HM-LC-SW1-SM,HM-LC-SW2-FM,HM-LC_Dim1TPBU-FM,HM-OU-CFM-PL,HM-OU-LED16,HM-
PBI-4-FM,HM-SEC-MDIR,HM-SEC-RHS,HM-SEC-SD,HM-SWI-3-FM,HM-Sen-MDIR-O
CUL_WS : S555TH
FHT : fht80b
FS20 : fs20pira,fs20s16,fs20s4a,fs20sd,fs20st
HMS : hms100-mg,hms100-tf,hms100-wd
KS300 : ks300
OWSWITCH : DS2413
Die obigen Informationen sind selbsterklärend, mit Ausnahme der "uniqueID".
Die "uniqueID" wird benötigt um die jeweiligen Installationen auseinander zu
halten. Sie besteht aus 16 zufällig erzeugten Hashpaaren und sollte somit
weitgehends einmalig sein.
Die "uniqueID" wird beim ersten Aufruf automatisch erzeugt und als neues
globales Attribut in der Fhem Konfiguration gespeichert. Zusätzlich wird ein
weiteres globales Attribut "sendStatistics" angelegt, mit dem der Anwender
jederzeit entscheiden kann, ob die obige Statistik übermittelt werden soll.
Das ganze sieht dann in der Konfiguration wie folgt aus:
attr global uniqueID 2a5212a53f8c5c11771a973315213bfe
attr global sendStatistics 1
Wie oben bereits erwähnt halte ich es für sinnvoll das Attribut
"sendStatistics" per default auf "1", also auf "immer übermitteln" setzen.
Somit würde relativ schnell eine "gut gefüllte" Statistik zusammenkommen.
Was passiert nun Serverseitig?
Auf fhem.de werden obige Daten in einer SQLite Datenbank zusammengetragen. Die
Datenbank hat zur Zeit vier Tabellen:
fhem_nodes:
beinhaltet die unique id, ein "lastSeen" Feld, sowie die ip-adresse. Das
"lastSeen" dient zur (zukünftigen) Filterung von "Karteileichen". Man kann
also die Statistik anhand dieses Feldes auch "eingrenzen" (berücksichtige alle
Einträge die nicht älter als 1 Jahr sind) aber auch z.B. (wenn
"sendStatistics" per default auf "1" steht) ableiten wieviele Updates pro Tag
/ Woche / Monat / Jahr durchgeführt wurden. Aber auch die Anzahl der
Neuinstallationen könnte man daraus ableiten. Die IP-Adresse dient zur
Geolokalisierung, also in welchem Land wird Fhem eingesetzt. Daraus lässt sich
dann ableiten, wie und ob Fhem in Zukunft eine Mehrsprachigkeit unterstützen
soll und vorallem welche Sprachen. Da eine Geolokalisierung nur grob die
tatsächliche Lokalisierung liefert (obwohl z.B. ich in der 2. größten Stadt in
Niedersachsen lebe, werde ich fast immer einem Ort zugewiesen, der gerade mal
ein Fünftel so gross ist aber in der Nähe liegt.) ist auch diese
unproblematisch.
fhem_system:
beinhaltet neben der "uniqueID" alle obigen Punkte bzgl. "release", "OS",
"Architektur", "branch" sowie "Perlversion".
fhem_modules:
beinhaltet neben der "uniqueID" alle von der jeweiligen Fhem-Installation
definierten Module inkl. der Anzahl der Definitionen, wie aus der obigen
Übersicht zu entnehmen ist. Diese Daten sind dynamisch, d.h. sie werden
jedesmal überschrieben. Also wenn "meine" "uniqueID" heute übermittelt, das
ich 28 CUL_HM devices definiert habe, ich aber morgen 10 ausser Betrieb nehme,
dann werden auch nur 18 devices erfasst. Dadurch ist die Statistik immer
aktuell und z.B. "Testdefinitionen" oder die Löschung eines devices fällt
somit auch aus der Statistik.
fhem_models:
beinhaltet neben der "uniqueID" alle Modelltypen, die im Rahmen einer
Definition gesetzt sind. Bisher muss das Attribut "model" manuell durch den
Anwender gesetzt werden, sofern das jeweilige Fhem-Modul dieses Attribut
unterstützt. Ausnahme hierbei CUL_HM: hier wird das Model direkt aus der
Hardware ausgelesen und gesetzt. Somit hat man eine sehr gute Übersicht der
eingesetzten Hardware, allerdings ohne einer Gesamtzahl.
"fheminfo" soll neben der Möglichkeit über einen Befehlsaufruf in der
Commandline direkt am Ende eines Updates automatisiert aufgerufen werden. In
der Commandline unterstützt "fheminfo" das Argument "send", also "fheminfo
send". Somit hat man die Möglichkeit die Übermittlung auch manuell
anzustossen.
Die "uniqueID" kann / sollte bei einer komplettem "Reinstallation" nach
möglichkeit immer "mitgenommen", also wiederverwendet werden. Somit entsteht
keine "Karteileiche", da im Falle einer nicht vorhandenen "uniqueID" in der
Konfiguration von Fhem diese wieder neu erzeugt werden würde.
Um Euch einen Eindruck zu vermitteln wie die Daten künftig "aufbereitet"
werden sollen, füge ich einen Screenshot bei. Dies ist der erste "Entwurf" mit
ein paar Testdaten (nein ich habe kein Windows :-) ).
So, nun hoffe ich auf rege Teilnahme und denke ich konnte die Funktionsweise
transparent "rüber bringen", so dass die meisten Bedenken aus dem Wege geräumt
sind und dem automatischem Übertragen als default Einstellung nichts entgegen
steht.
In diesem Sinne...
Gruß Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Halte ich für sinnvoll, gut und unbedenklich.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ich schliesse mich LaLeLu an.... ich halte das auch für ok...
Am Samstag, 1. Dezember 2012 09:58:25 UTC+1 schrieb LaLeLu:
> Halte ich für sinnvoll, gut und unbedenklich.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
UniqID zusammen mit IP -hm?
Ich verstehe Deinen Ansatz, aber kannst Du nicht einfach nur das Ergebnis der IP, also den Ort oder besser wirklich nur das Land speichern?
Sonst würde ich eher zu default 'no' tendieren wollen.
Vielen dank.
Martin Fischer schrieb:
>Hallo @all,
>
>am 31.10.2012 habe ich eine Meinungsbildabfrage zu einer angedachten
>Erweiterung der update-Funktion gestartet.
>
>Ich bedanke mich an dieser Stelle nochmals bei allen Teilnehmern und
>auch für
>die eine oder andere hilfreiche Anregung.
>
>Hier nochmal zur Erinnerung die Beschreibung der Erweiterung:
>Die update-Funktion soll dahingehend erweitert werden, das im Rahmen
>eines
>Updates anonymisiert Daten zu der installierten Fhem Version gesammelt
>werden.
>Diese Daten sollen dazu dienen um Entwicklern aber auch dem
>interessierten
>Anwender einen Überblick über die eingesetzte Hardware, Perlversion
>sowie die
>jeweilge Anzahl der definierten Module zu verschaffen.
>
>Die Statistik liefert ein ziemlich genaues Bild der Fhem-Umgebung um
>ggf.
>Schwerpunkte im Rahmen der Entwicklungen abzuleiten.
>
>Ich habe nun die letzten Tage genutzt um alles soweit umzusetzen, der
>"Prototyp" ist so gut wie fertig.
>
>Im Rahmen der ersten Abfrage haben einige von Euch den Wunsch
>geäussert, diese
>Daten nicht ungefragt zu versenden. Andere haben widerum geäussert, das
>sie
>damit kein Problem hätten.
>
>Da natürlich eine statistische Erhebung nur dann sinnvolle Rückschlüsse
>
>zulässt, wenn möglichst viele daran teilnehmen, möchte ich heute
>nochmals
>final ein abschliessendes Meinungsbild abfragen.
>
>Konkret: Übermittlung der Daten per default _an_
>
>Ich würde mich freuen, wenn jeder der seine Meinung kundtun möchte,
>bitte nur
>kurz und knapp seinen Standpunkt schildert. Eine "Grundsatzdiskussion"
>möchte
>ich nach Möglichkeit an dieser Stelle vermeiden. Rein rechtlich
>gesehen, ist
>die Erhebung der Daten unproblematisch, da keinerlei personenbezogenen
>Daten
>erfasst werden.
>
>Bevor Ihr nun aber Eure Meinungen kundtun, will ich Euch kurz den
>aktuellen
>Stand und die Funktionsweise erklären:
>
>fheminfo
>
>"fheminfo" wird ein neuer Command in Fhem. Durch den Aufruf von
>"fheminfo"
>kann der Anwender jederzeit die Informationen einsehen, die im Rahmen
>eines
>Updates übertragen werden. Hier die aktuelle Ausgabe von fheminfo von
>einem
>Produktivsystem:
>
>fhem> fheminfo
>Fhem info:
> Release : 5.3
> Branch : DEVELOPMENT
> OS : linux
> Arch : i686-linux-gnu-thread-multi-64int
> Perl : v5.14.2
> uniqueID : 2a5212a53f8c5c11771a973315213bfe
>
>Defined modules:
> ACU : 1
> CUL : 1
> CUL_FHTTK : 12
> CUL_HM : 66
> CUL_WS : 4
> FHEM2FHEM : 1
> FHEMWEB : 3
> FHT : 9
> FHZ : 1
> FS20 : 23
> FileLog : 31
> Global : 1
> HCS : 1
> HMLAN : 1
> HMS : 3
> IPCAM : 4
> KS300 : 1
> OWAD : 1
> OWCOUNT : 4
> OWID : 1
> OWMULTI : 1
> OWSWITCH : 2
> OWTHERM : 8
> OWX : 1
> Twilight : 1
> Weather : 1
> at : 4
> autocreate : 1
> dummy : 23
> notify : 54
> structure : 3
> telnet : 2
> watchdog : 9
> weblink : 17
>
>Defined models per module:
> CUL : CUN
> CUL_FHTTK : FHT80TF
>CUL_HM : HM-CC-TC,HM-CC-VD,HM-LC-DIM1T-CV,HM-LC-DIM1T-FM,HM-LC-SW1-
>PL,HM-LC-SW1-SM,HM-LC-SW2-FM,HM-LC_Dim1TPBU-FM,HM-OU-CFM-PL,HM-OU-LED16,HM-
>PBI-4-FM,HM-SEC-MDIR,HM-SEC-RHS,HM-SEC-SD,HM-SWI-3-FM,HM-Sen-MDIR-O
> CUL_WS : S555TH
> FHT : fht80b
> FS20 : fs20pira,fs20s16,fs20s4a,fs20sd,fs20st
> HMS : hms100-mg,hms100-tf,hms100-wd
> KS300 : ks300
> OWSWITCH : DS2413
>
>Die obigen Informationen sind selbsterklärend, mit Ausnahme der
>"uniqueID".
>Die "uniqueID" wird benötigt um die jeweiligen Installationen
>auseinander zu
>halten. Sie besteht aus 16 zufällig erzeugten Hashpaaren und sollte
>somit
>weitgehends einmalig sein.
>
>Die "uniqueID" wird beim ersten Aufruf automatisch erzeugt und als
>neues
>globales Attribut in der Fhem Konfiguration gespeichert. Zusätzlich
>wird ein
>weiteres globales Attribut "sendStatistics" angelegt, mit dem der
>Anwender
>jederzeit entscheiden kann, ob die obige Statistik übermittelt werden
>soll.
>Das ganze sieht dann in der Konfiguration wie folgt aus:
>
>attr global uniqueID 2a5212a53f8c5c11771a973315213bfe
>attr global sendStatistics 1
>
>Wie oben bereits erwähnt halte ich es für sinnvoll das Attribut
>"sendStatistics" per default auf "1", also auf "immer übermitteln"
>setzen.
>Somit würde relativ schnell eine "gut gefüllte" Statistik
>zusammenkommen.
>
>Was passiert nun Serverseitig?
>
>Auf fhem.de werden obige Daten in einer SQLite Datenbank
>zusammengetragen. Die
>Datenbank hat zur Zeit vier Tabellen:
>fhem_nodes:
>beinhaltet die unique id, ein "lastSeen" Feld, sowie die ip-adresse.
>Das
>"lastSeen" dient zur (zukünftigen) Filterung von "Karteileichen". Man
>kann
>also die Statistik anhand dieses Feldes auch "eingrenzen"
>(berücksichtige alle
>Einträge die nicht älter als 1 Jahr sind) aber auch z.B. (wenn
>"sendStatistics" per default auf "1" steht) ableiten wieviele Updates
>pro Tag
>/ Woche / Monat / Jahr durchgeführt wurden. Aber auch die Anzahl der
>Neuinstallationen könnte man daraus ableiten. Die IP-Adresse dient zur
>Geolokalisierung, also in welchem Land wird Fhem eingesetzt. Daraus
>lässt sich
>dann ableiten, wie und ob Fhem in Zukunft eine Mehrsprachigkeit
>unterstützen
>soll und vorallem welche Sprachen. Da eine Geolokalisierung nur grob
>die
>tatsächliche Lokalisierung liefert (obwohl z.B. ich in der 2. größten
>Stadt in
>Niedersachsen lebe, werde ich fast immer einem Ort zugewiesen, der
>gerade mal
>ein Fünftel so gross ist aber in der Nähe liegt.) ist auch diese
>unproblematisch.
>
>fhem_system:
>beinhaltet neben der "uniqueID" alle obigen Punkte bzgl. "release",
>"OS",
>"Architektur", "branch" sowie "Perlversion".
>
>fhem_modules:
>beinhaltet neben der "uniqueID" alle von der jeweiligen
>Fhem-Installation
>definierten Module inkl. der Anzahl der Definitionen, wie aus der
>obigen
>Übersicht zu entnehmen ist. Diese Daten sind dynamisch, d.h. sie werden
>
>jedesmal überschrieben. Also wenn "meine" "uniqueID" heute übermittelt,
>das
>ich 28 CUL_HM devices definiert habe, ich aber morgen 10 ausser Betrieb
>nehme,
>dann werden auch nur 18 devices erfasst. Dadurch ist die Statistik
>immer
>aktuell und z.B. "Testdefinitionen" oder die Löschung eines devices
>fällt
>somit auch aus der Statistik.
>
>fhem_models:
>beinhaltet neben der "uniqueID" alle Modelltypen, die im Rahmen einer
>Definition gesetzt sind. Bisher muss das Attribut "model" manuell durch
>den
>Anwender gesetzt werden, sofern das jeweilige Fhem-Modul dieses
>Attribut
>unterstützt. Ausnahme hierbei CUL_HM: hier wird das Model direkt aus
>der
>Hardware ausgelesen und gesetzt. Somit hat man eine sehr gute Übersicht
>der
>eingesetzten Hardware, allerdings ohne einer Gesamtzahl.
>
>"fheminfo" soll neben der Möglichkeit über einen Befehlsaufruf in der
>Commandline direkt am Ende eines Updates automatisiert aufgerufen
>werden. In
>der Commandline unterstützt "fheminfo" das Argument "send", also
>"fheminfo
>send". Somit hat man die Möglichkeit die Übermittlung auch manuell
>anzustossen.
>
>Die "uniqueID" kann / sollte bei einer komplettem "Reinstallation" nach
>
>möglichkeit immer "mitgenommen", also wiederverwendet werden. Somit
>entsteht
>keine "Karteileiche", da im Falle einer nicht vorhandenen "uniqueID" in
>der
>Konfiguration von Fhem diese wieder neu erzeugt werden würde.
>
>Um Euch einen Eindruck zu vermitteln wie die Daten künftig
>"aufbereitet"
>werden sollen, füge ich einen Screenshot bei. Dies ist der erste
>"Entwurf" mit
>ein paar Testdaten (nein ich habe kein Windows :-) ).
>
>So, nun hoffe ich auf rege Teilnahme und denke ich konnte die
>Funktionsweise
>transparent "rüber bringen", so dass die meisten Bedenken aus dem Wege
>geräumt
>sind und dem automatischem Übertragen als default Einstellung nichts
>entgegen
>steht.
>
>In diesem Sinne...
>
>Gruß Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo Martin,
Am 01.12.2012 05:10, schrieb Martin Fischer:
> Konkret: Übermittlung der Daten per default _an_
>
für mich in Ordnung.
> fheminfo
>
>
hierzu drei Anmerkungen:
- In der c't gab es vor längerer Zeit einen Aufsatz zu der Frage, ob die
IP-Adresse ein personenbezogenes Datum sei. Diese Frage konnte nicht
verneint werden und die Empfehlung war m.W., IP-Adressen, wenn
überhaupt, nur pseudonymisiert zu speichern. Ich schlage vor, aus der
IP-Adresse die Geolokalisierung abzuleiten und dann wegzuwerfen.
- Ich schlage vor, zu jeder UniqueID einen Timestamp mitzuführen. Neben
der Möglichkeit, die Entwicklung und Schwerpunkte im Laufe der Jahre
mitzuverfolgen gibt es uns auch die Möglichkeit, über ein Aging der
Einträge potentiell nicht mehr aktive Installationen optional nicht mehr
in den Analysen zu berücksichtigen.
- Schreibt update die UniqueID hart in die Konfigurationsdatei nach dem
Verfahren, was angewendet wird, wenn der Save-Knopf gedrückt wird? Das
möchte ich nicht - ich habe den Save-Knopf bei mir verboten, weil ich
befürchte, daß meine Konfigurationsdateien dabei durcheinanderkommen.
Viele Grüße
Boris
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ohne Speicherung der übermittelten IP, also nur die Geo-Daten währe ich
auch dafür. IP-Adressen können Netzbetreiberintern einer Person zugeordnet
werden (innerhalb einer bestimmten Zeitspamme). Auch wenn es heist, dass
das nur die Polizei auf gerichtlicher Anordnung usw. darf, steht das
"könnte" nachwievor im Raum.
Zumal, was bringt euch die IP, da die sich im Regelfall aller 24h ändert.
Die könnt ihr für keinerlei Statistiken verwenden.
Gruß
Markus
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
hallo boris,
Am Samstag, 1. Dezember 2012, 10:36:19 schrieb Dr. Boris Neubert:
> [...]
> - Ich schlage vor, zu jeder UniqueID einen Timestamp mitzuführen. Neben
> der Möglichkeit, die Entwicklung und Schwerpunkte im Laufe der Jahre
> mitzuverfolgen gibt es uns auch die Möglichkeit, über ein Aging der
> Einträge potentiell nicht mehr aktive Installationen optional nicht mehr
> in den Analysen zu berücksichtigen.
das ist schon drin.. das ist das feld "lastSeen". ;-)
gruss
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Samstag, 1. Dezember 2012 12:43:58 UTC+1 schrieb joachim herold:
>
> Ich schliesse mich Markus an,
> Geo-Daten ja (sprachbezogen, also deutsch, englisch, etc.), IP-Speicherung
> Nein!
> Default on eigentlich ungern, und wenn, dann nur mit deutlichem Hinweis,
> dass Daten gesendet werden.
> Moegliche Loesung, im Rahmen des Updates den Benutzer fragen.
> Wenn z.B. spezielle Moduleigenbauten vorhanden sind, ist der Benutzer
> Eindeutig identifizierbar, hier muss eine Moeglichkeit gegeben sein, dieses
> Modul nicht mitzuuebermitteln.
>
Als Lösung würde ich vorschlagen nur die Module zu übertragen, welche eine
SVN $Id Zeile haben. Somit nur die offiziellen Module übertragen werden.
Ich hab beispielsweise ebenfalls eigene Module die ich für spezielle Sachen
nutze.
Gruß
Markus
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
IP Speicherung geht gar nicht (ich verwende z.b. statische IPs)
Ansonsten ginge "default on" gerade noch so.
On 1 Dez., 15:14, Markus Bloch wrote:
> Am Samstag, 1. Dezember 2012 12:43:58 UTC+1 schrieb joachim herold:
>
>
>
> > Ich schliesse mich Markus an,
> > Geo-Daten ja (sprachbezogen, also deutsch, englisch, etc.), IP-Speicherung
> > Nein!
> > Default on eigentlich ungern, und wenn, dann nur mit deutlichem Hinweis,
> > dass Daten gesendet werden.
> > Moegliche Loesung, im Rahmen des Updates den Benutzer fragen.
> > Wenn z.B. spezielle Moduleigenbauten vorhanden sind, ist der Benutzer
> > Eindeutig identifizierbar, hier muss eine Moeglichkeit gegeben sein, dieses
> > Modul nicht mitzuuebermitteln.
>
> Als Lösung würde ich vorschlagen nur die Module zu übertragen, welche eine
> SVN $Id Zeile haben. Somit nur die offiziellen Module übertragen werden.
> Ich hab beispielsweise ebenfalls eigene Module die ich für spezielle Sachen
> nutze.
>
> Gruß
> Markus
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ich bin für...
Default on.
Keine Speicherung der IP.
Eintrag der gesendeten Daten in der Log-Datei, ggf. über ein im Default eingeschaltetes Attribut abschaltbar.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Default on. Statt der IP direkt die Geodaten abspeichern.
Am 1. Dezember 2012 23:14 schrieb cge :
> Ich bin für...
> Default on.
> Keine Speicherung der IP.
> Eintrag der gesendeten Daten in der Log-Datei, ggf. über ein im Default
> eingeschaltetes Attribut abschaltbar.
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Samstag, 1. Dezember 2012 05:10:25 UTC+1 schrieb Martin Fischer:
>
> Wie oben bereits erwähnt halte ich es für sinnvoll das Attribut
> "sendStatistics" per default auf "1", also auf "immer übermitteln" setzen.
> Somit würde relativ schnell eine "gut gefüllte" Statistik zusammenkommen.
>
> Hallo Martin,
meine Meinung:
Ich halte es für bedenklich ohne Nachfrage beim Nutzer UniqueIDs,
IP-Adressen oder sonstiges per Default auf einen FHEM-Server zu schicken.
Sobald die UniqueID generiert ist, ist diese personenbezogen. Da reicht
schon, wenn ein User diese einmal nach FHEM users postet.
Bei der geringen Zahl FHEM-User würden allein schon Geo-Daten reichen, um
einen Nutzer zu identifizieren.
Der Benutzer muss generell zumindest einmal gefragt werden, bevor Daten
übertragen werden. Daei muss vorher angezeigt werden, welche Daten an
fhem.de übertragen werden sollen und zu welchem Zweck.
Wenn das nicht geht, muss das Senden der Daten ausgeschaltet werden.
Ich halte es nicht für gut Daten der FHEM-Benutzer zu speichern, nur weil
irgend jemand es schick findet, wenn wir Statistiken haben.
Ich möchte nicht auf diese Weise überwacht werden.
MfG Willi
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ich muss zugeben, dass ich mir das Thema FHEM-Statistik bisher nicht genau
angesehen habe.
Jetzt bin ich innerlich aufgewühlt, weil FHEM evtl. anfängt ohne Nachfrage
beim Benutzer Daten auf zentralen Servern zu sammeln.
Wer hat eigentlich Admin-Rechte auf dem Server fhem.de Server bzw. das
Recht Skripte zu installieren, die Daten sammeln?
Ich muss mal eine Nacht darüber schlafen, finde jedoch das geplante
Opt-Out-Verfahren für derzeit sehr bedenklich und mit meinen Grundsätzen
nicht vereinbar.
MfG Willi
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Samstag, 1. Dezember 2012 12:43:58 UTC+1 schrieb joachim herold:
> Wenn z.B. spezielle Moduleigenbauten vorhanden sind, ist der Benutzer
> Eindeutig identifizierbar, hier muss eine Moeglichkeit gegeben sein, dieses
> Modul nicht mitzuuebermitteln.
>
Wenn der Benutzer der Übersendung der Statistikdaten zugestimmt hat, dürfen
Modulnamen, wenn überhaupt, nur anhand einer Positivliste übertragen
werden. Auch ich verwende eigene Module und wäre darüber eindeutig
identifizierbar. Die Unterscheidung anhand des Kriteriums IDs ist nicht
ausreichend. Woher will der Benutzer wissen, dass dies das Kriterium ist?
Ich würde aber eher dafür stimmen keinerlei Modulinformationen zu
übertragen. Der Benutzer wird vermutlich über die Kombination der genutzten
Module identifizierbar sein. Zusammen mit der UniqueID kann man sogar das
Benutzervehalten herausfinden......
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hiya @all,
eigentlich wollte ich eine Grundsatzdiskussion vermeiden. Da hier aber doch
der eine oder andere Kommentar gekommen ist, möchte ich nun auch mal meine "2
cents" dazu äussern.
Datenschutz:
Wer sich mit dem Thema Datenschutz ernsthaft auseinander setzt, der wird
zwangsläufig über den § 4 des Bundesdateschutzgesetztes "stolpern":
§ 4 Zulässigkeit der Datenerhebung, -verarbeitung und -nutzung
(1) Die Erhebung, Verarbeitung und Nutzung personenbezogener Daten sind nur
zulässig, soweit dieses Gesetz oder eine andere Rechtsvorschrift dies erlaubt
oder anordnet oder der Betroffene eingewilligt hat.
(2) Personenbezogene Daten sind beim Betroffenen zu erheben. Ohne seine
Mitwirkung dürfen sie nur erhoben werden, wenn
1. eine Rechtsvorschrift dies vorsieht oder zwingend voraussetzt oder
2. a) die zu erfüllende Verwaltungsaufgabe ihrer Art nach oder der
Geschäftszweck eine Erhebung bei anderen Personen oder Stellen erforderlich
macht oder
b) die Erhebung beim Betroffenen einen unverhältnismäßigen Aufwand
erfordern würde und keine Anhaltspunkte dafür bestehen, dass überwiegende
schutzwürdige Interessen des Betroffenen beeinträchtigt werden.
(3) Werden personenbezogene Daten beim Betroffenen erhoben, so ist er, sofern
er nicht bereits auf andere Weise Kenntnis erlangt hat, von der
verantwortlichen Stelle über
1. die Identität der verantwortlichen Stelle,
2. die Zweckbestimmungen der Erhebung, Verarbeitung oder Nutzung und
3. die Kategorien von Empfängern nur, soweit der Betroffene nach den Umständen
des Einzelfalles nicht mit der Übermittlung an diese rechnen muss, zu
unterrichten. Werden personenbezogene Daten beim Betroffenen aufgrund einer
Rechtsvorschrift erhoben, die zur Auskunft verpflichtet, oder ist die
Erteilung der Auskunft Voraussetzung für die Gewährung von Rechtsvorteilen, so
ist der Betroffene hierauf, sonst auf die Freiwilligkeit seiner Angaben
hinzuweisen. Soweit nach den Umständen des Einzelfalles erforderlich oder auf
Verlangen, ist er über die Rechtsvorschrift und über die Folgen der
Verweigerung von Angaben aufzuklären.
Hier ist ganz klar von "Personenbezogenen Daten" die Rede. Der Befehl
"fheminfo" übersendet _absolut_ _keine_ _personenbezogenen_ _Daten_ wie hier
"befürchtet" wird. Darüber hinaus liegt der Quelltext offen, so dass jeder,
der irgendwelche bedenken hat, diesen einsehen kann.
Aufgrund einiger Anregungen wird auch serverseitig _keine_ _IP_ _Adresse_
gespeichert. Zugriff auf erhobenen Daten (OS, Architektur, Perl Version, FHEM
Version, Namen und Anzahl der definierten Module, Namen der definierten
Modelle, sowie die Geodaten) hat _ausschliesslich_ Rudolf König.
Die Geodaten basieren auf einer Geo-IP Datenbank mit einer Genauigkeit von ca.
40-80 km.
Alle erhobenen Daten kann der Anwender durch Aufruf von "fheminfo" einsehen
und selber entscheiden, ob er diese Informationen mittels "fheminfo send"
übertragen will. Wer dieses nicht möchte, ruft halt kein "fheminfo send" auf.
"fheminfo" wird nach einer initialen Testphase im Rahmen des update Prozesses
aufgerufen. Per Default werden dann diese Informationen gesendet. _ABER_ _NUR_
wenn das globale Attribut "sendStatistics" auf "1" steht.
Also auch im Falle von update hat der Anwender die volle Kontrolle über die
Übermittlung der Daten. Wer dies nicht möchte, setze "sendStatistics" auf "0".
Schon wird update _nichts_ übertragen.
Soviel zu der "technischen Umsetzung".
Nun jedoch mal meine persönliche Meinung als u.a. "Professional Certificate
Governance, Risk and Compliance ISO/IEC 27000" im Rahmen der internationalen
Norm ISO/IEC 27001 http://de.wikipedia.org/wiki/ISO/IEC_27001 der täglich bei
einem international tätigem Internet Service Provider u.a. für die gesamte
Datensicherheit zuständig ist. Und zu unseren Kunden gehört nicht "Lieschen
Müller" von neben an, sondern Bezirksregierungen, grosse Automobilunternehmen,
Banken und viele mehr. Soviel zu meinem persönlichem Background.
Ohne irgend jemand nahe treten zu wollen, denn das steht mir a) nicht zu und
b) liegt es mir fern, bin ich jedoch der Meinung, dass das Thema hier etwas
"überbewertet" wird. Jeder von uns surft täglich vielfach im Internet und
hinterlässt so viele personenbezogene Spuren (besonders die, die mit
statischer IP "unterwegs" sind) wie sonst nirgendwo im "realen Leben". Jeder
der ein Windows installiert, wird weitaus mehr Daten innerhalb einer Woche
übertragen als das es FHEM wahrscheinlich in seinem ganzen Lebenszyklus machen
wird. Zur Zeit werden gerade die ersten Rechner ausgeliefert, die in
Kombination mit Windows _hardwareseitig_ einen Key "eingepflanzt" bekommen.
Hier hat man nicht mal die Möglichkeit ein "sendStatistics" auf "0" zu setzen.
Die Informationen werden _immer_ übertragen. Wird hier dann jeder auf Windows
verzichten? Ich denke nein.
Das Thema Android und "ei"Phone und "ei"Pad, google, Fratzenbuch, Xing,
Stayfriends, etc. lasse ich mal komplett aussen vor.
Im Übrigen hätte man schon in der Vergangenheit allein durch die Auswertung
der Logfiles von fhem.de Informationen zu IP, Host, welche Module werden
geladen,etc. sammeln können.
Weiterhin setzt hier wohl ein Großteil Hardware auf Funkbasis ein, dessen
Protokoll _keinerlei_ Verschlüsselung bietet. Diese bieten weitaus mehr
Möglichkeiten personenbezogene Daten zu beziehen, wie z.B. Gewohnheiten und
mehr. Und diese kann ich dann auch einem im Haushalt lebendem Personenkreis
zuordnen.
Es wurden auch Argumente geliefert, dass anhand der Modulnamen eine
_eindeutige_ Zuordnung zu Personen gegeben ist. Dieser Argumentation kann ich
nicht folgen, es sein denn jemand nennt seine Module
"98_Martin_Fischer_Braunschweig.pm". Wenn nun ein Modul "98_foobar.pm"
existiert, dann ist hieraus _absolut_ _kein_ Rückschluss auf irgendeine Person
möglich. Man überzeuge mich von dem Gegenteil!
So könnte ich noch zig weitere Argumente liefern, denen auch zig andere
Argumente entgegen gehalten werden. Diese Diskussion kann man wahrscheinlich
_endlos_ weiterführen. Aber wir würden zu keinem Ergebniss kommen. Deshalb
möchte ich mich auch möglichst aus der weiteren Diskussion heraushalten, da
der Anwender proaktiv die Übermittlung deaktivieren kann.
Kurz nach der Ankündigung des neuen Befehls haben innerhalb von 30 Minuten die
ersten 5 Anwender ihre Daten übertragen. Es gibt also auch die Seite, die das
Übermitteln der Daten als hilfreich für FHEM ansehen. Denn genau darauf zielt
diese Statistik ab.
Sie ermöglicht den Entwicklern abzuschätzen, wie häufig "ihre" Module
eingesetzt werden. Es ermöglicht eine sehr genaue Übersicht auf welcher
Plattform FHEM mit welcher Perlversion zum Einsatz kommt. Darüber hinaus
ermöglicht die ungefähre Angabe der Geo bezogenen Daten einen Rückschluss auf
mögliche Übersetzungen um den Zugang zu FHEM zu erleichtern. Diese Merkmale
sind der alleinige Fokus bei der statistischen Auswertung.
All diese positiven Merkmale werden meiner Meinung nach etwas bei dieser
Diskussion verdrängt.
Aber wie gesagt: es steht ja jedem frei, diese Informationen zu senden. Keiner
wird gezwungen und FHEM wird die Daten (obwohl sie _nicht_ personenbezogen und
somit unbedenklich sind) ungefragt senden.
Einen Punkt nehme ich mir allerdings noch mit auf die TODO:
Die Aufführung von _nicht_ _offiziellen_ FHEM Modulen werde ich unterbinden,
da diese Module auch nicht von Interesse im Rahmen der Entwicklung von FHEM
sind.
Neben der Möglichkeit die Übermittlung der Daten über das Attribute
"sendStatistics" aktiv zu beeinflussen, besteht darüber hinaus auch die
Möglichkeit mittels "exclude_from_update" den Befehl "fheminfo" komplett
auszuschliessen und ihn lokal z.B. zu löschen oder umzubenennen. update wird
(wenn es dann soweit ist) vorab die Existenz von "fhemupdate" prüfen; und wenn
es den nicht gibt, kann update ihn auch nicht aufrufen. Aber selbst wenn er
exisitert, (ich wiederhole mich) wird ja "sendStatistics" geprüft.
Vielleicht konnte ich ein paar Zweifel aus dem Weg räumen. Und wenn mir das
hiermit nicht gelungen ist, dann wird es auch künftig nicht gelingen.
Somit soll das erstmal alles zu diesem Thema von meiner Seite sein. Ich denke,
ich habe genug Möglichkeiten aufgezeigt um einer Übermittlung der Daten "aus
dem Weg" zu gehen.
In der Hoffnung, das dennoch viele diese Funktionen nutzen um FHEM stetig zu
verbessern, wünsche ich weiterhin viel Spaß und Erfolg mit FHEM.
Gruß Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Montag, 3. Dezember 2012 00:56:34 UTC+1 schrieb Martin Fischer:
> eigentlich wollte ich eine Grundsatzdiskussion vermeiden. Da hier aber
> doch
>
Hallo Martin,
genau die möchte ich auch vermeiden. Daher möchte ich auch nicht darauf
eingehen. Nur ein dazu: Die Vergleiche mit den Providern passen m. E.
nicht. Wir haben hier ein Open-Source-Projekt (GPLv2) mit besonderen
moralischen Pflichten den Nutzern gegenüber. Mir ist nicht bewusst, dass
wir bei FHEM eine AGB haben, der der Benutzer vor der Nutzung von FHEM
zustimmen muss.
Wesentlich ist für mich, ob Du die Benutzer VOR der Übertragung mindestens
einmalig fragst, ob Sie der Übertragung der Daten zustimmen. Es sollte dem
Benutzer auch klar gemacht werden.
Hast Du das vor oder nicht?
MfG Willi
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo,
kurzer Vorschlag am Morgen: update könnte erst prüfen, ob es das Attribut sendStatistics gibt. Falls nein, gibt es kein update sondern den Hinweis, daß man das Attribut gemäß seiner persönlichen Präferenzen setzen möge.
Grüße
Boris
-------- Original-Nachricht --------
Von: Willi
Gesendet: Mon Dec 03 06:18:26 MEZ 2012
An: fhem-users@googlegroups.com
Betreff: Re: [FHEM] Meinungsbild - Fhem statistics (die 2.)
Am Montag, 3. Dezember 2012 00:56:34 UTC+1 schrieb Martin Fischer:
> eigentlich wollte ich eine Grundsatzdiskussion vermeiden. Da hier aber
> doch
>
Hallo Martin,
genau die möchte ich auch vermeiden. Daher möchte ich auch nicht darauf
eingehen. Nur ein dazu: Die Vergleiche mit den Providern passen m. E.
nicht. Wir haben hier ein Open-Source-Projekt (GPLv2) mit besonderen
moralischen Pflichten den Nutzern gegenüber. Mir ist nicht bewusst, dass
wir bei FHEM eine AGB haben, der der Benutzer vor der Nutzung von FHEM
zustimmen muss.
Wesentlich ist für mich, ob Du die Benutzer VOR der Übertragung mindestens
einmalig fragst, ob Sie der Übertragung der Daten zustimmen. Es sollte dem
Benutzer auch klar gemacht werden.
Hast Du das vor oder nicht?
MfG Willi
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
--
sent from my WePad - apologies for brevity
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am Montag, 3. Dezember 2012, 07:01:50 schrieb Dr. Boris Neubert:
> Hallo,
>
> kurzer Vorschlag am Morgen: update könnte erst prüfen, ob es das Attribut
> sendStatistics gibt. Falls nein, gibt es kein update sondern den Hinweis,
> daß man das Attribut gemäß seiner persönlichen Präferenzen setzen möge.
und genau so wird es auch implementiert. boris ist hellseher ;-)
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
default on ist für mich in Ordnung,
Speicherung der IP geht nicht, da es statische IPs gibt
Boris Vorschlag, beim Update einen Hinweistext anzuzeigen, der mit ja oder
nein beantwortet werden kann und entsprechend (automatisiert) die Attribute
gesetzt werden, halte ich für eine gute Idee
Am Samstag, 1. Dezember 2012 05:10:25 UTC+1 schrieb Martin Fischer:
>
> Hallo @all,
>
> am 31.10.2012 habe ich eine Meinungsbildabfrage zu einer angedachten
> Erweiterung der update-Funktion gestartet.
>
> Ich bedanke mich an dieser Stelle nochmals bei allen Teilnehmern und auch
> für
> die eine oder andere hilfreiche Anregung.
>
> Hier nochmal zur Erinnerung die Beschreibung der Erweiterung:
> Die update-Funktion soll dahingehend erweitert werden, das im Rahmen eines
> Updates anonymisiert Daten zu der installierten Fhem Version gesammelt
> werden.
> Diese Daten sollen dazu dienen um Entwicklern aber auch dem interessierten
> Anwender einen Überblick über die eingesetzte Hardware, Perlversion sowie
> die
> jeweilge Anzahl der definierten Module zu verschaffen.
>
> Die Statistik liefert ein ziemlich genaues Bild der Fhem-Umgebung um ggf.
> Schwerpunkte im Rahmen der Entwicklungen abzuleiten.
>
> Ich habe nun die letzten Tage genutzt um alles soweit umzusetzen, der
> "Prototyp" ist so gut wie fertig.
>
> Im Rahmen der ersten Abfrage haben einige von Euch den Wunsch geäussert,
> diese
> Daten nicht ungefragt zu versenden. Andere haben widerum geäussert, das
> sie
> damit kein Problem hätten.
>
> Da natürlich eine statistische Erhebung nur dann sinnvolle Rückschlüsse
> zulässt, wenn möglichst viele daran teilnehmen, möchte ich heute nochmals
> final ein abschliessendes Meinungsbild abfragen.
>
> Konkret: Übermittlung der Daten per default _an_
>
> Ich würde mich freuen, wenn jeder der seine Meinung kundtun möchte, bitte
> nur
> kurz und knapp seinen Standpunkt schildert. Eine "Grundsatzdiskussion"
> möchte
> ich nach Möglichkeit an dieser Stelle vermeiden. Rein rechtlich gesehen,
> ist
> die Erhebung der Daten unproblematisch, da keinerlei personenbezogenen
> Daten
> erfasst werden.
>
> Bevor Ihr nun aber Eure Meinungen kundtun, will ich Euch kurz den
> aktuellen
> Stand und die Funktionsweise erklären:
>
> fheminfo
>
> "fheminfo" wird ein neuer Command in Fhem. Durch den Aufruf von "fheminfo"
> kann der Anwender jederzeit die Informationen einsehen, die im Rahmen
> eines
> Updates übertragen werden. Hier die aktuelle Ausgabe von fheminfo von
> einem
> Produktivsystem:
>
> fhem> fheminfo
> Fhem info:
> Release : 5.3
> Branch : DEVELOPMENT
> OS : linux
> Arch : i686-linux-gnu-thread-multi-64int
> Perl : v5.14.2
> uniqueID : 2a5212a53f8c5c11771a973315213bfe
>
> Defined modules:
> ACU : 1
> CUL : 1
> CUL_FHTTK : 12
> CUL_HM : 66
> CUL_WS : 4
> FHEM2FHEM : 1
> FHEMWEB : 3
> FHT : 9
> FHZ : 1
> FS20 : 23
> FileLog : 31
> Global : 1
> HCS : 1
> HMLAN : 1
> HMS : 3
> IPCAM : 4
> KS300 : 1
> OWAD : 1
> OWCOUNT : 4
> OWID : 1
> OWMULTI : 1
> OWSWITCH : 2
> OWTHERM : 8
> OWX : 1
> Twilight : 1
> Weather : 1
> at : 4
> autocreate : 1
> dummy : 23
> notify : 54
> structure : 3
> telnet : 2
> watchdog : 9
> weblink : 17
>
> Defined models per module:
> CUL : CUN
> CUL_FHTTK : FHT80TF
> CUL_HM : HM-CC-TC,HM-CC-VD,HM-LC-DIM1T-CV,HM-LC-DIM1T-FM,HM-LC-SW1-
> PL,HM-LC-SW1-SM,HM-LC-SW2-FM,HM-LC_Dim1TPBU-FM,HM-OU-CFM-PL,HM-OU-LED16,HM-
>
> PBI-4-FM,HM-SEC-MDIR,HM-SEC-RHS,HM-SEC-SD,HM-SWI-3-FM,HM-Sen-MDIR-O
> CUL_WS : S555TH
> FHT : fht80b
> FS20 : fs20pira,fs20s16,fs20s4a,fs20sd,fs20st
> HMS : hms100-mg,hms100-tf,hms100-wd
> KS300 : ks300
> OWSWITCH : DS2413
>
> Die obigen Informationen sind selbsterklärend, mit Ausnahme der
> "uniqueID".
> Die "uniqueID" wird benötigt um die jeweiligen Installationen auseinander
> zu
> halten. Sie besteht aus 16 zufällig erzeugten Hashpaaren und sollte somit
> weitgehends einmalig sein.
>
> Die "uniqueID" wird beim ersten Aufruf automatisch erzeugt und als neues
> globales Attribut in der Fhem Konfiguration gespeichert. Zusätzlich wird
> ein
> weiteres globales Attribut "sendStatistics" angelegt, mit dem der Anwender
> jederzeit entscheiden kann, ob die obige Statistik übermittelt werden
> soll.
> Das ganze sieht dann in der Konfiguration wie folgt aus:
>
> attr global uniqueID 2a5212a53f8c5c11771a973315213bfe
> attr global sendStatistics 1
>
> Wie oben bereits erwähnt halte ich es für sinnvoll das Attribut
> "sendStatistics" per default auf "1", also auf "immer übermitteln" setzen.
> Somit würde relativ schnell eine "gut gefüllte" Statistik zusammenkommen.
>
> Was passiert nun Serverseitig?
>
> Auf fhem.de werden obige Daten in einer SQLite Datenbank
> zusammengetragen. Die
> Datenbank hat zur Zeit vier Tabellen:
> fhem_nodes:
> beinhaltet die unique id, ein "lastSeen" Feld, sowie die ip-adresse. Das
> "lastSeen" dient zur (zukünftigen) Filterung von "Karteileichen". Man kann
> also die Statistik anhand dieses Feldes auch "eingrenzen" (berücksichtige
> alle
> Einträge die nicht älter als 1 Jahr sind) aber auch z.B. (wenn
> "sendStatistics" per default auf "1" steht) ableiten wieviele Updates pro
> Tag
> / Woche / Monat / Jahr durchgeführt wurden. Aber auch die Anzahl der
> Neuinstallationen könnte man daraus ableiten. Die IP-Adresse dient zur
> Geolokalisierung, also in welchem Land wird Fhem eingesetzt. Daraus lässt
> sich
> dann ableiten, wie und ob Fhem in Zukunft eine Mehrsprachigkeit
> unterstützen
> soll und vorallem welche Sprachen. Da eine Geolokalisierung nur grob die
> tatsächliche Lokalisierung liefert (obwohl z.B. ich in der 2. größten
> Stadt in
> Niedersachsen lebe, werde ich fast immer einem Ort zugewiesen, der gerade
> mal
> ein Fünftel so gross ist aber in der Nähe liegt.) ist auch diese
> unproblematisch.
>
> fhem_system:
> beinhaltet neben der "uniqueID" alle obigen Punkte bzgl. "release", "OS",
> "Architektur", "branch" sowie "Perlversion".
>
> fhem_modules:
> beinhaltet neben der "uniqueID" alle von der jeweiligen Fhem-Installation
> definierten Module inkl. der Anzahl der Definitionen, wie aus der obigen
> Übersicht zu entnehmen ist. Diese Daten sind dynamisch, d.h. sie werden
> jedesmal überschrieben. Also wenn "meine" "uniqueID" heute übermittelt,
> das
> ich 28 CUL_HM devices definiert habe, ich aber morgen 10 ausser Betrieb
> nehme,
> dann werden auch nur 18 devices erfasst. Dadurch ist die Statistik immer
> aktuell und z.B. "Testdefinitionen" oder die Löschung eines devices fällt
> somit auch aus der Statistik.
>
> fhem_models:
> beinhaltet neben der "uniqueID" alle Modelltypen, die im Rahmen einer
> Definition gesetzt sind. Bisher muss das Attribut "model" manuell durch
> den
> Anwender gesetzt werden, sofern das jeweilige Fhem-Modul dieses Attribut
> unterstützt. Ausnahme hierbei CUL_HM: hier wird das Model direkt aus der
> Hardware ausgelesen und gesetzt. Somit hat man eine sehr gute Übersicht
> der
> eingesetzten Hardware, allerdings ohne einer Gesamtzahl.
>
> "fheminfo" soll neben der Möglichkeit über einen Befehlsaufruf in der
> Commandline direkt am Ende eines Updates automatisiert aufgerufen werden.
> In
> der Commandline unterstützt "fheminfo" das Argument "send", also "fheminfo
> send". Somit hat man die Möglichkeit die Übermittlung auch manuell
> anzustossen.
>
> Die "uniqueID" kann / sollte bei einer komplettem "Reinstallation" nach
> möglichkeit immer "mitgenommen", also wiederverwendet werden. Somit
> entsteht
> keine "Karteileiche", da im Falle einer nicht vorhandenen "uniqueID" in
> der
> Konfiguration von Fhem diese wieder neu erzeugt werden würde.
>
> Um Euch einen Eindruck zu vermitteln wie die Daten künftig "aufbereitet"
> werden sollen, füge ich einen Screenshot bei. Dies ist der erste "Entwurf"
> mit
> ein paar Testdaten (nein ich habe kein Windows :-) ).
>
> So, nun hoffe ich auf rege Teilnahme und denke ich konnte die
> Funktionsweise
> transparent "rüber bringen", so dass die meisten Bedenken aus dem Wege
> geräumt
> sind und dem automatischem Übertragen als default Einstellung nichts
> entgegen
> steht.
>
> In diesem Sinne...
>
> Gruß Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Meine Meinung,
Ich habe kein Problem damit, dir einen Fingerabdruck mit meiner config
zu schicken,
aber, nicht mit jedem Update. (Sammelwahn)
Ich will einfach JEDESMAL gefragt werden, ob ich schicke oder nicht.
wenn es nur global geht mit--> "sendStatistics" auf "1"
dann wird bei mir es auf "0" stehen.
Somit bekommst du von mir keine Daten --> deine Statistik ist somit
nicht aussagekräftig.
bzw unvollständig.
Gut finde ich, dass du keine IP speicherst, kann dich niemand dazu
zwingen sie heraus zu geben.
Hary
On 3 Dez., 07:47, Martin Fischer wrote:
> Am Montag, 3. Dezember 2012, 07:01:50 schrieb Dr. Boris Neubert:
>
> > Hallo,
>
> > kurzer Vorschlag am Morgen: update könnte erst prüfen, ob es das Attribut
> > sendStatistics gibt. Falls nein, gibt es kein update sondern den Hinweis,
> > daß man das Attribut gemäß seiner persönlichen Präferenzen setzen möge.
>
> und genau so wird es auch implementiert. boris ist hellseher ;-)
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> aber, nicht mit jedem Update. (Sammelwahn)
wann, wenn nicht beim Update, denn sonst (vernünftigerweise)? Wobei man
theoretisch testen könnte, ob die Daten sich seit dem letzten Update
verändert haben, bevor man sie abschickt - aber dagegen spricht nicht nur
der Aufwand, sondern auch, dass ja auch die AKTIVEN Installationen wichtig
sind. Wenn man nur 1x was geschickt hat und dann nie wieder, ist die Info
(fast) wertlos.
Ich will einfach JEDESMAL gefragt werden, ob ich schicke oder nicht.
>
unter der Prämisse dass das Update immer von Hand angestoßen wird, würde
ich das auch noch als denkbaren Weg ansehen. Z.B. mit einem Parameter -
"update ichwillnichtzurstatistikbeitragen" oder so. ;-)
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Oder
attr sendStatistics askEveryTime
Am 3. Dezember 2012 12:51 schrieb Tom :
> > aber, nicht mit jedem Update. (Sammelwahn)
>
> wann, wenn nicht beim Update, denn sonst (vernünftigerweise)? Wobei man
> theoretisch testen könnte, ob die Daten sich seit dem letzten Update
> verändert haben, bevor man sie abschickt - aber dagegen spricht nicht nur
> der Aufwand, sondern auch, dass ja auch die AKTIVEN Installationen wichtig
> sind. Wenn man nur 1x was geschickt hat und dann nie wieder, ist die Info
> (fast) wertlos.
>
> Ich will einfach JEDESMAL gefragt werden, ob ich schicke oder nicht.
>>
>
> unter der Prämisse dass das Update immer von Hand angestoßen wird, würde
> ich das auch noch als denkbaren Weg ansehen. Z.B. mit einem Parameter -
> "update ichwillnichtzurstatistikbeitragen" oder so. ;-)
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo Martin,
Ich freue mich schon auf die ostfriesische Variante von FHEM, denn nur
dafuer wird eine so feine Geolokalisierung gebraucht.
Sollte eine Ostfriesische Variante nicht angedacht sein reicht eine
Geolokalisierung fuer deutsch, englisch, franzoesisch, etc. volkommen aus.
alles andere ist in Meinen Augen "Sammelwahn" (tschuldigung, nich
persoenlich gemeint).
Ich selbst aucht eigentlich schon darauf, welche Daten ich wo und wann zur
Verfuegung stelle.
Es gibt Gruende, dass ich nicht bei Facebook o.a. bin, dass mein Handy ca.
10 Jahre alt ist (eben kein Smartphone). Es war schon schlimm genug, dass
ich fuer google.groups mehr preisgeben musste als ich wollte. In Verbindung
mit der Tatsache, dass auch fuer nichtangemeldete Internetbenutzer meine
E-Mailadresse im klartext zu sehen war.
Ich glaube, gerade open Source Software sollte sehr vorsichtig mit Daten
umgehen, und eben nicht den Fehler von Microsoft, Apple und Konsorten
machen.
Zur Zeit denke ich, wird die Datenuebersendung abgeschaltet bleiben.
Gruss Joachim
Am Samstag, 1. Dezember 2012 05:10:25 UTC+1 schrieb Martin Fischer:
>
> Hallo @all,
> ..........
> Die IP-Adresse dient zur
> Geolokalisierung, also in welchem Land wird Fhem eingesetzt. Daraus lässt
> sich
> dann ableiten, wie und ob Fhem in Zukunft eine Mehrsprachigkeit
> unterstützen
> soll und vorallem welche Sprachen. Da eine Geolokalisierung nur grob die
> tatsächliche Lokalisierung liefert (obwohl z.B. ich in der 2. größten
> Stadt in
> Niedersachsen lebe, werde ich fast immer einem Ort zugewiesen, der gerade
> mal
> ein Fünftel so gross ist aber in der Nähe liegt.) ist auch diese
> unproblematisch.
> ............
> In diesem Sinne...
>
> Gruß Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Martin,
Soviel zu der "technischen Umsetzung".
Bin einverstanden.
Optional könnte man vielleicht noch über einen "Fernlöschknopf" nachdenken
für diejenigen, welche später ihre Datenübermittlung widerrufen möchten.
Aber das wäre für mich nicht zwingend.
Ciao
Gerhard
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Default_on ist für mich völlig in Ordnung!
Alex
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Lieber Martin,
Deinen persönlichen Background in allen Ehren - aber wir sind hier nicht
bei einem Internetprovider, und das Argument "Es wird doch sowieso schon
alles gesammelt" ist nun wirklich in dieser Diskussion nicht valide.
Eben _weil_ die statistische Information über die Nutzung von FHEM sehr
wertvolle Hinweise liefert (z.B. darüber, welche Geräte nachgefragt
werden...), muss vor dem Einsatz dieser Datensammlung sehr genau definiert
werden:
1. Wer hat Zugriff auf die einzelnen Daten, die von einem Nutzer XYZ zum
Zeitpunkt t gesendet wurden ?
2. Wer hat Zugriff auf die aggregierten Daten ?
3. Wer ist verantwortlich für die gesammelten Daten, kann eventuell auch
die im Bundesdatenschutzgesetz verankerte Löschung durchführen ?
4. Wie erfolgt die ebenfalls gesetzlich geregelte Information der
Teilnehmer darüber, welche Daten über sie gesammelt worden sind ?
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ich würde die Daten auf jeden Fall schicken, bin aber der Meinung dass die
default Einstellung auf "nicht senden" gehört. Du schreibst "Rein rechtlich
gesehen, ist die Erhebung der Daten unproblematisch, da keinerlei
personenbezogenen Daten erfasst werden." Laut einem Urteil des EuGH
(http://curia.europa.eu/juris/liste.jsf?language=de&num=C-70/10) sind IP
Adressen aber sehr wohl personenbezogene Daten, diese solltest Du also
besser nicht ohne die bewusste Einwilligung der "Betroffenen" sammeln.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
...einfach beim erstmaligen Aufruf der Funktion einen Disclaimer
einblenden, den jeder mit "Accepted" anklicken muss und einen zweiten
Button mit der Message "Don't show this in the future".
Mal ehrlich: in der Zeit von Twitter, Facebook und millionen von Apps die
auf Mobiltelefonen Daten sammeln, ist fhem nun wirklich kein bedenkliches
Tool mit fragwürdigem Hintergrund.
Aber mann kann wirklich alles zerpflücken, wenn man es unbedingt will.
Bleibt doch mal etwas locker. Opt-in oder Opt-out ist doch nun wirklich
Banane.
VG
Ralf
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Dienstag, 4. Dezember 2012 12:01:08 UTC+1 schrieb dou...@m1n1.de:
>
>
> Mal ehrlich: in der Zeit von Twitter, Facebook und millionen von Apps die
> auf Mobiltelefonen Daten sammeln,
>
Nur weil "die" das tun, muss Fhem es nicht (genau) so halten.
> ist fhem nun wirklich kein bedenkliches Tool mit fragwürdigem Hintergrund.
>
"ist" .... noch?
Und für eine evtl.erforderliche Sprachunterstützung erscheint mir eine
Geolokalisierung per IP wenig hilfreich, denn ich habe auch hier im Forum
schon von dem ein oder anderen im Ausland lebenden Deutschen oder in
Deutschland lebenden Ausländer gelesen. Eine Heranziehung der
System-Locale, unter Linux z..B. "LANG=de_DE" (unter Windows / OSx wird es
Pendants geben), dürfte für diesen Zweck besser geeignet sein. Zumal auch
nach meinem Kenntnisstand die IP-Adresse ein personenbezogenes Datum ist.
Im Datenschutz geht es auch immer darum nur die erforderlichen Daten
("Datenminimierung") für eine Aufgabe zu erheben. Und erforderlich ist die
IP definitiv nicht.
Aber mann kann wirklich alles zerpflücken, wenn man es unbedingt will.
>
Moment.... War da nicht die Bitte um Rückäußerung im ersten Beitrag dieses
Threads????
> Bleibt doch mal etwas locker. Opt-in oder Opt-out ist doch nun wirklich
> Banane.
>
Was "Banane" ist, liegt hier wohl nur im Auge des Betrachters. Du hast
deine Sicht der Dinge, aber die anderen Argumente mit einem Obst
gleichzusetzen und damit diskreditieren zu wollen ist kein netter Zug in
einer gewollten / sachlichen Diskussion. Besser ist - gerade in solchen
Fällen wie dem aktuellen - die *vorherige* Erörterung.
Gruß
Thomas
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Du hast natürlich recht, Thomas!
Ich habe meinen Beitrag ganz bewusst so flachsig verfasst, um der
Diskussion auch mal wieder die Schärfe zu nehmen. Das ist sicherlich nicht
sachlich, aber vielleicht zweckdienlich. :-)
VG
Ralf
>
>
>> Bleibt doch mal etwas locker. Opt-in oder Opt-out ist doch nun wirklich
>> Banane.
>>
>
> Was "Banane" ist, liegt hier wohl nur im Auge des Betrachters. Du hast
> deine Sicht der Dinge, aber die anderen Argumente mit einem Obst
> gleichzusetzen und damit diskreditieren zu wollen ist kein netter Zug in
> einer gewollten / sachlichen Diskussion. Besser ist - gerade in solchen
> Fällen wie dem aktuellen - die *vorherige* Erörterung.
>
> Gruß
> Thomas
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Habe keine Bedenken solange die IP nicht gespeichert wird. Weiterhin macht
es in meinen Augen (außer für Stammtischtreffen ;) ) keinen Sinn, wo in
Deutschland die einzelnen User sind. Sprich es reicht, wenn man eine
Landesübersicht, oder ähnliches macht.
Da der Quelltext ja offen ist (dank Perl) kann es von meiner Seite in der
Trunk Version ruhig default on sein. Die Personen die die SVN Version
benutzten sind tendenziell eher informiert und auch in der Lage das Feature
abzuschalten.
Bei der Tag Version von FHEM bezweifle ich, dass es auf Grund des niedrigen
Updateintervalls überhaupt Sinn macht, die Daten zu sammeln.
Ich denke die gesammelten Daten haben absolut ihre Berechtigung, denn
sobald ein komplettes Refactoring ansteht, müssen Prioritäten gesetzt
werden und da ist es dann von Vorteil, wenn man die Benutzung der Module
weiß.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Ich finde alle datenschutzrechtlichen Bedenken zur 'Veröffentlichung' von
fhem-Daten haben Ihre Berechtigung. Ich gebe auch nur ungern meine Daten
preis, und tue das deshalb sehr restritiv.
Hier bin ich allerdings ziemlich gelassen, finde es nett zu sehen, wo die
Kommilitonen alle sitzen, und over all hilft es der Entwicklung, weil
Präferenzen erkennbar werden.
Ein Einverständnis, dass diese Daten von mir jetzt übergeben werden mit
Abwahlmöglichkeit sollte aber sein.
Jorge
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Noch einmal die Frage:
Wer hat Zugriff auf die Daten ?
Wer ist Verantwortlicher für die Einhaltung der gesetzlichen Regelungen ?
Vor einer Beantwortung dieser Fragen sollte niemand seine Daten
herausrücken.
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ich finde die Diskussion gut und konstruktiv. Sie muss geführt werden.
Weiterhin finde ich es völlig unschädlich, wenn ich Daten aus fhem in der
beschriebenen Form durch fheminfo herausgebe. Was kann man ernsthaft mit
dem Wissen anfangen, dass ich x Temperatursensoren und y Heizungen habe
oder welche Module ich nutze? Wir reden hier nicht über persönliche Daten.
Was soll man hiermit anfangen? Und wenn ich es doch glauben würde, dann
würde ich eben die Übertragung sperren.
Mir persönlich ist es auch völlig egal, wenn dies mit einer täglich
wechselnden IP abgespeichert würde.
Ich sage dass, obwohl ich auch sehr vorsichtig mit den von mir ins Internet
gegebenen Daten bin.
Trotzdem kann ich den Bedenken insoweit folgen, dass mir der Nutzen der
IP-Übertragung unklar ist.
Vielleicht bringt diese Idee etwas Entspannung:
- In einem Attribut könnte man die Wunschsprache für das How-To etc.
definieren, dadurch könnte einerseits direkt die Sprache Deutsch oder
Englisch angezeigt werden und andererseits könnte diese Sprache übermittelt
werden. Ist nicht Deutsch oder Englisch eingetragen, wird Englisch als
Anzeigesprache gewählt. Trotzdem sind die Wunschsprachen auswertbar. Man
muss sich diese nur ansehen. Unübersehbar viele werden sicher nicht
eingetragen werden.
- In einem weiteren Attribut könnte optional der Ort oder die Postleitzahl
oder das Bundesland eingetragen werden. Man sollte jedoch nur eine Info
anfordern. Dies könnte dann übertragen werden. Jeder könnte entscheiden, ob
er diesen Eintrag macht oder nicht. Für die anderen Statistiken ist die
Information jedenfalls nicht wirklich wichtig.
LaLeLu
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am Dienstag, 4. Dezember 2012, 12:27:10 schrieb Prof. Dr. Peter A. Henning:
> [...]
> Wer hat Zugriff auf die Daten ?
> Wer ist Verantwortlicher für die Einhaltung der gesetzlichen Regelungen ?
peter, um mit der gleiche art und weise zu antworten, wie du hier oft
"herumpolterst":
die fragen wurden, sogar mit erwähnung der person beantwortet. daher hilft an
dieser stelle auch mal das lesen und nicht nur "überfliegen".
btw.: wenn ich mich recht entsinne, bist du nicht "unserer"
datenschutzbeauftragte, so wie du boris die tage "belehrt" hast, er sei nicht
"unser" cto und mich schon des öfteren darauf hingewiesen hast, das ich nicht
"der projektleiter" bin.
manchmal ist es halt so: wie es in den wald schreit....
davon abgesehen, habe ich alles(!) komplett offengelegt. jeder hat die volle
transparenz und kann sogar den quelltext einsehen. siehe dazu:
contrib/statistics/statistics.cgi
zur zeit ist die übermittlung nur durch proaktiven aufruf des befehls fheminfo
möglich. und ob es tatsächlich in das "update" wandert ist noch gar nicht
final geklärt. es ist _angedacht_ und dazu gehören auch noch weitere prüfungen
zur rechtssicherheit.
und wer zur zeit keine daten übertragen möchte, der überträgt sie halt nicht.
keiner wird ihm daher böse sein!
nach den anfänglich geäusserten bedenken bzgl. der IP speicherung, habe ich
diesen _konstruktiven_ vorschlag aufgegriffen und _vor_ veröffentlichung des
befehls fheminfo entfernt. diese wird also nicht gespeichert, wie ich auch
berichtet habe. siehe dazu thread "neuer befehl fheminfo".
einen weiteren punkt habe ich mir noch auf die TODO genommen:
die in der fhem.cfg hinterlegte uniqueID werde ich in eine separate datei
auslagern, damit diese (obwohl damit absolut keiner was anfangen kann, selbst
wenn er weiss, das meine ID f0c143c1295fb7d56b0561d6e9394dd6 lautet; und das
ist sogar eine meiner realen IDs) nicht "versehentlich" hier gepostet wird.
wenn man also _konstruktive_ vorschläge unterbreitet, dann werden die in der
regel auch umgesetzt. und an dieser stelle bedanke ich mich für alle
rückmeldungen egal ob positiv oder negativ (auch wenn einige davon für _mich_
nicht nachvollziehbar sind) sowie den konstruktiven vorschlägen.
im übrigen gehöre _ich_ nicht zu dem kreis, der auf seine meinung beharrt. und
genau deshalb ist der ganze "fall" zur "prüfung und bewertung" beim
landesbeauftragten für den datenschutz" von mir vorgelegt wurden, um hier
rechtssicherheit zu haben. und _diese_ person ist für mich ausschlaggebend!
dessen antwort warte ich derzeit ab und werde darüber berichten. und bevor
hier weitere mutmassungen geäussert werden:
ja, auch ich nehme das thema _sehr_ ernst, wie man vielleicht der diskussion
entnehmen kann. auch wenn es das eine oder andere mal anders dargestellt wird.
deshalb sollte man sich auch alle informationen diesbzgl. durchlesen, _bevor_
man hier eine "revolution" anzettelt.
auch kann ich deine antwort schon voraussehen.. denn auch du bewegst dich
mittlerweile sehr transparent im internet, besonders in den fhem gruppen. ich
könnte mir den spass machen, deine antwort vorzuformulieren, abzulegen und
wenn du dann antwortest, mit meiner "vorlage" zu vergleichen.. ich bin mir
sicher, das sie zu 70-80% inhaltlich die gleichen punkte in der zu erwartenen
art aufführt.
und ja, sorry für die direkten worte und das ich gerade dich direkt
anspreche... irgendwann kommt halt der zeitpunkt, wo auch ich (so wie
inzwischen einige andere anwender wie entwickler) langsam die geduld mit
deiner belehrenden art verliere. viele anwender und entwickler sind hier
absolute experten (zum teil auch mit akademischem grad und lehrstuhl) in
gewissen fachbereichen. man sollte also nicht immer davon ausgehen, das wir
alle "keine ahnung" haben, wovon wir schreiben und ohne sachverstand an die
themen gehen. es gibt hier keinen, der sich mit seinen errungenschaften wie
"mehrfach ausgezeichneter pädagoge, mitwirkung an iso standards,
millionenaufträge in der eu" etc. brüstet. mit ausnahme einer person.
besonders als "person des öffentlichen lebens" sollte man sich auch manchmal
damit befassen, wie man von anderen wahrgenommen wird. und auch daran
arbeiten.. eigenbild, fremdbild und feedback sind die "zauberworte". wen es
interessiert, der kann das gerne bei wikipedia nachlesen (auch wenn das keine
offzielle "wissenschaftliche" abhandlung ist). es verschafft einem zumindest
ein "gefühl" worum es dabei geht. man spricht da auch im zusammenhang von
"geben und nehmen".
abschliessend ende ich mit einem zitat von dir, das du am 03.12. auf ein
feedback von willi geschrieben hast (nachzulesen in fhem-developers):
"Verhaltenskorrekturen kannst Du bei Deinen Kindern anbringen."
in diesem sinne, bin ich wahrscheinlich eine weitere person auf deiner
persönlichen "blacklist", denn "angedroht" hast du mir das ja schon vor
einiger zeit. ich kann damit leben, denn einen willen von _konstruktiver_
zusammenarbeit deinerseits kann ich leider schon lange nicht mehr ableiten..
martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Martin,
sehr gute Antwort! Ich empfinde es genau so.
@pah
Bitte setze mich auch auf Deine blacklist.
LaLeLu
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Soso, schon wieder glaubt jemand mit u.a. "Professional Certificate
Governance, Risk and Compliance ISO/IEC 27000" .. "der täglich bei
einem international tätigem Internet Service Provider u.a. für die gesamte
Datensicherheit zuständig ist" und "grosse Automobilunternehmen,
Banken und viele mehr" als Kunden hat, er müsse mir Verhaltensratschläge
geben. Eher lustig, das.
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
bingo!
ich sach nur 70% und "message nicht verstanden"...
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Du solltest vielleicht Elterbeirat im Kindergarten werden - da werden diese
kommunikativen "Fähigkeiten" stark nachgefragt :-))
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Diese Art und Weise ist einfach unterirdisch und eine Beleidigung für jeden
Teilnehmer hier, der konstruktiv beitragen möchte.
Warum suchen sie sich nicht einfach nen anderen Spielplatz? Wenn ich das
hier richtig sehe, nimmt die Zahl derer, die sich durch ihre Art gestört
fühlen, täglich zu.
Ich weiss zwar nicht was noch passieren muss, damit jemand wie sie mal zum
Nachdenken kommt, aber so herausragend sind ihrer Leistungen nicht, das man
nicht auf Sie verzichten könnte, denn -seien wir ehrlich- mehr als einige
Zeilen Code (dessen Basis noch nicht mal auf ihrem Mist gewachsen ist) und
ne Menge Copy-Paste, ohne die Quellen ehrlicherweise zu nennen (Na? Wo kam
mir das noch gleich bekannt vor?) haben sie hier nicht vorzubringen, oder?
Vermissen würde ich sie mit Sicherheit nicht - aber mich über die Ruhe
freuen, die dann hier sicherlich Einzug hält.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Alles sehr lustig, und niemand lacht darüber mehr als ich - aber die Frage
steht immer noch im Raum:
Wer hat Zugriff auf die Daten ?
Wer ist Verantwortlicher für die Einhaltung der gesetzlichen Regelungen ?
Ist doch erstaunlich, was auf eine sachliche Frage hin so alles passiert.
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Aaaalso -
als ich im April in das Forum einstieg war ich ganz angetan über das
freundliche, nicht zu ausschweifende und lösungsorientierte Klima.
Seinerzeit und auch heute noch vorwiegend war das ein krasser Gegensatz zu
anderen Foren, in denen letztlich nur noch aufeinander herumgehackt wurde.
Das Forum hat schon sehr oft geholfen und mich eingefangen, sofern
gedanklich falsch abgebogen.
DANKE dafür an alle! Fantastisch, wieviel Wo-/manpower bisher drinsteckt.
Vor einigen Tagen habe ich in freier Entscheidung und aktiv die Erweiterung
"fheminfo" bei mir eingebaut und aktiv die Übertragung angestoßen. Ich
konnte vorher und nachher unter
http://fhem.de/stats/statistics.cgi
die Verbreitung von FHEM verfolgen und beobachte mit Spannung, ob sich
regionale Schwerpunkte herausstellen. Spannend warte ich auf weitere
"Auslandseinsätze". Die dort häufig genannten Module sind gleichzeitig
Anreize für eigene zukünftigen Erweiterungen.
Mit der Erweiterung habe ich somit überhaupt keine Probleme.
Als Idee evtl. noch:
- Aktivieren/deaktivieren auch per Maske einstellen können, ohne in Konfigs
einzusteigen.
- 3-stufiges Verfahren: Button anklicken "fheminfo", Daten anzeigen, Button
klicken "jetzt übertragen"
Grüße an alle und bleibt ruhig,
Stefan
Am Mittwoch, 5. Dezember 2012 14:56:59 UTC+1 schrieb dou...@m1n1.de:
>
>
> Diese Art und Weise ist einfach unterirdisch und eine Beleidigung für
> jeden Teilnehmer hier, der konstruktiv beitragen möchte.
>
> Warum suchen sie sich nicht einfach nen anderen Spielplatz? Wenn ich das
> hier richtig sehe, nimmt die Zahl derer, die sich durch ihre Art gestört
> fühlen, täglich zu.
> Ich weiss zwar nicht was noch passieren muss, damit jemand wie sie mal zum
> Nachdenken kommt, aber so herausragend sind ihrer Leistungen nicht, das man
> nicht auf Sie verzichten könnte, denn -seien wir ehrlich- mehr als einige
> Zeilen Code (dessen Basis noch nicht mal auf ihrem Mist gewachsen ist) und
> ne Menge Copy-Paste, ohne die Quellen ehrlicherweise zu nennen (Na? Wo kam
> mir das noch gleich bekannt vor?) haben sie hier nicht vorzubringen, oder?
>
> Vermissen würde ich sie mit Sicherheit nicht - aber mich über die Ruhe
> freuen, die dann hier sicherlich Einzug hält.
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
hallo stefan,
danke für das feedback..
Am Mittwoch, 5. Dezember 2012, 07:04:42 schrieb bsl:
> [...]
> als ich im April in das Forum einstieg war ich ganz angetan über das
> freundliche, nicht zu ausschweifende und lösungsorientierte Klima.
und genau so bin ich es seit 2008 auch gewohnt.. es kommt aber auch mal die
zeit, wo man einfach nur genug von gewissen verhaltensweisen hat...
> [...]
> Als Idee evtl. noch:
> - Aktivieren/deaktivieren auch per Maske einstellen können, ohne in Konfigs
> einzusteigen.
> - 3-stufiges Verfahren: Button anklicken "fheminfo", Daten anzeigen, Button
> klicken "jetzt übertragen"
bei deinem vorschlag, sowie anderen vorschlägen, die sich immer auf ein
"button" mit anklicken oder anderen interaktionen mit dem user beziehen, dürft
ihr bitte eins nicht vergessen:
fhem ist eigentlich rein commandline (via telnet) basiert. FHEMWEB (sowie
andere guis) waren in den jahren lediglich "erweiterungen" um die bedienung
über die commandline auch über einen browser zugänglich zu machen und
darzustellen.
im rahmen der "grossen umstrukturierung" mit der 5.3 haben boris, rudi und ich
FHEMWEB zum standard gui als festen bestandteil der distribution befördert.
vor der 5.3 konnte der anwender also entscheiden ob er fhem "standalone" oder
mit pgm2 (FHEMWEB) installieren möchte.
von daher muss alles, was in einer GUI läuft dennoch auch in der commandline
variante funktionieren. und da kann man bekanntlich nicht auf einen "BUTTON"
klicken. ausserdem gibt es zur zeit eine trennung der verantwortlichkeiten.
FHEMWEB wird im wesentlichen (mit unterstützung von boris) von rudi verwaltet.
daher müsste, wenn überhaupt, rudi so etwas in FHEMWEB "überführen" und ich
bin mir fast sicher, das er sich darauf so freuen wird, wie ein kind vorm
"schwarzen mann". wobei letzteres bitte nicht diskriminierend zu sehen ist
sondern im deutschen sprachgebrauch als synonym für eine
"kinderschreckfigur"[1] steht.
gruss martin
[1] http://de.wikipedia.org/wiki/Kinderschreckfigur
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Mittwoch, 5. Dezember 2012 15:53:50 UTC+1 schrieb Prof. Dr. Peter A.
Henning:
> Alles sehr lustig, und niemand lacht darüber mehr als ich - aber die Frage
> steht immer noch im Raum:
>
> Wer hat Zugriff auf die Daten ?
> Wer ist Verantwortlicher für die Einhaltung der gesetzlichen Regelungen ?
>
> Ist doch erstaunlich, was auf eine sachliche Frage hin so alles passiert.
>
Es wäre ja schön, wenn Du bei sachlichen Fragen bleiben würdest. Dann würde
sich auch jemand Deine Argumente anhören und mit Dir diskutieren wollen.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo Martin (und natürlich auch allen anderen),
erstmal vielen Dank an alle "Schöpfer" von FHEM und an dieses Forum!
Gerade für mich als echter Anfänger eine große Hilfe!!!!!!!!!!!
Da das atm die einzige Möglichkeit ist hier ein wenig beizusteuern, würde
ich die die
Funktion begrüssen. Da die Daten meines Erachtens unverfänglich sind "so
what". Ich
bin dabei. :)
Allerdings kann ich den Einwand auch verstehen, das es vieleicht der ein
oder andere nicht
möchte. Daher wäre ein Default off vieleicht die richtige Variante.....
Gruß
Stefan
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Nun, dann wäre es doch ganz interessant, die sachliche Antwort auf diese
Fragen zu kennen - aus den Posts jedenfalls lässt sich diese Antwort nicht
ziehen.
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
>
>
> So, per update habe ich nun auch fheminfo erhalten und per 'fheminfo send'
durchgeführt. Die von mir gesendeten Daten sind direkt in die Statistik auf
http://fhem.de/stats/statistics.cgi. eingeflossen.
Ich finde die Darstellung der Ergebnisse sehr gut. Prima finde ich auch,
dass die Ergebnisse der Statistiken für jedermann offen verfügbar sind. Ich
kann nichts Negatives an dem Verfahren erkennen.
LaLeLu
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo,
ich hab mich gestern auch dazu "hinreissen" lassen und fheminfo und danach
ein
fheminfo send durchgeführt.
Ich hab mit den übermittelten Infos keine Probleme.
Grüße
Am Donnerstag, 6. Dezember 2012 06:51:06 UTC+1 schrieb LaLeLu:
>
>
>> So, per update habe ich nun auch fheminfo erhalten und per 'fheminfo
> send' durchgeführt. Die von mir gesendeten Daten sind direkt in die
> Statistik auf http://fhem.de/stats/statistics.cgi. eingeflossen.
>
> Ich finde die Darstellung der Ergebnisse sehr gut. Prima finde ich auch,
> dass die Ergebnisse der Statistiken für jedermann offen verfügbar sind. Ich
> kann nichts Negatives an dem Verfahren erkennen.
>
> LaLeLu
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Huh??
"Your browser does not support charts"??
FF 17.0... Allerdings ist die Kennung ausgeschaltet, also ein "unknown
browser". Das sollte doch die Charts nicht beeinflussen. Die sollten
doch an den Anfrager gesendet werden - so oder so??
Gruß
Am 08.12.2012 13:59, schrieb puschel74:
> Hallo,
>
> ich hab mich gestern auch dazu "hinreissen" lassen und fheminfo und
> danach ein
> fheminfo send durchgeführt.
> Ich hab mit den übermittelten Infos keine Probleme.
>
> Grüße
>
> Am Donnerstag, 6. Dezember 2012 06:51:06 UTC+1 schrieb LaLeLu:
>
>
> So, per update habe ich nun auch fheminfo erhalten und per
> 'fheminfo send' durchgeführt. Die von mir gesendeten Daten sind
> direkt in die Statistik auf http://fhem.de/stats/statistics.cgi
> . eingeflossen.
>
> Ich finde die Darstellung der Ergebnisse sehr gut. Prima finde ich
> auch, dass die Ergebnisse der Statistiken für jedermann offen
> verfügbar sind. Ich kann nichts Negatives an dem Verfahren erkennen.
>
> LaLeLu
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Ich schliesse mich Markus an,
Geo-Daten ja (sprachbezogen, also deutsch, englisch, etc.), IP-Speicherung
Nein!
Default on eigentlich ungern, und wenn, dann nur mit deutlichem Hinweis,
dass Daten gesendet werden.
Moegliche Loesung, im Rahmen des Updates den Benutzer fragen.
Wenn z.B. spezielle Moduleigenbauten vorhanden sind, ist der Benutzer
Eindeutig identifizierbar, hier muss eine Moeglichkeit gegeben sein, dieses
Modul nicht mitzuuebermitteln.
gruss Joachim
Am Samstag, 1. Dezember 2012 12:18:25 UTC+1 schrieb Markus Bloch:
>
> Ohne Speicherung der übermittelten IP, also nur die Geo-Daten währe ich
> auch dafür. IP-Adressen können Netzbetreiberintern einer Person zugeordnet
> werden (innerhalb einer bestimmten Zeitspamme). Auch wenn es heist, dass
> das nur die Polizei auf gerichtlicher Anordnung usw. darf, steht das
> "könnte" nachwievor im Raum.
>
> Zumal, was bringt euch die IP, da die sich im Regelfall aller 24h ändert.
> Die könnt ihr für keinerlei Statistiken verwenden.
>
> Gruß
> Markus
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com