HM-CC-TC MISSING-ACK bei Einstellen desired-temp

[locodriver]

                                                         

Sehe ich auch so... für heute erst mal "Gute Nacht".

Am Dienstag, 30. Oktober 2012 00:26:34 UTC+1 schrieb kohrti:
>
> Hallo nochmal,
>  
>
>> Meine Theorie ist, dass der CUL/CUNO die Telegramme nicht so sendet wie
>> der HMLAN und deshalb der CC die Befehlsumsetzung verweigert.
>>
> --> Also das der Sender Typ irgendwie übermittelt wird? Das können
> hoffentlich auch die Experten hier sagen. Ansonsten glaube ich auch dass
> der CUNO gegenüber dem HMLAN sich anders verhält. das ist ja das problem.
> Entweder das Timing oder das Protokoll oder die Message Inhalte stimmen
> nicht... so ganz allgemein ausgedrückt.
>
> Gruß,
> Kohrti
>

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

[locodriver]

                                                         

Noch 'ne Ergänzung: Logeintrag vom Badfenster:

2012-10-29_13:33:24 Bad_Fenster geschlossen
2012-10-29_13:33:24 Bad_Fenster contact: geschlossen (to Bad_Regler)

Logeintrag vom CC:
2012-10-29_13:33:27 Bad_Regler desired-temp: 15.5
2012-10-29_13:33:27 Bad_Regler desired-temp: 15.5

Also nur 3 Sekunden später.



Am Dienstag, 30. Oktober 2012 00:39:32 UTC+1 schrieb Uwe:
>
> Sehe ich auch so... für heute erst mal "Gute Nacht".
>
> Am Dienstag, 30. Oktober 2012 00:26:34 UTC+1 schrieb kohrti:
>>
>> Hallo nochmal,
>>  
>>
>>> Meine Theorie ist, dass der CUL/CUNO die Telegramme nicht so sendet wie
>>> der HMLAN und deshalb der CC die Befehlsumsetzung verweigert.
>>>
>> --> Also das der Sender Typ irgendwie übermittelt wird? Das können
>> hoffentlich auch die Experten hier sagen. Ansonsten glaube ich auch dass
>> der CUNO gegenüber dem HMLAN sich anders verhält. das ist ja das problem.
>> Entweder das Timing oder das Protokoll oder die Message Inhalte stimmen
>> nicht... so ganz allgemein ausgedrückt.
>>
>> Gruß,
>> Kohrti
>>
>

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

[Guest]

Originally posted by: <email address deleted>

Moin Uwe,

wäre es möglich dieses Szenario (CC/Türkontakt) mit folgenden Einstellungen
nochmal zu loggen:

attr global mseclog 1
attr global verbose 5

Dann sollten wir die Messages sehen können und ich kann vergleichen was
denn bei mir anders ist. Evtl. gibt uns das ja die nötige Info um dem CC
Messages schicken zu können.

Danke!

Gruß,
Kohrti

Am Dienstag, 30. Oktober 2012 00:55:04 UTC+1 schrieb Uwe:
>
> Noch 'ne Ergänzung: Logeintrag vom Badfenster:
>
> 2012-10-29_13:33:24 Bad_Fenster geschlossen
> 2012-10-29_13:33:24 Bad_Fenster contact: geschlossen (to Bad_Regler)
>
> Logeintrag vom CC:
> 2012-10-29_13:33:27 Bad_Regler desired-temp: 15.5
> 2012-10-29_13:33:27 Bad_Regler desired-temp: 15.5
>
> Also nur 3 Sekunden später.
>
>
>
> Am Dienstag, 30. Oktober 2012 00:39:32 UTC+1 schrieb Uwe:
>>
>> Sehe ich auch so... für heute erst mal "Gute Nacht".
>>
>> Am Dienstag, 30. Oktober 2012 00:26:34 UTC+1 schrieb kohrti:
>>>
>>> Hallo nochmal,
>>>  
>>>
>>>> Meine Theorie ist, dass der CUL/CUNO die Telegramme nicht so sendet wie
>>>> der HMLAN und deshalb der CC die Befehlsumsetzung verweigert.
>>>>
>>> --> Also das der Sender Typ irgendwie übermittelt wird? Das können
>>> hoffentlich auch die Experten hier sagen. Ansonsten glaube ich auch dass
>>> der CUNO gegenüber dem HMLAN sich anders verhält. das ist ja das problem.
>>> Entweder das Timing oder das Protokoll oder die Message Inhalte stimmen
>>> nicht... so ganz allgemein ausgedrückt.
>>>
>>> Gruß,
>>> Kohrti
>>>
>>

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

