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

[Guest]

Originally posted by: <email address deleted>

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é

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

[Guest]

Originally posted by: <email address deleted>

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 loglevel 1
attr 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

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

[Guest]

Originally posted by: <email address deleted>

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é


Am Donnerstag, 29. November 2012 10:26:03 UTC+1 schrieb 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 loglevel 1
> attr 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
>
>

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

[Guest]

Originally posted by: <email address deleted>

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

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

[Guest]

Originally posted by: <email address deleted>

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é

Am Montag, 3. Dezember 2012 09:46:41 UTC+1 schrieb 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
>

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

[Guest]

Originally posted by: <email address deleted>

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


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

[Guest]

Originally posted by: <email address deleted>

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é


On Tuesday, December 18, 2012 1:15:25 PM UTC+1, Martin wrote:
>
> 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
>
>
>

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

[Guest]

Originally posted by: <email address deleted>

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

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

[Guest]

Originally posted by: <email address deleted>

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

Am Dienstag, 18. Dezember 2012 17:44:36 UTC+1 schrieb 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:
>>
>> 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
>>
>>
>>

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