MISSING ACK vom HM-CC-TC

Begonnen von Guest, 27 November 2011, 10:32:36

Vorheriges Thema - Nächstes Thema

Guest

Originally posted by: <email address deleted>

Hallo zusammen,
ich betreibe fhem auf einer FB7270 und benutze einen HM-CFG-LAN in
Verbindung mit einigen HM-CC-TC und HM-CC-VD. Fhem ist auf einem USB-
Stick installiert, der in der FritzBox steckt.
Mein Ziel ist es, die Anwesenheit meiner Familienmitglieder dadurch zu
ermitteln, dass ich überprüfe, ob deren Handy ins WLAN eingebucht
ist.  Wenn das für eine gewisse Zeit nicht der Fall ist, dann soll die
Heizung in dem entsprechenden Raum runtergeregelt werden. Wenn alle
Stellantriebe in allen Räumen kleiner 10% gestellt sind, wird über
einen Funkschalter die Heizungspumpe abgestellt.
Soweit so gut, das Überprüfen der Anwesenheit klappt prima, nur leider
wiedersetzt sich der HM-CC-TC hartnäckig jedem Konfigurationsversuch.
Als Beispiel mal ein Versuch, die day-temp auf 24°C zu setzen (nur als
Beispiel, das Runterregeln der Heizung funktioniert ja so nicht).


2011-11-27 09:58:51 CUL_HM OG_Daniel_TC day-temp 24.0
2011-11-27 09:59:23 HMLAN Zentrale RCV L:0C N:65 CMD:8670 SRC:1500A8
DST:000000 00CF34
2011-11-27 09:59:23 HMLAN Zentrale SND L:10 N:98 CMD:A001 SRC:AECE83
DST:1500A8 02050000000005 (CONFIG_START CHANNEL:02 PEER_ADDRESS:000000
PEER_CHANNEL:00 PARAM_LIST:05)
2011-11-27 09:59:24 CUL_HM OG_Daniel_TC MISSING ACK

Zu sehen ist hier, das nach einem Broadcast vom HM-CC-TC (Adresse
1500A8) mein HM-CFG-LAN (Adresse AECE83) die Konfiguration starten
möchte. Eine Sekunde später kommt dann ein MISSING ACK .

Das Pairing der beiden Devices scheint i.O. zu sein, weil ich z.B.
beim Ändern einer Temperaturliste am HM-CC-TC diese zum HM-CFG-LAN
übertragen bekomme. Wenn die Geräte nicht gepairt wären, dann sollte
dieses ja nicht funktionieren.

Wenn ich den HM-CC-TC in den Konfigurationsmodus versetzte (durch
langes Drücken der OK-Taste), dann wird der Befehl "set Daniel_TC day-
temp 24.0" ohne weiteres akzeptiert und auch am Gerät ausgeführt.

Die Frage ist jetzt, warum der Befehl nicht akzeptiert wird! Folgende
Gedanken dazu:
- Kann es damit zusammen hängen, dass die PEER_ADDRESS = 000000 ist?
Sollte diese nicht die Adresse des Senders sein? Wo wird diese
festgelegt?
- Ist der Channel 02 richtig? Der HM-CC-TC hat doch drei Kanäle, nur
einer davon ist konfigurierbar.
- im Autocreate wird hmClass und hmSubType immer als "unknown"
ermittelt. Muss dort etwas anderes stehen oder ist das unerheblich?
- ist das Timing des Befehls richtig? Warum kommt genau nach einer
Sekunde das MISSING ACK? Hört der HM-CC-TC nach einem Broadcast
überhaupt auf neue Kommandos?
- könnte das an der Konfiguration mit der Fritz-Box liegen? Lohnt sich
die Arbeit, Fhem auf meine Diskstation zu installieren?

Viele Fragen, ich weiß, aber vielleicht kann jemand die ein oder
andere Frage ja beantworten und mir so helfen, dieses lästige Problem
zu lösen.

Anbei noch meine fhem.cfg zur Info.


Schon mal vielen Dank für eure Hilfe

Gruß,
Stefan

attr global autoload_undefined_devices 1
attr global logfile ./log/fhem-%Y-%m.log
attr global modpath .
attr global port 7072 global
attr global statefile ./log/fhem.save
attr global userattr webCmd
attr global verbose 4

define WEB FHEMWEB 8083 global

define WEBphone FHEMWEB 8084 global
attr WEBphone smallscreen 1

define WEBtablet FHEMWEB 8085 global
attr WEBtablet touchpad 1

define Logfile FileLog ./log/fhem-%Y-%m.log fakelog

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 Plots

define Zentrale HMLAN 192.168.178.33:1000
attr Zentrale hmId AECE83
attr Zentrale hmProtocolEvents 1

define OG_Daniel_TC CUL_HM 1500A8
attr OG_Daniel_TC devInfo 00FFFF
attr OG_Daniel_TC firmware 2.0
attr OG_Daniel_TC hmClass sender
attr OG_Daniel_TC loglevel 5
attr OG_Daniel_TC model HM-CC-TC
attr OG_Daniel_TC room Daniel
attr OG_Daniel_TC serialNr HEQ0511217
attr OG_Daniel_TC subType Climate-Control

define FileLog_OG_Daniel_TC FileLog ./log/OG_Daniel_TC-%Y.log
OG_Daniel_TC
attr FileLog_OG_Daniel_TC logtype text
attr FileLog_OG_Daniel_TC room Daniel

define OG_Daniel_VD CUL_HM 1548D3
attr OG_Daniel_VD devInfo 010100
attr OG_Daniel_VD firmware 1.8
attr OG_Daniel_VD hmClass unknown
attr OG_Daniel_VD model HM-CC-VD
attr OG_Daniel_VD room Daniel
attr OG_Daniel_VD serialNr HEQ0514667
attr OG_Daniel_VD subType unknown

define FileLog_OG_Daniel_VD FileLog ./log/OG_Daniel_VD-%Y.log
OG_Daniel_VD
attr FileLog_OG_Daniel_VD logtype text
attr FileLog_OG_Daniel_VD room Daniel

define OG_Daniel_TS CUL_HM 1453EA
attr OG_Daniel_TS devInfo 810101
attr OG_Daniel_TS firmware 2.0
attr OG_Daniel_TS hmClass sender
attr OG_Daniel_TS model HM-SEC-SC
attr OG_Daniel_TS room Daniel
attr OG_Daniel_TS serialNr HEQ0364954
attr OG_Daniel_TS subType threeStateSensor

