Neues FHEM-Modul "Things"

[Guest]

Originally posted by: <email address deleted>

Hallo an alle,

in einem anderen Thread<https://groups.google.com/forum/?fromgroups#!searchin/fhem-users/Uli$20Zappe/fhem-users/LlP37nPlRbM/Q35AcSNEKQEJ>hatte ich gefragt, wie man das
*dummy*-Modul so benutzen kann, dass durch Klick auf das Glühbirnensymbol
wie auch bei anderen Modulen üblich zwischen *on* und *off* umgeschaltet
werden kann. Hintergrund war, dass ich gerne auch Geräte konsistent in die
Weboberfläche integrieren würde, die nicht über über ein CUL o.ä.
angesteuert werden, sondern über Netzwerkbefehle. Ein Beispiel wäre, einen
Computer (z.B. einen Medienserver) aufzuwecken (= *on*) und schlafenzulegen
(= *off*). Das *dummy*-Modul, so meine Hoffnung, würde dann nach außen
gegenüber dem Nutzer ,,ein Gerät wie alle anderen auch" anzeigen, während es
intern über *notify* beliebige im Programmcode erzeugte Aktionen ausführen
könnte.

Das funktionierte auch bis eben auf die Tatsache, dass das *dummy*-Modul
bei Klick auf die Glühbirne immer nur ein-, nie aber ausschaltet.
Ausgerechnet für den *Smallscreen*-Modus, ideal für Touch-Fernbedienungen,
ist es damit unbrauchbar.

Es stellte sich in diesem Thread heraus, dass sich mein Wunsch mit dem *
dummy*-Modul in seiner heutigen Form schlicht nicht erfüllen lässt. Ich
bekam aber den Tipp, dass auch ,,normale" Module wie *FS20*, *IT* etc., bei
denen der Klick auf die Glühbirne wie gewünscht funktioniert, ein *dummy*-Attribut
haben, dass eine tatsächliche Ausführung eingegebener Befehle via FS20, IT
etc. verhindert, so dass sich ein solches Modul mit *dummy*-Attribut für
meine Zwecke ,,missbrauchen" ließe.

Um mit meinen real existierenden FS20-Modulen auf keinen Fall ins Gehege zu
kommen, habe ich daher diese Pseudo-*dummy*-Geräte mit dem IT-Modul
realisiert. (*InterTechno*-Geräte habe ich keine, nicht einmal ein CUL mit
der nötigen Frequenz dafür.) Das funktionierte vom Ergebnis her wie
gewollt, nur gab es in der Logdatei laufend Fehlermeldungen (kein IODevice
etc.).

Nachdem ich sehr viele solcher *dummy*-Geräte anlegen will und auf Dauer
nicht auf dieses Provisorium bauen wollte, habe ich daher jetzt ein eigenes
Modul dafür geschrieben, das ich auf den generischen Namen *Things* getauft
habe (nach *Internet of Things*).

Mit *Things* definierte Geräte verhalten sich im Gegensatz zu mit *dummy*definierten wie ,,vollwertige" Aktoren, inklusive dem wechselnden Ein- und
Ausschalten durch Klick auf das Glühbirnensymbol. Ansonsten tut *Things*aber wie gesagt schlicht nichts; die wirklichen Aktionen müssen via
*notify* ausgelöst werden.

Hier ein Beispiel für einen Video-Projektor, der über Ethernet gesteuert
werden kann. Ein kleines Perl-Skript */usr/local/bin/projector* erzeugt die
zum Aufwecken und Schlafenlegen des Projektors (mit dem Hostnamen *projector
* im lokalen Netzwerk und dem Port *23*) erforderlichen Bitfolgen (aus dem
Projektor-Handbuch entnommen); dabei reagiert es der Konsistenz mit FHEM
halber auf die Parameter *on* und *off*:

*/usr/local/bin/projector*
*
*

*
#!/usr/bin/perl -w
*
*

*
*
use IO::Socket;
*
*

