Hi,
I removed the units in parentheses from the readings in the KS300 module.
Previous version:
2012-04-01 19:23:18 temperature 10.7 (Celsius)
2012-04-01 19:23:18 humidity 29 (%)
Current version:
2012-04-01 19:23:18 temperature 10.7
2012-04-01 19:23:18 humidity 29
This makes it easier to postprocess the readings. I hope I did not break
anything else. I checked DBLog and PachLog.
Please report any problems here.
Kind regards
Boris
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
In den Readings sollte es einen eigenen Eintrag dafür geben
Readings
2012-04-01 19:23:18 temperature 10.7 (Celsius)
2012-04-01 19:23:18 temperature_unit Celsius
Gruss
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo,
die Einheitenfrage hatten wir in fhem-devel ausführlich diskutiert und sind zu der Entscheidung gekommen, die in http://fhemwiki.de/wiki/DevelopmentGuidelines unter Einheitendarstellung dokumentiert ist.
Viele Grüße
Boris
"Prof. Dr. Peter A. Henning"
schrieb:
>Ich bin eigentlich dafür, in die umgekehrte Richtung zu gehen und die
>korrekten Einheiten - also °C und % - dabei zu lassen, sogar im
>hash
>einen eigenen Eintrag dafür zu machen.
>
>Es sollte dem Frontend überlassen werden, wie dies dann dargestellt
>wird.
>
>Bei den Log-Datein sehe ich das Argument der einfachen Verarbeitung ja
>ein
>- aber dann sollten Einheiten und Größenangaben bei Start eines neuen
>Log
>in eine/zwei Headerzeilen geschrieben werden und in den nachfolgenden
>Zeilen nicht mehr auftauchen. habe ich so bei meinem Photovoltaikmodul
>realisiert.
>
>Denn merke: Irgendjemand will die Daten auch noch zehn Jahre später
>auswerten - und ohne Einheiten ist das manchmal nicht so einfach ...
>
>
>LG
>
>pah
>
>--
>To unsubscribe from this group, send email to
>fhem-users+unsubscribe@googlegroups.com
--
Diese Nachricht wurde von meinem WePad mit K-9 Mail gesendet.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Mag ja sein, dass Ihr das verworfen habt - das ist aber mit Sicherheit
nicht sehr sinnvoll. Dafür kann ich eine ganze Latte von Argumenten
präsentieren:
1. Gerade für die Internationalisierung muss es notwendig sein,
Temperaturen auch in Grad Fahrenheit anzuzeigen.
2. Die SI-Einheit der Temperatur ist nicht "Celsius", sondern "Grad
Celsius" oder "Kelvin" (ohne Grad).
3. Wenn man an einen AD-Konverter einen Feuchtesensor anschließt, möchte
man die Werte nicht als Spannung angezeigt bekommen - sondern entsprechend
der Kalibrierung des Sensors eben als Prozent.
4. Auch einen Zähler sollte man nicht einfach als nackte Zahl anzeigen -
sondern in den Attributen des Devices festlegen, was hier eigentlich
gemessen wird.
5 Mit zunehmender Komplexität von FHEM wieß irgendwann niemand mehr, was
die ganzen Zahlen bedeuten
6.... bliebig fortführbar.
Als Beispiel kann man sich das Modul OWAD.pm im contrib/1-Wire ansehen.
Damit kann ich für jeden der vier Kanäle festlegen
- wie er heißt (z.B. Humidity)
- welchen Typ die Messung liefert (z.B. voltage oder temperature)
- welche Einheit die Messung hat (z.B. Volt) und wie diese abgekürzt wird
(z.B. V).
Im hash stehen also außer {VAL} und {TIME} zusätzlich die Einträge {TYPE},
{UNIT} und {UNITABBR}
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am 11.04.2012 um 21:50 schrieb Prof. Dr. Peter A. Henning:
> Im hash stehen also außer {VAL} und {TIME} zusätzlich die Einträge {TYPE}, {UNIT} und {UNITABBR}
UNIT steht ja auch in den Development Guidelines. Noch TYPE und UNITABBR dazu, und der Programmteil ist abgehakt.
Was eher lustig ist, wäre das Logfile. Da würde ich mir eine generische Routine wünschen, die immer, wenn ein Logfile neu angelegt wird, die Parametrisierung ins Logfile schreibt. (in den ersten Zeilen, max. jeweils 3 Spalten). Un natürlich updated, wenn sich die Einheiten ändern...
Grüße
Oskar
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Da würde ich mir eine generische Routine wünschen, die immer, wenn ein
> Logfile neu angelegt wird, die Parametrisierung ins Logfile schreibt.
Wenn man darueber im klaren ist, wie Events in fhem implementiert sind, dann
kommt man schnell darauf dass sowas einen groesseren Umbau bedeutet.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am 12.04.2012 um 09:32 schrieb Rudolf Koenig:
>> Da würde ich mir eine generische Routine wünschen, die immer, wenn ein
>> Logfile neu angelegt wird, die Parametrisierung ins Logfile schreibt.
>
> Wenn man darueber im klaren ist, wie Events in fhem implementiert sind, dann
> kommt man schnell darauf dass sowas einen groesseren Umbau bedeutet.
Deswegen hab ich es auch noch nicht gemacht, sondern auf die Wunschliste geschrieben...
Frohe Pfingsten
Oskar
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo,
Am 11.04.2012 21:50, schrieb Prof. Dr. Peter A. Henning:
> Mag ja sein, dass Ihr das verworfen habt - das ist aber mit Sicherheit
> nicht sehr sinnvoll. Dafür kann ich eine ganze Latte von Argumenten
> präsentieren:
es ist unstrittig, daß Klarheit darüber bestehen muß, welche Einheit die
Zahl in der Value-Teil des Readings hat.
Wie diese Klarheit hergestellt wird, war diskussionsfähig. Diese
Diskussion haben wir in fhem-devel ausführlich geführt (siehe
Mailingslisten-Archiv) und dann am 18.06.2010 als E9 zur Entscheidung
gestellt. Das Ergebnis ist im Wiki dokumentiert.
Ich werde diese Diskussion kein zweites Mal führen.
Viele Grüße
Boris
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Dr. Boris Neubert wrote:
> Ich werde diese Diskussion kein zweites Mal führen.
Dito.
-kai
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Nun, wenn das 3 Leute (!) vor 2 Jahren (!) so entschieden haben, muss das
natürlich richtig sein und für alle Ewigkeit Bestand haben...
Erinnert so etwas an das Statement von Bill Gates, dass man mit dem
Internet kein Geschäft machen könne.
Nur mal so interessehalber: Wie viele Sensoren und Aktoren sind seitdem
hinzugekommen ?
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
"Genersich" ist tatsächlich schwierig.
Braucht man aber auch nicht. In meinem Fall wird sowohl bei der
Fotovoltaikanlage (NT5000.pm) als auch beim umgebauten CUL_EM der erste
Eintrag des Tages als Tabellenheader ausgeschrieben.
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Nicht alles, was hinkt, ist auch ein Vergleich. Wer zu spät kommt, den bestraft das Leben.
Die Anzahl hinzukekommener Sensoren bestätigt eigentlich eher die Notwendigkeit, eine feste Norm zu haben. IMHO, YMMV.
Prof. Dr. Peter A. Henning wrote:
[...]
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Prof. Dr. Peter A. Henning wrote:
> Mag ja sein, dass Ihr das verworfen habt - das ist aber mit Sicherheit
> nicht sehr sinnvoll.
Leider hat uns -- also denen, die seinerzeit die Weiterentwicklung von FHEM
aktiv weiterführen wollten -- damals kein Weiser aus dem Morgenland den Weg
gewiesen. Vielleicht war's neblig ...
»Mit Sicherheit« ist folgender Punkt allerdings Quatsch:
> 1. Gerade für die Internationalisierung muss es notwendig sein,
> Temperaturen auch in Grad Fahrenheit anzuzeigen.
»Notwendig sein« »muß« es nicht, nie. Es mag eine Voraussetzung sein für
den FHEM-Durchbruch in den USA (»Heutzutage wird [die Fahrenheit-Skala]
nur noch in den USA und in wenigen anderen englischsprachigen Ländern
verwendet.[1]«) -- who cares? Und der Kernpunkt ist ja grade, daß durch
die Definition eines Bezugssystems, in dem bestimmte Daten vorliegen,
die _Anzeige_ in beliebigen lokalen Präferenzen möglich wird -- ohne
fallabhängiges Parsen der Werte (»17 °C«, »17 C«, »17 Grad«, ...).
MfG,
-kai
[1] http://de.wikipedia.org/wiki/Grad_Fahrenheit
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Weiser oder nicht, das lassen wir mal die Nachwelt entscheiden ;-)
Der Knackpunkt ist aber, dass die Zukunftsfähigkeit einer Anwendung heute
wesentlich davon bestimmt wird, wie viele Metadaten sie mitliefert.
Eine Zahl 24.3 besagt gar nichts - und weder ein beliebiger menschlicher
Nutzer, noch ein intelligentes Frontend kann erraten dass es sich hierbei
a.) um eine Temperatur und b.) eine Messung in der Einheit °C handelt.
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Da die Metadaten implizit vorhanden sind, ist die »Zukunfsfähigkeit« nicht tangiert.
24.3 sagt für sich genommen nichts aus; der Unterschied zu 24.3 °C allerdings ist
marginal, denn eine Temperatur von 24,3 Grad Celsius mag für das Wohnzimmer OK
sein, für den Kühlschrank ist sie es nicht. Der Kontext ist entscheidend, mit den
nackten Zahlen arbeitet niemand, kann niemand sinnvoll arbeiten, egal, ob sie eine
Einheit in ihrer Rohform führen oder nich: "wenn eine Temperatur von FHEM unter
3.1415 °C oder über 52 °C liegt, löse die Selbstzerstörung aus" macht einfach
absolut keinen Sinn -- dies ist aber effektiv Dein Anwendungsfall. Hingegen ist
"wenn 'TKuehlschrank' unter 2.3 oder über 7.5 liegt, sende SMS" ein Szenario, wo
grade das Fehlen der Einheiten in den Rohdaten (die implizit aus der Tatsache, daß
TKuehlschrank ein Wert eines Temperatursensors ist, der in FHEM eben immer °C
liefert, dennoch bekannt sind) die Abbildung in "FHEM-Perl-Code" vereinfacht.
Ergo: Einheiten in den Rohdaten sind a) überflüssig und b) hinderlich -- und die
Darstellung sowieso Sache des UIs, nicht des FHEM-Kerns. QED.
-kai
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Ihr wollt schon gerne aneinander vorbei reden. Oder verstehe ich das nicht?
Ihr seid doch auch alle der Meinung, das die Einheiten im aktuellen Logeintrag (Zeile) nichts zu suchen haben, oder?
Die einzige Frage ist doch, wo die zum Zahlenwert gehörigen Metadaten (Einheit und der ganze Kram) gespeichert wird bzw. ob überhaupt.
Wenn Ihr so weitermacht, kommt das hier wohl eher nicht voran. Im übrigen sind die Metadaten eben nicht implizit vorhanden. Zumindest nicht im Logfile. Da steht nur, dass ein vom Nutzer beliebig benannter Sensor irgendwelche Daten angeliefert hat. Manchmal mit Beschreibung, manchmal mit so komischen Abkürzungen wie T, H, D oder so.
Grüße
Oskar
Ihr seid doch auch der Meinung, das Suggestivfragen doof sind?
Am 15.04.2012 um 12:09 schrieb Kai 'wusel' Siering:
> Da die Metadaten implizit vorhanden sind, ist die »Zukunfsfähigkeit« nicht tangiert.
>
> 24.3 sagt für sich genommen nichts aus; der Unterschied zu 24.3 °C allerdings ist
> marginal, denn eine Temperatur von 24,3 Grad Celsius mag für das Wohnzimmer OK
> sein, für den Kühlschrank ist sie es nicht. Der Kontext ist entscheidend, mit den
> nackten Zahlen arbeitet niemand, kann niemand sinnvoll arbeiten, egal, ob sie eine
> Einheit in ihrer Rohform führen oder nich: "wenn eine Temperatur von FHEM unter
> 3.1415 °C oder über 52 °C liegt, löse die Selbstzerstörung aus" macht einfach
> absolut keinen Sinn -- dies ist aber effektiv Dein Anwendungsfall. Hingegen ist
> "wenn 'TKuehlschrank' unter 2.3 oder über 7.5 liegt, sende SMS" ein Szenario, wo
> grade das Fehlen der Einheiten in den Rohdaten (die implizit aus der Tatsache, daß
> TKuehlschrank ein Wert eines Temperatursensors ist, der in FHEM eben immer °C
> liefert, dennoch bekannt sind) die Abbildung in "FHEM-Perl-Code" vereinfacht.
>
> Ergo: Einheiten in den Rohdaten sind a) überflüssig und b) hinderlich -- und die
> Darstellung sowieso Sache des UIs, nicht des FHEM-Kerns. QED.
> -kai
>
> --
> 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>
Nein, so billig kommst Du mir nicht davon.
Der Kontext muss sich natürlich aus dem Namen ergeben. Wenn Das
Wohnzimmerthermometer t1 und das Kühlschrankthermometer t2 heißen, besteht
das Problem natürlich. Darum soll die Definition des Gerätes enthalten
1.Typ der Messgröße (z.B. temperature). Diese folgt manchmal aus dem
Sensormodell (z.B. messen Thermometer eigentlich nur Temperaturen), an
anderer Stelle sollte sie explizit angegeben werden (z.B. wenn man mit
einem AD-Wandler + Sensor die relative Feuchte misst)
2.Name (mit Kontextbezug, also von mir aus "Kühlschrank_T")
3.Einheit (z.B. Kelvin)
Erst durch diese Angaben im Hash kann das Frontend vollständig vom Backend
getrennt werden - und alle für eine Darstellung notwendigen Angaben an
einer Stelle erhalten.
@oskar: Natürlich gehören die Einheiten in jede Logdatei. Aber nur einmal -
es ist überflüssig, sie in jeder Zeile zu haben.
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Dein lustiger AD-Wandler braucht ein Modul; dort wird definiert, was für ein Wert da gemessen wird (Temperatur, Feuchte, Zählerstand, ...).
Hernach ist für FHEM und Frontends klar, wie der Wert zu interpretieren ist. Der Name hat nur für den Nutzer eine Funktion, für FHEM als auch die Frontends ist es ein beliebiger Wert. (Wer gerne durch Logfiles waten will, tut wahrscheinlich gut daran, sich an ein Schema zu halten. Aber das ist nicht das Thema.)
Einheiten haben in einem maschinengelesenen Log nichts verloren; und schon gar nicht nur an exponierter Stelle, grade das verkomplizierte die Verarbeitung massiv. (Wer loggt, tut das nicht auf 32 MB USB-Sticks; insofern sind die paar Bytes/Zeile für die Einheit eh' zu vernachlässigen, der Mehraufwand für "erste-Zeile-Sonderbehandlungen" in Relation nicht zu rechtfertigen.) FHEM kann über den Devicenamen alle notwendigen Informationen ermitteln. Wer ein Ewiges Wetterlog starten will, loggt eben separat via notify und angehängter Einheit und schreibt sich einen eigenen Plotter für sein Logfileformat.
Streit um des Kaisers Bart, eines toten Kaisers (Thema ist schon durch) obendrein. Daß die Planungen für FHEM5 von der Realität (FHEM5 ist schon da, aber nicht wie geplant) überholt wurden, ist nur bedingt hilfreich.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Jan-Hinrich Fessel wrote:
> Ihr wollt schon gerne aneinander vorbei reden. Oder verstehe ich das nicht?
Ich denke nicht, daß Herr Prof. Dr. und meinereiner aneinander vorbei reden; er mag unnötig komplizierte Logfiles, ich welche, die einfach weiterzuverarbeiten sind. Aus meiner Sicht ein ziemlicher Gegensatz ;)
> Ihr seid doch auch alle der Meinung, das die Einheiten im aktuellen Logeintrag (Zeile) nichts zu suchen haben, oder?
Ich bin der Meinung, daß sie im Logfile gar nichts verloren haben. Er ist dieser Meinung: »Natürlich gehören die Einheiten in jede Logdatei. Aber nur einmal [...].«
> Wenn Ihr so weitermacht, kommt das hier wohl eher nicht voran.
Die Diskussion mit "pah" ist eine akademische; Zitat Boris:
| es ist unstrittig, daß Klarheit darüber bestehen muß, welche Einheit die
| Zahl in der Value-Teil des Readings hat.
|
| Wie diese Klarheit hergestellt wird, war diskussionsfähig. Diese
| Diskussion haben wir in fhem-devel ausführlich geführt (siehe
| Mailingslisten-Archiv) und dann am 18.06.2010 als E9 zur Entscheidung
| gestellt. Das Ergebnis ist im Wiki dokumentiert.
Aber mit der Realität ist das ja so eine Sache ;)
> Im übrigen sind die Metadaten eben nicht implizit vorhanden. Zumindest nicht im Logfile. Da steht nur, dass ein vom Nutzer beliebig benannter Sensor irgendwelche Daten angeliefert hat. Manchmal mit Beschreibung, manchmal mit so komischen Abkürzungen wie T, H, D oder so.
Yepp; und die Gretchenfrage ist wohl eigentlich die, wem das Logfile dienen soll; derzeit wird dies meinem Verständnis nach von FHEM intern benutzt, um z. B. die Graphen zu malen. Ergo hat da drinzustehen, was FHEM hierzu braucht. Technisch braucht FHEM die Einheiten nicht, denn die könnte es intern nachschlagen.
Im Endeffekt allerdings ging es IIRC mal darum, von dem "mnchmal mit Beschreibung, manchmal mit so komischen Abkürzungen" wegzukommen, es also auch den Frondends einfacher zu machen.
FHEM hindert jedenfalls meines Wissens niemanden, ein beliebig formatiertes Logfile für eigene Bedürfnisse zu schreiben -- die (Unix-)Shell ist da ziemlich mächtig ...
Ciao,
-kai
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Na, da ist dein Wissen aber nicht auf dem aktuellen Stand der Informatik -
vielleicht kommst Du mal zu mir in die Vorlesung ;-)
Natürlich gehören Einheiten in ein maschinenlesbares Log - schau Dir
vielleicht mal an, warum wir im Semantic Web versuchen, alles mit Metadaten
zu versehen
Es ist außerdem großer Unsinn, für verschiedene Messwerte mit der gleichen
Hardware unterschiedliche Module zu bauen. Ein Modul, das den A/D abfragt,
darf eben nicht hartcodiert die gemessenen Größen und Einheiten drin haben
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> - Stand der Kunst in der Informatik ist, Daten mit so vielen Metadaten
> zu versehen, dass ihre BEDEUTUNG klar ist. Wer darauf verzichtet, setzt
> sich der Gefahr aus, dass er in 5 Jahren nicht mehr weiß, um was es
sich
> handelt.
Mein Senf dazu, da das Problem durch totschweigen sich nicht erledigt,
sondern
sich eher ausbreitet.
Management Summary:
Ich bin dagegen _alle_ zum Auswerten _benoetigten_ Metadaten in den Log zu
schreiben, und automatisch geht das mAn schon gar nicht.
Details:
Wenn irgendwer (z.Bsp. ich in 5 Jahren, oder jemand der meine logs gefunden
hat) nicht genau weiss, was in einem Log gespeichert sind, dann werden
automatisch generierte Metadaten auch nicht helfen.
Das es sich um Temperatur in Celsius handelt wird man wahrscheinlich am
ehesten
rauskriegen, was und wie ich gemessen habe (z.Bsp. Sensor an dem Keller-
Innenwand, direkt ueber dem Heizrohr), werden mir die automatisch
generierten
Metadaten nicht verraten. Und ohne diese Information ist mAn eine
Auswertung
bedeutungslos.
Umgekehrt finde ich es auch unwahrscheinlich, dass man noch weiss, wo genau
welcher Sensor war, aber nicht mehr, dass es in Celsius oder in Fahrenheit
gemessen hat. Wer vergesslich ist, kann selber Notizen anfertigen, das muss
aber nicht automatisch ins logfile geschrieben werden.
Wohlgmerkt ich bin nicht dagegen, dass der Benutzer genau weiss in welcher
Einheit gemessen wird, das muss aber nicht unbedingt ins Logfile.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Salve,
On 04/17/2012 10:07 PM, Prof. Dr. Peter A. Henning wrote:
> Na, da ist dein Wissen aber nicht auf dem aktuellen Stand der Informatik
Starker Tobak. Mit der Verdrehung von Aussagen allerdings kommst Du auch nicht weiter. Ich schrieb ...
| FHEM hindert jedenfalls meines Wissens niemanden, ein beliebig formatiertes Logfile für eigene Bedürfnisse zu schreiben -- die (Unix-)Shell ist da ziemlich mächtig ...
... und dieses Wissen hat nichts mit informatorischen Theorien zu tun. Wer lesen kann, ist klar im Vorteil. Korrektes Zitieren ist in akademischen Zirkeln ja leider keine Tugend mehr.
> - vielleicht kommst Du mal zu mir in die Vorlesung ;-)
Da ich befürchten muß, daß Du auch dort meilenweit am Thema vorbei redest, verzichte ich dankend.
> Natürlich gehören Einheiten in ein maschinenlesbares Log
Nope. Einheiten haben im hier diskutierten maschinengelesenen Log nichts verloren, denn FHEM kann über den Devicenamen alle notwendigen Informationen ermitteln, diese Information ist also redundant. Die Präsentation der Werte ist nicht gebunden an die Rohdaten.
> schau Dir vielleicht mal an, warum wir im Semantic Web versuchen, alles mit Metadaten zu versehen
Auch hier wiederhole ich mich: nicht alles, was hinkt, ist ein Vergleich. Das Semantische Web ist etwas vollkommen anderes als ein Logfile einer (konkreten) FHEM-Installation bzw., genauer, das Logfile eines Sensors einer solchen. Die »Metadaten«, die Du so krampfhaft in den Logs unterbringen willst -- was übrigens nicht wirklich was mit Metadaten zu tun hat; Metadaten wären es, wenn Du fordertest, zum jeweiligen Logfile eine Beschreibungsdatei zu erzeugen -- sind schon da, denn per Definition weiß FHEM ja, daß Temperaturen in Grad Celsius gespeichert werden (Kelvin wäre möglich, aber unpraktisch und im Haupteinsatzgebiet von FHEM, der Hausautomatisierung, auch nicht gebräuchlich). Bei der Nutzung außerhalb von FHEM, z. B. im Semantischen Web, mußt Du diese Information mittransportieren.
> Es ist außerdem großer Unsinn, für verschiedene Messwerte mit der gleichen Hardware unterschiedliche Module zu bauen.
Im Prinzip schon, und auch wieder nicht. In einem gesteuerten Projektteam sollte es nicht so sein; das ist aber nicht der aktuelle Ansatz bei FHEM. Und das ist gut so, imho.
MfG,
-kai
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com