Befehle kommen bei HM-CC-TC nur sporadisch an

[Guest]

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

[Guest]

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

[Guest]

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

[Guest]

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

[rudolfkoenig]

                                                   

> 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

[Guest]

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

[Guest]

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

[rudolfkoenig]

                                                   

> 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

[Guest]

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

[Guest]

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

[Oskar]

                                                     

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

[eppi]

                                               

Hallo

> - Gibt es das Problem des Setzens von desired-temp nur mit HM-CFG-LAN oder auch mit CUL?

[Guest]

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

[Guest]

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

[rudolfkoenig]

                                                   

> @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