[Guest]

Originally posted by: <email address deleted>

Folgendes ist noch wichtig:

attr global mseclog 1
attr global verbose 5

im CUL/CUNO attr:
hmProtocolEvents 3

Dann müßtest du alles im Log sehen können.

NEUIGKEITEN (für mich zumindest):

Wenn ich "desired-temp" setze und manuell einmal kurz auf "OK" auf dem
Thermostaten drücke funktioniert es. Evtl. hilft das ja dem Problem auf die
Spur zu kommen.

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

[Guest]

Originally posted by: <email address deleted>

Komisch... jetzt geht das gleiche nicht mehr... Ich probiere weiter...


> NEUIGKEITEN (für mich zumindest):
>
> Wenn ich "desired-temp" setze und manuell einmal kurz auf "OK" auf dem
> Thermostaten drücke funktioniert es. Evtl. hilft das ja dem Problem auf die
> Spur zu kommen.
>
>

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

[locodriver]

                                                         

Hallo Korthi, kann es erst am WE testen, da keiner da ist, der mir mal das
Fenster öffnet. Das funzt per VPN noch nicht.

Uwe


Am Dienstag, 30. Oktober 2012 08:59:06 UTC+1 schrieb kohrti:
>
> Moin Uwe,
>
> wäre es möglich dieses Szenario (CC/Türkontakt) mit folgenden
> Einstellungen nochmal zu loggen:
>
> attr global mseclog 1
> attr global verbose 5
>
> Dann sollten wir die Messages sehen können und ich kann vergleichen was
> denn bei mir anders ist. Evtl. gibt uns das ja die nötige Info um dem CC
> Messages schicken zu können.
>
> Danke!
>
> Gruß,
> Kohrti
>
> Am Dienstag, 30. Oktober 2012 00:55:04 UTC+1 schrieb Uwe:
>>
>> Noch 'ne Ergänzung: Logeintrag vom Badfenster:
>>
>> 2012-10-29_13:33:24 Bad_Fenster geschlossen
>> 2012-10-29_13:33:24 Bad_Fenster contact: geschlossen (to Bad_Regler)
>>
>> Logeintrag vom CC:
>> 2012-10-29_13:33:27 Bad_Regler desired-temp: 15.5
>> 2012-10-29_13:33:27 Bad_Regler desired-temp: 15.5
>>
>> Also nur 3 Sekunden später.
>>
>>
>>
>> Am Dienstag, 30. Oktober 2012 00:39:32 UTC+1 schrieb Uwe:
>>>
>>> Sehe ich auch so... für heute erst mal "Gute Nacht".
>>>
>>> Am Dienstag, 30. Oktober 2012 00:26:34 UTC+1 schrieb kohrti:
>>>>
>>>> Hallo nochmal,
>>>>  
>>>>
>>>>> Meine Theorie ist, dass der CUL/CUNO die Telegramme nicht so sendet
>>>>> wie der HMLAN und deshalb der CC die Befehlsumsetzung verweigert.
>>>>>
>>>> --> Also das der Sender Typ irgendwie übermittelt wird? Das können
>>>> hoffentlich auch die Experten hier sagen. Ansonsten glaube ich auch dass
>>>> der CUNO gegenüber dem HMLAN sich anders verhält. das ist ja das problem.
>>>> Entweder das Timing oder das Protokoll oder die Message Inhalte stimmen
>>>> nicht... so ganz allgemein ausgedrückt.
>>>>
>>>> Gruß,
>>>> Kohrti
>>>>
>>>

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

[Guest]

Originally posted by: <email address deleted>

Das wär doch mal eine Erweiterung für VPN...


