FHEM Forum
FHEM => fhem-users => Thema gestartet von: Guest am 24 April 2012, 03:13:05
Originally posted by: <email address deleted>
Nach einigen Stunden habe ich folgendes Ergebnis:
- Stellantrieb mit HM-CC-TC gepaart
- HM-CC-TT mit FHEM gepaart
- Alle Nachrichten von HM-CC-TC kommen bei FHEM an. (z.B. wenn die
SOLL-Temperatur am Gerät manuell verändert wurde sowie die zyklischen
Benachrichtigungen über die IST-Daten)
- die meisten Befehle von FHEM zum HM-CC-TC kommen nur sporadisch an.
Ich habe zwar einige hinbekommen, jedoch mit x-mal ausprobieren
Meist folgt auf einen set desired-temp Befehl ein Missing-Ack.
Manchmal funktioniert es und es kommt ein desired-temp-ack zurück.
Auf der Kommandozeile (nicht in der Telnet-Sitzung) bekomme ich
machmal folgende Meldung:
# Use of uninitialized value in sprintf at /opt/share/fhem/FHEM/
10_CUL_HM.pm line 455.
Ich bin jetzt kein Linux-Kenner - jedoch wundert mich die Ausgabe in
der Shell.
Any Ideas?
Viele Grüße,
Merhan
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo,
vielleicht vorher in der Group mal nach ähnlichen Problemen suchen.
Hier vielleicht :
http://groups.google.com/group/fhem-users/browse_thread/thread/2fe4abe2f299d795/b5f2cebb39c90baa?hl=de&lnk=gst&q=Missing+Ack#b5f2cebb39c90baa
Viele Grüße
Michael
On 24 Apr., 03:13, Merhan Öztürk
wrote:
> Nach einigen Stunden habe ich folgendes Ergebnis:
>
> - Stellantrieb mit HM-CC-TC gepaart
> - HM-CC-TT mit FHEM gepaart
>
> - Alle Nachrichten von HM-CC-TC kommen bei FHEM an. (z.B. wenn die
> SOLL-Temperatur am Gerät manuell verändert wurde sowie die zyklischen
> Benachrichtigungen über die IST-Daten)
>
> - die meisten Befehle von FHEM zum HM-CC-TC kommen nur sporadisch an.
> Ich habe zwar einige hinbekommen, jedoch mit x-mal ausprobieren
>
> Meist folgt auf einen set desired-temp Befehl ein Missing-Ack.
> Manchmal funktioniert es und es kommt ein desired-temp-ack zurück.
>
> Auf der Kommandozeile (nicht in der Telnet-Sitzung) bekomme ich
> machmal folgende Meldung:
>
> # Use of uninitialized value in sprintf at /opt/share/fhem/FHEM/
> 10_CUL_HM.pm line 455.
>
> Ich bin jetzt kein Linux-Kenner - jedoch wundert mich die Ausgabe in
> der Shell.
>
> Any Ideas?
>
> Viele Grüße,
> Merhan
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Danke für den Hinweis. Diesen Thread habe ich bereits studiert und er
hat mir leider nicht geholfen.
Der letzte Eintrag ist vom 21. Dez und da in der Wiki ein Artikel zu
HM_CC_TT vorhanden ist dachte ich, dass der Thread veraltet ist.
Laut diesem Thread ist die Unterstützung für HM_CC_TC noch nicht
vollständing implementiert:
In diesem
http://groups.google.com/group/fhem-users/browse_thread/thread/f48693ad0fd075ef/53dc546320a58adc?hl=de&lnk=gst&q=+HM-CC-TC#53dc546320a58adc
Mein nächstes Projekt war sowieso das Mitlesen einzurichten.
Freue mich über neue Erkenntnisse.
Grüße,
Merhan
On 24 Apr., 08:50, itjunky wrote:
> Hallo,
>
> vielleicht vorher in der Group mal nach ähnlichen Problemen suchen.
>
> Hier vielleicht :http://groups.google.com/group/fhem-users/browse_thread/thread/2fe4ab...
>
> Viele Grüße
>
> Michael
>
> On 24 Apr., 03:13, Merhan Öztürk
> wrote:
>
>
>
>
>
>
>
> > Nach einigen Stunden habe ich folgendes Ergebnis:
>
> > - Stellantrieb mit HM-CC-TC gepaart
> > - HM-CC-TT mit FHEM gepaart
>
> > - Alle Nachrichten von HM-CC-TC kommen bei FHEM an. (z.B. wenn die
> > SOLL-Temperatur am Gerät manuell verändert wurde sowie die zyklischen
> > Benachrichtigungen über die IST-Daten)
>
> > - die meisten Befehle von FHEM zum HM-CC-TC kommen nur sporadisch an.
> > Ich habe zwar einige hinbekommen, jedoch mit x-mal ausprobieren
>
> > Meist folgt auf einen set desired-temp Befehl ein Missing-Ack.
> > Manchmal funktioniert es und es kommt ein desired-temp-ack zurück.
>
> > Auf der Kommandozeile (nicht in der Telnet-Sitzung) bekomme ich
> > machmal folgende Meldung:
>
> > # Use of uninitialized value in sprintf at /opt/share/fhem/FHEM/
> > 10_CUL_HM.pm line 455.
>
> > Ich bin jetzt kein Linux-Kenner - jedoch wundert mich die Ausgabe in
> > der Shell.
>
> > Any Ideas?
>
> > Viele Grüße,
> > Merhan
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Einträge aus der LOG-Datei mit Verbose 5:
zwei mal den Befehl set desired-temp abgesetzt. Auch wenn es
funktioniert, dauert es recht lange bis ein desired-temp-ack kommt.
Im ersten Beispiel kommt die Message nach ca. 30 Sek.
Der zweite Befehl führte zu einem MISSING-ACK
///////// Befehl: >set WZ_Heizung desired-temp 16<
2012.04.24 12:07:18 5: SW: K
2012.04.24 12:07:18 5: HMLAN/RAW: /HHM-LAN-IF,
03C1,IEQ0245123,174037,67CA6C,0D9FDD9E,0004
2012.04.24 12:07:18 5: HMLAN_Parse: HMLAN1 HHM-LAN-IF,
03C1,IEQ0245123,174037,67CA6C,0D9FDD9E,0004
2012.04.24 12:07:18 5: Cmd: >set WZ_Heizung desired-temp 16<
2012.04.24 12:07:18 2: CUL_HM set WZ_Heizung desired-temp 16
2012.04.24 12:07:18 5: Triggering WZ_Heizung (1 changes)
2012.04.24 12:07:18 5: WZ_Heizung trigger: Checking Aufstehen for
notify
. weitere notify
.
.
///////// Reaktion nach einer Weile:
2012.04.24 12:07:43 5: SW: K
2012.04.24 12:07:43 5: HMLAN/RAW: /HHM-LAN-IF,
03C1,IEQ0245123,174037,67CA6C,0DA03F72,0004
2012.04.24 12:07:43 5: HMLAN_Parse: HMLAN1 HHM-LAN-IF,
03C1,IEQ0245123,174037,67CA6C,0DA03F72,0004
2012.04.24 12:08:03 5: HMLAN/RAW: /
E19CA61,0000,0DA08C6E,FF,FFC3,03867019CA6100000000C62B
2012.04.24 12:08:03 5: HMLAN_Parse: HMLAN1
E19CA61,0000,0DA08C6E,FF,FFC3,03867019CA6100000000C62B
2012.04.24 12:08:03 5: HMLAN1 dispatch A0C03867019CA6100000000C62B
2012.04.24 12:08:03 4: RCV L:0C N:03 CMD:8670
(TYPE=112,WAKEMEUP,BCAST,RPTEN) SRC:19CA61 DST:000000 00C62B
2012.04.24 12:08:03 5: SW: SE3D27A2D,00,00000000,01,E3D27A2D,
10A11267CA6C19CA61
2012.04.24 12:08:03 4: SND L:09 N:10 CMD:A112
(TYPE=18,WAKEUP,BIDI,RPTEN) SRC:67CA6C DST:19CA61 (HAVE_DATA)
2012.04.24 12:08:03 5: Triggering WZ_Heizung (0 changes)
2012.04.24 12:08:03 5: WZ_Heizung trigger: Checking Aufstehen for
notify
////////// hier ein Beispiel für ein Missing-Ack
////////// Befehl: >set WZ_Heizung desired-temp 15<
2012.04.24 12:18:20 5: HMLAN/RAW: /
E1877E7,0000,0DA9F96B,FF,FFC9,0782021877E719CA610101000031
2012.04.24 12:18:20 5: HMLAN_Parse: HMLAN1
E1877E7,0000,0DA9F96B,FF,FFC9,0782021877E719CA610101000031
2012.04.24 12:18:20 5: HMLAN1 dispatch A0E0782021877E719CA610101000031
2012.04.24 12:18:20 4: RCV L:0E N:07 CMD:8202 (TYPE=2,WAKEMEUP,RPTEN)
SRC:1877E7 DST:19CA61 0101000031
2012.04.24 12:18:22 5: Cmd: >set WZ_Heizung desired-temp 15<
2012.04.24 12:18:22 2: CUL_HM set WZ_Heizung desired-temp 15
2012.04.24 12:18:22 5: Triggering WZ_Heizung (1 changes)
2012.04.24 12:18:22 5: WZ_Heizung trigger: Checking Aufstehen for
notify
. weitere notify
.
.
/////////// Reaktion MISSING_ACK:
2012.04.24 12:20:10 5: HMLAN/RAW: /
E19CA61,0000,0DABA3BC,FF,FFC3,08867019CA6100000000C62A
2012.04.24 12:20:10 5: HMLAN_Parse: HMLAN1
E19CA61,0000,0DABA3BC,FF,FFC3,08867019CA6100000000C62A
2012.04.24 12:20:10 5: HMLAN1 dispatch A0C08867019CA6100000000C62A
2012.04.24 12:20:10 4: RCV L:0C N:08 CMD:8670
(TYPE=112,WAKEMEUP,BCAST,RPTEN) SRC:19CA61 DST:000000 00C62A
2012.04.24 12:20:10 5: SW:
SE3DD9205,00,00000000,01,E3DD9205,17A11267CA6C19CA61
2012.04.24 12:20:10 4: SND L:09 N:17 CMD:A112
(TYPE=18,WAKEUP,BIDI,RPTEN) SRC:67CA6C DST:19CA61 (HAVE_DATA)
2012.04.24 12:20:10 5: Triggering WZ_Heizung (0 changes)
2012.04.24 12:18:22 5: WZ_Heizung trigger: Checking Aufstehen for
notify
. weitere notify
.
.
2012.04.24 12:20:10 5: HMLAN/RAW: /RE3DD909D,0002,00000000,FF,7FFF,
16800267CA6C161D290101FE00
2012.04.24 12:20:10 5: HMLAN_Parse: HMLAN1 RE3DD909D,0002,00000000,FF,
7FFF,16800267CA6C161D290101FE00
2012.04.24 12:20:10 5: HMLAN1 dispatch A0D16800267CA6C161D290101FE00
2012.04.24 12:20:10 4: RCV L:0D N:16 CMD:8002 (TYPE=2,RPTEN) SRC:
67CA6C DST:161D29 0101FE00 (ACK_STATUS CHANNEL:01 STATUS:FE)
2012.04.24 12:20:10 5: HMLAN/RAW: /RE3DD9205,0008,00000000,FF,7FFF,
17A11267CA6C19CA61
2012.04.24 12:20:10 5: HMLAN_Parse: HMLAN1 RE3DD9205,0008,00000000,FF,
7FFF,17A11267CA6C19CA61
2012.04.24 12:20:10 5: HMLAN1 dispatch A0917A11267CA6C19CA61NACK
2012.04.24 12:20:10 5: Triggering WZ_Heizung (1 changes)
2012.04.24 12:20:10 5: WZ_Heizung trigger: Checking Aufstehen for
notify
. weitere notify
.
.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Im ersten Beispiel kommt die Message nach ca. 30 Sek.
Das HM-CC-TC ist die meiste Zeit am Schlafen, sendet nur alle fn(x) Sekunden
eine Nachricht an die Ventile, die wahrscheinlich auch synchron zum HM-CC-TC
schlafen. Die Funktion fn(x) ist mir unbekannt.
Wenn fhem an das HM-CC-TC was zu sagen hat (z.Bsp desired-temp), dann sendet es
die Nachricht nach dem Empfang der "Ventil"-Nachricht erst los.
Parallel dazu sendet fhem an dem HMLAN ein Keepalive (K) alle 25 Sekunden, da
nach 30Sek ohne keepalive das HMLAN die Verbindung selbst zuklappt.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Dass die Ventile mit HM-CC-TC synchron sind steht sogar in der Doku, damit
gibts auch mal Probleme was dann zum schnellen Batterieverbrauch führt.
Die Funktion fn(x) kenn ich auch noch nciht.
Ich hab das Thema Heizung zur Seite gelegt um mich in Ruhe im Sommer damit
zu beschäftigen wenn die Dinger nicht in Benutzung sind.
VG
Am Dienstag, 24. April 2012 12:39:44 UTC+2 schrieb Rudolf Koenig:
>
> > Im ersten Beispiel kommt die Message nach ca. 30 Sek.
>
> Das HM-CC-TC ist die meiste Zeit am Schlafen, sendet nur alle fn(x)
> Sekunden
> eine Nachricht an die Ventile, die wahrscheinlich auch synchron zum
> HM-CC-TC
> schlafen. Die Funktion fn(x) ist mir unbekannt.
>
> Wenn fhem an das HM-CC-TC was zu sagen hat (z.Bsp desired-temp), dann
> sendet es
> die Nachricht nach dem Empfang der "Ventil"-Nachricht erst los.
>
> Parallel dazu sendet fhem an dem HMLAN ein Keepalive (K) alle 25 Sekunden,
> da
> nach 30Sek ohne keepalive das HMLAN die Verbindung selbst zuklappt.
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
> Wenn fhem an das HM-CC-TC was zu sagen hat (z.Bsp desired-temp), dann sendet es
> die Nachricht nach dem Empfang der "Ventil"-Nachricht erst los.
Ok ich verstehe die Verzögerung.
Was ich nicht verstehe wie es ziemlich zeitnah nach einem Befehl FEHM -
> HM-CC-TC zu einem MISSING-ACK kommen kann:
Hier der Auszug aus der Log-Datei zu einem set desired-temp mit einem
unmittelbaren MISSING-ACK in der Telnet Konsole:
//////////////////////////////////
2012.04.24 12:59:10 5: HMLAN/RAW: /
E19CA61,0000,0DCF5BB7,FF,FFC3,17A25819CA611877E70000
2012.04.24 12:59:10 5: HMLAN_Parse: HMLAN1
E19CA61,0000,0DCF5BB7,FF,FFC3,17A25819CA611877E70000
2012.04.24 12:59:10 5: HMLAN1 dispatch A0B17A25819CA611877E70000
2012.04.24 12:59:10 4: RCV L:0B N:17 CMD:A258
(TYPE=88,WAKEMEUP,BIDI,RPTEN) SRC:19CA61 DST:1877E7 0000
2012.04.24 12:59:10 5: SW:
SE40147E4,00,00000000,01,E40147E4,23A11267CA6C19CA61
2012.04.24 12:59:10 4: SND L:09 N:23 CMD:A112
(TYPE=18,WAKEUP,BIDI,RPTEN) SRC:67CA6C DST:19CA61 (HAVE_DATA)
2012.04.24 12:59:10 5: Triggering WZ_Heizung (0 changes)
2012.04.24 12:59:10 5: WZ_Heizung trigger: Checking Aufstehen for
notify
2012.04.24 12:59:10 5: HMLAN/RAW: /
E1877E7,0000,0DCF5C3A,FF,FFC9,1782021877E719CA610101000031
2012.04.24 12:59:10 5: HMLAN_Parse: HMLAN1
E1877E7,0000,0DCF5C3A,FF,FFC9,1782021877E719CA610101000031
2012.04.24 12:59:10 5: HMLAN1 dispatch A0E1782021877E719CA610101000031
2012.04.24 12:59:10 4: RCV L:0E N:17 CMD:8202 (TYPE=2,WAKEMEUP,RPTEN)
SRC:1877E7 DST:19CA61 0101000031
2012.04.24 12:59:11 5: HMLAN/RAW: /RE40147E4,0008,00000000,FF,7FFF,
23A11267CA6C19CA61
2012.04.24 12:59:11 5: HMLAN_Parse: HMLAN1 RE40147E4,0008,00000000,FF,
7FFF,23A11267CA6C19CA61
2012.04.24 12:59:11 5: HMLAN1 dispatch A0923A11267CA6C19CA61NACK
2012.04.24 12:59:11 5: Triggering WZ_Heizung (1 changes)
2012.04.24 12:59:11 5: WZ_Heizung trigger: Checking Aufstehen for
notify
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Hier der Auszug aus der Log-Datei zu einem set desired-temp mit einem
> unmittelbaren MISSING-ACK in der Telnet Konsole:
Stell mal verbose auf 4 (sonst wird es fuer diesen Zweck unleserlich), und
mseclog auf 1. Was bleibt:
> RCV L:0B N:17 CMD:A258 SRC:19CA61 DST:1877E7 0000
CC-TC an CC-VD, sollte von fhem als "actuator:0 %" gemeldet werden.
> SND L:09 N:23 CMD:A112 SRC:67CA6C DST:19CA61 (HAVE_DATA)
FHEM an CC-TC (hab was zu sagen, schick mir ein ACK)
> RCV L:0E N:17 CMD:8202 SRC:1877E7 DST:19CA61 0101000031
CC-VD an CC-TC: "actuator:0 %, motor:ok, battery:ok"
Das HMLAN ist (zu?) klug, und sendet schon mal ohne fhem-Auftrag ACKs, bzw.
beantwortet die AES Anfragen. Evtl. haengt das Problem damit zusammen. Oder
fhem haette erst nach dem CC-VD Antwort mit seinem HAVE_DATA melden sollen.
Ich habe solche Logs selber schon laenger untersucht, und nicht wesentlich mehr
rausgefunden, als bisher in 10_CUL_HM.pm implementiert ist. Evtl. muss man
unterschiedliche Theorien ausprobieren, das ueberlasse ich aber gerne anderen
:)
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Nachdem Mann ein NACK (0008) bekommen hat, sollte man gleich ein
"+123456,02,00," schicken.
Wobei 123456 die alte Zieladdresse ist
Beim nächsten HM-TT-TC aufwachen schickt der HMLAN dann ein bericht zum
FHEM aber diesmal mit status 0081. (wakemeup ist jetzt 0)
Das heisst, ich bin wach, schick mir neue auftrage (also ganz neu, auch
neue message nummer und timestamps)
Alle offene commands koennen jetzt geschickt werden (warten auf Ack, dann
die nächste, usw)
--Johan
On Tue, Apr 24, 2012 at 1:52 PM, Rudolf Koenig wrote:
> > Hier der Auszug aus der Log-Datei zu einem set desired-temp mit einem
> > unmittelbaren MISSING-ACK in der Telnet Konsole:
>
> Stell mal verbose auf 4 (sonst wird es fuer diesen Zweck unleserlich), und
> mseclog auf 1. Was bleibt:
>
>
> > RCV L:0B N:17 CMD:A258 SRC:19CA61 DST:1877E7 0000
> CC-TC an CC-VD, sollte von fhem als "actuator:0 %" gemeldet werden.
>
> > SND L:09 N:23 CMD:A112 SRC:67CA6C DST:19CA61 (HAVE_DATA)
> FHEM an CC-TC (hab was zu sagen, schick mir ein ACK)
>
>
> > RCV L:0E N:17 CMD:8202 SRC:1877E7 DST:19CA61 0101000031
> CC-VD an CC-TC: "actuator:0 %, motor:ok, battery:ok"
>
>
> Das HMLAN ist (zu?) klug, und sendet schon mal ohne fhem-Auftrag ACKs, bzw.
> beantwortet die AES Anfragen. Evtl. haengt das Problem damit zusammen.
> Oder
> fhem haette erst nach dem CC-VD Antwort mit seinem HAVE_DATA melden sollen.
>
> Ich habe solche Logs selber schon laenger untersucht, und nicht wesentlich
> mehr
> rausgefunden, als bisher in 10_CUL_HM.pm implementiert ist. Evtl. muss man
> unterschiedliche Theorien ausprobieren, das ueberlasse ich aber gerne
> anderen
> :)
>
> --
> 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>
Ich hatte mir auch ein HM-CFG-LAN sowie HM-CC-TC und HM-CC-VD vor einiger
Zeit gekauft und hatte beim Testsetup bzgl. desired-temp das gleiche
Problem. Ich hatte auch das Gefühl, dass das Setzen des desired-temp nur
funktioniert, wenn HM-CC-TC vorher aufgewacht war. Direkt nach dem Pairing
war das deshalb kein Problem.
Ich hatte danach wegen anderer Projekte die Geräte beiseite gelegt und war
davon ausgegangen, das das Problem zwischen meinen Ohren lag.
Zur Klärung:
- Gibt es das Problem des Setzens von desired-temp nur mit HM-CFG-LAN oder
auch mit CUL?
- Gibt es jemanden der das Problem nicht hat, also bei dem das Setzen von
desired-temp immer funktioniert?
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am 24.04.2012 um 18:33 schrieb Willi:
> Ich hatte mir auch ein HM-CFG-LAN sowie HM-CC-TC und HM-CC-VD vor einiger Zeit gekauft und hatte beim Testsetup bzgl. desired-temp das gleiche Problem. Ich hatte auch das Gefühl, dass das Setzen des desired-temp nur funktioniert, wenn HM-CC-TC vorher aufgewacht war. Direkt nach dem Pairing war das deshalb kein Problem.
> Zur Klärung:
>
> - Gibt es das Problem des Setzens von desired-temp nur mit HM-CFG-LAN oder auch mit CUL?
Meine oberflächliche Auswertung der Posting hier ergibt, das sich nur HM-CFG-LAN Benutzer über das Problem beschweren. Als ich noch das CUL hatte, ging es bei mir auch. Jetzt nur selten. Und zwar niemals, wenn das Setzen nach Funkverkehr zwischen HM-CC-TC und -VD stattfinden sollte. Also praktisch immer.
> - Gibt es jemanden der das Problem nicht hat, also bei dem das Setzen von desired-temp immer funktioniert?
Scheinbar ja.
Grüße
Oskar
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo
> - Gibt es das Problem des Setzens von desired-temp nur mit HM-CFG-LAN oder auch mit CUL?
> - Gibt es jemanden der das Problem nicht hat, also bei dem das Setzen von desired-temp immer funktioniert?
Ich habe 5 Stück HM-CC-TC gekoopelt mit je einem HM-CC-VD. Ich verwende einen CUL im rfmode homematic mit version 1.39. Ich kann problemlos die desired-temp ändern.
Gruss Dani
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Dienstag, 24. April 2012 18:46:19 UTC+2 schrieb eppi:
>
> Ich habe 5 Stück HM-CC-TC gekoopelt mit je einem HM-CC-VD. Ich verwende
> einen CUL im rfmode homematic mit version 1.39. Ich kann problemlos die
> desired-temp ändern.
>
Das ist ja seltsam. Ich hatte vermutet, dass es daran liegt, dass das
Timing noch nicht stimmt und HM-CC-TC erst die Befehle im Wachmodus
annimmt. Dann hätte es auch bei CUL Probleme geben müssen.
@Rudi: Wird HM-CC-TC in der CUL-Firmware oder in den CUL-Routinen für FHEM
irgendwie anders behandelt? So wie es eine FHT-Spezialbehandlung und
Warteschlange in der CUL Firmware gibt und hier erst gesendet wird, wenn
sicher ist, dass der FHT80b wach ist.
Oder liegt es daran, dass die HMLAN-Nutzer zumeist AES verwenden und hier
das Timing sowie der Ablauf unterschiedlich ist?
Seltsam.......
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
>
> Oder liegt es daran, dass die HMLAN-Nutzer zumeist AES verwenden und hier
> das Timing sowie der Ablauf unterschiedlich ist?
>
> Seltsam.......
Ich habe kein AES aktiviert und die Probleme. Zufällig ist heute mein
CUL- Modul gekommen. Ich wollte es für FS20 & Co verwenden jedoch
spricht nichts gegen einen Test.
Kann Ich relativ einfach meine vorhandene Konfig beibehalten und den
HM-Lan durch den CUL- Stick ersetzen?
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> @Rudi: Wird HM-CC-TC in der CUL-Firmware oder in den CUL-Routinen für FHEM
> irgendwie anders behandelt?
Nein. AskSin (==BidCos) in culfw ist sehr duenn...
> Oder liegt es daran, dass die HMLAN-Nutzer zumeist AES verwenden und hier
> das Timing sowie der Ablauf unterschiedlich ist?
Ich meine das HM-CC-TC verwendet kein AES. Ich tippe darauf, dass das HMLAN
(zu) klug ist, und manches anders macht, als ich denke. Ganz genau blicke ich
die HMLAN Kommandos eh noch nicht: z.Bsp folgendes in HMLAN_Write kann nur
Unfug sein:
===
if(!$lhash{$dst} && $dst ne "000000") { # Don't think I grok the logic
HMLAN_SimpleWrite($hash, "+$dst,00,00,");
HMLAN_SimpleWrite($hash, "+$dst,00,00,");
HMLAN_SimpleWrite($hash, "+$dst,00,00,");
HMLAN_SimpleWrite($hash, "-$dst");
HMLAN_SimpleWrite($hash, "+$dst,00,00,");
HMLAN_SimpleWrite($hash, "+$dst,00,00,");
HMLAN_SimpleWrite($hash, "+$dst,00,00,");
HMLAN_SimpleWrite($hash, "+$dst,00,00,");
$lhash{$dst} = 1;
}
===
aber das HMLAN-Config macht es auch so, und wenn ich die Wiederholungen
wegoptimiere, dann tut es auch nicht :/
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
I programmed it in basic, the way I described. 100% success rate.
--Johan
On Tue, Apr 24, 2012 at 9:06 PM, Rudolf Koenig wrote:
> > @Rudi: Wird HM-CC-TC in der CUL-Firmware oder in den CUL-Routinen für
> FHEM
> > irgendwie anders behandelt?
>
> Nein. AskSin (==BidCos) in culfw ist sehr duenn...
>
>
> > Oder liegt es daran, dass die HMLAN-Nutzer zumeist AES verwenden und hier
> > das Timing sowie der Ablauf unterschiedlich ist?
>
> Ich meine das HM-CC-TC verwendet kein AES. Ich tippe darauf, dass das HMLAN
> (zu) klug ist, und manches anders macht, als ich denke. Ganz genau blicke
> ich
> die HMLAN Kommandos eh noch nicht: z.Bsp folgendes in HMLAN_Write kann nur
> Unfug sein:
> ===
> if(!$lhash{$dst} && $dst ne "000000") { # Don't think I grok the
> logic
> HMLAN_SimpleWrite($hash, "+$dst,00,00,");
> HMLAN_SimpleWrite($hash, "+$dst,00,00,");
> HMLAN_SimpleWrite($hash, "+$dst,00,00,");
> HMLAN_SimpleWrite($hash, "-$dst");
> HMLAN_SimpleWrite($hash, "+$dst,00,00,");
> HMLAN_SimpleWrite($hash, "+$dst,00,00,");
> HMLAN_SimpleWrite($hash, "+$dst,00,00,");
> HMLAN_SimpleWrite($hash, "+$dst,00,00,");
> $lhash{$dst} = 1;
> }
> ===
> aber das HMLAN-Config macht es auch so, und wenn ich die Wiederholungen
> wegoptimiere, dann tut es auch nicht :/
>
> --
> 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>
Am Mittwoch, 25. April 2012 00:19:25 UTC+2 schrieb Johank:
>
> I programmed it in basic, the way I described. 100% success rate.
>
> --Johan
Hello Johan,
this sound very good!
Would you supply us with the pogramm code and also put it into FHEMs SVN?
Regards
Willi
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
das hilft jetzt vll nur noch begrenzt aber ich kann bestätigen dass ich
meine 4 Thermostate mit dem CUL problemlos bedienen kann und mit dem HMLAN
die o.b. Probleme habe.
VG
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Sequence as follows:
send a command....
receive a NACK (0008)
send +123456,02,00,
on the next tem/hum report from device 123456 (not a valve set command !!)
the HMLAN adapter will come back with delayed NACK,
(0081).
Then recreate the old command (pull it from the stack), pack it up again
with new msgnr, timestamps etc and send it out again.
That's all.
Hope someone can Perlifise this.
--Johan
2012/4/29 unimatrix
> das hilft jetzt vll nur noch begrenzt aber ich kann bestätigen dass ich
> meine 4 Thermostate mit dem CUL problemlos bedienen kann und mit dem HMLAN
> die o.b. Probleme habe.
>
> VG
>
>>
>> --
> 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>
ich habe nun endlich mein CUL am laufen und kann dies auch bestätigen.
Mit dem CUL gibt es keine Probleme. Alle Befehle werden deterministisch
angenommen.
Mit HMLAN bekommt man auf oft MISSING ACK auf Befehle seitens FHEM.
Am Sonntag, 29. April 2012 10:18:16 UTC+2 schrieb unimatrix:
>
> das hilft jetzt vll nur noch begrenzt aber ich kann bestätigen dass ich
> meine 4 Thermostate mit dem CUL problemlos bedienen kann und mit dem HMLAN
> die o.b. Probleme habe.
>
> VG
>>
>>
>>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Sonntag, 6. Mai 2012 17:36:57 UTC+2 schrieb fhem-hm-knecht:
>
> Der Hmlan darf nur bei Der Broadcastmeldung von Temperatur und
> Humidity
> das Disired-temp setzten,
>
> da der hmlan es auch bei der Meldung zum actuator versucht,
> gibt es die Nacks
>
> Johann hat es ja bereits beschrieben.
>
>
Hmm. Jetzt verstehe ich nichts mehr.
Johan hatte geschrieben:
>Sequence as follows:
>
>send a command....
>receive a NACK (0008)
>send +123456,02,00,
>on the next tem/hum report from device 123456 (not a valve set command !!)
the HMLAN adapter will come back with delayed NACK,
>(0081).
>Then recreate the old command (pull it from the stack), pack it up again
with new msgnr, timestamps etc and send it out again.
@Hary:
Ich dachte man muss dies implementieren und dafür eine Warteschlange der
abzusetzenden Befehle implementieren. Diese kann man dann erst senden,
wenn das nächste Mal der tem/hum report kommt.
Bisher gibt es diese Warteschlange m.E. nicht. Daher hatte ich Rudi
gefragt, ob man das in 00_HMLAN.pm hin bekommt ohne dazwischengeschalteten
Prozess.
Siehst Du das anders? Wenn ja:
Was ist Deiner Meinung nach jetzt die Lösung? Hast Du einen Fix?
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Dazu braucht man wohl eine Queue der noch nicht bestätigten Befehle.
Das gibt es schon, und wird extensiv genutzt (siehe CUL_HM_PushCmdStack & co)
bloss bei einem NACK wird alles weggeworfen. Das koennte man aendern, wenn man
weiss wie, macht bloss das jetzt schon komplexe CUL_HM.pm nicht wirklich
verstaendlicher.
> Solch eine Queue gibt es ja auch für CUL und FHT80b, jedoch in der Firmware
> der CUL (also quasi als separater Prozess) und nicht in FHEM.
Da ist es noch kompilzierter: es gibt eigentlich auch in fhem ein Puffer (attr
FHZ softbuffer), war aber beim CUL kontraproduktiv, ist also nur beim FHZ
aktiv. Das FHZ vergisst nach 'ne Weile FHT Befehle, da musste jemand die
merken...
> Schleierhaft ist für mich, warum es mit CUL ohne diese Logik funktioniert,
> aber HMLAN dies benötigt.............
Weil ich den HMLAN nicht wirklich kapiere, es wundert mich eh, dass soviel
damit funktioniert :) Wenn jemand sich einarbeiten will, kann ich gerne
assistieren.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ok. Dann nehme ich bzgl. Warteschlange, etc. alles zurück.
Dann fehlt "nur" noch die neue Logic, die beim NACK nichts wegschmeisst,
sondern die Befehle des entsprechenden HM-CC-TC neu sendet (natürlich nur
bei temp/hum) und löscht wenn das ACK kommt.
;-)
Was mich wundert: Gibt es diese Probleme nur mit HM-CC-TC oder auch mit
anderen Geräten? Wenn nur mit HM-CC-TC, bräuchte man einen eigenen Stack
für HM-CC-TC.
Aber vermutlich ist es einfacher, ist stelle mein HMLAN in eine Ecke und
nutze CUL...............
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Der Hmlan darf nur bei Der Broadcastmeldung von Temperatur und Humidity das
> Disired-temp setzten, da der hmlan es auch bei der Meldung zum actuator
> versucht, gibt es die Nacks
Ist nur komisch, dass beim CUL das trotzdem klappt. Die HM-CC-TC Daten nicht
nach dem Ventil-Meldung zu schicken waere einfach, erst auf NACK zu warten und
fuer die HMLAN/TC-CC Kombination exrawurst zu drehen, ist komplizierter, bzw.
macht CUL_HM.pm noch unuebersichtlicher.
Koennt Ihr bitte noch pruefen, ob die "einfache" Methode reicht?
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
@Rudi,
Es koente es auch klappen mit nur beim tem/hum (also die "70"/112 message)
das Kommando zu schicken. Fuer HMLAN wird es nicht schlechter sein, weil
die andere (beim "58"/88) sowieso nie klappen.
Willi, der HM-CC-TC schläft ein (jedenfalls auf das Kanal auf dem mit der
Adapter kommuniziert wird). Das gleiche problem koente es geben bei andere
teile die auch einschlafen.
--Johan
2012/5/6 Willi
> Ok. Dann nehme ich bzgl. Warteschlange, etc. alles zurück.
>
> Dann fehlt "nur" noch die neue Logic, die beim NACK nichts wegschmeisst,
> sondern die Befehle des entsprechenden HM-CC-TC neu sendet (natürlich nur
> bei temp/hum) und löscht wenn das ACK kommt.
> ;-)
>
> Was mich wundert: Gibt es diese Probleme nur mit HM-CC-TC oder auch mit
> anderen Geräten? Wenn nur mit HM-CC-TC, bräuchte man einen eigenen Stack
> für HM-CC-TC.
>
> Aber vermutlich ist es einfacher, ist stelle mein HMLAN in eine Ecke und
> nutze CUL...............
>
> --
> 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
ich bin in Perl miserabel bis sau schlecht aber loggen kann ich :)
mein fix ist bisher HM-CC-TC=IODev CUL2, Rest =IODev hmlan1
disered-temp wird nur vom HM-CC-TC angenommen nach einer Temp/Hum
Meldung (Fakt) sprich,
(HM-CC-TC= SRC:135B35)
das es besser lesbar ist kürze ich die Meldungen ein!
CUL CUL2 RCV L:0C N:62 CMD:8670 DST:000000 00B243
CUL CUL2 SND L:09 N:21 CMD:A112 SRC:F12222 DST:135B35 (HAVE_DATA)
CUL CUL2 RCV L:0A N:21 CMD:8002 SRC:135B35 DST:F12222 00
CUL CUL2 SND L:0C N:22 CMD:A011 SRC:F12222 DST:135B35 02021E
CUL CUL2 RCV L:0E N:22 CMD:8002 SRC:135B35 DST:F12222 01021E0059
CUL_HM eg_Halle_Hz1 desired-temp: 15.0
das war der Idealfall :)
der unidealfall mit cul ist folgender und geht trotzdem
CUL_HM eg_Halle_Hz1 desired-temp 12.0
CUL CUL2 RCV L:0B N:61 CMD:A258 SRC:135B35 DST:179CDE 0000
CUL CUL2 SND L:09 N:1F CMD:A112 SRC:F12222 DST:135B35 (HAVE_DATA))
CUL CUL2 RCV L:0E N:61 CMD:8202 SRC:179CDE DST:135B35 0101000037
CUL_HM EG_KU actuator: 0 %
Regler kommt und dazwischen
--> Have Data weg :(
CUL CUL2 RCV L:0C N:62 CMD:8670 SRC:135B35 DST:000000 00B243
(TYPE=112,WAKEMEUP,BCAST,RPTEN)
CUL CUL2 SND L:0C N:20 CMD:A011 SRC:F12222 DST:135B35 020218 (SET
CHANNEL:02 VALUE:18) (TYPE=17,BIDI,RPTEN)
CUL CUL2 RCV L:0E N:20 CMD:8002 SRC:135B35 DST:F12222 0102180058
(ACK_STATUS CHANNEL:02 STATUS:18 RSSI:58) (TYPE=2,RPTEN)
CUL_HM eg_Halle_Hz1 desired-temp-ack: 12.0
CUL_HM eg_Halle_Hz1 desired-temp: 12.0
HM-CC-TC ist nicht auf das (Have data) pingelich und nimmt das das
neue disired temp trotzdem an :)
jetzt der HM_lan
CUL_HM eg_Halle_Hz1 desired-temp 11.0
jetzt die Meldung vom regler
CUL CUL2 RCV L:0B N:76 CMD:A258 SRC:135B35 DST:179CDE 0000
HMLAN hmlan1 SND L:09 N:01 CMD:A112 SRC:F12222 DST:135B35 (HAVE_DATA)
CUL CUL2 RCV L:0E N:76 CMD:8202 SRC:179CDE DST:135B35 0101000037
CUL_HM EG_KU actuator: 0 %
CUL_HM EG_KU motor: ok
CUL_HM EG_KU battery: ok
und noch drei Wiederholungen
CUL CUL2 RCV L:09 N:01 CMD:A112 SRC:F12222 DST:135B35 (HAVE_DATA)
(TYPE=18,WAKEUP,BIDI,RPTEN)
CUL CUL2 RCV L:09 N:01 CMD:A112 SRC:F12222 DST:135B35 (HAVE_DATA)
(TYPE=18,WAKEUP,BIDI,RPTEN)
CUL CUL2 RCV L:09 N:01 CMD:A112 SRC:F12222 DST:135B35 (HAVE_DATA)
(TYPE=18,WAKEUP,BIDI,RPTEN)
CUL_HM eg_Halle_Hz1 MISSING ACK
und jetzt Beleidigt
Cul und Hmlan machen es beide nicht richtig,
der Hmlan ist allerdings gleich beleidigt, der Cul nicht und wartet
auf die nächste Meldung ohne Have data, weil schon gesendet, und der
Hm-cc-tc ist da nicht so pingelich :)
vielleicht hilfts es dem Rudi :)))))))))))))
Hary
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo,
ich würde mich gerne in das Thema einarbeiten, da ich momentan Zeit
habe.
Mir fehlt aber zum einen der ÜBerblick über fhem (Wie funktioniert das
System überhaupt ??).
Zweitens wären auch Infos wichtig und notwendig, die den HMLAN und das
Protokoll betreffen.
Wenn ich da entsprechende Infos bekommen könnte, dann könnte ich mir
vorstellen, daß ich mich um das Thema mal kümmern könnte.
Viele Grüße
Michael
On 6 Mai, 19:13, Rudolf Koenig wrote:
> > Dazu braucht man wohl eine Queue der noch nicht best tigten Befehle.
>
> Das gibt es schon, und wird extensiv genutzt (siehe CUL_HM_PushCmdStack & co)
> bloss bei einem NACK wird alles weggeworfen. Das koennte man aendern, wenn man
> weiss wie, macht bloss das jetzt schon komplexe CUL_HM.pm nicht wirklich
> verstaendlicher.
>
> > Solch eine Queue gibt es ja auch f r CUL und FHT80b, jedoch in der Firmware
> > der CUL (also quasi als separater Prozess) und nicht in FHEM.
>
> Da ist es noch kompilzierter: es gibt eigentlich auch in fhem ein Puffer (attr
> FHZ softbuffer), war aber beim CUL kontraproduktiv, ist also nur beim FHZ
> aktiv. Das FHZ vergisst nach 'ne Weile FHT Befehle, da musste jemand die
> merken...
>
> > Schleierhaft ist f r mich, warum es mit CUL ohne diese Logik funktioniert,
> > aber HMLAN dies ben tigt.............
>
> Weil ich den HMLAN nicht wirklich kapiere, es wundert mich eh, dass soviel
> damit funktioniert :) Wenn jemand sich einarbeiten will, kann ich gerne
> assistieren.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Zweitens wären auch Infos wichtig und notwendig, die den HMLAN und das
> Protokoll betreffen.
Wenn man das HMLAN nicht verschluesselt betreibt, dann gibt es die (meisten!?)
empfangenen Daten in hex zurueck mit weiteren mir mehr oder weniger unbekannten
Daten. Senden funktioniert auch so aehnlich, deswegen habe ich das HMLAN mit
relativ wenig Aufwand CUL-Kompatibel gemacht.
Man kann ueber contrib/tcptee.pl das Windows HMLAN Konfig-Programm
protokollieren, was die Befehle konkret bewirken, muss man aber selbst
zusammenreimen. Das was ich verstanden habe, habe ich in 99_HMLAN.pm
implementiert. Weitere Dokumentation ist mir nicht bekannt.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Am Sonntag, 6. Mai 2012 15:33:30 UTC+2 schrieb Merhan:
>
> ich habe nun endlich mein CUL am laufen und kann dies auch bestätigen.
>
> Mit dem CUL gibt es keine Probleme. Alle Befehle werden deterministisch
> angenommen.
>
Wenn ich Johan richtig verstehe, müssten wir um HMLAN mit HM-CC-TC richtig
zu unterstützen die Befehle zwischenspeichern und in der beschriebenen
Weise nach NACK neu senden. Dazu braucht man wohl eine Queue der noch nicht
bestätigten Befehle.
Solch eine Queue gibt es ja auch für CUL und FHT80b, jedoch in der Firmware
der CUL (also quasi als separater Prozess) und nicht in FHEM.
@Rudi: An Dich als Author von 00_HMLAN.pm und als FHEM-Versteher: Reicht
Deiner Meinung nach eine einfache Queue der nicht bestätigten Befehle in
00_HMLAN.pm oder braucht man eher einen separaten Prozess der zwischen
HMLAN und FHEM läuft und dies realisiert?
Schleierhaft ist für mich, warum es mit CUL ohne diese Logik funktioniert,
aber HMLAN dies benötigt.............
-- Willi
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ack's werden beim HMLAN ueber diese + und - zeilen gesteuert. Nach zb einem
-123456 (geraete Adresse) gibt das HMLAN keinen eigenen Acks mehr. Genau
wie das funktioniert mit die beide kommands(+123456,00,00, +123456,02,00,)
hab Ich dass auch noch nicht, aber ich bekomme nur selten retransmits (nur
beim timesync).
+123456 scheint das gleiche zu machen als +123456,00,00.
--Johan
2012/5/6 Willi
> Am Sonntag, 6. Mai 2012 15:33:30 UTC+2 schrieb Merhan:
>
>> ich habe nun endlich mein CUL am laufen und kann dies auch bestätigen.
>>
>> Mit dem CUL gibt es keine Probleme. Alle Befehle werden deterministisch
>> angenommen.
>>
>
> Wenn ich Johan richtig verstehe, müssten wir um HMLAN mit HM-CC-TC
> richtig zu unterstützen die Befehle zwischenspeichern und in der
> beschriebenen Weise nach NACK neu senden. Dazu braucht man wohl eine Queue
> der noch nicht bestätigten Befehle.
> Solch eine Queue gibt es ja auch für CUL und FHT80b, jedoch in der
> Firmware der CUL (also quasi als separater Prozess) und nicht in FHEM.
>
> @Rudi: An Dich als Author von 00_HMLAN.pm und als FHEM-Versteher: Reicht
> Deiner Meinung nach eine einfache Queue der nicht bestätigten Befehle in
> 00_HMLAN.pm oder braucht man eher einen separaten Prozess der zwischen
> HMLAN und FHEM läuft und dies realisiert?
>
> Schleierhaft ist für mich, warum es mit CUL ohne diese Logik funktioniert,
> aber HMLAN dies benötigt.............
>
> -- Willi
>
>
> --
> 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
Der Hmlan darf nur bei Der Broadcastmeldung von Temperatur und
Humidity
das Disired-temp setzten,
da der hmlan es auch bei der Meldung zum actuator versucht,
gibt es die Nacks
Johann hat es ja bereits beschrieben.
Hary
On 6 Mai, 15:53, Willi wrote:
> Am Sonntag, 6. Mai 2012 15:33:30 UTC+2 schrieb Merhan:
>
>
>
> > ich habe nun endlich mein CUL am laufen und kann dies auch bestätigen.
>
> > Mit dem CUL gibt es keine Probleme. Alle Befehle werden deterministisch
> > angenommen.
>
> Wenn ich Johan richtig verstehe, müssten wir um HMLAN mit HM-CC-TC richtig
> zu unterstützen die Befehle zwischenspeichern und in der beschriebenen
> Weise nach NACK neu senden. Dazu braucht man wohl eine Queue der noch nicht
> bestätigten Befehle.
> Solch eine Queue gibt es ja auch für CUL und FHT80b, jedoch in der Firmware
> der CUL (also quasi als separater Prozess) und nicht in FHEM.
>
> @Rudi: An Dich als Author von 00_HMLAN.pm und als FHEM-Versteher: Reicht
> Deiner Meinung nach eine einfache Queue der nicht bestätigten Befehle in
> 00_HMLAN.pm oder braucht man eher einen separaten Prozess der zwischen
> HMLAN und FHEM läuft und dies realisiert?
>
> Schleierhaft ist für mich, warum es mit CUL ohne diese Logik funktioniert,
> aber HMLAN dies benötigt.............
>
> -- Willi
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com