define FileLog_OG_Daniel_TS FileLog ./log/OG_Daniel_TS-%Y.log
OG_Daniel_TS
attr FileLog_OG_Daniel_TS logtype text
attr FileLog_OG_Daniel_TS room Daniel

define EG_Wohnzimmer_TC CUL_HM 129CA9
attr EG_Wohnzimmer_TC devInfo 00FFFF
attr EG_Wohnzimmer_TC firmware 1.9
attr EG_Wohnzimmer_TC hmClass unknown
attr EG_Wohnzimmer_TC model HM-CC-TC
attr EG_Wohnzimmer_TC room Wohnzimmer
attr EG_Wohnzimmer_TC serialNr GEQ0161864
attr EG_Wohnzimmer_TC subType unknown

define FileLog_EG_Wohnzimmer_TC FileLog ./log/EG_Wohnzimmer_TC-%Y.log
EG_Wohnzimmer_TC
attr FileLog_EG_Wohnzimmer_TC logtype text
attr FileLog_EG_Wohnzimmer_TC room Wohnzimmer

define K_Heizung_P dummy
attr K_Heizung_P room Heizungskeller

define EG_Wohnzimmer_VD CUL_HM 12D882
attr EG_Wohnzimmer_VD devInfo 010100
attr EG_Wohnzimmer_VD firmware 1.8
attr EG_Wohnzimmer_VD hmClass unknown
attr EG_Wohnzimmer_VD model HM-CC-VD
attr EG_Wohnzimmer_VD room Wohnzimmer
attr EG_Wohnzimmer_VD serialNr HEQ0067832
attr EG_Wohnzimmer_VD subType unknown

define FileLog_EG_Wohnzimmer_VD FileLog ./log/EG_Wohnzimmer_VD-%Y.log
EG_Wohnzimmer_VD
attr FileLog_EG_Wohnzimmer_VD logtype text
attr FileLog_EG_Wohnzimmer_VD room Wohnzimmer

define EG_Kueche_VD CUL_HM 126633
attr EG_Kueche_VD devInfo 010100
attr EG_Kueche_VD firmware 1.8
attr EG_Kueche_VD hmClass unknown
attr EG_Kueche_VD model HM-CC-VD
attr EG_Kueche_VD room Wohnzimmer
attr EG_Kueche_VD serialNr GEQ0162965
attr EG_Kueche_VD subType unknown

define FileLog_EG_Kueche_VD FileLog ./log/EG_Kueche_VD-%Y.log
EG_Kueche_VD
attr FileLog_EG_Kueche_VD logtype text
attr FileLog_EG_Kueche_VD room Wohnzimmer

define EG_Wohnzimmer_TS CUL_HM 124292
attr EG_Wohnzimmer_TS devInfo 810101
attr EG_Wohnzimmer_TS firmware 1.9
attr EG_Wohnzimmer_TS hmClass sender
attr EG_Wohnzimmer_TS model HM-SEC-SC
attr EG_Wohnzimmer_TS room Wohnzimmer
attr EG_Wohnzimmer_TS serialNr GEQ0164945
attr EG_Wohnzimmer_TS subType threeStateSensor

define FileLog_EG_Wohnzimmer_TS FileLog ./log/EG_Wohnzimmer_TS-%Y.log
EG_Wohnzimmer_TS
attr FileLog_EG_Wohnzimmer_TS logtype text
attr FileLog_EG_Wohnzimmer_TS room Wohnzimmer

define K_Heizung_SW1 CUL_HM 16D1E0
attr K_Heizung_SW1 devInfo 040200
attr K_Heizung_SW1 firmware 1.9
attr K_Heizung_SW1 hmClass receiver
attr K_Heizung_SW1 model HM-LC-SW4-DR
attr K_Heizung_SW1 room Heizungskeller
attr K_Heizung_SW1 serialNr IEQ0087769
attr K_Heizung_SW1 subType switch

define FileLog_K_Heizung_SW1 FileLog ./log/K_Heizung_SW1-%Y.log
K_Heizung_SW1
attr FileLog_K_Heizung_SW1 logtype text
attr FileLog_K_Heizung_SW1 room Heizungskeller

define K_Heizung_SW1_CHN_2 CUL_HM 16D1E002
attr K_Heizung_SW1_CHN_2 devInfo 040200
attr K_Heizung_SW1_CHN_2 firmware 1.9
attr K_Heizung_SW1_CHN_2 hmClass receiver
attr K_Heizung_SW1_CHN_2 model HM-LC-SW4-DR
attr K_Heizung_SW1_CHN_2 room Heizungskeller
attr K_Heizung_SW1_CHN_2 serialNr IEQ0087769
attr K_Heizung_SW1_CHN_2 subType switch

define FileLog_K_Heizung_SW1_CHN_2 FileLog ./log/K_Heizung_SW1_CHN_2-
%Y.log K_Heizung_SW1_CHN_
attr FileLog_K_Heizung_SW1_CHN_2 logtype text
attr FileLog_K_Heizung_SW1_CHN_2 room Heizungskeller

define Wasserpumpe CUL_HM 16D1E003
attr Wasserpumpe devInfo 040200
attr Wasserpumpe firmware 1.9
attr Wasserpumpe hmClass receiver
attr Wasserpumpe model HM-LC-SW4-DR
attr Wasserpumpe room Heizungskeller
attr Wasserpumpe serialNr IEQ0087769
attr Wasserpumpe subType switch

define FileLog_Wasserpumpe FileLog ./log/Wasserpumpe-%Y.log
Wasserpumpe
attr FileLog_Wasserpumpe logtype text
attr FileLog_Wasserpumpe room Heizungskeller

define Heizungspumpe CUL_HM 16D1E004
attr Heizungspumpe devInfo 040200
attr Heizungspumpe firmware 1.9
attr Heizungspumpe hmClass receiver
attr Heizungspumpe model HM-LC-SW4-DR
attr Heizungspumpe room Heizungskeller
attr Heizungspumpe serialNr IEQ0087769
attr Heizungspumpe subType switch

define VentilStoerung dummy

define VDKuecheWD watchdog EG_Kueche_VD 01:00:00 SAME set
VentilStoerung 1

define VDWohnzimmerWD watchdog EG_Wohnzimmer_VD 01:00:00 SAME set
VentilStoerung 1

define VDDanielWD watchdog OG_Daniel_VD 01:00:00 SAME set
VentilStoerung 1

