Originally posted by: <email address deleted>
Liebe Community,
die Nutzung von 1-Wire-Sensoren funktioniert mit FHEM ja schon ganz gut -
allerdings muss das OWFS (One-Wire Filesystem) installiert sein. Das war
mir ehrlich gesagt etwas zuviel Overhead, ich habe darum in den letzten
Tagen das 1-Wire-Protokoll direkt in perl implementiert und bin dabei, ein
neues FHEM-Modul zu schreiben.
Bisher gibt es schon ein standalone perl-Programm owtest.pl, mit welchem
die über einen USB-to-1-Wire-Konverter (nennt sich USB9097 und enthält
einen sehr schönen DS2480B Seriell-to-1-Wire-Konverter,
http://owfs.org/index.php?page=usb-usb9097) angeschlossenen
Temperatursensoren ausgelesen werden können. Das owtest.pl stelle ich gerne
per eMail zur Verfügung.
Daraus ergibt sich die 1. Frage hier in die Runde:
Wer hat in FHEM andere 1-Wire-Devices als die DS1820-Thermometer in
Benutzung ? Ich selbst habe nur die DS1820 im Einsatz, wenn ich aber ein
FHEM-Modul baue, sollte dieses alle existierenden OWFS-Installationen
ersetzen können.
Soweit, so gut - Problem ist, dass in dem USB9097 ein Billigst
USB-to-Serial-Umsetzer eingebaut ist, der das Linux-Kernelmodul ch341
benötigt. Und das ist (wie üblich...) auf der Fritzbox 7390 eingespart
worden. Im Moment läuft das owtest.pl also nur auf ordentlichen Linux-PCs.
Daraus ergibt sich die
2.Frage hier in die Runde:
Hat jemand eine ordentlich installierte Cross-Compile-Umgebung und kann das
ch341.ko für die FB7390 erstellen ? Das liegt bei mir nicht am Wollen oder
Können - aber meine Zeit ist relativ knapp.
Falls sich das nicht realisieren lässt, wird mir nicht anderes übrig
bleiben, als schnell einen passiven Serial-to-1-Wire-Konverter
zusammenzustöpseln - siehe
http://owfs.org/index.php?page=com-ds9097-passive - und an einen
USB-to-Serial-Umsetzer mit FTDI-Chip anzuschließen.
Gruß
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hi Peter,
warum nimmst Du nicht einen CUNO. Der emuliert für die One-Wire
Temp-Sensoren HMS Sensoren, und somit kannst Du diese direkt in FHEM
einbinden.
In der CUNO-Firmware sind wesentliche Teile des OneWire Protokolls drin.
Man kann die HMS Emulation einschalten und somit zumindest die
Temp-Sensoren ohne neue Module in FHEM einbinden.
Alles andere müßte man natürlich erweitern. Aber es ist eine solide
Basis, die auch von einigen bereits erfolgreich eingesetzt wird.
Gruß,
Olaf
Am 27.12.2011 11:16, schrieb Prof. Dr. Peter A. Henning:
> Liebe Community,
>
> die Nutzung von 1-Wire-Sensoren funktioniert mit FHEM ja schon ganz gut
> - allerdings muss das OWFS (One-Wire Filesystem) installiert sein. Das
> war mir ehrlich gesagt etwas zuviel Overhead, ich habe darum in den
> letzten Tagen das 1-Wire-Protokoll direkt in perl implementiert und bin
> dabei, ein neues FHEM-Modul zu schreiben.
>
> Bisher gibt es schon ein standalone perl-Programm owtest.pl, mit welchem
> die über einen USB-to-1-Wire-Konverter (nennt sich USB9097 und enthält
> einen sehr schönen DS2480B Seriell-to-1-Wire-Konverter,
> http://owfs.org/index.php?page=usb-usb9097) angeschlossenen
> Temperatursensoren ausgelesen werden können. Das owtest.pl stelle ich
> gerne per eMail zur Verfügung.
>
> Daraus ergibt sich die 1. Frage hier in die Runde:
> Wer hat in FHEM andere 1-Wire-Devices als die DS1820-Thermometer in
> Benutzung ? Ich selbst habe nur die DS1820 im Einsatz, wenn ich aber ein
> FHEM-Modul baue, sollte dieses alle existierenden OWFS-Installationen
> ersetzen können.
>
> Soweit, so gut - Problem ist, dass in dem USB9097 ein Billigst
> USB-to-Serial-Umsetzer eingebaut ist, der das Linux-Kernelmodul ch341
> benötigt. Und das ist (wie üblich...) auf der Fritzbox 7390 eingespart
> worden. Im Moment läuft das owtest.pl also nur auf ordentlichen
> Linux-PCs. Daraus ergibt sich die
>
> 2.Frage hier in die Runde:
> Hat jemand eine ordentlich installierte Cross-Compile-Umgebung und kann
> das ch341.ko für die FB7390 erstellen ? Das liegt bei mir nicht am
> Wollen oder Können - aber meine Zeit ist relativ knapp.
>
> Falls sich das nicht realisieren lässt, wird mir nicht anderes übrig
> bleiben, als schnell einen passiven Serial-to-1-Wire-Konverter
> zusammenzustöpseln - siehe
> http://owfs.org/index.php?page=com-ds9097-passive - und an einen
> USB-to-Serial-Umsetzer mit FTDI-Chip anzuschließen.
>
> Gruß
>
> pah
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
--
------------------------------------------------------------------------
Prof. Dr. Olaf Droegehorn
General Manager Tel. : +49-561-82020-410
DHS - Computertechnik GmbH Fax. : +49-561-82020-399
Carlsdorfer Straße 3 E-Mail: O.Droegehorn@dhs-
computertechnik.de
D-34128 Kassel WEB: www.dhs-computertechnik.de
------------------------------------------------------------------------
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Weiß ich, weiß ich.
1. Grund: Ich fahre mit meinen beiden CUL sehr gut, an der betreffenden
Stelle liegt auch ein USB-Kabel. Aber kein Ethernet.
2. Grund: Bei Verwendung des CUNO müssen die Temperatursensoren in das HMS
gemappt werden, es gibt also wieder eine Zwischenschicht. Das ist bei einem
so simplen Protokoll eher ungünstig.
Außerdem sehe ich das als sportliche Übung, ich habe schon für meinen
solaren Wechselrichter ein neues FHEM-Modul gebaut (auch serielle
Schnittstelle...)
Gruß pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Es gibt sogar noch einen dritten Grund: Offenbar gibt es ein paar
Hersteller, die inzwischen recht günstige Multi-Sensoren abieten.
Siehe z.B.
http://www.fuchs-shop.com/de/shop/6/1/13372331/
Gruß pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
hiya,
dann will ich auch mal ein paar worte zum thema verlieren ohne jetzt explizit
teile deiner mail zu quoten..
ich selber setze mehr als nur temperatur-sensoren unter 1-wire ein und halte
es aus meiner sicht für überflüssig, das rad neu zu erfinden. die variante
mittels owfs auf die devices zuzugreifen ist seit jahren in der entwicklung
und unterstützt viele unterschiedliche devices.
ich selber nutze 1-wire um meinen gaszähler und diverse stromzähler zu
counten, zuständen von türen und toren zu melden, sowie luftfeuchte zu messen.
darüber hinaus kann ich noch ein LCD ansteuern. das ganze aus fhem heraus:
-rw-r--r-- 1 root root 20447 2011-10-04 22:34 00_OWFS.pm
-rw-r--r-- 1 root root 8363 2011-09-21 20:54 20_OWCOUNT.pm
-rw-r--r-- 1 root root 13071 2011-09-21 20:54 20_OWHUB.pm
-rw-r--r-- 1 root root 11751 2011-09-21 20:54 20_OWLCD.pm
-rw-r--r-- 1 root root 8363 2011-09-21 20:54 20_OWMULTI.pm
-rw-r--r-- 1 root root 22942 2011-09-21 20:54 20_OWSWITCH.pm
-rw-r--r-- 1 root root 12778 2011-10-03 17:27 20_OWTEMP.pm
leider sind die module nocht zu rudimentär, da ich zur zeit auf grund von
anstehendem nachwuchs kaum die zeit finde zeit dort rein zustecken.
generell verfolge ich das ziel:
ein modul das die ganze kommunikation übernimmt:
00_OWFS
und dann je nach sensor/ic eigene module:
20_OWCOUNT unterstützt derzeit DS2423
20_OWHUB unterstützt derzeit einen speziellen hutschienen hub und liest den
DS2450 aus
20_OWLCD unterstützt derzeit LCD16, LCD20, LCD40
20_OWMULTI ist noch nicht fertig
20_OWSWITCH unterstützt derzeit DS2405, DS2406, DS2408, DS2413
20_OWTEMP unterstützt derzeit DS18B20, DS18S20
das ganze OWFS geraffel ist ein rewrite gegenüber der bisherigen OWFS
unterstützung in FHEM und komplett modular aufgebaut. die einzelnen module
können sehr klein gehalten werden und nur für die darstellung, umrechnung,
etc. genutzt werden, während 00_OWFS den bus überwacht (ALARMS) und die
kommunikation zwischen den modulen und den devices übernimmt.
letztlich muss jeder "seine variante" für sich entscheiden. ich finde den
ansatz gut, das der CUNO 1-wire intergriert hat, jedoch nicht die umsetzung.
1-wire ist nun mal 1-wire und kein HMS device. das "vermischt" aus meiner
sicht die technologien und schränkt stark ein.
wenn man sich mal das OWFS genauer betrachtet, dann ist es aus meiner sicht
kein "overhead"; das 1-wire perl modul könnte man komplett in FHEM im modul
00_OWFS integrieren; somit müsste man lediglich den 1-wire server daemon
installieren. alle anderen perl-module von 1-wire benötigt man dann nicht.
wozu sollte man dann also die ganze logik neu entwickeln. der aufwand eine
cross-compile umgebung zu schaffen. es existiert ja nun mal schon alles und
müsste nur zusammen geführt und gepflegt werden. ich habe sogar ein ppa-
repository wo ich die owfs unterstützung für ubuntu vorhalte.
da ich fhem nicht auf einer fritzbox betreibe, wäre es für alle seiten aus
meiner sicht sinnvoller avm auf die nerven zu gehen, das sie die notwendigen
module integriert. das owfs auf 'ner fritzbox ohne probleme läuft, zeigt ja
die unterstützung seitens freetz.
schön wäre auch peter, wenn du mir meine frage aus september beantworten
könntest, damit ich das modul 20_OWHUB mal fertigstellen kann ;-) wir
schrieben ja bereits mehrfach darüber, doch die "formel zu umrechnung" von dir
ist bisher ausgeblieben.
ich will hier jetzt keine grundsatz diskussion anstossen, aus meiner sicht
wird 1-wire hier leider immer nur auf "temperatur-messung" reduziert, dabei
stehen mit 1-wire viele türen offen. deshalb halte ich auch ein "rewrite" oder
"device-mapping" langfristig für nicht die richtige variante.
generell halte ich es für sinnvoll bestehende APIs, schnittstellen, etc. zu
nutzten und fhem dafür fit zu machen mit diesen zu kommunizieren. aber auch
fhem um eine vernüftige API zu erweitern, um eine einheitliche schnittstelle
nach aussen (für z.b. frontends, cacti, etc.) anzubieten.
gruss martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Tja, die Antwort auf die Frage vom September steht noch aus, das ist
richtig. Aber manchmal habe ich auch keine Lust...
Betreffend die Diskussion, ob nun OWFS oder meine neue Entwicklung: Soll
jeder selbst entscheiden - Missionar bin ich nun wirklich nicht.
Gruß
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Martin,
ich geb Dir völlig recht, 1-Wire kann mehr als Temp-Sensoren. Da aber
dies der häufigste Einsatz ist haben wir in der CUNO-FW erstmal dafür
ein Mapping gemacht.
Die Firmware unterstützt viel mehr, und ich hätte auch gern ein 1-Wire
FHEM MOdul, wo man wählen kann, ob man ein USB-Device als Transmitter
nutzt, oder eben den CUNO.
Und ob man nun obendrauf OWFS, oder irgendein anderes Modul macht, ist
eigentlich egal.
Bei dem FHEM-1-Wire Modul wird man für USB deutlich mehr implementieren
müssen als für CUNO, da dir CUNO-Firmware einiges von 1-Wire bereits
macht. Speicher auslesen, Devices am Bus listen, ets.
Wenn man so ein Modul hätte und wählen kann, wie man mit dem Bus redet,
ist der Rest dann egal. Man müßte sich nur auf eine Schnittstelle "nach
oben" einigen, die dieses Modul dann abliefert und worauf OWFS und der
Rest aufsetzen kann.
Dies wäre dann ein etwas größeres Software-Anliegen, da man hier VOR dem
loshacken mal über Strukturen und Schnittstellen nachdenken muß.
Würde gern sowas mitbauen. Ist die Frage, wer sich noch dran beteiligt.
Gruß,
Olaf
Am 27.12.2011 16:38, schrieb Martin Fischer:
> hiya,
>
> dann will ich auch mal ein paar worte zum thema verlieren ohne jetzt explizit
> teile deiner mail zu quoten..
>
> ich selber setze mehr als nur temperatur-sensoren unter 1-wire ein und halte
> es aus meiner sicht für überflüssig, das rad neu zu erfinden. die variante
> mittels owfs auf die devices zuzugreifen ist seit jahren in der entwicklung
> und unterstützt viele unterschiedliche devices.
>
> ich selber nutze 1-wire um meinen gaszähler und diverse stromzähler zu
> counten, zuständen von türen und toren zu melden, sowie luftfeuchte zu messen.
> darüber hinaus kann ich noch ein LCD ansteuern. das ganze aus fhem heraus:
>
> -rw-r--r-- 1 root root 20447 2011-10-04 22:34 00_OWFS.pm
> -rw-r--r-- 1 root root 8363 2011-09-21 20:54 20_OWCOUNT.pm
> -rw-r--r-- 1 root root 13071 2011-09-21 20:54 20_OWHUB.pm
> -rw-r--r-- 1 root root 11751 2011-09-21 20:54 20_OWLCD.pm
> -rw-r--r-- 1 root root 8363 2011-09-21 20:54 20_OWMULTI.pm
> -rw-r--r-- 1 root root 22942 2011-09-21 20:54 20_OWSWITCH.pm
> -rw-r--r-- 1 root root 12778 2011-10-03 17:27 20_OWTEMP.pm
>
> leider sind die module nocht zu rudimentär, da ich zur zeit auf grund von
> anstehendem nachwuchs kaum die zeit finde zeit dort rein zustecken.
>
> generell verfolge ich das ziel:
> ein modul das die ganze kommunikation übernimmt:
> 00_OWFS
> und dann je nach sensor/ic eigene module:
> 20_OWCOUNT unterstützt derzeit DS2423
> 20_OWHUB unterstützt derzeit einen speziellen hutschienen hub und liest den
> DS2450 aus
> 20_OWLCD unterstützt derzeit LCD16, LCD20, LCD40
> 20_OWMULTI ist noch nicht fertig
> 20_OWSWITCH unterstützt derzeit DS2405, DS2406, DS2408, DS2413
> 20_OWTEMP unterstützt derzeit DS18B20, DS18S20
>
> das ganze OWFS geraffel ist ein rewrite gegenüber der bisherigen OWFS
> unterstützung in FHEM und komplett modular aufgebaut. die einzelnen module
> können sehr klein gehalten werden und nur für die darstellung, umrechnung,
> etc. genutzt werden, während 00_OWFS den bus überwacht (ALARMS) und die
> kommunikation zwischen den modulen und den devices übernimmt.
>
> letztlich muss jeder "seine variante" für sich entscheiden. ich finde den
> ansatz gut, das der CUNO 1-wire intergriert hat, jedoch nicht die umsetzung.
> 1-wire ist nun mal 1-wire und kein HMS device. das "vermischt" aus meiner
> sicht die technologien und schränkt stark ein.
>
> wenn man sich mal das OWFS genauer betrachtet, dann ist es aus meiner sicht
> kein "overhead"; das 1-wire perl modul könnte man komplett in FHEM im modul
> 00_OWFS integrieren; somit müsste man lediglich den 1-wire server daemon
> installieren. alle anderen perl-module von 1-wire benötigt man dann nicht.
> wozu sollte man dann also die ganze logik neu entwickeln. der aufwand eine
> cross-compile umgebung zu schaffen. es existiert ja nun mal schon alles und
> müsste nur zusammen geführt und gepflegt werden. ich habe sogar ein ppa-
> repository wo ich die owfs unterstützung für ubuntu vorhalte.
>
> da ich fhem nicht auf einer fritzbox betreibe, wäre es für alle seiten aus
> meiner sicht sinnvoller avm auf die nerven zu gehen, das sie die notwendigen
> module integriert. das owfs auf 'ner fritzbox ohne probleme läuft, zeigt ja
> die unterstützung seitens freetz.
>
> schön wäre auch peter, wenn du mir meine frage aus september beantworten
> könntest, damit ich das modul 20_OWHUB mal fertigstellen kann ;-) wir
> schrieben ja bereits mehrfach darüber, doch die "formel zu umrechnung" von dir
> ist bisher ausgeblieben.
>
> ich will hier jetzt keine grundsatz diskussion anstossen, aus meiner sicht
> wird 1-wire hier leider immer nur auf "temperatur-messung" reduziert, dabei
> stehen mit 1-wire viele türen offen. deshalb halte ich auch ein "rewrite" oder
> "device-mapping" langfristig für nicht die richtige variante.
>
> generell halte ich es für sinnvoll bestehende APIs, schnittstellen, etc. zu
> nutzten und fhem dafür fit zu machen mit diesen zu kommunizieren. aber auch
> fhem um eine vernüftige API zu erweitern, um eine einheitliche schnittstelle
> nach aussen (für z.b. frontends, cacti, etc.) anzubieten.
>
> gruss martin
>
--
------------------------------------------------------------------------
Prof. Dr. Olaf Droegehorn
General Manager Tel. : +49-561-82020-410
DHS - Computertechnik GmbH Fax. : +49-561-82020-399
Carlsdorfer Straße 3 E-Mail: O.Droegehorn@dhs-
computertechnik.de
D-34128 Kassel WEB: www.dhs-computertechnik.de
------------------------------------------------------------------------
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
hallo olaf,
Am Dienstag, 27. Dezember 2011 schrieb Olaf Droegehorn:
> ich geb Dir völlig recht, 1-Wire kann mehr als Temp-Sensoren. Da aber
> dies der häufigste Einsatz ist haben wir in der CUNO-FW erstmal dafür
> ein Mapping gemacht.
mein beitrag sollte auch keine kritik wiedergeben. allein die umsetzung
mittels mapping halte ich halt für nicht *ideal*.
> Die Firmware unterstützt viel mehr, und ich hätte auch gern ein 1-Wire
> FHEM MOdul, wo man wählen kann, ob man ein USB-Device als Transmitter
> nutzt, oder eben den CUNO.
> [...]
> > Dies wäre dann ein etwas größeres Software-Anliegen, da man hier VOR dem
> loshacken mal über Strukturen und Schnittstellen nachdenken muß.
du sprichst mir hiermit aus der seele!
ich hätte auch am liebsten _ein_ modul, das sowohl einen ds9490r (u.a.), cuno
oder owfs server bedienen kann. das wäre dann aus meiner sicht eine
zukunftsweisende implementierung von 1-wire, da sie dem nutzer freistellt
seine hard- / software auszuwählen.
meine "kritik", wenn man sie denn als solche interpretieren möchte, richtete
sich daran, das peter die 3. variante von 1-wire implementieren möchte. klar
erkenne ich auch sein motiv, es möglichst "einfach" auf embedded systemen wie
z.b. fritzbox ans laufen zu bekommen ohne grosse abhängikeiten anderer module.
letztlich habe ich den nutzer im fokus:
wir sehen fast täglich wie schwer sich "greenhorns" mit fhem am anfang tun.
wenn nun auch noch 3 verschiedene varianten für z.b. nur die temperatur
abfrage von 1-wire komponenten umgesetzt werden, diese auch noch von 3
verschiedenen developern umgesetzt werden, dann sind wir wieder da wo wir
schon vor geraumer zeit diskutiert haben (und uns aus meiner sicht immer noch
nicht weiterbewegt haben, weshalb auch myHCE 2.0 auf "eis liegt"). es wird
dann wieder unterschiedliche umsetzungen jedes einzelnen developers geben, was
dazu führt, das mehr aufwand in die darstellungsebene (frontends oder fhem
list TYPE=, etc.) gesteckt werden muss und somit total
"verwurschtelt" wird.
gerade in bezug auf die frontends ist es aus meiner sicht wichtig, vernünftige
schnittstellen zu implementieren, die genau das liefern, was gerade angezeigt
werden soll. dabei sollte die logik aber auch die einheitliche präsentation
der daten (on, off, open, close, temperature, humidity, etc.) möglichst in
fhem bleiben.
klar ist auch, das der vorteil an fhem die flexibilität und die "alle wege
führen nach rom" strategie ist, dennoch bin ich der meinung das ein gewisser
grad von standardisierung fhem keineswegs einschrängt, sondern es einfacher
machen würde. und somit wieder dem nutzer zu gute kommt.
ich habe lange die "füsse stillgehalten" bezüglich coding-styles, api, etc.
aber wenn es nun schule macht, das technologien die fhem bereits unterstützt
in unterschiedliche modulen implementiert werden und der benutzer sich fragt,
warum das alles "doppelt-gemoppelt" ist, stelle ich mir die frage wohin das
dann führen soll, bzw. wer das dem nutzer erklären und die ganzen code warten
soll.
besonders dann, wenn module auf "exotische" kernelmodule zurück greifen
müssen, die erst in einer cross-compile umgebung gebaut werden müssen um auf
system "x" oder "y" zu laufen. wenn dann der entwickler sein interesse
verliert oder "keine lust" mehr hat und sich keiner der sache annimmt werden
die module dann einschlafen oder den nächsten versionssprung von fhem dann
nicht überleben. schlimmstenfalls aber auch die portierung auf andere systeme
aka fritzbox behindern.
deshalb beführworte ich deinen ansatz absolut und werde ihn unterstützen.
ich habe mal einen follow-up nach "fhem-developers" gemacht.
@peter:
du bist herzlichst eingeladen dich dort zu beteiliegen. besonders was die
standardisierung von bezeichnungen, berechnungen, etc. angeht um das thema
evtl. doch mal wieder aufzugreifen und dann vielleicht anstatt der geplanten
5.0er integration das zur 6.0er zu schaffen ;-)
martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Olaf Droegehorn wrote:
> Hallo Martin,
>
> ich geb Dir völlig recht, 1-Wire kann mehr als Temp-Sensoren. Da aber
> dies der häufigste Einsatz ist haben wir in der CUNO-FW erstmal dafür
> ein Mapping gemacht.
... was, ich selber nutze noch keinen CUNO, das leidige Thema der UI-
Einbindung gleich erschlagen dürfte (Weitergabe der 1-Wire-Sensoren
als bekanntes Gerät).
Ich nutze seit Jahren Selbstbau-Sensorkabel auf Basis des 9097-Ansatzes
mit digitemp. Works for me, allerdings nutze ich bislang auch nicht mehr
als 3-4 DS1820 am ungespeisten 1-Wire-Bus. Dafür tat das bislang auch
unter ARM (meiner präferierten Home-Automation-Plattform) mit 'nem ollen
USB2Serial-Konverter (als auch per ssh-Aufruf über vernetzte Systeme
hinweg). Bislang habe ich das nur experimentell an FHEM angeflanscht
(eben auf Basis von digitemp, welches als externes Kommando periodisch
aufgerufen wird), würde mich aber über eine OWFS-lose generische Imple-
mentation freuen. (Und ich mappe optional DS1820 zu CUL_WS-Temperatur-
fühlern, da das erstens kein funktionaler Verlust ist und zweitens dies
die einzig existierende Möglichkeit darstellt, diese Daten zu nutzen,
ohne selbst Frontends schreiben zu müssen -- FHEM-Devel-Diskussion von
vor 2? Jahren.)
MfG,
-kai
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com