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

kossmann

Hallo Martin,

gibt es für die HM-Sec-RHS Fenstergriff-Sensoren schon Hoffnung auf eine Realisierung? Die Dinger scheinen den Batteriestatus nur beim Öffnen/Schließen des Batterierfachs zu übertragen - was grundsätzlich reicht (wenn bei einer Änderung (ok->low) auch etwas übertragen wird), aber es wäre schon schön, wenn man es trotzdem einstellen könnte.

martinp876

Hallo Kossmann,

ich arbeite nicht daran, burst in CUL zu implementieren (zeitmangel).
Dass der Batteriestatus nur 'mitgemeldet' wird macht m.E. sinn und ist (hoffentlich ;-) ) überall so. Das ist ja nicht wirklich ein event - dafür ist so eine Batterieüberwachung nicht so klar definiert - so meine Meinung jedenfalls.

Klarer ist da  der ActionDetector - leider erst bei Batterie 'off' ...

Gruss
Martin

kossmann

Hallo Martin,

den "Burst-Modus" habe ich in den letzten Tagen schon öfter gelesen - was ist das eigentlich? Ich finde leider nichts darüber.

Ich habe meine HM-Aktoren und -Sensoren am HMLAN, dieser unterstützt den Burst-Modus, wenn ich dich am Wochenende richtig verstanden habe. Ich weiß aber immer noch nicht, was dieser mit den Batterie-Meldungen zu tun haben soll.

Meine Rauchmelder melden ihren Batteriestatus mehr oder weniger alle 4 Tage (einer zickt noch etwas ´rum, das muss ich mir noch mal ansehen), der HM-Sec-RHS scheint hingegen grundsätzlich nichts zyklisch zu senden, obwohl dies laut Windows-Software so konfiguriert ist.

justme1968

hallo martin,

mir ist deine antwort nicht ganz klar. vor allem nicht was das mit dem burst mode zu tun hat.

schau mal ganz an den anfang dieses threads. da ging es darum für einen hm-sec-sc die zyklischen status meldungen zu aktivieren. und jetzt ist die frage ob das für einen hm-sec-rhs auch möglich ist. erst mal völlig unabhängig davon wie wir es schaffen die konfigurationsänderung auch zu übertragen. wenn das ohne burst mode nur möglich ist wenn die pairing taste gedrückt wird habe ich kein problem das zu machen.

das der batteriestatus nur mitgemeldet wird macht meiner meinung nach nicht unbedingt sinn. wenn ich ein fenster überwachen will das normalerweise zu ist bekomme ich auf diese weise ja nie eine meldung. und wenn dann nach 2 Jahren die batterie leer ist erst rech nicht mehr. da nütz dann auch der actiondetector nichts mehr.


gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

martinp876

Andre,

devices werden auf unterscheidliche weise 'aufgeweckt'. Manche sind immer wach, andere wachen zyklich auf und anderen werden durch einen 'burst' aufweckt. Wenn dies nicht klappt kann man nicht mit dem Deivce reden, nur mithören. Wenn man eine CUL hat kann man keine Nachrichten an 'burst-Devices' schicken. HMLAN kann das.

Manche devices schicken zylische Nachrichten zur Überwachung des alive-status, andere nicht. Dass man dies einstellen kann habe ich nicht gesehen.

Dass der Batterie-status gemeldet wird oder nicht ist geschmackssache. Ich denke es sollte in so vielen Messages wie möglich enthalten sein. Man kann bei vielen Devices den status Abfragen (statusRequest). Da ist meist die Batterie mit drin. Man kann einbauen, dass man zyklich einen status an dies device schickt... oder der Action detector....
Ist auch eine Sache des Batterieverbrauchs. Wenn man vor lauter nachschauen dann ständig die Batterein wechseln muss...

Generell sollte die meisten Batterie-devices zyklich nachrichten senden. Bei remotes ist dies wohl nicht so, auch nicht notwendig - m.E.

Gruss martin

kossmann

