[FHZ] CUL ersetzt FHZ1300

Martin Fischer · 20 Dezember 2009, 22:32:28

Am Donnerstag 17 Dezember 2009 schrieb Martin Fischer:
> Am Donnerstag 17 Dezember 2009 schrieb Manfred Caspari:
> > ich hatte auch komische Effekte bei der Umstellung. Habe dann die FHT's
> > wie in Punkt6 der FAQ beschrieben neu "angelernt", und seither keine
> > Probleme.
> >
> > > http://www.koeniglich.de/fhem/faq.html#faq6
>
> und genau das hat seit jahren mit dem fhz1300 funktioniert, nur mit dem cul
> will es nicht

ich habe zum testen an einem rechner den fhz1300 und an einem zweiten rechner
den cul. kann es evtl. daran liegen, das ich mit dem cul meine fht's nicht
paaren kann, weil sich die beiden (fhz1300 / cul) in die quere kommen?

--

You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

Dr. Boris Neubert · 21 Dezember 2009, 08:22:50

> ich habe zum testen an einem rechner den fhz1300 und an einem zweiten rechner
> den cul. kann es evtl. daran liegen, das ich mit dem cul meine fht's nicht
> paaren kann, weil sich die beiden (fhz1300 / cul) in die quere kommen?

Das ist sogar sehr wahrscheinlich, ich habe es in diversen Postings schon so
erwaehnt.

Trotzdem wurmt mich wieso "get CUL T02" nichts meldet.
Koenntest Du folgendes in einem Screen/Minicom, welches mit dem CUL verbunden
ist, ausfuehren, und mir/uns die Ergebnisse zeigen.

% screen /dev/ttyACM0 (oder vergleichbares)
V
T01
T02
T12344142
T02
T010000
T02

Ich habe gerade mein CUL mit dem 1.35 CUL.hex von der Webseite geflashed, und
bekomme folgende Ergebnisse:

V => V 1.35 CUL868
T01 => 0000
T02 => N/A
T1234416742 =>
T02 => 1234:4142
T010000 =>
T02 => N/A

Eigentlich koennte man auch in fhem die gleichen Befehle ausfuehren, jeweils
als "get CUL raw XXX" wenn man Daten zurueckhaben will, oder "set CUL raw XXX",
wenn keine Ergebnisse gemeldet werden (z.Bsp beim T1234416742 oder beim
T010000).

Gruss,
Rudi

--

You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

Martin Fischer · 21 Dezember 2009, 09:26:52

guten morgen rudi,

Am Montag 21 Dezember 2009 schrieb Rudolf Koenig:
> Trotzdem wurmt mich wieso "get CUL T02" nichts meldet.
> Koenntest Du folgendes in einem Screen/Minicom, welches mit dem CUL
> verbunden ist, ausfuehren, und mir/uns die Ergebnisse zeigen.
>
> % screen /dev/ttyACM0 (oder vergleichbares)
> V
> T01
> T02
> T12344142
> T02
> T010000
> T02

V => V 1.35 CUL868
T01 => 3B3B
T02 =>
T1234416742 =>
T02 =>
T010000 =>
T02 =>

kann es sein, dass das CUL defekt ist? aber komischerweise kann ich alle FS20
aktoren schalten.

gruß martin

--

You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

Tobias · 21 Dezember 2009, 10:01:36

> V => V 1.35 CUL868
> T01 => 3B3B
> T02 =>

