Meinungsbild - Fhem statistics (die 2.)

[Guest]

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

[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.

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

[Martin Fischer]

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

[Guest]

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

[LuckyDay]

                                         

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

[borsti67]

                                                 

> 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

[Matthias Gehre]

                                                       

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

[Joachim]

                                                   

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

[Guest]

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

[Guest]

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

[Guest]

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

[Guest]

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

[Guest]

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

[Guest]

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

[Guest]

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