define FileLog_Heizungspumpe FileLog ./log/Heizungspumpe-%Y.log
Heizungspumpe
attr FileLog_Heizungspumpe logtype text
attr FileLog_Heizungspumpe room Heizungskeller

define VDKueche notify EG_Kueche_VD { if(ReadingsVal("EG_Kueche_VD",
"STATE", "20") + 1 > 6 || ReadingsVal("EG_Wohnzimmer_VD", "STATE",
"20") + 1 > 6 || ReadingsVal("OG_Daniel_VD", "STATE", "20") + 1 > 6 ||
Value("VentilStoerung") ) { fhem "set Heizungspumpe on" } else { fhem
"set Heizungspumpe off" } }

define VDWohnzimmer notify EG_Wohnzimmer_VD
{ if(ReadingsVal("EG_Kueche_VD", "STATE", "20") + 1 > 6 ||
ReadingsVal("EG_Wohnzimmer_VD", "STATE", "20") + 1 > 6 ||
ReadingsVal("OG_Daniel_VD", "STATE", "20") + 1 > 6 ||
Value("VentilStoerung")) { fhem "set Heizungspumpe on" } else { fhem
"set Heizungspumpe off" } }

define VDDaniel notify OG_Daniel_VD { if(ReadingsVal("EG_Kueche_VD",
"STATE", "20") + 1 > 6 || ReadingsVal("EG_Wohnzimmer_VD", "STATE",
"20") + 1 > 6 || ReadingsVal("OG_Daniel_VD", "STATE", "20") + 1 > 6 ||
Value("VentilStoerung")) { fhem "set Heizungspumpe on" } else { fhem
"set Heizungspumpe off" } }

define WasserpumpeAn at *05:00:00 set Wasserpumpe on

define WasserpumpeAus at *19:00:00 set Wasserpumpe off

define Daniel_ist_da dummy
attr Daniel_ist_da room Anwesenheit

define FileLog_Daniel_ist_da FileLog ./log/OG_Daniel_TC-%Y-%m.log
Daniel_ist_da
attr FileLog_Daniel_ist_da logtype text

define Jan_ist_da dummy
attr Jan_ist_da room Anwesenheit

define FileLog_Jan_ist_da FileLog ./log/OG_Jan_TC-%Y-%m.log Jan_ist_da
attr FileLog_Jan_ist_da logtype text

define Monika_ist_da dummy
attr Monika_ist_da room Anwesenheit

define FileLog_Monika_ist_da FileLog ./log/OG_Monika_TC-%Y-%m.log
Monika_ist_da
attr FileLog_Monika_ist_da logtype text

define Stefan_ist_da dummy
attr Stefan_ist_da room Anwesenheit

define FileLog_Stefan_ist_da FileLog ./log/OG_Stefan_TC-%Y-%m.log
Stefan_ist_da
attr FileLog_Stefan_ist_da logtype text

define Ronja_ist_da dummy
attr Ronja_ist_da room Anwesenheit

define FileLog_Ronja_ist_da FileLog ./log/OG_Ronja_TC-%Y-%m.log
Ronja_ist_da
attr FileLog_Ronja_ist_da logtype text