Zitat von: martinp876 schrieb am Di, 29 Januar 2013 15:15Manche sind immer wach, andere wachen zyklich auf und anderen werden durch einen 'burst' aufweckt. Wenn dies nicht klappt kann man nicht mit dem Deivce reden, nur mithören. Wenn man eine CUL hat kann man keine Nachrichten an 'burst-Devices' schicken. HMLAN kann das.
Wir reden von einem HMLAN an FHEM, richtig? Wenn ich davon ausgehen darf, das HM-Sec-RHS ein solcher "Burst-Sensor" ist, müsste ich ihn doch von FHEM aus (mit HMLAN) auslesen können. Ein set Wohnzimmer_Balkontuer getpair lässt sich zwar abfeuern, es bleibt jedoch als "protCmdPend - 1 CMDs_pending" in der ToDo-Liste.

Unterstützt der HM-Sec-RHS keinen "Burst-Mode", habe ich irgendwas falsch verstanden oder liegt hier ein anderes Problem vor?

martinp876

haben wir es schon. ein rhs kann config oder wakeup, kein burst.
Wenn kommands pending sind dann warten sie auf das gesendet werden - und das passiert nur bei config - warten auf Anlernen - und wakeup - warten auf das wakeup-signal.

beim RHS bin ich mir nicht sicher wie das wakeup aussieht. da gibt es unterschiede zwischen TC und VD - daher kann der rhs noch einmal anders sein.
Wenn du einmal loggst was der rhs so von sich gibt kann ich einmal probieren.
Loggen im rohformat also

attr global verbose 1
attr global mseclog 1
attr <hmlan> loglevel 1

und mir die HMID des rhs sagen. Einige zeit loggen - der rhs schickt evtl nur alle 88200sec eine nachricht - also einmal am Tag. Diese Nachricht waere gut.

kossmann

Ich habe die Loglevel mal hoch gedreht und wir warten, vielleicht kannst du hiermit aber schon etwas anfangen:

2013-01-28_20:13:39 Wohnzimmer_Balkontuer open
2013-01-28_20:13:39 Wohnzimmer_Balkontuer contact: open (to MyHMLAN)
2013-01-28_20:13:39 Wohnzimmer_Balkontuer RSSI: -80
2013-01-28_20:13:39 Wohnzimmer_Balkontuer RAWMSG: E1CC451,0000,1A2270C9,FF,FFB0,3BA4411CC451203317013AC8
2013-01-28_20:13:42 Wohnzimmer_Balkontuer alive: yes
2013-01-28_20:13:42 Wohnzimmer_Balkontuer battery: ok
2013-01-28_20:13:42 Wohnzimmer_Balkontuer cover: open
2013-01-28_20:13:42 Wohnzimmer_Balkontuer open
2013-01-28_20:13:42 Wohnzimmer_Balkontuer contact: open (to MyHMLAN)
2013-01-28_20:13:42 Wohnzimmer_Balkontuer RSSI: -80
2013-01-28_20:13:42 Wohnzimmer_Balkontuer RAWMSG: E1CC451,0000,1A227D56,FF,FFB0,3CA6101CC4512033170601C80E
2013-01-28_20:13:44 Wohnzimmer_Balkontuer alive: yes
2013-01-28_20:13:44 Wohnzimmer_Balkontuer battery: ok
2013-01-28_20:13:44 Wohnzimmer_Balkontuer cover: closed
2013-01-28_20:13:44 Wohnzimmer_Balkontuer open
2013-01-28_20:13:44 Wohnzimmer_Balkontuer contact: open (to MyHMLAN)
2013-01-28_20:13:44 Wohnzimmer_Balkontuer RSSI: -73
2013-01-28_20:13:44 Wohnzimmer_Balkontuer RAWMSG: E1CC451,0000,1A228621,FF,FFB7,3DA6101CC4512033170601C800
2013-01-28_20:13:45 Wohnzimmer_Balkontuer closed
2013-01-28_20:13:45 Wohnzimmer_Balkontuer contact: closed (to MyHMLAN)
2013-01-28_20:13:45 Wohnzimmer_Balkontuer RSSI: -76
2013-01-28_20:13:45 Wohnzimmer_Balkontuer RAWMSG: E1CC451,0000,1A228B2B,FF,FFB4,3EA4411CC451203317013B00

Um überhaupt eine Battery-Meldung zu erhalten, habe ich gestern den Deckel kurz abgenommen.