Sending ACK for HM-RC-Sec3 in 10_CUL_HM.pm

[Andre]

Hallo,

ich verwende die Homematic Fernbedienung HM-RC-Sec3 für die Steuerung meiner Alarmanlagenfunktion. Damit die LED auf der FB zur Bestätigung grün leuchtet, habe ich die Tipps aus dem Posting https://groups.google.com/d/topic/fhem-users/o2KVuZy62KQ/discussion ausprobiert. Klappt auch hin und wieder, habe aber die beschriebenen Timing Probleme. Da es beim threeStateSensor HM-SEC-SC wunderbar funktioniert habe ich den Code dazu aus 10_CUL_HM.pm verwendet und für die Fernbedienung ebenfalls direkt in 10_CUL_HM.pm implementiert:

#################################################

elsif($st eq "remote" || $st eq "pushButton" || $st eq "swi") { #############

        # start custom code

if($model eq "HM-RC-SEC3") {

          # Sending ACK to remote  to show green confirmation led

 CUL_HM_SndCmd($shash, "++8002".$dst.$src."0000"); # Sending ACK

 $sendAck = "";

  # Log 1, "Sent ACK ";

}

        # end custom code

        ...

}

#################################################

Mit der Anpassung funktioniert bei mir nun auch die LED der Fernbedienung nahezu problemlos (ca. 95%). Die FB ist dazu mit einem virtuellem HM Device gepaired. 

Da es natürlich nicht besonders sinnvoll ist direkt den Sourcecode zu verändern hier ein paar Fragen dazu:

1) Ergibt es eventuell Sinn dies in ähnlicher Art für die HM-RC-Sec3 dauerhaft einzuchecken? Aus meiner Sicht sollte ein ACK ja immer kommen.

2) Warum funktioniert die obige Anpassung deutlich stabiler als der Vorschlag aus dem Posting? Kommt die ACK Message eventuell deutlich früher als ein nachgelagertes notify?

3) Gibt es eine sinnvolle und funktionierende Stelle zur Implementierung wenn es nicht in den originalen Sourcecode soll/kann?

Besten Dank!

Gruß,

André

[Martin]

Hallo Andre,

Deine Aenderung sollte so nicht eingecheckt werden, da sie gegen mehrere Regeln verstoesst
1) es macht keinen Sinn, dies nur fuer dieese Model zu machen. es wird fuer alle gleich, das sowieso alle gleich reagieren sollen und reagieren
2) du schickst ein ACK auch wenn du nicht der Empfaenger bist. So was darf man nicht.
3) du schickst ein ACK auch wenn der Sender keines gefordert hat - das geht auch nicht gut.

Das mit dem Notify habe ich nicht verstanden. Die aktuelle Version sendet acks genauso schnell, wie deine Version - aber haelt sich an die Regeln.

Das es bei dir Funktioniert glaube ich - deckt aber nicht alle Faelle ab.
Um zu verstehen, was bei dir falsch laeuft muss man erste einmal wissen
- an wen schickt den ein RC3?
- mit wem ist RC3 gepairt?
- wie ist das timing und was ist da falsch?
- was schickt dein RC3

Also kannst du einen satz logs zusammenstellen mit den Daten von oben.
Bekommen kannst du die amkompaktestem wenn du die Logs einstellst auf

attr global verbose 1
attr global mseglog 1
attr <cul|hmlan> loglevel 1
attr <cul|hmlan> hmProtokolEvents 0

dann Tasten druecken und dazuchreiben, wann es ok war und wann nicht.
ein getConfig ist auch immer gut, dann kenne ich pairings und peerings

Gruss
Martin

[Andre]

Hallo Martin,

danke für Deine Antwort. Es sollte so auch nicht eingecheckt werden sondern nur eine Anregung sein über so etwas nachzudenken. Zu Deinen Punkten

1) Ich habe nur die eine Fernbedienung und kann nur damit testen. Wenn sich alle gleich verhalten umso besser

2) Das kann bestimmt abgefragt werden, oder? Ich meine so eine Abfrage an anderen Stellen gesehen zu haben

3) Warum? Ist ein ACK in dem Protokoll nicht bei jedem Befehl vorgesehen? Schicht der Tür-Fenster Kontakt HM-SEC-SC eine Anforderung für ein ACK?

Danke auch für den Hinweis wie die Logs einzustellen sind. Ich werde das in den kommenden Tagen testen und meine Ergebnisse und die Readings posten. 

