Zyklische Statusmeldungen HM-SEC-SC

Begonnen von Andre, 11 Januar 2013, 20:34:45

Vorheriges Thema - Nächstes Thema

Andre

Hallo,

ich hatte es bei Anfängerfragen schon mal versucht, vielleicht ist meine Frage hier ja besser aufgehoben.

Ich würde bei meinen HM-SEC-SC Fensterkontakten gerne die zyklische Statusmeldung aktivieren. Ich habe einige Post gefunden, die Register 09 in Liste 01 empfehlen. Wenn ich dieses Register von 00 auf 01 (soll bool sein, daher habe ich das so getestet) verändere und dann die Anlerntaste drücke wird zwar etwas übertragen, aber die Werte im Register ändern sich nach einem getConfig nicht.

Hat das schon mal jemand über FHEM erfolgreich gesetzt? Ist das Register 09 in Liste 1 korrekt?

Gruß,
André

martinp876

Hallo Andre,

sollte eigentlich korrekt sein. Highlevel habe ich gerade eingebaut.
Jetzt sollte es gehen mit
set <name> regSet cyclicInfoMsg on

sowie die üblichen Kommandos wie get regList....

Lass hören ob es funktioniert. gib mir noch 2h zum einlagern...

Welchen Subtype meldet das Device eigentlich?

Gruss
Martin


Andre

Hallo Martin,

super Sache, ich teste sobald es live ist. Das Teil meldet als subType threeStateSensor, hier der list Auszug falls Du noch mehr damit anfangen kannst:

Internals:
   DEF        1CFF23
   IODev      myCUL
   LASTIODev  myCUL
   MSGCNT     2
   NAME       eg_FensterTerasse
   NR         93
   STATE      closed
   TYPE       CUL_HM
   lastMsg    No:FF - t:41 s:1CFF23 d:F11034 01F000
   myCUL_MSGCNT 2
   myCUL_RAWMSG A0CFFA4411CFF23F1103401F000F8
   myCUL_RSSI -78
   myCUL_TIME 2013-01-12 13:11:10
   protLastRcv 2013-01-12 13:11:10
   Readings:
     2013-01-05 22:55:09   CommandAccepted no
     2013-01-05 22:48:16   PairedTo        0xF11034
     2013-01-05 22:48:16   RegL_00:        02:01 09:00 0A:F1 0B:10 0C:34 10:01 14:06 00:00
     2013-01-05 22:48:17   RegL_01:        08:00 20:60 21:00 22:64 30:06 00:00
     2013-01-06 00:27:32   alive           yes
     2013-01-06 00:27:32   battery         ok
     2013-01-12 13:11:10   contact         closed (to myCUL)
     2013-01-06 00:27:32   cover           closed
     2013-01-05 22:55:14   peerList        0
     2013-01-12 13:11:10   state           closed
   Helper:
     mId        002F
     rxType     12
     Respwait:
Attributes:
   actCycle   028:00
   actStatus  alive
   devInfo    810101
   firmware   2.0
   fm_fav     2
   fm_name    Fenster%20Terrasse
   fm_order   4
   fm_type    none
   fp_Erdgeschoss 50,100,2,Terassenfenster
   group      Fenster
   hmClass    sender
   model      HM-SEC-SC
   peerIDs    1
   room       Erdgeschoss
   serialNr   JEQ0249260
   subType    threeStateSensor

Register 14 in RegL_00 ist übrigens die maximale Anzahl an Übertragungsversuchen (TRANSMIT_DEV_TRY_MAX), vielleicht magst Du das auch noch high level einbauen. Kann Werte zwischen 1 und 10 (A) annehmen, default ist 6.

Gruß,
André

martinp876

Zitat von: Andre schrieb am Sa, 12 Januar 2013 19:01Hallo Martin,


Register 14 in RegL_00 ist übrigens die maximale Anzahl an Übertragungsversuchen (TRANSMIT_DEV_TRY_MAX), vielleicht magst Du das auch noch high level einbauen. Kann Werte zwischen 1 und 10 (A) annehmen, default ist 6.