*
*
if ($#ARGV != 0)
*
*
{
*
*
print "Usage: projector on|off\n"; exit -1;
*
*
}
*
*

*
*
$SOCK = new IO::Socket::INET (PeerAddr => 'projector', PeerPort => '23',
Proto => 'tcp');
*
*
die "Could not create socket: $!\n" unless $SOCK;
*
*

*
*
if ($ARGV[0] eq "on")
*
*
{
*
*
print $SOCK "\xbe\xef\x03\x06\x00\xba\xd2\x01\x00\x00\x60\x01\x00";
*
*
}
*
*
elsif ($ARGV[0] eq "off")
*
*
{
*
*
print $SOCK "\xbe\xef\x03\x06\x00\x2a\xd3\x01\x00\x00\x60\x00\x00";
*
*
}
*
*
else
*
*
{
*
*
print "Usage: projector on|off\n"; close($SOCK); exit -1;
*
*
}
*
*

*
*
close($SOCK);
*

*

*
Die zugehörige Definition in FHEM lautet mit *Things* nun:

define Projektor Things
attr Projektor room Kino

define ProjektorOn notify Projektor:on "/usr/local/bin/projector on"
attr ProjektorOn room Internal Objects

define ProjektorOff notify Projektor:off "/usr/local/bin/projector off"
attr ProjektorOff room Internal Objects


Wenn man nun z.B. mit dem FS20-Sender *Projektor_SENDER* den Projektor
aufwecken und schlafenlegen will, so definiert man:

define Projektor_PAIR notify Projektor_SENDER set Projektor %
attr Projektor_PAIR room Internal Objects


Das Gerät *Projektor* lässt sich also nach obiger Definition fortan wie
jeder ,,reale" FS20-Aktor mit einem FS20-Sender koppeln.

*Drei Hinweise:*

   1. Wie bei allen anderen Geräten auch funktioniert auch bei *Things* das
   wechselseitige Ein- und Ausschalten durch Klick auf die Glühbirne erst,
   wenn das neu definierte Gerät von *Unsorted* in einen Raum verschoben
   worden ist, sofern für das *FHEMWEB*-Objekt *longpoll = 1* gesetzt wurde.
   2. Wie bei allen anderen Geräten auch funktioniert auch bei *Things* das
   wechselseitige Ein- und Ausschalten durch Klick auf die Glühbirne leider
   nicht mehr, sobald das Attribut *webCmd* definiert ist. Das ist ein Bug
   in FHEM.
   3. *Things* kennt alle Befehle, die auch FS20 kennt. Das dient nur der
   universellen Einsetzbarkeit für *notify* und hat keinerlei weitere
   Bedeutung, da ja keiner dieser Befehle irgendetwas bewirkt.

Schließlich möchte ich noch darauf hinweisen, dass ich vom internen Aufbau
von FHEM so gut wie gar nichts verstehe und das mein erster Verusch war,
ein Modul zu erstellen. Alten Hasen mag es bei dem Code also zu Recht
grausen. Bei mir zumindest tut er aber genau, was er soll.

Ich habe keine Ahnung, wie das bei FHEM mit Commits gehandhabt wird,
deswegen hänge ich den Code für *Things* einfach an dieses Posting an.
Einfach die Datei *99_Things.pm* nach */usr/share/fhem/FHEM/* kopieren, und
es sollte funktionieren.

Wenn viele das Modul nützlich finden sollten, kann es gerne in die
Distribution aufgenommen werden. Verbesserungen sind natürlich ebenso
willkommen.

Uli

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Guten Morgen,

erster Verbesserungsvorschlag: Modul umbenennen. Der Modulname sollte
irgendetwas mit dem Gerät oder der Funktion zu tun haben. Sogar "dummy"
sagt mehr aus, als "Things".

LG

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Am Sonntag, 20. Mai 2012 06:40:49 UTC+2 schrieb Prof. Dr. Peter A. Henning:
>
> erster Verbesserungsvorschlag: Modul umbenennen. Der Modulname sollte
> irgendetwas mit dem Gerät oder der Funktion zu tun haben. Sogar "dummy"
> sagt mehr aus, als "Things".
>
Hmmm, also Namen sind nun wirklich Geschmacksache. Ich halte den Namen für
ausgesprochen gelungen, denn erstens ist es eben ein absolut generisches
Modul; über Funktion und Gerät ist *nichts* bekannt. Und zweitens ist *
Things* seit der hochkochenden Debatte über das *Internet of Things* in
meinen Ohren hoch mit sehr passenden Assoziationen aufgeladen.

Uli

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Erstens: Es gibt keine "hochkochende Debatte" um das Internet of Things -
sondern nur eine Vielzahl von Forschungsprojekten. Unter anderem derzeit
drei aus meinem Team. Nenn doch einfach mal Deine drei letzten
Publikationen auf dem Gebiet, dann können wir ja auf wissenschaftlicher
Ebene diskutieren.

Zweitens: Es ist unseriös, einen Modulnamen mit "Assoziationen
aufzuladen".  Das ist  der Stil der "Computer BILD".

Drittens: "Thing" ist die Oberklasse für alle Konzepte in
ontologiebschreibenden Sprachen wie etwa OWL. Definitionsgemäß ein Konzept
ohne Attribute. Das oben beschriebene Modul hat aber diverse Attribute, es
ist keineswegs "absolut generisch".

Schließlich: Seine eigenen Schöpfungen für "ausgesprochen gelungen" zu
halten, ist nun wirklich keine Kunst. Wenn man sich aber dem Urteil anderer
unterwirft, sollte man auch auf deren Äußerungen hin etwas nachdenken.

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Jetzt bin ich doch etwas geplättet von dem Umgangston hier – also
jedenfalls von Deinem, Peter. Ich wollte einfach etwas an die Community
zurückgeben, nachdem ich selbst viel von FHEM profitiert habe und recht
begeistert davon bin. Auf solche Animositäten, und noch dazu wegen eines
schlichten Namens, hatte ich eigentlich keine Lust ...

Erstens: Es gibt keine "hochkochende Debatte" um das Internet of Things -
> sondern nur eine Vielzahl von Forschungsprojekten.


Aha.

Ich sehe, Du streitest generell sehr gerne um Worte. Eine ,,Vielzahl von
Forschungsprojekten" und eine ,,hochkochende Debatte" sind Facetten
derselben Entwicklung, zeitlich leicht versetzt. Wenn Du sehr in die
akademische Seite der Entwicklung eingebunden bist, fehlt Dir vielleicht
einfach der Blick von außen, um festzustellen, dass das Thema jüngst in den
Mainstream-Medien stark zunehmende Beachtung gefunden hat. Das habe ich mit
"hochkochen" beschrieben.
 

> Unter anderem derzeit drei aus meinem Team.


Ich bin beeindruckt.

Nenn doch einfach mal Deine drei letzten Publikationen auf dem Gebiet, dann
> können wir ja auf wissenschaftlicher Ebene diskutieren.
>

Ach so, mit Würmern, die nicht in Deinem Forschungsgebiet tätig sind,
redest Du erst gar nicht?

Welches Gebiet, übrigens? Die Natur- und Ingenieurwissenschaften, die sich
mit der technischen Implementation des *Internet of Things* befassen, oder
die Humanwissenschaften, die sich über adäquate Namensgebung technischer
Artefakte Gedanken machen? Einschlägig wäre hier ja letzteres.

Meine diesbezüglichen wissenschaftlichen Meriten beschränken sich leider
auf Sozialphilosophie und Techniksoziologie. Sorry, dass ich Dir da nicht
das Wasser reichen kann.

Wissenschaftlich über einen Namen diskutieren . Aber damit Du Ruhe
gibst:

*Das Ende des Konsums in der Informationsgesellschaft*, in: Fischer, Peter
/ Hubig, Christoph / Koslowski, Peter (Hg.): *Wirtschaftsethische Fragen
der E-Economy*, Heidelberg (Physica) 2003 (englisch: *The End of
Consumption in Information Society*, in: *Business Ethics and the
Electronic Economy*, Berlin/Heidelberg/New York (Springer) 2004)

*Vom spielerischen Ernst des Programmierens*, in: Gehring, Robert A. /
Lutterbeck, Bernd (Hg.): *Open Source Jahrbuch 2004. Zwischen
Softwareentwicklung und Gesellschaftsmodell*, Berlin (Lehmanns Media) 2004

*Spielothek und Wahrheit*, in: Peter Koslowski / Birger P. Priddat (Hg.): *Ethik
des Konsums*, Paderborn (Wilhelm Fink) 2006

Zweitens: Es ist unseriös, einen Modulnamen mit "Assoziationen
> aufzuladen".  Das ist  der Stil der "Computer BILD".
>

Die *Computer BILD* gibt sich mit der Benennung von Modulnamen ab? Wusste
ich gar nicht ...

,,Seriosität" ist ein habitueller Terminus der herrschenden Elite und
insofern aus meiner Perspektive ganz sicher nicht erstrebenswert.

Assoziationsräume hingegen sind eine wichtige Möglichkeit, Technologie den
Nutzern zugänglich zu machen.

Gretchenfrage: Welchen Namen findest Du besser für Multicast DNS: *mDNS*oder
*Bonjour*? Mein Votum ginge wenig überraschend an *Bonjour*.

Drittens: "Thing" ist die Oberklasse für alle Konzepte in
> ontologiebschreibenden Sprachen wie etwa OWL.


Wovon wie viele Nutzer von FHEM etwas wissen? Die sehen in der momentanen
Implementation der Weboberfläche aber die Modulnamen sogar als gruppierende
Überschrift ...

Schließlich: Seine eigenen Schöpfungen für "ausgesprochen gelungen" zu
> halten, ist nun wirklich keine Kunst.


Habe ich auch nicht behauptet. Ich nehme einfach das Recht des Vaters in
Anspruch, sein Baby zu taufen. *:–)*  Und alle anderen finden den gewählten
Namen dann üblicherweise doof, ist immer so ...

Wenn man sich aber dem Urteil anderer unterwirft,


Wo habe ich gesagt, dass ich das tue?

Einem Urteil, das in einem Ton wie das Deine daherkommt, ,,unterwerfe" (was
für ein Ausdruck!) ich mich ganz sicher nicht ...

sollte man auch auf deren Äußerungen hin etwas nachdenken.
>

Habe ich getan. Und stell Dir vor, trotzdem bin ich nicht zu demselben
Ergebnis gekommen wie Du.

So, und jetzt packen wir unsere Profilneurosen wieder in das kleine
Köfferchen und benehmen uns wieder wie zivilisierte Menschen oder gehen
zumindest wieder brav im Sandkasten spielen, OK? Ich werde zu dieser
lächerlichen Namensfrage jedenfalls kein Wort mehr verlieren. Und kuck'
mal, das ist doch das Schöne an Open Source: niemand hindert Dich, einen
Fork zu machen und *Things* in *KD23Q* umzubenennen ...

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Dr. Boris Neubert]

                                             

Hallo,

jetzt mal jenseits des Internet der Eitelkeiten:

Am 20.05.2012 06:05, schrieb Uli Zappe:

> Das funktionierte auch bis eben auf die Tatsache, dass das /dummy/-Modul
> bei Klick auf die Glühbirne immer nur ein-, nie aber ausschaltet.
> Ausgerechnet für den /Smallscreen/-Modus, ideal für
> Touch-Fernbedienungen, ist es damit unbrauchbar.

Ich habe soeben folgendes ausprobiert:

define Projektor dummy
attr Projektor setList on off
define ProjektorOn notify Projektor:on
"/data/Homeautomation/scripts/sendmsg.sh foo"
define ProjektorOff notify Projektor:off
"/data/Homeautomation/scripts/sendmsg.sh bar"


Mit
   set Projektor on
und
   set Projektor off

kann ich den Dummy schalten. Die Anzeige in pgm2 entspricht ebenfalls
den Erwartungen.

Wo ist denn genau Dein Problem bei dem Dummy?

Viele Grüße
Boris

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> Es stellte sich in diesem Thread heraus, dass sich mein Wunsch mit dem *
> dummy*-Modul in seiner heutigen Form schlicht nicht erfüllen lässt.

Ich habe z.Zt keine Probleme in smallScreen Modus ein Dummy zu togglen:
  define dm dummy
  attr dm setList on off
Nein, ich habe es nicht gerade gefixed.


> Das funktionierte vom Ergebnis her wie gewollt, nur gab es in der Logdatei
> laufend Fehlermeldungen (kein IODevice etc.).

Ich wuesste gerne warum hier Fehler auftreten. Das dummy Attribut kann von
jedem Modul verwendet werden, der IODev unterstuetzt: es verhindert das
Schreiben von Nachrichten an das dazugehoerige IODev.

IODev muss weiterhin wie gewohnt gesetzt sein, das passiert aber normalerweise
implizit durch die Reihenfolge des Geraets beim Einlesen der config.


> Mit *Things* definierte Geräte verhalten sich im Gegensatz zu mit

Den Namen finde ich auch irrefuehrend, da es nicht ahnen laesst dass dies ein
dummy Modul mit FS20 Befehlssatz sein soll.


>  2. Wie bei allen anderen Geräten auch funktioniert auch bei *Things* das
>  wechselseitige Ein- und Ausschalten durch Klick auf die Glühbirne leider
>  nicht mehr, sobald das Attribut *webCmd* definiert ist. Das ist ein Bug
>  in FHEM.

Ich bitte um Verstaendnis, dass ich hier anderer Meinung bin.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hallo Boris,

jetzt mal jenseits des Internet der Eitelkeiten:
>

ja, seeeehr gerne ...

Ich habe soeben folgendes ausprobiert:
>
> [...]
>
> Mit
>         set Projektor on
> und
>         set Projektor off
>
> kann ich den Dummy schalten. Die Anzeige in pgm2 entspricht ebenfalls
> den Erwartungen.
>
> Wo ist denn genau Dein Problem bei dem Dummy?
>

Wie geschrieben: Versuche in der Weboberfläche zwischen *on* und *off* zu
toggeln, indem Du auf das Glühbirnensymbol klickst. *Das* geht nicht, aber
das wollte ich unbedingt für die Fernbedienung via *iPod touch*, wo Du ja
nur diese Symbole siehst und *on* und *off* nicht getrennt zugänglich sind.

Viele Grüße

Uli

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Dr. Boris Neubert]

                                             

Hallo,

Am 20.05.2012 09:12, schrieb Uli Zappe:
>     Wo ist denn genau Dein Problem bei dem Dummy?
>
>
> Wie geschrieben: Versuche in der Weboberfläche zwischen /on/ und /off/
> zu toggeln, indem Du auf das Glühbirnensymbol klickst. /Das/ geht nicht,
> aber das wollte ich unbedingt für die Fernbedienung via /iPod touch/, wo
> Du ja nur diese Symbole siehst und /on/ und /off/ nicht getrennt
> zugänglich sind.

ich kann das nicht bestätigen. Ich kann toggeln, indem ich die Glühbirne
anklicke.

Ich schlage vor, daß Du
a) Deine fhem-Installation auf den neuesten Stand aus SVN bringst und
b) eine minimale Konfiguration aufsetzt zum Testen mit verbose 5
und dann z.B. mit dem Event Monitor und dem Log versuchst, dem Problem
auf die Schliche zu kommen.

Viele Grüße
Boris

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Nun, ich denke, das erledigt sich von selbst.

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Am Sonntag, 20. Mai 2012 09:06:41 UTC+2 schrieb Rudolf Koenig:
>
> Ich habe z.Zt keine Probleme in smallScreen Modus ein Dummy zu togglen:
>   define dm dummy
>   attr dm setList on off
> Nein, ich habe es nicht gerade gefixed.
>

Weia, Du hast recht! Dass das hier nie funktioniert hat, liegt an der etwas
exotischen Tatsache, dass, damit es klappt, *setList* konfiguriert sein *
muss* und *gleichzeitig* *webCmd* *nicht konfiguriert sein* *darf*.

Und genau *diese* Konfiguration kam mir beim Testen offenbar nie in den
Sinn; entweder hatte ich mit meiner noch geringen Erfahrung mit FHEM *
setList* nicht konfiguriert oder *webCmd* gleich mit ...

Und nachdem ich dann hier in der Gruppe nachfragte<https://groups.google.com/forum/?fromgroups#!searchin/fhem-users/Uli$20Zappe/fhem-users/LlP37nPlRbM/Q35AcSNEKQEJ> und
auch niemand anderes auf die Idee kam bzw. die anderen meine Probleme sogar
zu bestätigen schienen und mir kompliziertere Lösungen vorschlugen, bin ich
ab da davon ausgegangen, dass das eben tatsächlich nicht geht.

Sorry für die Verwirrung, aber das war offenbar nicht nur mir nicht
wirklich klar.
 

> > Das funktionierte vom Ergebnis her wie gewollt, nur gab es in der
> Logdatei
> > laufend Fehlermeldungen (kein IODevice etc.).
>
> Ich wuesste gerne warum hier Fehler auftreten. Das dummy Attribut kann von
> jedem Modul verwendet werden, der IODev unterstuetzt: es verhindert das
> Schreiben von Nachrichten an das dazugehoerige IODev.
>
> IODev muss weiterhin wie gewohnt gesetzt sein, das passiert aber
> normalerweise
> implizit durch die Reihenfolge des Geraets beim Einlesen der config.


Bei mir aber nicht, weil ich ja das InterTechno-Modul verwendet habe, für
das gar kein mögliches IODev existierte (ich habe nur ein CUL mit 868 MHz).

Daher die Fehlermeldungen.

Den Namen finde ich auch irrefuehrend, da es nicht ahnen laesst dass dies
> ein
> dummy Modul mit FS20 Befehlssatz sein soll.
>

Den Namensstreit können wir ja jetzt getrost zu den Akten legen, da sich *
Things* als völlig unnötig erwiesen hat ... *8–}*
 

> >  2. Wie bei allen anderen Ger�ten auch funktioniert auch bei *Things*
> das
> >  wechselseitige Ein- und Ausschalten durch Klick auf die Gl�hbirne
> leider
> >  nicht mehr, sobald das Attribut *webCmd* definiert ist. Das ist ein Bug
> >  in FHEM.
>
> Ich bitte um Verstaendnis, dass ich hier anderer Meinung bin.
>

Ooh, mir war angesichts vieler Nutzerklagen über diesen Punkt nicht klar,
dass das kein Bug ist, sondern ein Feature ...

(Auch wenn ich es nicht wirklich verstehe, da ich es ausgesprochen
praktisch fände, zum Beispiel *webCmd on:off:dim50%* zu konfigurieren, und
dann z.B. über mein iPad oder meinen Mac eben auch 50% wählen zu können,
aber über einen iPod touch zumindest noch ein- und ausschalten zu können.
Und das geht jetzt eben leider nicht.)

Viele Grüße

Uli

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Sini]

                                                         

Entschuldigung, aber dieser Post ist an Arroganz wohl nicht mehr zu
überbieten.

Ich dachte, FHEM ist ein Projekt, an dem alle mitarbeiten sollen, aber bei
solchen Aussagen, da gebe ich dem Ersteller Recht, kann einem die Lust
daran ja wirklich vergehen. Muss man nun erst mehrere Publikationen
veröffentlicht haben, um hier ,,mitspielen" zu dürfen?

Ich lese hier schon länger mit, und es mag ja sein, dass der Herr Prof.
einiges an Zeit in das Projekt investiert, aber da frage ich mich doch, wer
sein Gehalt bezahlt, und ob es ihm zusteht, in solch einem Ton hier
aufzutreten... Eine Vorbildfunktion stelle ich mir jedenfalls anders vor.

Meiner Meinung nach sind solche Aussagen mehr als unangemessen...

Am Sonntag, 20. Mai 2012 07:44:18 UTC+2 schrieb Prof. Dr. Peter A. Henning:
>
> Erstens: Es gibt keine "hochkochende Debatte" um das Internet of Things -
> sondern nur eine Vielzahl von Forschungsprojekten. Unter anderem derzeit
> drei aus meinem Team. Nenn doch einfach mal Deine drei letzten
> Publikationen auf dem Gebiet, dann können wir ja auf wissenschaftlicher
> Ebene diskutieren.
>
> Zweitens: Es ist unseriös, einen Modulnamen mit "Assoziationen
> aufzuladen".  Das ist  der Stil der "Computer BILD".
>
> Drittens: "Thing" ist die Oberklasse für alle Konzepte in
> ontologiebschreibenden Sprachen wie etwa OWL. Definitionsgemäß ein Konzept
> ohne Attribute. Das oben beschriebene Modul hat aber diverse Attribute, es
> ist keineswegs "absolut generisch".
>
> Schließlich: Seine eigenen Schöpfungen für "ausgesprochen gelungen" zu
> halten, ist nun wirklich keine Kunst. Wenn man sich aber dem Urteil anderer
> unterwirft, sollte man auch auf deren Äußerungen hin etwas nachdenken.
>
> pah
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Wer sich so weit aus dem Fenster lehnt wie der Ersteller dieses
Thread, der muss auch mit entsprechenden Antworten rechnen.
Wenn hier jeder ein Modul als Workarount für ein Konfigurationsproblem
entwickeln würde...

OT: Wann wird der bei busware erhältliche HUL - USB-Stick von fhem
unterstützt? Mit dem 6LoWPAN - Protokoll käme fhem dem "Internet der
Dinge" dann etwas näher.

On 21 Mai, 13:53, Sini wrote:
> Entschuldigung, aber dieser Post ist an Arroganz wohl nicht mehr zu
> überbieten.
>
> Ich dachte, FHEM ist ein Projekt, an dem alle mitarbeiten sollen, aber bei
> solchen Aussagen, da gebe ich dem Ersteller Recht, kann einem die Lust
> daran ja wirklich vergehen. Muss man nun erst mehrere Publikationen
> veröffentlicht haben, um hier ,,mitspielen" zu dürfen?
>
> Ich lese hier schon länger mit, und es mag ja sein, dass der Herr Prof.
> einiges an Zeit in das Projekt investiert, aber da frage ich mich doch, wer
> sein Gehalt bezahlt, und ob es ihm zusteht, in solch einem Ton hier
> aufzutreten... Eine Vorbildfunktion stelle ich mir jedenfalls anders vor.
>
> Meiner Meinung nach sind solche Aussagen mehr als unangemessen...
>
> Am Sonntag, 20. Mai 2012 07:44:18 UTC+2 schrieb Prof. Dr. Peter A. Henning:
>
>
>
>
>
>
>
>
>
> > Erstens: Es gibt keine "hochkochende Debatte" um das Internet of Things -
> > sondern nur eine Vielzahl von Forschungsprojekten. Unter anderem derzeit
> > drei aus meinem Team. Nenn doch einfach mal Deine drei letzten
> > Publikationen auf dem Gebiet, dann können wir ja auf wissenschaftlicher
> > Ebene diskutieren.
>
> > Zweitens: Es ist unseriös, einen Modulnamen mit "Assoziationen
> > aufzuladen".  Das ist  der Stil der "Computer BILD".
>
> > Drittens: "Thing" ist die Oberklasse für alle Konzepte in
> > ontologiebschreibenden Sprachen wie etwa OWL. Definitionsgemäß ein Konzept
> > ohne Attribute. Das oben beschriebene Modul hat aber diverse Attribute, es
> > ist keineswegs "absolut generisch".
>
> > Schließlich: Seine eigenen Schöpfungen für "ausgesprochen gelungen" zu
> > halten, ist nun wirklich keine Kunst. Wenn man sich aber dem Urteil anderer
> > unterwirft, sollte man auch auf deren Äußerungen hin etwas nachdenken.
>
> > pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Sicher nicht um mitspielen zu dürfen. Aber dann, wenn man großspurige
Aussagen über Forschungsthemen macht, ohne diese zu verstehen.

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

@Sini:
Sicher nicht um mitspielen zu dürfen. Aber dann, wenn man großspurige
Aussagen über Forschungsthemen macht, ohne diese zu verstehen.  Der Rest
ist unterste Schublade - denn eine Gehaltsdiskussion sollten wir hier nicht
führen.

@Heiermann:
Das ist eine Zeitfrage - nicht nur des Programmieraufwands, sondern der
zeitlichen Entwicklung der Protokolle. Da ist nämlich noch keine
Konsolidierung erreicht, und es wäre schade, ein paar Personenmonate zu
investieren, wenn das Ergebnis nur ebenso lange genutzt werden kann.

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com