Gruß,

André

[Martin]

Hallo Andre

1) Ich habe nur die eine Fernbedienung und kann nur damit testen. Wenn sich alle gleich verhalten umso besser

wir koennen gerne gemeinsam eine Loesung finden
 

2) Das kann bestimmt abgefragt werden, oder? Ich meine so eine Abfrage an anderen Stellen gesehen zu haben

Korrekt. Der Code ist ja schon drin und sollte es abdecken. Wenn etwas erweitert werden muss, dann muessen wir das Detail finden und behandeln.
 

3) Warum? Ist ein ACK in dem Protokoll nicht bei jedem Befehl vorgesehen? Schicht der Tür-Fenster Kontakt HM-SEC-SC eine Anforderung für ein ACK?

ob ein ACK gewuenscht ist, ist in den Flags kodiert. Es wird nicht immer gewuenscht. Dein Code schickt sogar ein ack auf ein ack. Zum Glueck hoert deine Remote auf, sonst haettest du eine Endlosschleife. Im Prinzip ich dies alles dahingehend erweitert - und es funktioniert auch so.

Danke auch für den Hinweis wie die Logs einzustellen sind. Ich werde das in den kommenden Tagen testen und meine Ergebnisse und die Readings posten. 

waere schoen. Wenn ich die logs sehe kann ich dir hoffentlich sagen, wo das Problem liegt und wir koennen ggf den Ack mechanismus anpassen. 

Gruss
Martin

[Andre]

Hallo Martin,

ich bin jetzt dazu gekommen die Auswertung zu machen. Ich hoffe die Ausführungen sind soweit verständlich.

Also meine Fernbedienung (HmID 19AE6B) ist mit dem CUL Stick myCUL gepaired. Die Kanäle der Buttons sind alle mit einem virtuellen Device (ID ABC123) gepaired, da ich keinen physikalischen Aktor damit steuern möchte. Alles im großen und ganzen nach der genannten Anleitung.

Readings der FB selbst

CommandAccepted yes

PairedTo 0xF11034

RegL_00: 02:01 0A:F1 0B:10 0C:34 00:00

battery ok

noReceiver src:19AE6B (A440) 034D8F544754139CBADB65DB15324061E1CF8044

state CUL_HM_remote_19AE6B_Btn_03 Short (to HMvirtual)

Readings des Buttons:

R-HMvirtual_chn-01-expectAES off

R-HMvirtual_chn-01-peerNeedsBurst off

RegL_01: 04:10 08:00 09:00 00:00

RegL_04:HMvirtual_chn:01 01:00 00:00

peerList HMvirtual_chn:01,

state (to HMvirtual)

Ich habe einen notify, der das Drücken eines Buttons abfängt und dann ein ACK (8002) als Raw Message sendet. Mit Deinen genannten Einstellungen bekomme ich folgende Logs:

2012.12.18 00:41:26.302 1: myCUL: A0BC3A04019AE6BABC12303D3 -89

2012.12.18 00:41:28.815 1: SW: As0A8002ABC12319AE6B0300

2012.12.18 00:41:28.843 1: myCUL: A0BC3A04019AE6BABC12303D3 -83

Und dann noch ein Versuch:

2012.12.18 00:52:14.337 1: myCUL: A0BF2A44019AE6BABC1230302 -80

2012.12.18 00:52:14.643 1: SW: As0A8002ABC12319AE6B0300

2012.12.18 00:52:14.664 1: myCUL: A0BF2A04019AE6BABC1230302 -78.5

2012.12.18 00:52:14.841 1: myCUL: A0BF2A04019AE6BABC1230302 -76

Beide führen nicht zu einer ACK Anzeige auf der FB. Wenn ich das Senden der ACK Message direkt in 10_CUL_HM einbaue funktioniert es. Hier kann ich bei Bedarf auch noch die Logs erzeugen. Meine Vermutung war es, dass die ACK Nachrichten vielleicht zu spät versendet werden.

Ich hoffe Du kannst hiermit schon etwas anfangen, wenn noch etwas fehlt liefere ich gerne noch etwas nach.

Gruß,

André

[Martin]

Hallo Andre,

Beide führen nicht zu einer ACK Anzeige auf der FB. Wenn ich das Senden der ACK Message direkt in 10_CUL_HM einbaue funktioniert es. Hier kann ich bei Bedarf auch noch die Logs erzeugen. Meine Vermutung war es, dass die ACK Nachrichten vielleicht zu spät versendet werden.