Kannst Du "T03" ausprobieren? Beim mir liefert es "4a" zurueck. Wenn das bei
Dir auch leer ist, dann hast Du ein Firmware bei dem das FHT80b Support
(#define HAS_FHT_80b) ausgeschaltet ist, z.Bsp der CUL_FHT8v.hex ist so einer.

--

You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

rudolfkoenig · 21 Dezember 2009, 10:11:12

Am Montag 21 Dezember 2009 schrieb Rudolf Koenig:
> > V => V 1.35 CUL868
> > T01 => 3B3B
> > T02 =>
>
> Kannst Du "T03" ausprobieren? Beim mir liefert es "4a" zurueck. Wenn das
> bei Dir auch leer ist, dann hast Du ein Firmware bei dem das FHT80b
> Support (#define HAS_FHT_80b) ausgeschaltet ist, z.Bsp der CUL_FHT8v.hex
> ist so einer.

T03 =>
in der tat, ich habe CUL_FHT8v.hex geflasht. aber erst nachdem ich mit CUL.hex
keinen erfolg hatte (schrieb ich ja bereits).

es ist mir aus keiner beschreibung her bewusst, das dort der komplette support
für die 80b disabled ist. vielleicht als vorschlag: einfach an die version den
flashtyp anhängen. das erleichtert das debugging

na dann werd ich mal wohl neu flashen und mich gleich wieder melden.

--

You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

Tobias · 21 Dezember 2009, 10:31:50

Am Montag 21 Dezember 2009 schrieb Martin Fischer:
> Am Montag 21 Dezember 2009 schrieb Rudolf Koenig:
> > > V => V 1.35 CUL868
> > > T01 => 3B3B
> > > T02 =>
> >
> > Kannst Du "T03" ausprobieren? Beim mir liefert es "4a" zurueck. Wenn das
> > bei Dir auch leer ist, dann hast Du ein Firmware bei dem das FHT80b
> > Support (#define HAS_FHT_80b) ausgeschaltet ist, z.Bsp der CUL_FHT8v.hex
> > ist so einer.

ok.. nachdem ich nun "make conf1" statt "make conf2" ausgeführt und dann die
CUL.hex geflasht habe kommt nun:

V => V 1.35 CUL868
T01 => 0000
T02 => N/A
T1234416742 =>
T02 => 1234:4167,42
T010000 =>
T02 => N/A
T03 => 4A

einzige abweichung gegenüber deiner ausgabe ist das erste T02:

bei dir:
> 1234:4142

bei mir:
1234:4167,42

aber zu meiner ehrenrettung muss ich sagen:

zitat README:
CUL firware needs compileconfig.h. Before the first build type either
"make conf1" oder "make conf2".

To compile the CUL firmware with RF_ROUTING support (and without FHT8v),
type "make conf1".
To compile the CUL firmware with FHT8v support (and without RF_ROUTING),
type "make conf2".

hieraus geht nicht hervor, das bei conf2 auch der ganze FHT support disabled
wird. ich interpretiere das so:

make conf1: hat zusätzlich RF_ROUTING aber kann nicht mit FHT8v kommunizieren
make conf2: hat kann mit FHT8v kommunizieren hat dafür aber nicht RF_ROUTING

vielleicht sollte man bei conf2 ergänzen, das dann auch der FHT80b support
disabled ist.

so: nun werde ich erstmal die FHZ abklemmen und dann sehen ob das paaren nun
funktioniert.

--

You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

Tobias · 21 Dezember 2009, 11:04:21

Am Montag 21 Dezember 2009 schrieb Martin Fischer:
> so: nun werde ich erstmal die FHZ abklemmen und dann sehen ob das paaren
> nun funktioniert.

it work's

danke rudi, für den entscheidenen hinweis!

--

You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

Tobias · 21 Dezember 2009, 13:58:26

nachdem der fehler mit der falschen firmware nun geklärt ist, bleibt noch das
folgende offen:

Am Mittwoch 16 Dezember 2009 schrieb Martin Fischer:
> kurz nochmal die ausgangsbasis:
> # CUL868
> define CUL868 CUL /dev/cul868 3333
> attr CUL868 model CUL
>
> define EG.bu.HZ FHT 1701
> define EG.bz.HZ FHT 1501
> define EG.sz.HZ FHT 1801
> define EG.wz.HZ FHT 0b01

jetzt auch alle gepaart.

> fhem> set CUL868 verbose 61
> 2009.12.16 23:21:04 4: set CUL868 verbose 61
> 2009.12.16 23:21:20 4: CUL868: T47149402FA
> 2009.12.16 23:21:20 3: FHT Unknown device 4714, please define it
> 2009.12.16 23:21:21 4: CUL868: T47149482FA
> 2009.12.16 23:21:21 3: FHT Unknown device 4714, please define it
>
> wo zum teufel kommt das nun her? selbiges kommt für 340c, cc55 und

bleibt also zu klären, was das hier nun für devices sind:

2009.12.21 13:23:41 3: FHT Unknown device 4714, please define it
2009.12.21 13:23:42 3: FHT Unknown device 4714, please define it
2009.12.21 13:24:33 3: FHT Unknown device 340c, please define it
2009.12.21 13:24:33 3: FHT Unknown device 340c, please define it
2009.12.21 13:25:09 3: FHT Unknown device ecb1, please define it
2009.12.21 13:25:09 3: FHT Unknown device ecb1, please define it
2009.12.21 13:25:45 3: FHT Unknown device cc55, please define it
2009.12.21 13:25:45 3: FHT Unknown device cc55, please define it

und was das die für werte liefern.

nun habe ich auch diese definiert:
define foo.01 FHT 340c
define foo.02 FHT ecb1
define foo.03 FHT cc55
define foo.04 FHT 4714

und sicherheitshalber auch ein befehl hinterher gesendet:
set TYPE=FHT time

ergebnis:
2009.12.21 13:36:39 2: FHT set foo.1 hour 13 minute 36
2009.12.21 13:36:39 2: FHT set foo.2 hour 13 minute 36
2009.12.21 13:36:39 2: FHT set foo.3 hour 13 minute 36
2009.12.21 13:36:39 2: FHT set foo.4 hour 13 minute 36
2009.12.21 13:37:09 4: FHT foo.1 (Unknown: 0a => 27)
2009.12.21 13:37:09 4: FHT foo.1 (Unknown: 0a => 27)
2009.12.21 13:37:21 4: FHT foo.2 (Unknown: 96 => 11)
2009.12.21 13:37:21 4: FHT foo.2 (Unknown: 96 => 12)
2009.12.21 13:38:09 4: FHT foo.3 (Unknown: d4 => 15)
2009.12.21 13:38:09 4: FHT foo.3 (Unknown: d4 => 14)
2009.12.21 13:40:13 4: FHT foo.4 (Unknown: 94 => 242)
2009.12.21 13:40:14 4: FHT foo.4 (Unknown: 94 => 242)
2009.12.21 13:41:21 4: FHT foo.1 (Unknown: 0a => 27)
2009.12.21 13:41:25 4: FHT foo.2 (Unknown: 96 => 12)
2009.12.21 13:41:25 4: FHT foo.2 (Unknown: 96 => 13)
2009.12.21 13:42:17 4: FHT foo.3 (Unknown: d4 => 22)
2009.12.21 13:42:17 4: FHT foo.3 (Unknown: d4 => 17)
2009.12.21 13:44:21 4: FHT foo.4 (Unknown: 94 => 243)
2009.12.21 13:44:22 4: FHT foo.4 (Unknown: 94 => 243)
2009.12.21 13:45:29 4: FHT foo.2 (Unknown: 96 => 12)
2009.12.21 13:45:29 4: FHT foo.2 (Unknown: 96 => 12)
2009.12.21 13:45:33 4: FHT foo.1 (Unknown: 0a => 28)
2009.12.21 13:45:33 4: FHT foo.1 (Unknown: 0a => 27)
2009.12.21 13:46:25 4: FHT foo.3 (Unknown: d4 => 13)

fhem> list foo.1
Internals:
CODE 340c
CUL868_MSGCNT 9
CUL868_RAWMSG T340C0A821B
CUL868_TIME 2009-12-21 13:49:45
DEF 340c
IODev CUL868
LASTIODev CUL868
MSGCNT 9
NAME foo.1
NR 730
STATE

TYPE FHT
Attributes:
retrycount 3

die anderen sehen genauso aus.

--

You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

UliM · 21 Dezember 2009, 14:04:50

Am Mittwoch 16 Dezember 2009 schrieb Martin Fischer:
> hiya,
>
> habe heute meinen ersten CUL in betrieb genommen. dieser soll die FHZ1300
> voll ersetzten.
>
> auf den ersten anhieb klappt es auch so wie es scheint, doch das eine oder
> andere problem habe ich noch:

nach der (jetzt funktionierenden) paarung habe ich

fhem> set TYPE=FHT report1 255 report2 255

abgesetzt. nach kurzer zeit bekomme ich auch schon die ersten rückmeldungen:

2009.12.21 13:49:55 4: CUL868: T17017D67331B
2009.12.21 13:49:55 4: FHT EG.bu.HZ start-xmit: 51
2009.12.21 13:49:55 4: CUL868: T17017D7733FA
2009.12.21 13:49:55 4: FHT EG.bu.HZ FHZ:start-xmit: 51
2009.12.21 13:49:56 4: CUL868: T17012869331A
2009.12.21 13:49:56 4: FHT EG.bu.HZ sat-from1: 08:30
2009.12.21 13:49:56 4: CUL868: T1701287933FA
2009.12.21 13:49:56 4: FHT EG.bu.HZ FHZ:sat-from1: 08:30
2009.12.21 13:49:56 4: CUL868: T170129698F1B
2009.12.21 13:49:56 4: FHT EG.bu.HZ sat-to1: 23:50
2009.12.21 13:49:56 4: CUL868: T170129798FFA
2009.12.21 13:49:56 4: FHT EG.bu.HZ FHZ:sat-to1: 23:50
2009.12.21 13:49:56 4: CUL868: T17012A69901B
2009.12.21 13:49:56 4: FHT EG.bu.HZ sat-from2: 24:00
2009.12.21 13:49:56 4: CUL868: T17012A7990FA
2009.12.21 13:49:56 4: FHT EG.bu.HZ FHZ:sat-from2: 24:00
2009.12.21 13:49:56 4: CUL868: T17012B69901A
2009.12.21 13:49:56 4: FHT EG.bu.HZ sat-to2: 24:00
2009.12.21 13:49:57 4: CUL868: T17012B7990FA
2009.12.21 13:49:57 4: FHT EG.bu.HZ FHZ:sat-to2: 24:00
2009.12.21 13:49:57 4: CUL868: T17012B7990FA
2009.12.21 13:49:57 4: FHT EG.bu.HZ FHZ:sat-to2: 24:00
2009.12.21 13:49:57 4: CUL868: T17014B67901B
2009.12.21 13:49:57 4: FHT EG.bu.HZ ack: 144
2009.12.21 13:49:57 4: CUL868: T17014B7790FA
2009.12.21 13:49:57 4: FHT EG.bu.HZ FHZ:ack: 144
2009.12.21 13:49:58 4: CUL868: T17012C69331B
2009.12.21 13:49:58 4: FHT EG.bu.HZ sun-from1: 08:30
2009.12.21 13:49:58 4: CUL868: T17012C7933FA
2009.12.21 13:49:58 4: FHT EG.bu.HZ FHZ:sun-from1: 08:30
2009.12.21 13:49:58 4: CUL868: T17012D698F1B
2009.12.21 13:49:58 4: FHT EG.bu.HZ sun-to1: 23:50
2009.12.21 13:49:58 4: CUL868: T17012D798FFA
2009.12.21 13:49:58 4: FHT EG.bu.HZ FHZ:sun-to1: 23:50
2009.12.21 13:49:58 4: CUL868: T17012E69901A
2009.12.21 13:49:58 4: FHT EG.bu.HZ sun-from2: 24:00
2009.12.21 13:49:58 4: CUL868: T17012E7990FA
2009.12.21 13:49:58 4: FHT EG.bu.HZ FHZ:sun-from2: 24:00
2009.12.21 13:49:58 4: CUL868: T17012F69901B
2009.12.21 13:49:58 4: FHT EG.bu.HZ sun-to2: 24:00
2009.12.21 13:49:59 4: CUL868: T17012F7990FA
2009.12.21 13:49:59 4: FHT EG.bu.HZ FHZ:sun-to2: 24:00
2009.12.21 13:49:59 4: CUL868: T17014B67901A
2009.12.21 13:49:59 4: FHT EG.bu.HZ ack: 144
2009.12.21 13:49:59 4: CUL868: LOVF
2009.12.21 13:49:59 2: CUL: unknown message LOVF
2009.12.21 13:49:59 4: CUL868: T17014B7790FA
2009.12.21 13:49:59 4: FHT EG.bu.HZ FHZ:ack: 144
2009.12.21 13:49:59 4: CUL868: LOVF
2009.12.21 13:49:59 2: CUL: unknown message LOVF
2009.12.21 13:49:59 4: CUL868: T17014B7790FA
2009.12.21 13:49:59 4: FHT EG.bu.HZ FHZ:ack: 144
2009.12.21 13:49:59 4: CUL868: LOVF
2009.12.21 13:49:59 2: CUL: unknown message LOVF
2009.12.21 13:49:59 4: CUL868: T17014B7790FA
2009.12.21 13:49:59 4: FHT EG.bu.HZ FHZ:ack: 144
2009.12.21 13:50:00 4: CUL868: LOVF
2009.12.21 13:50:00 2: CUL: unknown message LOVF
2009.12.21 13:50:00 4: CUL868: T17014B7790FA
2009.12.21 13:50:00 4: FHT EG.bu.HZ FHZ:ack: 144

was hat es mit

CUL868: LOVF
CUL: unknown message LOVF

auf sich? das habe ich FHZ nie gesehen. das ganze tritt bei mehreren FHT's
auf.

--

You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

Martin Fischer · 21 Dezember 2009, 14:25:10

einen hab ich noch

fhem> set TYPE=FHT time
No set implemented for EG.bu.TK.01
No set implemented for EG.es.TK.01
No set implemented for EG.sz.TK.01
No set implemented for EG.wz.TK.01

wobei es sich bei EG.*.TK.01 um TYPE CUL_FHTTK handelt. diese sollten bei

set TYPE=FHT

ausgeschlossen werden.

--

You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

rudolfkoenig · 21 Dezember 2009, 15:35:18

> was hat es mit
>
> CUL868: LOVF
> CUL: unknown message LOVF
>
> auf sich? das habe ich FHZ nie gesehen. das ganze tritt bei mehreren FHT's
> auf.

LOVF = Limit-OVerFlow = 1% Sendezeit ueberschritten

Die zweite Zahl beim "get CUL raw X" zeigt die verbliebene Sendezeit in 10ms
Einheiten an. Eine der viertelstuendlichen Nachrichten von einer FHT
entgegenzunehmen braucht ca. 53 Einheiten. Eine FS20 Nachricht senden ca 20
Einheiten. 10 FHT's belegen ca 60% der Sendezeit eines CULs nur mit der
Temperatur-Meldungen. Mehr wenn Nachrichten wegen schlechten Empfang wiederholt
werden.

--

You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

Martin Fischer · 21 Dezember 2009, 15:45:48

Am Montag 21 Dezember 2009 schrieb Rudolf Koenig:
> LOVF = Limit-OVerFlow = 1% Sendezeit ueberschritten
>
> Die zweite Zahl beim "get CUL raw X" zeigt die verbliebene Sendezeit in
> 10ms Einheiten an. Eine der viertelstuendlichen Nachrichten von einer FHT
> entgegenzunehmen braucht ca. 53 Einheiten. Eine FS20 Nachricht senden ca
> 20 Einheiten. 10 FHT's belegen ca 60% der Sendezeit eines CULs nur mit der
> Temperatur-Meldungen. Mehr wenn Nachrichten wegen schlechten Empfang
> wiederholt werden.

ah, danke! werden die dann weiterhin ge'buffered' oder muss ich die dann
später erneut senden?

--

You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

Matthias Gehre · 21 Dezember 2009, 16:02:20

> ah, danke! werden die dann weiterhin ge'buffered' oder muss ich die dann
> später erneut senden?

Eine Nachricht wird nur dann aus dem CUL-Puffer geloescht, falls der FHT sie
entgegengenommen hatte. Der Puffer kann also leicht vollaufen, falls man einem
ausgeschalteten FHT Daten sendet...

--

You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

rudolfkoenig · 21 Dezember 2009, 19:07:30

> fhem> set TYPE=FHT time
> No set implemented for EG.bu.TK.01
[...]

Habs geaendert und alles eingecheckt.

--

You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.

Dr. Boris Neubert · 21 Dezember 2009, 20:12:54

Am Montag 21 Dezember 2009 schrieb Rudolf Koenig:
> > ah, danke! werden die dann weiterhin ge'buffered' oder muss ich die dann
> > später erneut senden?
>
> Eine Nachricht wird nur dann aus dem CUL-Puffer geloescht, falls der FHT
> sie entgegengenommen hatte. Der Puffer kann also leicht vollaufen, falls
> man einem ausgeschalteten FHT Daten sendet...

kann man denn den puffer manuell löschen?

wie ist das mit der reihenfolge? wenn der erste im buffer liegende befehl
nicht ge'acked' wird, bleiben dann die anderen dahinter im buffer hägen?

wäre es hier nicht angebracht nach einem timeout den 'blocker' zu löschen?

--

You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.