define IstStefanDa at +*00:10:00 { my $ip = '192.168.178.21';; my $p =
Net::Ping->new( "icmp", 1, 64 ) ;; if ($p->ping($ip)) { {fhem "set
Stefan_ist_da on" } } else { {fhem "set Stefan_ist_da off" } } }

define IstMonikaDa at +*00:10:00 { my $ip = '192.168.178.22';; my $p =
Net::Ping->new( "icmp", 1, 64 ) ;; if ($p->ping($ip)) { {fhem "set
Monika_ist_da on" } } else { {fhem "set Monika_ist_da off" } } }

define IstDanielDa at +*00:10:00 { my $ip = '192.168.178.36';; my $p =
Net::Ping->new( "icmp", 1, 64 ) ;; if ($p->ping($ip)) { {fhem "set
Daniel_ist_da on" } } else { {fhem "set Daniel_ist_da off" } } }

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

rudolfkoenig

                                                   

> Das Pairing der beiden Devices scheint i.O. zu sein, weil ich z.B.
> beim Ändern einer Temperaturliste am HM-CC-TC diese zum HM-CFG-LAN
> übertragen bekomme.

Das ist kein Grund, fhem empfaengt alle Nachrichten im Klartext auch dann wenn
ein HM-Geraet mit einem anderen "angelernt" ist, unabhaengig von der evtl.
konfigurierten "Verschluesselung". Bitte auf die SVN Version updaten, da steht
es im Readings CommandAccepted auf yes oder no, das ist mWn ein besseres Indiz.



> Wenn ich den HM-CC-TC in den Konfigurationsmodus versetzte (durch
> langes Drücken der OK-Taste), dann wird der Befehl "set Daniel_TC day-
> temp 24.0" ohne weiteres akzeptiert und auch am Gerät ausgeführt.

Das ist ein "Beweis" fuer erfolgtes Anlernen.

Evtl. haengt das Problem auch mit dem am 2011-11-06 ausgebauten A112 zusammen.
Kannst Du das untermauern?



> - Kann es damit zusammen hängen, dass die PEER_ADDRESS = 000000 ist?

PEER_ADDRESS ist was anderes, der Empfaenger ist unter DST zu sehen.
Will aber damit nicht sagen, dass fhem hier richtig sendet.



> - Ist der Channel 02 richtig? Der HM-CC-TC hat doch drei Kanäle, nur
> einer davon ist konfigurierbar.

Du weisst mehr als ich :)



> - im Autocreate wird hmClass und hmSubType immer als "unknown"

Fuer HM-CC-TC ist das irrelevant. Schoenheitshalber sollten wir das setzen:
wenn mir jemand einen Patch schickt...



> - ist das Timing des Befehls richtig? Warum kommt genau nach einer
> Sekunde das MISSING ACK? Hört der HM-CC-TC nach einem Broadcast
> überhaupt auf neue Kommandos?

Das HM-CC-TC Protocol habe ich nach Studieren einiger Nachrichten
implementiert, ich waere ueberrascht, wenn es perfekt ist. Und ich habe
deutlich weniger Zeit diesmal mit dem Geraet verbracht als mit dem Vorgaenger
(FHT80b).  Wenn jemand das Protokoll versteht, waere ich dankbar fuer die
Erklaerung.

Wenn ich es richtig verstanden habe, kann man mit dem CC-TC immer dann eine
Sekunde lang reden, wenn es eine Actuator-Meldung losgeworden ist.  Aber evtl.
wartet fhem nicht lange genug, und die Nachricht kollidiert mit dem Ack des
Ventilantriebes. Wenn eine Nachricht nicht mit einem ACK quittiert wird, dann
sendet fhem das noch zweimal raus. Danach gibt es ein "MISSING ACK".


Ich finde es amuesant, dass viele diesen ACK als DEN Vorteil von HM versus FS20
ansehen.  Bei einem "MISSING ACK" ist ja nicht sicher, dass das Befehl nicht
angekommen ist, man hat nur den Ack nicht gehoert.  Konfiguriert jeder
haendisch bei so einem "MISSING ACK" ein notify?  Und was genau?  Anruf via
Telefon dass die Lampe nicht angegangen ist? Solange versuchen, bis es klappt?




> - könnte das an der Konfiguration mit der Fritz-Box liegen? Lohnt sich
> die Arbeit, Fhem auf meine Diskstation zu installieren?

Nein, nein. Evtl. koennte man mseclog einschalten, um zu sehen, ob die Anfrage
innerhalb der Sekunde gesendet wird.

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

Guest

Originally posted by: <email address deleted>

On 27 Nov., 11:18, Rudolf Koenig wrote:
> > Das Pairing der beiden Devices scheint i.O. zu sein, weil ich z.B.
> > beim ndern einer Temperaturliste am HM-CC-TC diese zum HM-CFG-LAN
> > bertragen bekomme.
>
> Das ist kein Grund, fhem empfaengt alle Nachrichten im Klartext auch dann wenn
> ein HM-Geraet mit einem anderen "angelernt" ist, unabhaengig von der evtl.
> konfigurierten "Verschluesselung". Bitte auf die SVN Version updaten, da steht
> es im Readings CommandAccepted auf yes oder no, das ist mWn ein besseres Indiz.

Ja, aber mein HM-CC-TC sendet an die Addresse des HM-CFG-LAN, d.h. dst
ist AECE83. Das könnte er ja nicht wissen, wenn er nicht angelernt
wäre.
Die Version ist aktuell, das Log habe ich aus dem Telnet, wo kann ich
das Readings, was Du angesprochen hast, herbekommen?

>
> > Wenn ich den HM-CC-TC in den Konfigurationsmodus versetzte (durch
> > langes Dr cken der OK-Taste), dann wird der Befehl "set Daniel_TC day-
> > temp 24.0" ohne weiteres akzeptiert und auch am Ger t ausgef hrt.
>
> Das ist ein "Beweis" fuer erfolgtes Anlernen.
>
> Evtl. haengt das Problem auch mit dem am 2011-11-06 ausgebauten A112 zusammen.
> Kannst Du das untermauern?

Es hat vorher auch schon nicht funktioniert, d.h. irgendwann hat es
mal zufällig für ein paar Kommandos funktioniert und dann mal wieder
nicht, aber nix zuverlässiges

>
>
> > - ist das Timing des Befehls richtig? Warum kommt genau nach einer
> > Sekunde das MISSING ACK? H rt der HM-CC-TC nach einem Broadcast
> > berhaupt auf neue Kommandos?
>
> Das HM-CC-TC Protocol habe ich nach Studieren einiger Nachrichten
> implementiert, ich waere ueberrascht, wenn es perfekt ist. Und ich habe
> deutlich weniger Zeit diesmal mit dem Geraet verbracht als mit dem Vorgaenger
> (FHT80b).  Wenn jemand das Protokoll versteht, waere ich dankbar fuer die
> Erklaerung.
>
> Wenn ich es richtig verstanden habe, kann man mit dem CC-TC immer dann eine
> Sekunde lang reden, wenn es eine Actuator-Meldung losgeworden ist.  Aber evtl.
> wartet fhem nicht lange genug, und die Nachricht kollidiert mit dem Ack des
> Ventilantriebes. Wenn eine Nachricht nicht mit einem ACK quittiert wird, dann
> sendet fhem das noch zweimal raus. Danach gibt es ein "MISSING ACK".

Die Implementierung im CUL_HM ist aber so, dass er nach einer
Broadcast-Meldung sendet und nicht nach einer Actuator-Meldung. Könnte
hier das Problem liegen? Nach meiner Beobachtung sind Actuator-
Meldungen und Broadcast-Meldungen nicht miteinander synchronisiert,
daher könnte es ja sein, dass zufällig mal die Actuator-Meldung <1s
vor der Broadcast-Meldung gekommen ist. In diesem Fall sollte es ja
dann funktionieren. Wie kann ich das im CUL_HM mal probeweise ändern?
Ich hätte gedacht, ich verschiebe einfach den Block, der nach dem
Kommentar "Wenn wir etwas zu sagen haben" in den Bereich nach dem
Empfang des Actuator-Kommandos. Hat aber nicht so richtig gespielt.
Liegt wahrscheinlich daran, dass ich die Struktur von fhem-
Implementierung noch nicht so richtig verstehe. Ich werde aber weiter
basteln. Hast Du eine Idee, wie ich klugerweise überprüfen kann, wann
und wie lange HM-CC-TC empfangsbereit ist? Einfach mit Nachrichten
zuballern und schauen, wann eine Reaktion kommt, wäre meine Idee. Habe
aber so recht keine Idee, wie das Perl-mässig umzusetzen wäre. Kann
ich über ein Notify evtl. direkt ein Perl-Befehl absetzen? Dann könnte
ich ja mal alle möglichen Nachrichten durchschauen, wann was geht.

Danke für Hilfe!

Stefan

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

rudolfkoenig

                                                   

> Die Implementierung im CUL_HM ist aber so, dass er nach einer
> Broadcast-Meldung sendet und nicht nach einer Actuator-Meldung.

Vielleicht ist das unser Problem. Du Koenntest die Bedingung fuer
CUL_HM_ProcessCmdStack in CUL_HM_Parse() aendern, die ersten zwei Aufrufe
kommen evtl in Frage. Ich wuerde an deine Stelle erst mit Log diese Stellen
anreichern, um zu sehen, welcher betroffen ist.



> Einfach mit Nachrichten zuballern und schauen, wann eine Reaktion kommt, wäre
> meine Idee.

Mich graust es zwar dabei, aber "wenns Schee macht" :)



> Kann ich über ein Notify evtl. direkt ein Perl-Befehl absetzen?

Sicher, es ist doch ein Standardfall:
  define xx notify { MyPerlFunc() }

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

Zrrronggg!

                                                     

Bezüglich der Sidenote:

Ich habe zwei FS20 Schalter, die eher unzuverlässig arbeiten. Ich
vermute das ist ein Funkabdeckungsproblem. Für mich wäre da das ACK
als Debuggingtool hilfreicher, als Schalten, hinlaufen nachsehen, und
das 30x - um zu sehen, ob der neue Standort des RFR nun besser ist.
Und bei schlechter Lage vor die Lampe stellen und auf die
Fernbedienung drücken bringt ja auch nichts: Wenns nicht geht, weiss
man ja nichtmal, ob des Signal der Fernbedienung angekommen ist.

Ich habe ausserdem immer noch das extrem skurile Problem, dass
meistens AUS geht, AN aber nicht (oder umgekehrt). Lustigerweise: Neu
anlernen des FS Aktors verbessert die Siautation immer für eine
Weile.

Da würde das ACK doch helfen.  Und ja, wenn kein ACK kommt, würde ich
es etwas später noch mal versuchen. (Aber sicher nur dann, wenn der
Schalter statistisch oft genug überhaupt reagiert und sicher auch
nicht 10x oder so.)



On 27 Nov., 15:43, Rudolf Koenig wrote:
> > Die Implementierung im CUL_HM ist aber so, dass er nach einer
> > Broadcast-Meldung sendet und nicht nach einer Actuator-Meldung.
>
> Vielleicht ist das unser Problem. Du Koenntest die Bedingung fuer
> CUL_HM_ProcessCmdStack in CUL_HM_Parse() aendern, die ersten zwei Aufrufe
> kommen evtl in Frage. Ich wuerde an deine Stelle erst mit Log diese Stellen
> anreichern, um zu sehen, welcher betroffen ist.
>
> > Einfach mit Nachrichten zuballern und schauen, wann eine Reaktion kommt, w re
> > meine Idee.
>
> Mich graust es zwar dabei, aber "wenns Schee macht" :)
>
> > Kann ich ber ein Notify evtl. direkt ein Perl-Befehl absetzen?
>
> Sicher, es ist doch ein Standardfall:
>   define xx notify { MyPerlFunc() }

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
FHEM auf Linkstation Mini, CUL 868 SlowRF, 2xCUL 868 RFR, CUL 433 für IT, 2xHMLAN-Configurator mit VCCU, ITV-100 Repeater, Sender und Aktoren von FHT, FS20, S300, HM, IT, RSL

Guest

Originally posted by: <email address deleted>

On 27 Nov., 15:43, Rudolf Koenig wrote:
> > Die Implementierung im CUL_HM ist aber so, dass er nach einer
> > Broadcast-Meldung sendet und nicht nach einer Actuator-Meldung.
>
> Vielleicht ist das unser Problem. Du Koenntest die Bedingung fuer
> CUL_HM_ProcessCmdStack in CUL_HM_Parse() aendern, die ersten zwei Aufrufe
> kommen evtl in Frage. Ich wuerde an deine Stelle erst mit Log diese Stellen
> anreichern, um zu sehen, welcher betroffen ist.

Sorry, bin leider Perl-Dummy, das Buch liegt schon auf dem Nachttisch,
aber über die einführenden Kapitel bin ich noch nicht weggekommen.
Ich habe jetzt nur mal versucht, den Block

      # If we have something to tell:
      my $sdt = $shash->{SET_DESIRED_TEMP};     # DOES NOT WORK
      if($sdt) {
        CUL_HM_SendCmd($shash,
                sprintf("++A011%s%s0201${sdt}0000", $id,$dst), 1, 1);
        delete($shash->{SET_DESIRED_TEMP});

      } else {
        CUL_HM_SendCmd($shash, "++A112$id$src", 1, 1) if($shash-
>{cmdStack});
      }

an eine andere Stelle zu verschieben, und zwar an die Stelle nach dem
Empfang des A258-Kommandos (Befehl zum Setzen des Aktuators). Es kommt
ein A112-Kommando an der Stelle, die ich mir gewünscht habe, aber
leider immer noch ein MISSING ACK. Leider Pech....
Hast Du noch weitere Ideen?


> > Kann ich ber ein Notify evtl. direkt ein Perl-Befehl absetzen?
>
> Sicher, es ist doch ein Standardfall:
>   define xx notify { MyPerlFunc() }

Sorry, falsch formuliert! Richtig müsste es heißen, wie müsste der
Perl-Aufruf lauten, der direkt den Befehl zum Starten der
Konfiguration an den HM-CC-TC sendet. Kann ich auf eine Low-Level-
Routine zurückgreifen?

Danke für Hilfe,
Gruß,
Stefan

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

rudolfkoenig

                                                   

> Hast Du noch weitere Ideen?

Ja: ein HMLAN mit dem Originalsoftware oder CCU  danabenstellen, und zuschauen,
wie man es machen muesste. :)



> Kann ich auf eine Low-Level-Routine zurückgreifen?

Du kannst beliebige Perlfunktionen anrufen, aber ich finde
  set raw ++blablabla am einfachsten.
Beim jedem Sender und beim HM-CC-TC kommt das Argument auf dem CmdStack, und
wird, wenn das TC sich meldet, ausgefuehrt.

Sonst vielleicht nuetzlich:
  { CUL_HM_Parse($defs{MyCUL}, "A") }
  { CUL_HM_ProcessCmdStack($defs{MyTC}) }
  { CUL_HM_SendCmd($defs{MyTC}, "A", 1, 1) }

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

andre

                                             

Halllo zusammen,

ich bin neu bei FHEM mit einer FB7390 und HM-CC-TC, HM-CC-VD und HM-
CFG-LAN dabei und bisher hell-auf begeistert von den Möglichkeiten,
die mir FHEM bietet und auch dabei, meine Einrichtungen schrittweise
auszubauen :-)

Nun habe ich dem Beitrag gelesen, dass Du die Heizung dynamisch ja
nach Anwesenheit der Personen hoch- oder runterregelst. Das würde ich
gerne bei mir ähnlich machen. Mit der Idee, über einen Ping die
Anwesenheit zu prüfen, kann ich leider nicht zuverlässig feststellen,
ob eine Person da ist oder nicht, da mein iPhone nicht auf Pings
antwortet, wenn es sein WLAN Modul schlafen legt. Daher war meine
Idee, dass über die Fritzbox festzustellen, da diese zuverlässig
feststellen kann, ob ein Gerät in sein WLAN im Moment eingebucht ist
oder nicht. Daher habe ich ein bisschen rumgesucht und bin auf den
folgenden Shell Aufruf gestoßen (und zwar hier:
http://www.wehavemorefun.de/fritzbox/index.php/Ctlmgr Darüber lassen
sich auch noch Unmengen an weiteren Infos abfragen und ändern):

ctlmgr_ctl r landevice settings/landevice0/active

Dieser Aufruf gibt entweder 0 auf der Konsole aus, wenn das Gerät
nicht im Netzwerk ist, oder entsprechend 1. Auch wenn das Gerät über
ein Ping nicht mehr erreichbar ist (das landevice0 ist dabei mein
iPhone).

Über diesen Aufruf würde ich nun gerne das Dummy Device entsprechend
schalten, indem dieser Shell Befehl z.B. alle 10 Minuten aufgerufen
wird.

Um dies zu Bewerkstelligen, habe ich folgende Nachricht zur Grundlage
genommen:
http://groups.google.com/group/fhem-users/browse_thread/thread/cd8f5b4aa29fad0c/59906e788512294a

Leider bekomme ich es aber einfach nicht auf die Reihe, das FHEM at-
Kommande so anzupassen, dass der Wert entsprechend eingelesen wird.
Auch funktioniert das Beispiel im o.a. Thread bei mir auch nicht
(natürlich mit anderen Beispieldaten) :-(

Hat da jemand evtl. eine Idee wie das geht?

Vielen Dank und viele Grüße,
André



On Nov 27, 10:32 am, "ru...@dfr-software.de"
wrote:
> Hallo zusammen,
> ich betreibe fhem auf einer FB7270 und benutze einen HM-CFG-LAN in
> Verbindung mit einigen HM-CC-TC und HM-CC-VD. Fhem ist auf einem USB-
> Stick installiert, der in der FritzBox steckt.
> Mein Ziel ist es, die Anwesenheit meiner Familienmitglieder dadurch zu
> ermitteln, dass ich überprüfe, ob deren Handy ins WLAN eingebucht
> ist.  Wenn das für eine gewisse Zeit nicht der Fall ist, dann soll die
> Heizung in dem entsprechenden Raum runtergeregelt werden. Wenn alle
> Stellantriebe in allen Räumen kleiner 10% gestellt sind, wird über
> einen Funkschalter die Heizungspumpe abgestellt.
> Soweit so gut, das Überprüfen der Anwesenheit klappt prima, nur leider
> wiedersetzt sich der HM-CC-TC hartnäckig jedem Konfigurationsversuch.
> Als Beispiel mal ein Versuch, die day-temp auf 24°C zu setzen (nur als
> Beispiel, das Runterregeln der Heizung funktioniert ja so nicht).
>
> 2011-11-27 09:58:51 CUL_HM OG_Daniel_TC day-temp 24.0
> 2011-11-27 09:59:23 HMLAN Zentrale RCV L:0C N:65 CMD:8670 SRC:1500A8
> DST:000000 00CF34
> 2011-11-27 09:59:23 HMLAN Zentrale SND L:10 N:98 CMD:A001 SRC:AECE83
> DST:1500A8 02050000000005 (CONFIG_START CHANNEL:02 PEER_ADDRESS:000000
> PEER_CHANNEL:00 PARAM_LIST:05)
> 2011-11-27 09:59:24 CUL_HM OG_Daniel_TC MISSING ACK
>
> Zu sehen ist hier, das nach einem Broadcast vom HM-CC-TC (Adresse
> 1500A8) mein HM-CFG-LAN (Adresse AECE83) die Konfiguration starten
> möchte. Eine Sekunde später kommt dann ein MISSING ACK .
>
> Das Pairing der beiden Devices scheint i.O. zu sein, weil ich z.B.
> beim Ändern einer Temperaturliste am HM-CC-TC diese zum HM-CFG-LAN
> übertragen bekomme. Wenn die Geräte nicht gepairt wären, dann sollte
> dieses ja nicht funktionieren.
>
> Wenn ich den HM-CC-TC in den Konfigurationsmodus versetzte (durch
> langes Drücken der OK-Taste), dann wird der Befehl "set Daniel_TC day-
> temp 24.0" ohne weiteres akzeptiert und auch am Gerät ausgeführt.
>
> Die Frage ist jetzt, warum der Befehl nicht akzeptiert wird! Folgende
> Gedanken dazu:
> - Kann es damit zusammen hängen, dass die PEER_ADDRESS = 000000 ist?
> Sollte diese nicht die Adresse des Senders sein? Wo wird diese
> festgelegt?
> - Ist der Channel 02 richtig? Der HM-CC-TC hat doch drei Kanäle, nur
> einer davon ist konfigurierbar.
> - im Autocreate wird hmClass und hmSubType immer als "unknown"
> ermittelt. Muss dort etwas anderes stehen oder ist das unerheblich?
> - ist das Timing des Befehls richtig? Warum kommt genau nach einer
> Sekunde das MISSING ACK? Hört der HM-CC-TC nach einem Broadcast
> überhaupt auf neue Kommandos?
> - könnte das an der Konfiguration mit der Fritz-Box liegen? Lohnt sich
> die Arbeit, Fhem auf meine Diskstation zu installieren?
>
> Viele Fragen, ich weiß, aber vielleicht kann jemand die ein oder
> andere Frage ja beantworten und mir so helfen, dieses lästige Problem
> zu lösen.
>
> Anbei noch meine fhem.cfg zur Info.
>
> Schon mal vielen Dank für eure Hilfe
>
> Gruß,
> Stefan
>
> attr global autoload_undefined_devices 1
> attr global logfile ./log/fhem-%Y-%m.log
> attr global modpath .
> attr global port 7072 global
> attr global statefile ./log/fhem.save
> attr global userattr webCmd
> attr global verbose 4
>
> define WEB FHEMWEB 8083 global
>
> define WEBphone FHEMWEB 8084 global
> attr WEBphone smallscreen 1
>
> define WEBtablet FHEMWEB 8085 global
> attr WEBtablet touchpad 1
>
> define Logfile FileLog ./log/fhem-%Y-%m.log fakelog
>
> 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 Plots
>
> define Zentrale HMLAN 192.168.178.33:1000
> attr Zentrale hmId AECE83
> attr Zentrale hmProtocolEvents 1
>
> define OG_Daniel_TC CUL_HM 1500A8
> attr OG_Daniel_TC devInfo 00FFFF
> attr OG_Daniel_TC firmware 2.0
> attr OG_Daniel_TC hmClass sender
> attr OG_Daniel_TC loglevel 5
> attr OG_Daniel_TC model HM-CC-TC
> attr OG_Daniel_TC room Daniel
> attr OG_Daniel_TC serialNr HEQ0511217
> attr OG_Daniel_TC subType Climate-Control
>
> define FileLog_OG_Daniel_TC FileLog ./log/OG_Daniel_TC-%Y.log
> OG_Daniel_TC
> attr FileLog_OG_Daniel_TC logtype text
> attr FileLog_OG_Daniel_TC room Daniel
>
> define OG_Daniel_VD CUL_HM 1548D3
> attr OG_Daniel_VD devInfo 010100
> attr OG_Daniel_VD firmware 1.8
> attr OG_Daniel_VD hmClass unknown
> attr OG_Daniel_VD model HM-CC-VD
> attr OG_Daniel_VD room Daniel
> attr OG_Daniel_VD serialNr HEQ0514667
> attr OG_Daniel_VD subType unknown
>
> define FileLog_OG_Daniel_VD FileLog ./log/OG_Daniel_VD-%Y.log
> OG_Daniel_VD
> attr FileLog_OG_Daniel_VD logtype text
> attr FileLog_OG_Daniel_VD room Daniel
>
> define OG_Daniel_TS CUL_HM 1453EA
> attr OG_Daniel_TS devInfo 810101
> attr OG_Daniel_TS firmware 2.0
> attr OG_Daniel_TS hmClass sender
> attr OG_Daniel_TS model HM-SEC-SC
> attr OG_Daniel_TS room Daniel
> attr OG_Daniel_TS serialNr HEQ0364954
> attr OG_Daniel_TS subType threeStateSensor
>
> define FileLog_OG_Daniel_TS FileLog ./log/OG_Daniel_TS-%Y.log
> OG_Daniel_TS
> attr FileLog_OG_Daniel_TS logtype text
> attr FileLog_OG_Daniel_TS room Daniel
>
> define EG_Wohnzimmer_TC CUL_HM 129CA9
> attr EG_Wohnzimmer_TC devInfo 00FFFF
> attr EG_Wohnzimmer_TC firmware 1.9
> attr EG_Wohnzimmer_TC hmClass unknown
> attr EG_Wohnzimmer_TC model HM-CC-TC
> attr EG_Wohnzimmer_TC room Wohnzimmer
> attr EG_Wohnzimmer_TC serialNr GEQ0161864
> attr EG_Wohnzimmer_TC subType unknown
>
> define FileLog_EG_Wohnzimmer_TC FileLog ./log/EG_Wohnzimmer_TC-%Y.log
> EG_Wohnzimmer_TC
> attr FileLog_EG_Wohnzimmer_TC logtype text
> attr FileLog_EG_Wohnzimmer_TC room Wohnzimmer
>
> define K_Heizung_P dummy
> attr K_Heizung_P room Heizungskeller
>
> define EG_Wohnzimmer_VD CUL_HM 12D882
> attr EG_Wohnzimmer_VD devInfo 010100
> attr EG_Wohnzimmer_VD firmware 1.8
> attr EG_Wohnzimmer_VD hmClass unknown
> attr EG_Wohnzimmer_VD model HM-CC-VD
> attr EG_Wohnzimmer_VD room Wohnzimmer
> attr EG_Wohnzimmer_VD serialNr HEQ0067832
> attr EG_Wohnzimmer_VD subType unknown
>
> define FileLog_EG_Wohnzimmer_VD FileLog ./log/EG_Wohnzimmer_VD-%Y.log
> EG_Wohnzimmer_VD
> attr FileLog_EG_Wohnzimmer_VD logtype text
> attr FileLog_EG_Wohnzimmer_VD room Wohnzimmer
>
> define EG_Kueche_VD CUL_HM 126633
> attr EG_Kueche_VD devInfo 010100
> attr EG_Kueche_VD firmware 1.8
> attr EG_Kueche_VD hmClass unknown
> attr EG_Kueche_VD model HM-CC-VD
> attr EG_Kueche_VD room Wohnzimmer
> attr EG_Kueche_VD serialNr GEQ0162965
> attr EG_Kueche_VD subType unknown
>
> define FileLog_EG_Kueche_VD FileLog ./log/EG_Kueche_VD-%Y.log
> EG_Kueche_VD
> attr FileLog_EG_Kueche_VD logtype text
> attr FileLog_EG_Kueche_VD room Wohnzimmer
>
> define EG_Wohnzimmer_TS CUL_HM 124292
> attr EG_Wohnzimmer_TS devInfo 810101
> attr EG_Wohnzimmer_TS firmware 1.9
> attr EG_Wohnzimmer_TS hmClass sender
> attr EG_Wohnzimmer_TS model HM-SEC-SC
> attr EG_Wohnzimmer_TS room Wohnzimmer
> attr EG_Wohnzimmer_TS serialNr GEQ0164945
> attr EG_Wohnzimmer_TS subType threeStateSensor
>
> define FileLog_EG_Wohnzimmer_TS FileLog ./log/EG_Wohnzimmer_TS-%Y.log
> EG_Wohnzimmer_TS
> attr FileLog_EG_Wohnzimmer_TS logtype text
> attr FileLog_EG_Wohnzimmer_TS room Wohnzimmer
>
> define K_Heizung_SW1 CUL_HM 16D1E0
> attr K_Heizung_SW1 devInfo 040200
> attr K_Heizung_SW1 firmware 1.9
> attr K_Heizung_SW1 hmClass receiver
> attr K_Heizung_SW1 model HM-LC-SW4-DR
> attr K_Heizung_SW1 room Heizungskeller
> attr K_Heizung_SW1 serialNr IEQ0087769
> attr K_Heizung_SW1 subType switch
>
> define FileLog_K_Heizung_SW1 FileLog ./log/K_Heizung_SW1-%Y.log
> K_Heizung_SW1
> attr FileLog_K_Heizung_SW1 logtype text
> attr FileLog_K_Heizung_SW1 room Heizungskeller
>
> define K_Heizung_SW1_CHN_2 CUL_HM 16D1E002
> attr K_Heizung_SW1_CHN_2 devInfo 040200
> attr K_Heizung_SW1_CHN_2 firmware 1.9
> attr K_Heizung_SW1_CHN_2 hmClass receiver
> attr K_Heizung_SW1_CHN_2 model HM-LC-SW4-DR
> attr K_Heizung_SW1_CHN_2 room Heizungskeller
> attr K_Heizung_SW1_CHN_2 serialNr IEQ0087769
> attr K_Heizung_SW1_CHN_2 subType switch
>
> define FileLog_K_Heizung_SW1_CHN_2 FileLog ./log/K_Heizung_SW1_CHN_2-
> %Y.log K_Heizung_SW1_CHN_
> attr FileLog_K_Heizung_SW1_CHN_2 logtype text
> attr FileLog_K_Heizung_SW1_CHN_2 room Heizungskeller
>
> define Wasserpumpe CUL_HM 16D1E003
> attr Wasserpumpe devInfo 040200
> attr Wasserpumpe firmware 1.9
> attr Wasserpumpe hmClass receiver
> attr Wasserpumpe model HM-LC-SW4-DR
> attr Wasserpumpe room Heizungskeller
> attr Wasserpumpe serialNr IEQ0087769
> attr Wasserpumpe subType switch
>
> define FileLog_Wasserpumpe FileLog ./log/Wasserpumpe-%Y.log
> Wasserpumpe
> attr FileLog_Wasserpumpe logtype text
> attr FileLog_Wasserpumpe room Heizungskeller
>
> define Heizungspumpe CUL_HM 16D1E004
> attr Heizungspumpe devInfo 040200
> attr Heizungspumpe firmware 1.9
> attr Heizungspumpe hmClass receiver
> attr Heizungspumpe model HM-LC-SW4-DR
> attr Heizungspumpe room Heizungskeller
> attr Heizungspumpe serialNr IEQ0087769
> attr Heizungspumpe subType switch
>
> define VentilStoerung dummy
>
> define VDKuecheWD watchdog EG_Kueche_VD 01:00:00 SAME set
> VentilStoerung 1
>
> define VDWohnzimmerWD watchdog EG_Wohnzimmer_VD 01:00:00 SAME set
> VentilStoerung 1
>
> define VDDanielWD watchdog OG_Daniel_VD 01:00:00 SAME set
> VentilStoerung 1
>
> define FileLog_Heizungspumpe FileLog ./log/Heizungspumpe-%Y.log
> Heizungspumpe
> attr FileLog_Heizungspumpe logtype text
> attr FileLog_Heizungspumpe room Heizungskeller
>
> define VDKueche notify EG_Kueche_VD { if(ReadingsVal("EG_Kueche_VD",
> "STATE", "20") + 1 > 6 || ReadingsVal("EG_Wohnzimmer_VD", "STATE",
> "20") + 1 > 6 || ReadingsVal("OG_Daniel_VD", "STATE", "20") + 1 > 6 ||
> Value("VentilStoerung") ) { fhem "set Heizungspumpe on" } else { fhem
> "set Heizungspumpe off" } }
>
> define VDWohnzimmer notify EG_Wohnzimmer_VD
> { if(ReadingsVal("EG_Kueche_VD", "STATE", "20") + 1 > 6 ||
> ReadingsVal("EG_Wohnzimmer_VD", "STATE", "20") + 1 > 6 ||
> ReadingsVal("OG_Daniel_VD", "STATE", "20") + 1 > 6 ||
> Value("VentilStoerung")) { fhem "set Heizungspumpe on" } else { fhem
> "set Heizungspumpe off" } }
>
> define VDDaniel notify OG_Daniel_VD { if(ReadingsVal("EG_Kueche_VD",
> "STATE", "20") + 1 > 6 || ReadingsVal("EG_Wohnzimmer_VD", "STATE",
> "20") + 1 > 6 || ReadingsVal("OG_Daniel_VD", "STATE", "20") + 1 > 6 ||
> Value("VentilStoerung")) { fhem "set Heizungspumpe on" } else { fhem
> "set Heizungspumpe off" } }
>
> define WasserpumpeAn at *05:00:00 set Wasserpumpe on
>
> define ...
>
> read more »

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

Guest

Originally posted by: <email address deleted>

Hallo,
dank Rudolfs Hilfe bin ich dem Problem ein bisschen näher gekommen.
Ich habe ein Notify definiert

define TestNotify notify OG_Daniel_TC
{ CUL_HM_SendCmd($defs{OG_Daniel_TC}, "27A112AECE831500A8", 1, 1) }

Dieses fängt an, wenn sich der HM-CC-TC meldet, A112-er Nachrichten an
ihn zu senden, und zwar so schnell es die Fritz-Box hergibt. Damit
kann ich sehen, dass der HM-CC-TC einfach irgentwann, ohne für mich
heute nachvollziebaren Grund, ein Ack sendet. Einmal ein Ack gesendet,
sendet es weiterhin Acks, wenn ich erneut das Kommando sende. Ich
hätte jetzt gerne gewusst, ob ich herausbekommen kann, ob das Gerät
ein Ack gesendet hat. Über

define TestWake at +*00:00:01 { if (ReadingsVal("OG_Daniel_TC",
"state", "MISSING ACK")=="MISSING ACK")
{ CUL_HM_SendCmd($defs{OG_Daniel_TC}, "27A112AECE831500A8", 1, 1) }
else { fhem "set OG_Daniel_TC day-temp 25.0" }}

 geht es nicht, dieser behält den Status Missing Ack bis ein gültiger
Wert vom HM-CC-TC gesendet wird. Ich möchte aber beim ersten Ack schon
aufhören und versuchen, ob ich dann das Kommando senden kann, welches
ich will. Das ist zwar überhaupt nicht schön, soll auch nicht so
bleiben, aber ich hoffe, damit etwas über die Ursache rauszukriegen!

Danke für Hilfe!

Gruß,
Stefan

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

rudolfkoenig

                                                   

> { CUL_HM_SendCmd($defs{OG_Daniel_TC}, "27A112AECE831500A8", 1, 1) }

Kannst Du bitte 27 durch ++ ersetzen?  An diese Stelle steht die
Sequenz-Nummer, und ich meine Duplikate werden einfach ignoriert.

Alternativ koenntest Du auch mit der 5.1-er Version der 10_CUL_HM.pm
experimentieren, der hat noch die A112 Aufforderung an das TC enthalten.

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