das ACK ist doch direkt in CUL_HM eingebaut.
Die Verzoegerung des ACK im ersten Fall ist nicht tragba, die 2 sec sind keine zu verstehende Verzoegerung.

Im 2. Fall ist die Verzoegerung ok
in beiden Faellen ist die Message nicht korrekt - sowohl message nummer als auch Message Inhalt.

Kannst du noch ein noch ein 'list' von deinem virtuellen Aktor schicken? Der scheint nicht gepairt. Bitte komplett: das virtuelle Device UND der erste virtuelle Kanal

Gruss
Martin

[Andre]

Hallo Martin,

jetzt scheinen wir meinem Problem näher zu kommen. Ich habe nur ein virtuelles Device definiert mit 

define HMvirtual CUL_HM ABC123

attr HMvirtual hmClass receiver

attr HMvirtual subType switch

Hier der Auszug von list HMvirtual

Internals:
   DEF        ABC123
   IODev      myCUL
   NAME       HMvirtual
   NR         110
   STATE      RESPONSE TIMEOUT:RegisterRead
   TYPE       CUL_HM
   protSnd    7 last_at:2012-12-18 17:20:59
   protState  CMDs_done_events:2
   protToutResp 6 last_at:2012-12-18 17:21:01
   Readings:
     2012-12-18 01:38:30   peerList        
     2012-12-18 17:21:01   state           RESPONSE TIMEOUT:RegisterRead
     Regl_00::
       VAL        
     Regl_01::
       VAL        
   Helper:
     burstEvtCnt 3
     getCfgList all
     getCfgListNo 3
     mId        0050
     rxType     1
Attributes:
   fm_fav     999
   hmClass    receiver
   peerIDs    
   room       CUL_HM
   subType    switch

Und hier der Auszug von list CUL_HM_remote_19AE6B_btn_03

Internals:
   DEF        19AE6B03
   IODev      myCUL
   NAME       CUL_HM_remote_19AE6B_Btn_03
   NR         107
   STATE       (to HMvirtual)
   TYPE       CUL_HM
   chanNo     03
   device     CUL_HM_remote_19AE6B
   Readings:
     2012-12-18 17:15:23   R-HMvirtual_chn-01-expectAES off 
     2012-12-18 17:15:23   R-HMvirtual_chn-01-peerNeedsBurst off 
     2012-12-18 00:26:49   RegL_01:        04:10 08:00 09:00 00:00
     2012-12-18 00:26:49   RegL_04:HMvirtual_chn:01 01:00 00:00
     2012-12-18 00:26:48   peerList        HMvirtual_chn:01,
     2012-12-18 17:15:45   state            (to HMvirtual)
   Helper:
     Shadowreg:
       RegL_04:HMvirtual_chn:01 01:00 00:00
Attributes:
   model      HM-RC-SEC3
   peerIDs    ABC12301,
   peerList   HMvirtual_chn:01,
   room       CUL_HM

Muss ich noch einen Kanal definieren auf dem virtuellen Device?

Gruß,

André

[Andre]

Hallo Martin,

ich glaube ich habe das Problem mit Deiner Hilfe gefunden (dank an den list Befehl). Ich habe den subType des virtuellen Devices von switch auf virtual umgestellt. Danach habe ich das pairing neu durchgeführt und siehe da, es funktioniert. Das notify event habe ich gelöscht. Mir war nicht klar, dass dies schon im CUL_HM implementiert ist. 

Ist es so  aus Deiner Sicht dann korrekt konfiguriert oder sollte ich noch etwas anders machen mit dem virtuellen Device?

Gruß,

Andre

On Tuesday, December 18, 2012 1:15:25 PM UTC+1, Martin wrote:

[Martin]

Andre,

kann man machen. Eigentlich sollten attribute wie subtype automatisch gesetzt werden. Das waere passiert, wenn du (mindestens) einenvirtuellen Kanal definiert haettest. Also nach dem Definieren des Virtuellen Device ein
set <virtDev> virtual 1 # oder eben wieviele Kanaele du brauchst

dann wuerden auch alle attribute gesetzt

Das device ist eigentlich nicht zum schalten gedacht - sondern die Kanaele - angelehnt an die realen komponenten.

Gruss
Martin