sollte schon drin sein - seit heute. und ein paar mehr.
waere gut, wenn du einmal testest

Gruss
Martin

Andre

Hallo Martin,

habe die Updates getestet, funktioniert alles wie gewünscht. Vielen Dank dafür!

Ein paar Kleinigkeiten hätte ich noch:

- Was ist der Unterschied zwischen TRANSMIT_TRY_MAX und TRANSMIT_DEV_TRY_MAX? Die eine Einstellung ist in Reg00 und die andere in Reg01. Du hast die in Reg01 implementiert, das funktioniert auch soweit. Wäre für mich interessant zu verstehen.

- Magst Du EVENT_DELAYTIME noch high level einbauen? (list 1, index 33, min 0, max 7620, unit s, float, default 0.0)

- Generell bekomme ich es nicht hin ein register mittels regBulk zu setzen. Beispiel war ja die cyclicInfoMsg. Versucht habe ich es mit "set eg_FensterGarage regBulk 00 09:00", es kommt dann auch die meldung set_on als state aber nach dem Betätigen der Anlerntaste und getConfig ist der Status wieder wie vorher. Mache ich etwas falsch oder gibt es da einen kleinen Bug?

- Einer noch OT, was macht eigentlich "peerNeedsBurst"?

Gruß,
André

martinp876

- Was ist der Unterschied zwischen TRANSMIT_TRY_MAX und TRANSMIT_DEV_TRY_MAX?

dev ist das device und auch dort einzustellen, der andere am Channel. Somit kann man die retransmit-rate für jeden Kanal (und dessen messages) sowie das device getrennt einstellen.

- Magst Du EVENT_DELAYTIME noch high level einbauen?
done - bitte werte prüfen, ob die Berechnung des Float stimmt

- Generell bekomme ich es nicht hin ein register mittels regBulk zu setzen.Mache ich etwas falsch oder gibt es da einen kleinen Bug?
ich hatte es getestet - aber nicht mit einzelnen Werten. Muss ich noch einmal. Mal sehen

- Einer noch OT, was macht eigentlich "peerNeedsBurst"?
das kann man bei remotes einstellen - pro kanal/peer. Damit beauftragt man die remote beim trigger dieflags entsprechend dem "burst mode" zu setzen. Also wenn der peer (aktor-channel) burst braucht muss man es in diesem link (channel->peer) setzen, sonst nicht.
Ich hoffe es kam an ;-)

Gruss
Martin

Andre

Hallo,

überschneiden sich diese beiden Register Definitionen oder ist das so gewollt / notwendig:

-  eventDlyTime    =>{a=> 33  ,s=>1  ,l=>1,min=>0  ,max=>7620    ,c=>'fltCvT'   ,f=>''     ,u=>'s'   ,d=>1,t=>"event delay time"},
-  evtDly          =>{a=> 33  ,s=>1  ,l=>1,min=>0  ,max=>7620    ,c=>'factor'   ,f=>1.6    ,u=>'s'   ,d=>0,t=>"Event delay time",}, #todo check calculation

?

Gruß,
André

Samsi

@Martin

danke für Deine Erklärung, aber ich habe das mit den Bursts noch nicht verstanden. Aus welchem Grund gibt es Aktoren die einen 'Burst' benötigen? Weist Du was da passiert?
FHEM 5.5 / BBB Debian Wheezy

Homematic CFG-LAN

HM-Sec-MDIR / HM-Sec-SD / HM-Sec-WDS / HM-LC-Sw2-FM / HM-Sec-SC / HM-LC-Sw1PBU-FM / HM-SCI-3-FM / HM-Sec-Key / HM-RC-Key3-B / HM-LC-Dim1TPBU-FM /  HM-CC-RT-DN / HM-PBI-4-FM / HM-RC-Key4-2 / HM-ES-PMSw1-Pl / HM-LC-Sw4-WM