Am Dienstag, 30. Oktober 2012 12:22:54 UTC+1 schrieb Uwe:
>
> Hallo Korthi, kann es erst am WE testen, da keiner da ist, der mir mal das
> Fenster öffnet. Das funzt per VPN noch nicht.
>
> Uwe
>
>
> Am Dienstag, 30. Oktober 2012 08:59:06 UTC+1 schrieb kohrti:
>>
>> Moin Uwe,
>>
>> wäre es möglich dieses Szenario (CC/Türkontakt) mit folgenden
>> Einstellungen nochmal zu loggen:
>>
>> attr global mseclog 1
>> attr global verbose 5
>>
>> Dann sollten wir die Messages sehen können und ich kann vergleichen was
>> denn bei mir anders ist. Evtl. gibt uns das ja die nötige Info um dem CC
>> Messages schicken zu können.
>>
>> Danke!
>>
>> Gruß,
>> Kohrti
>>
>> Am Dienstag, 30. Oktober 2012 00:55:04 UTC+1 schrieb Uwe:
>>>
>>> Noch 'ne Ergänzung: Logeintrag vom Badfenster:
>>>
>>> 2012-10-29_13:33:24 Bad_Fenster geschlossen
>>> 2012-10-29_13:33:24 Bad_Fenster contact: geschlossen (to Bad_Regler)
>>>
>>> Logeintrag vom CC:
>>> 2012-10-29_13:33:27 Bad_Regler desired-temp: 15.5
>>> 2012-10-29_13:33:27 Bad_Regler desired-temp: 15.5
>>>
>>> Also nur 3 Sekunden später.
>>>
>>>
>>>
>>> Am Dienstag, 30. Oktober 2012 00:39:32 UTC+1 schrieb Uwe:
>>>>
>>>> Sehe ich auch so... für heute erst mal "Gute Nacht".
>>>>
>>>> Am Dienstag, 30. Oktober 2012 00:26:34 UTC+1 schrieb kohrti:
>>>>>
>>>>> Hallo nochmal,
>>>>>  
>>>>>
>>>>>> Meine Theorie ist, dass der CUL/CUNO die Telegramme nicht so sendet
>>>>>> wie der HMLAN und deshalb der CC die Befehlsumsetzung verweigert.
>>>>>>
>>>>> --> Also das der Sender Typ irgendwie übermittelt wird? Das können
>>>>> hoffentlich auch die Experten hier sagen. Ansonsten glaube ich auch dass
>>>>> der CUNO gegenüber dem HMLAN sich anders verhält. das ist ja das problem.
>>>>> Entweder das Timing oder das Protokoll oder die Message Inhalte stimmen
>>>>> nicht... so ganz allgemein ausgedrückt.
>>>>>
>>>>> Gruß,
>>>>> Kohrti
>>>>>
>>>>

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

[LuckyDay]

                                         

@ Kohrti
ich antworte dir einmal

ich hab mir dein Log angeschaut
2012-10-29 23:33:24.450 CUL CUNO RCV L:0C N:4D F:86 CMD:70
SRC:az_Thermostat DST:broadcast 00D637 (WeatherEvent TEMP:21.4 HUM:55)
(,WAKEMEUP,BCAST,RPTEN)
2012-10-29 23:33:24.673 CUL CUNO SND L:09 N:64 F:A1 CMD:12 SRC:F11234
DST:az_Thermostat (HAVE_DATA) (,WAKEUP,BIDI,RPTEN)

Vom eintreffen bis zur Sendung sind es 223ms

da schläft das TC schon wieder.
alles über 205 ms ist ein Problem. wobei die Wandelzeiten bei dir,
cuno->fhem fhem->cuno noch garnicht dabei sind.
Zeitfresser sind:
eingeschaltetes hmProtocolEvents
Filelog

ausprobieren könnest du einmal, mit einer minimal config an den Start
gehen, like

wo nur dein Cuno und ein TC definiert ist ohne Filelog, und sonnst
nix, außer das Fhem selber benötigt.
ob es dann geht.

Hary