martinp876

Zitat von: Samsi schrieb am Mo, 14 Januar 2013 17:13@Martin

danke für Deine Erklärung, aber ich habe das mit den Bursts noch nicht verstanden. Aus welchem Grund gibt es Aktoren die einen 'Burst' benötigen? Weist Du was da passiert?

nicht wirklich. Es hat auf jeden fall etwas mit Batterie-sparen zu tun. Es ist wohl fuer die Gruppe devices, die a) Batterie haben und b) sich nicht zyklisch melden(die benutzen 'wakeup mode' und c) es notwendig ist, mit ihnen zu kommunizieren.
Eine RC12 ohne display ist ein reiner Sender - also nur 'config'
eine RC19 hat ein display. Muss also kommandos aus der Zentral empfangen koennen => 'config' und 'burst' werden unterstuetzt
ein TC muss sowieso regelmaessig mit einem VD sprechen => 'wakeup mode'

230V devices sind in der regel immer ansprechbar - der mode hat keinen Namen.

Der Begriff burst suggeriert eine Blockabfertigung. Gesehen habe ich hier keine Auswirkungen.

Gruss
Martin

Dirk

Hi,

das hat tatsächlich mit dem Batterieverbrauch zu tun.
Die meiste Zeit ist der Controller der Gertäte im "Tiefschlaf" so dass nur wenige µA Stromverbrauch fließen.
Der Empfänger-Chip (der CC1101) befindet sich auch  im "Schlaf" und in einem so genanntem "Wake On Radio" modus. Auch um möglichst wenig Energie zu verbrauchen. Aus diesem Modus kann der Empfänger aber nur durch eben diese Burst-Packete geweckt werden.

Den Burst brauchen also nur Batteriebetriebene Aktoren welche besonders Energiesparend arbeiten, und soffort auf Funkbefehle regieren sollen. Also z.B. HM-LC-Sw1-BA-PCB, KeyMatic und vermutlich auch WinMatic.

Die Heizungsthermostate und die Ventilstellantriebe brauchen das nicht, weil diese von sich aus alle x sek. kommunizieren und eben nicht bei einer Änderung soffort reagieren.

gruß
Dirk

martinp876

Hallo Dirk,

macht Sinn.
Weisst du, ob die CUL das unterstuetzt?
Gruss
Martin

Dirk

Hi Martin,

laut letzter Information ist das bei CUL nicht imlementiert.
HM-Lan senden den Burst auch selber, also transparent.

Zuletzt hatten wir das hier mal.

Gruß
Dirk

martinp876

Danke,

dann heist dies vorlaeufig, dass alle Burst devices nicht von einer CUL unterstuetzt werden. Dies gilt auch fuer AES kommunikation habe ich verstanden.
Ich sehe immer wieder Fragen "cul versus hmlan" - man sollte dies den Usern sagen, ist ein wichtiger Punkt.

Gruss
Martin

Dirk

Das ist Korrekt,

allerdings kenne ich derzeit nur HM-LC-Sw1-BA-PCB und KeyMatic die das ganz sicher Nutzen.
KeyMatic und vermutlich auch WinMatic erzwingen sowieso AES, daher geht das hier nicht ohne HM-Lan.

Somit bleibt als Vorteil "nur" HM-LC-Sw1-BA-PCB übrig.

Ich dachte ich hatte schon mal im Wiki erwähnt, finde es aber nicht mehr. Man könnte ja mal eine Matrix machen mit den technischen Daten, Vor- und Nachteilen der einzelnen Geräte.

martinp876

Hallo Dirk,

Die Liste der devices ist
HM-Sec-Key        
HM-Sec-Key-S      
HM-Sec-Key-O      
HM-Sec-Key-Generic
HM-LC-Sw1-Ba-PCB
HM-Sec-Win
HM-Sec-SD        
HM-Sec-SD-Generic
HM-Dis-TD-T

nach stand XML
Also weitgehend korrekt deine Aussage

Gruss
Maritn