On 29 Okt., 23:47, kohrti wrote:
> Hallo,
>
> grundsätzlich will ich die Solltemperatur "desired-temp" von fhem
> einstellen können. Manchmal geht es ja sogar (1 v. 10 Versuchen). Momentan
> geht es nur über das EInstellrad zuverlässig.
>
> Mein PIDPWM Regler benötigt die Solltemperatur desired-temp, um dann die
> aktoren für die Fußbodenheizung zu steuern. Die Aktoren werden von dem
> Modul gesteuert, nicht von dem Thermostat. Letzteres benutze ich nur als
> Sensor mit etwas Intelligenz weil man dort ja auch Programme hinterlegen
> kann für die Solltemperatur desried-temp.
> Damit sollen Bewohner die Möglichkeit haben die Heizung im Raum zu
> beeinflussen, aber ich möchte das auch von Remote tun, daher will ich
> desried-temp setzen können.
>
> Ich hoffe es ist jetzt etwas klarer, dass NICHT der Thermostat den sollwert
> schickt sondern MEIN Regler.
>
> Gruß,
> Kohrti
>
> Hier noch ein aktuelles Log:
> *2012-10-29 23:33:10.108 CUL_HM az_Thermostat desired-temp 15.0*
> 2012-10-29 23:33:16.757 CUL CUNO RCV L:0C N:BB F:86 CMD:70
> SRC:ku_Thermostat DST:broadcast 00D73A (WeatherEvent TEMP:21.5 HUM:58)
> (,WAKEMEUP,BCAST,RPTEN)
> 2012-10-29 23:33:16.881 CUL_HM ku_Thermostat T: 21.5 H: 58
> 2012-10-29 23:33:16.881 CUL_HM ku_Thermostat measured-temp: 21.5
> 2012-10-29 23:33:16.881 CUL_HM ku_Thermostat humidity: 58
> 2012-10-29 23:33:24.450 CUL CUNO RCV L:0C N:4D F:86 CMD:70
> SRC:az_Thermostat DST:broadcast 00D637 (WeatherEvent TEMP:21.4 HUM:55)
> (,WAKEMEUP,BCAST,RPTEN)
> 2012-10-29 23:33:24.673 CUL CUNO SND L:09 N:64 F:A1 CMD:12 SRC:F11234
> DST:az_Thermostat (HAVE_DATA) (,WAKEUP,BIDI,RPTEN)
> 2012-10-29 23:33:24.797 CUL_HM az_Thermostat T: 21.4 H: 55
> 2012-10-29 23:33:24.797 CUL_HM az_Thermostat measured-temp: 21.4
> 2012-10-29 23:33:24.797 CUL_HM az_Thermostat humidity: 55
> *2012-10-29 23:33:28.824 CUL_HM az_Thermostat MISSING ACK*
>
> --> Sind denn 124ms genug für den Thermostat nach WAKEUP? Ich mache nochmal
> ein positives Log um das Timing dafür zu sehen....
>
> Am Montag, 29. Oktober 2012 23:34:02 UTC+1 schrieb UliM:
>
>
>
>
>
>
>
>
>
> > Hi,
> > was willst Du denn eigentlich erreichen?
> > Wenn Du die desired-temp gesetzt hast, dann....?
>
> > Der HM-TC-CC schickt NICHT den Sollwert der Ventilstellung, solange noch
> > kein Ventilstelltrieb HM-CC-VD angelernt ist. Genau daran zahne ich auch,
> > siehehttps://groups.google.com/d/topic/fhem-users/ux-Vz-pMi7A/discussion
> > Da ist wohl noch etwas Entwicklungsarbeit zu tun.
> > Erster Schritt wäre, dass jemand, der ein HM-CC-VD besitzt, den
> > Funkverkehr beim Anlernen des VD an den TC mitschneidet und hier postet.
> > Das kann dann eventuell als Basis für das pairing eines virtuellen VD
> > dienen. Ob's dann wirklich funktioniert, muss man sehen - wahrscheinlich
> > schickt ja der VD auf jede Nachricht des CC einen ACK, auch den müsste man
> > dann emulieren.
>
> > Solange hier niemand diesen Funkverkehr kundtut, geht's nicht weiter.
>
> > Es bleibt also spannend
>
> > Gruß, Uli

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

[Guest]

Originally posted by: <email address deleted>

Hallo Hary,

herzlichen Dank für die Infos, die Gold Wert sind.

Ich habe folgende Konfiguration getestet und dabei verbose=0, FileLogs für
den CC aus und hmprotocolevents=0:

attr global autoload_undefined_devices 1
attr global backupdir /var/media/ftp/FHEMBackups
attr global logfile ./log/fhem-%Y-%m.log
attr global modpath .
attr global motd SecurityCheck:\
\
WEB,WEBtablet has no basicAuth attribute.\
telnetPort has no password/globalpassword attribute.\
Running with root privileges.\
Restart fhem for a new check if the problem is fixed,\
or set the global attribute motd to none to supress this message.\

attr global statefile ./log/fhem.save
attr global userattr icon webCmd
attr global verbose 0

#
# pgm2 / autocreate configfile. Take a look at the other examples for more.
#

define WEB FHEMWEB 8083 global

define WEBphone FHEMWEB 8084 global
attr WEBphone basicAuth Y2tvaHJ0OjM5NTYqS2Vs
attr WEBphone smallscreen 1

define WEBtablet FHEMWEB 8085 global
attr WEBtablet touchpad 1

define autocreate autocreate
attr autocreate autosave 1
attr autocreate device_room %TYPE
attr autocreate filelog ./log/%NAME-%Y.log
attr autocreate weblink 1
attr autocreate weblink_room Wetter

define CUNO CUL 192.168.2.34:2323 1234
attr CUNO rfmode HomeMatic
attr CUNO room CUL_HM

define telnetPort telnet 7072 global

define az_Thermostat CUL_HM 1D6A43
attr az_Thermostat actCycle 000:10
attr az_Thermostat actStatus alive
attr az_Thermostat devInfo 00FFFF
attr az_Thermostat firmware 2.1
attr az_Thermostat hmClass receiver
attr az_Thermostat model HM-CC-TC
attr az_Thermostat protCmdDel 11
attr az_Thermostat protLastRcv 2012-10-30 17:50:39
attr az_Thermostat protResndCnt 8
attr az_Thermostat protResndFailCnt 4
attr az_Thermostat protResndFailLast 2012-10-29 21:41:29
attr az_Thermostat protResndLast 2012-10-29 21:41:28
attr az_Thermostat protSndCnt 8
attr az_Thermostat protSndLast 2012-10-29 19:05:12
attr az_Thermostat room Office
attr az_Thermostat serialNr JEQ0195296
attr az_Thermostat subType thermostat

Ich habe auch mal versucht mit nic -15 den fhem Prozess zu beschleunigen -
ohne Erfolg.

Also die Zeiten mal zusammengefaßt lauten wie folgt:
CC->CUNO->fhem->Verarbeitung->fhem->CUNO->CC

Ich weiß die Zeiten aus den Logs für "fhem->Verarbeitung->fhem", die sind
mittlerweile mit obiger Konfig. (inkl.hmProtocolEvents=1) bei 127ms. Noch
jeweils für die Kommunikation 40ms für CC->CUNO->fhem und zurück komme ich
auf 127ms+40ms=167ms < 205ms. D.h. nach meiner (zugegeben sehr groben)
Rechnung bliebe ich unter 205ms. Slebst mit eingeschalteten
hmProtocolEvents (was in den 127ms dabei ist).
So, da muss wohl meine Annahme, dass die Kommunikation hin und zurück 40ms
benötigt falsch sein. Hm....

Einmal hat es gerade eben dann doch nochmal funktioniert. Aber leider nur
ein mal.

Gruß,
kohrti

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

[Guest]

Originally posted by: <email address deleted>

UUUUUps!

Ein Kleiner Fehler ist mir unterlaufen beim Höhersetzen der Prozess Prio
auf der FritzBox. Die Sytax des Befehls ist hier etwas anders und der
Befehl lautet:

nice *-n -10* /var/InternerSpeicher/fhem/startfhem

Damit habe ich in meinem Produktivsystem (mit FileLogs etc.) jetzt
desired-temp schon 3 mal nacheinander ändern können!

Ich teste weiter und melde mich wieder!

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

[Guest]

Originally posted by: <email address deleted>

Also nochmal ein Update.

Das 3 mal erfolgreiche desired-temp setzen war wohl ein Zufall. Ich werde
mich mal bemühen meine zu schnelle Freude und damit verbunden Postings zu
unterdrücken.

Hier nun mein aktueller Log:

2012-10-30 20:49:48.185 CUL_HM az_Thermostat desired-temp 13.5
2012-10-30 20:50:15.379 CUL CUNO RCV L:0C N:45 F:86 CMD:70
SRC:az_Thermostat DST:broadcast 00E635 (WeatherEvent TEMP:23 HUM:53)
(,WAKEMEUP,BCAST,RPTEN)
2012-10-30 20:50:15.494 CUL CUNO SND L:09 N:03 F:A1 CMD:12 SRC:F11234
DST:az_Thermostat (HAVE_DATA) (,WAKEUP,BIDI,RPTEN)
2012-10-30 20:50:15.502 CUL_HM az_Thermostat T: 23 H: 53
2012-10-30 20:50:15.502 CUL_HM az_Thermostat measured-temp: 23
2012-10-30 20:50:15.502 CUL_HM az_Thermostat humidity: 53
2012-10-30 20:50:19.534 CUL_HM az_Thermostat MISSING ACK

Also (mit hmprotocolevents=1) die Zeitdifferenz ist 115ms < 205ms und
sollte garnicht so schlecht aussehen. Die Realität zeigt aber, dass es
nicht funzt. Langsam gehen mir die Ideen aus.

Gruß,
kohrti

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

[Guest]

Originally posted by: <email address deleted>

Zusammenfassung:

1. Es gibt die Idee das Protokoll mitzulauschen zwischen CC und
Fenterkontakt, der anscheinend eine sofortige Wirkung am CC hat. D.h. man
muß nicht warten bis der CC aufwacht. -->Idee von Uwe
2. Die eingebrachte Zeitdauer von 205ms (-->von fhem-hm-knecht) scheint
nicht haltbar zu sein, obwohl ich daran glaube. Aus obigem Post sieht man
aber, dass die Zeitdifferenz von 115ms + Kommunikation CC<->fhem
anscheinend länger ist. Wie man End2End messen soll weiß ich nicht. Selbst
mit Wireshark würde man nicht die Strecke CUNO-CC mitmessen. Reduktion des
Loggings und LogFiles brachte keine Besserung. --> von kohrti
3. Anscheinend hatte das setzen von desired-temp in einer älteren fhem
Version besser funktioniert. -->von Merhan
4. Das beschleunigen des fhem Prozesses brachte keine Abhilfe. --> von
kohrti

Ich halte das setzen der desired-temp (und andere Parameter) für wichtig,
und dies scheint ja ein generisches Problem zu sein (zumindest für CUNO,
CUL und HMLAN weiß ich nicht) da es eben mehrfach benötigt wird (eben für
andere Parameter auch; evtl. auch für andere Devices?).

-->Daher verfolge ich Weg 1 und evtl. auch Weg 3, obwohl ich denke, dass
wenn ich 3. mache es wohl wenig Sinn macht, aber trotzdem. Noch andere
Ideen?

Gruß,
der verzweifelte kohrti

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

[Billy]

                                                         

Hallo,

1. Es gibt die Idee das Protokoll mitzulauschen zwischen CC und
> Fenterkontakt, der anscheinend eine sofortige Wirkung am CC hat. D.h. man
> muß nicht warten bis der CC aufwacht. -->Idee von Uwe
>

mit CC meinst HM-CC-TC ?

Ich halte das setzen der desired-temp (und andere Parameter) für wichtig!

 
Ich auch und bei mir läuft es mit dem HMLAN jetzt 100%ig inclusive der Mode
Umschaltung und der Offset Rückmeldung!
Mit den alten Versionen lief es bei mir deutlich schlechter bzw. garnicht!
Zu Cuno + Cul kann ich nichts sagen.

Gruss Billy

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

[Guest]

Originally posted by: <email address deleted>

>
> 1. Es gibt die Idee das Protokoll mitzulauschen zwischen CC und
> Fenterkontakt, der anscheinend eine sofortige Wirkung am CC hat. D.h. man
> muß nicht warten bis der CC aufwacht. -->Idee von Uwe
>

mit CC meinst HM-CC-TC ?

--> Ja

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

[Guest]

Originally posted by: <email address deleted>

Auch an dieser Stelle noch mal der Hinweis, das der HM-CC-TC sein
Empfangsverhalten zu Lasten der Batterielebensdauer ändert, sobald er an
einen Fensterkontakt angelernt wurde.

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