HM-Sec-SCo Tür-Fensterkontakt, optisch: Unterschied zwischen den Versionen
MGu (Diskussion | Beiträge) K (→Betrieb mit FHEM: Bei den Event-Ausgaben verdeckt die Randnotiz Teile der Ausgabe.) |
K (Schreibweise "HomeMatic") |
||
| (28 dazwischenliegende Versionen von 10 Benutzern werden nicht angezeigt) | |||
| Zeile 14: | Zeile 14: | ||
|HWManufacturer=ELV / eQ-3 | |HWManufacturer=ELV / eQ-3 | ||
}} | }} | ||
== Features == | == Features == | ||
[[HomeMatic]] Funk-Tür-/Fensterkontakt zur optischen Erkennung von Tür- bzw. Fensteröffnungen oder -schließungen, z.B. zur Sicherheit oder um automatisch, bei vorhandenem [[HM-CC-RT-DN]], die Heizung herunter zu regeln, sobald ein Fenster oder eine Tür geöffnet wird. | [[HomeMatic]] Funk-Tür-/Fensterkontakt zur optischen Erkennung von Tür- bzw. Fensteröffnungen oder -schließungen, z.B. zur Sicherheit oder um automatisch, bei vorhandenem [[HM-CC-RT-DN]], die Heizung herunter zu regeln, sobald ein Fenster oder eine Tür geöffnet wird. | ||
== | == HM-SEC-SC und HM-SEC-SCo == | ||
Das meiste zum [[HM-SEC-SC Tür-Fensterkontakt|HM-SEC-SC]] Beschriebene zur Nutzung gilt auch für den HM-Sec-SCo. | Das meiste zum [[HM-SEC-SC Tür-Fensterkontakt|HM-SEC-SC]] Beschriebene zur Nutzung gilt auch für den HM-Sec-SCo. | ||
| Zeile 24: | Zeile 23: | ||
Mindestens bei Benutzung mit einem CUL (vermutlich auch via HM-CFG-USB und HM-CFG-LAN) muss FHEM auf das Perl-Modul Crypt::Rijndael zugreifen können. Wenn es nicht zur Verfügung steht, bleibt das Pairing unvollständig. Siehe auch [[AES_Encryption#IO <-> Gerät|den Abschnitt über AES-Encryption zwischen IO-Device und Gerät]]. | Mindestens bei Benutzung mit einem CUL (vermutlich auch via HM-CFG-USB und HM-CFG-LAN) muss FHEM auf das Perl-Modul Crypt::Rijndael zugreifen können. Wenn es nicht zur Verfügung steht, bleibt das Pairing unvollständig. Siehe auch [[AES_Encryption#IO <-> Gerät|den Abschnitt über AES-Encryption zwischen IO-Device und Gerät]]. | ||
== Aufbau == | |||
Das Gerät ist sowohl nutzungsbereit (ca. € 30) als auch als Bausatz (ca. € 20) verfügbar, letzterer muss selbst gelötet werden. Die Arbeitszeit sollte für erfahrende Personen unter 15 Minuten liegen. | |||
[[Datei:Ansicht1.jpg|200px|thumb|left|Bestückung beider Platinen]] | |||
[[Datei:Ansicht2.png|200px|thumb|right|Bestückung beider Platinen aus anderer Perspektive]] | |||
Es sind nur | |||
* das Funkmodul mit einer 8-poligen Stiftleiste | |||
* der Batteriekontakt (Minuspol) mit einem kurzen Drahtstück | |||
[[Datei:HM-Sec-SCo_Basisplatine.jpg|mini|250px|Markiert: Antennendurchführung (1), Batterieanschluss (2), sehr schmaler Platinensteg (3)]] | |||
an der Basisplatine anzulöten. | |||
Beim Zusammenbau muss darauf geachtet werden, dass immer das '''zugehörige''' Funkmodul mit der Basisplatine aus der Verpackung zusammen gelötet werden! | |||
Jede Platine für sich enthält die eindeutige ID. Aber nur auf dem Funkmodul ist diese erkennbar. Wenn die Module beim Zusammenbau vermischt werden, sendet das Gerät die Open/Close-Meldungen mit der ID des Funkmoduls. Die Sabotage- und vermutlich Batterie-Meldungen werden mit der ID der Basisplatine gesendet! | |||
Zu beachten ist noch, dass die Antenne '''vor''' dem Auflöten des Funkmoduls durch das markierte Loch der Basisplatine geführt werden muss. | |||
Die fertig montierte Platine muss sich leicht in das Gehäuse einsetzen lassen, anderenfalls wird der schmale Platinensteg u.U. zu stark belastet und kann brechen! | |||
== Betrieb mit FHEM == | == Betrieb mit FHEM == | ||
=== Event-Monitor === | === Event-Monitor === | ||
Wird z. B. das Fenster geöffnet, | Wird z. B. das Fenster geöffnet, übermittelt das Gerät folgendes: | ||
<pre> | <pre> | ||
2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG trigger_cnt: 11 | 2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG trigger_cnt: 11 | ||
| Zeile 36: | Zeile 53: | ||
</pre> | </pre> | ||
Beim Schließen | Beim Schließen: | ||
<pre> | <pre> | ||
2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG trigger_cnt: 12 | 2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG trigger_cnt: 12 | ||
| Zeile 46: | Zeile 63: | ||
=== Konfiguration === | === Konfiguration === | ||
Bei eingeschaltetem [[autocreate]] werden die erforderlichen Definitionen beim Pairen selbstständig erstellt. | Bei eingeschaltetem [[autocreate]] werden die erforderlichen Definitionen beim Pairen selbstständig erstellt. | ||
| Zeile 73: | Zeile 79: | ||
attr HM_Fensterstatus_BadEG subType threeStateSensor | attr HM_Fensterstatus_BadEG subType threeStateSensor | ||
</pre> | </pre> | ||
=== Peering === | |||
Peering wie im Artikel [[HomeMatic Peering Beispiele]] beschrieben durchführen. Ein Beispiel könnte wie folgt aussehen: | |||
:<code>set HM_Fensterstatus_BadEG peerChan 0 HM_Heizung_Bad_WindowRec single</code> | |||
Eine Besonderheit bei den Sensoren ist, dass nach dem Ausführen dieses Befehls die Taste auf dem Sensor gedrückt werden muss. Manchmal auch mehrfach nacheinander, da in der kurzen aktiven Zeit nicht alle Befehle empfangen/gesendet werden können. Fertig ist der Sensor sobald die ''peerList'' korrekt gefüllt ist und keine Befehle mehr in der Warteschlange hängen (''protState'' ''= CMDs_done''). | |||
== Beispiele == | == Beispiele == | ||
=== Aktionen durchführen, wenn Fenster zu lange geöffnet ist === | === Aktionen durchführen, wenn Fenster zu lange geöffnet ist === | ||
Mit der nachfolgenden [[DOIF]]-Definition wird ein [[FileLog|Log]]-Eintrag erzeugt | ==== DOIF-Variante ==== | ||
Mit der nachfolgenden [[DOIF]]-Definition wird ein [[FileLog|Log]]-Eintrag erzeugt. Eine Meldung auf der [[Enigma2 Receiver (Dreambox, VUplus etc.) steuern|Dreambox]] angezeigt, falls diese angeschaltet ist, und eine Nachricht per Prowl (funktioniert vermutlich nur unter Linux) verschickt. | |||
Der Code ist hier so angegeben, wie er in der Weboberfläche nach einem Klick auf das [[Konfiguration|DEF-Feld]] übernommen werden kann. Das DOIF ist vorab zu definieren, zum Beispiel mit: | Der Code ist hier so angegeben, wie er in der Weboberfläche nach einem Klick auf das [[Konfiguration|DEF-Feld]] übernommen werden kann. Das DOIF ist vorab zu definieren, zum Beispiel mit: | ||
:<code>def DOIF_FensterOffenMsg DOIF ([HM_Fensterstatus_BadEG])</code> | :<code>def DOIF_FensterOffenMsg DOIF ([HM_Fensterstatus_BadEG])</code> | ||
und kann dann anschließend in den Device-Details vervollständigt werden: | und kann dann anschließend in den Device-Details vervollständigt werden: | ||
< | <syntaxhighlight lang="perl"> | ||
([HM_Fensterstatus_BadEG] eq "open") ({ | ([HM_Fensterstatus_BadEG] eq "open") ({ | ||
Log 1, "Fenster seit mehr als 2 Stunden (7200 Sekunden) offen";; | Log 1, "Fenster seit mehr als 2 Stunden (7200 Sekunden) offen";; | ||
| Zeile 88: | Zeile 100: | ||
}) | }) | ||
DOELSE | DOELSE | ||
</ | </syntaxhighlight> | ||
Damit der Code-Block erst nach 7200 Sekunden getriggert wird, ist noch Folgendes auszuführen: | Damit der Code-Block erst nach 7200 Sekunden getriggert wird, ist noch Folgendes auszuführen: | ||
:<code>attr DOIF_FensterOffenMsg wait 7200:0</code> | |||
:<code> | ==== Watchdog-Variante ==== | ||
Alternativ zu der DOIF-Lösung gibt es eine einfache Lösung mit [[Watchdog]]. Dazu legt ihr einen Watchdog an: | |||
:<code>define watchdogBadEG watchdog HM_Fenster_BadEG:open 00:15 HM_Fenster_BadEG:closed set myTelegram message Das Fenster ist seit 15 min offen!</code> | |||
Der Watchdog besagt, dass er beim Status "open" des Gerätes/Devices "HM_Fenster_BadEG" (also dem Fenstersensor) aktiviert wird. Nach 15 Minuten schickt er eine Nachricht über [[Telegram]], es sei denn, es kommt zwischenzeitlich der Status "closed". | |||
=== Anzeige des Zeitpunkts der letzten Öffnung im STATE === | === Anzeige des Zeitpunkts der letzten Öffnung im STATE === | ||
Das Reading ''contact'' beinhaltet die Zustände ''open'' und ''closed'' | Das Reading ''contact'' beinhaltet die Zustände ''open'' und ''closed'' und der Zeitstempel der Änderung wird regelmäßig aktualisiert. Aus diesem Grund fällt die Nutzung des Attributs ''showtime'' hier weg. Wenigstens, wenn man nicht den Zeitpunkt des letzten Auslesens wissen will, sondern den der letzten Öffnung. | ||
Folgende Schreibweise ermöglicht es, dass im STATE-Internal der Zeitpunkt des letzten ''open'' verbleibt (zum Übernehmen als | Folgende Schreibweise ermöglicht es, dass im STATE-Internal der Zeitpunkt des letzten ''open'' verbleibt (zum Übernehmen als Einzeiler kopieren): | ||
:<code><nowiki>attr Sensor stateFormat {if (ReadingsVal(" | :<code><nowiki>attr Sensor stateFormat {if (ReadingsVal("HM_Fensterstatus_BadEG","contact","") =~ "open.*") {"open " . ReadingsTimestamp("HM_Fensterstatus_BadEG","contact","")} else {InternalVal("HM_Fensterstatus_BadEG","STATE","")}}</nowiki></code> | ||
Ein Thread zu diesem Thema findet sich im Forum unter dem Titel {{Link2Forum|Topic=41347|LinkText=HM-SEC-SCo: Letzte Türöffnung im State anzeigen}}. | Ein Thread zu diesem Thema findet sich im Forum unter dem Titel {{Link2Forum|Topic=41347|LinkText=HM-SEC-SCo: Letzte Türöffnung im State anzeigen}}. | ||
== Bekannte Probleme == | == Bekannte Probleme == | ||
Teilweise (siehe Diskussion im {{Link2Forum|Topic=33264|LinkText=Forum}}) werden die Fensterkontakte regelmäßig wiederkehrend als "dead" angezeigt. Grund ist, dass beim Anlernen ein actCycle von 50 Minuten eingetragen wird, während die Kontakte auch gerne mal länger brauchen, um sich bei der Zentrale zu melden. | * Es kann vorkommen, dass der HM-Sec-SCo nach Aufsetzen der Abdeckung anscheinend nicht funktioniert.<br> | ||
<pre style="width: | : Unter dem Titel {{Link2Forum|Topic=37508|LinkText="HM-Sec-SCo mit Abdeckung keine Funktion"}} wurde berichtet, dass von EQ3/ELV reparierte Geräte modifiziert zurückkamen. | ||
: Die Reparatur bestand darin, dass um den Foto-Sensor eine Abdeckung gelegt wurde. | |||
: Dieses Problem gibt es 2019 weiterhin. | |||
* Bei (direkter) Sonneneinstrahlung kann es zu Fehlfunktionen kommen, die sich in schnell wechselnden Statusänderungen äußern. | |||
: Teilweise (siehe Diskussion im {{Link2Forum|Topic=33264|LinkText=Forum}}) werden die Fensterkontakte regelmäßig wiederkehrend als "dead" angezeigt. | |||
: Grund ist, dass beim Anlernen ein actCycle von 50 Minuten eingetragen wird, während die Kontakte auch gerne mal länger brauchen, um sich bei der Zentrale zu melden. | |||
<pre style="width:505px;"> | |||
2015-01-31_17:57:39 Fstr_AusgTerrasse alive: yes | 2015-01-31_17:57:39 Fstr_AusgTerrasse alive: yes | ||
2015-01-31_17:57:39 Fstr_AusgTerrasse battery: ok | 2015-01-31_17:57:39 Fstr_AusgTerrasse battery: ok | ||
| Zeile 118: | Zeile 140: | ||
2015-01-31_19:04:09 Fstr_AusgTerrasse Activity: alive | 2015-01-31_19:04:09 Fstr_AusgTerrasse Activity: alive | ||
</pre> | </pre> | ||
: Um Abhilfe zu schaffen, den actCycle auf 01:05 setzen: | |||
Um Abhilfe zu schaffen, den actCycle auf 01:05 setzen: | :: <code>attr <HM-SEC-SCo> actCycle 001:05</code> | ||
:<code>attr <HM-SEC-SCo> actCycle 001:05</code> | : Save config nicht vergessen. | ||
Save config nicht vergessen. | |||
== Links == | == Links == | ||
* Anleitung [http://www.eq-3.de/Downloads/eq3/ | * Anleitung [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-Sec-SCo_UM_GE_eQ-3_web.pdf PDF] | ||
* Datenblatt [http://www.eq-3.de/ | * Datenblatt [http://www.eq-3.de/service/downloads.html?id=235&download=produkt&pid=1947 PDF] (der direkte Link auf das PDF klappt nicht, vermutlich wegen der Codierung des Umlautes :-( ) | ||
[[Kategorie:HomeMatic Components]] | [[Kategorie:HomeMatic Components]] | ||
[[Kategorie:Kontaktsensor (optisch)]] | [[Kategorie:Kontaktsensor (optisch)]] | ||
Aktuelle Version vom 3. Dezember 2021, 12:50 Uhr
| HM-Sec-SCo Tür-Fensterkontakt, optisch | |
|---|---|
| Allgemein | |
| Protokoll | HomeMatic |
| Typ | Sensor |
| Kategorie | HomeMatic |
| Technische Details | |
| Kommunikation | 868MHz |
| Kanäle | 1 |
| Betriebsspannung | 1,5 V DC |
| Leistungsaufnahme | max. 100 mA |
| Versorgung | Batterie (1x 1,5V LR03/Micro/AAA) |
| Abmessungen | 15x100x18mm |
| Sonstiges | |
| Modulname | CUL_HM |
| Hersteller | ELV / eQ-3 |
Features
HomeMatic Funk-Tür-/Fensterkontakt zur optischen Erkennung von Tür- bzw. Fensteröffnungen oder -schließungen, z.B. zur Sicherheit oder um automatisch, bei vorhandenem HM-CC-RT-DN, die Heizung herunter zu regeln, sobald ein Fenster oder eine Tür geöffnet wird.
HM-SEC-SC und HM-SEC-SCo
Das meiste zum HM-SEC-SC Beschriebene zur Nutzung gilt auch für den HM-Sec-SCo.
Wird mit aktiviertem AES ausgeliefert und kann nur mit Gateways, die AES unterstützen, gepaired werden (HM-LAN-CFG, HM-USB-CFG und CUL (seit Juli 2015)).
Mindestens bei Benutzung mit einem CUL (vermutlich auch via HM-CFG-USB und HM-CFG-LAN) muss FHEM auf das Perl-Modul Crypt::Rijndael zugreifen können. Wenn es nicht zur Verfügung steht, bleibt das Pairing unvollständig. Siehe auch den Abschnitt über AES-Encryption zwischen IO-Device und Gerät.
Aufbau
Das Gerät ist sowohl nutzungsbereit (ca. € 30) als auch als Bausatz (ca. € 20) verfügbar, letzterer muss selbst gelötet werden. Die Arbeitszeit sollte für erfahrende Personen unter 15 Minuten liegen.
Es sind nur
- das Funkmodul mit einer 8-poligen Stiftleiste
- der Batteriekontakt (Minuspol) mit einem kurzen Drahtstück
an der Basisplatine anzulöten.
Beim Zusammenbau muss darauf geachtet werden, dass immer das zugehörige Funkmodul mit der Basisplatine aus der Verpackung zusammen gelötet werden! Jede Platine für sich enthält die eindeutige ID. Aber nur auf dem Funkmodul ist diese erkennbar. Wenn die Module beim Zusammenbau vermischt werden, sendet das Gerät die Open/Close-Meldungen mit der ID des Funkmoduls. Die Sabotage- und vermutlich Batterie-Meldungen werden mit der ID der Basisplatine gesendet!
Zu beachten ist noch, dass die Antenne vor dem Auflöten des Funkmoduls durch das markierte Loch der Basisplatine geführt werden muss.
Die fertig montierte Platine muss sich leicht in das Gehäuse einsetzen lassen, anderenfalls wird der schmale Platinensteg u.U. zu stark belastet und kann brechen!
Betrieb mit FHEM
Event-Monitor
Wird z. B. das Fenster geöffnet, übermittelt das Gerät folgendes:
2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG trigger_cnt: 11 2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG trigDst_2573FB: noConfig 2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG battery: ok 2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG open 2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG contact: open (to MyHMLAN)
Beim Schließen:
2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG trigger_cnt: 12 2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG trigDst_2573FB: noConfig 2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG battery: ok 2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG closed 2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG contact: closed (to MyHMLAN)
Konfiguration
Bei eingeschaltetem autocreate werden die erforderlichen Definitionen beim Pairen selbstständig erstellt.
define HM_Fensterstatus_BadEG CUL_HM 35E390 attr HM_Fensterstatus_BadEG IODev MyHMLAN attr HM_Fensterstatus_BadEG actCycle 000:50 attr HM_Fensterstatus_BadEG actStatus dead attr HM_Fensterstatus_BadEG autoReadReg 4_reqStatus attr HM_Fensterstatus_BadEG expert 2_full attr HM_Fensterstatus_BadEG firmware 1.0 attr HM_Fensterstatus_BadEG model HM-SEC-SCo attr HM_Fensterstatus_BadEG peerIDs 00000000, attr HM_Fensterstatus_BadEG room CUL_HM attr HM_Fensterstatus_BadEG serialNr LEQxxxxxxx attr HM_Fensterstatus_BadEG subType threeStateSensor
Peering
Peering wie im Artikel HomeMatic Peering Beispiele beschrieben durchführen. Ein Beispiel könnte wie folgt aussehen:
set HM_Fensterstatus_BadEG peerChan 0 HM_Heizung_Bad_WindowRec single
Eine Besonderheit bei den Sensoren ist, dass nach dem Ausführen dieses Befehls die Taste auf dem Sensor gedrückt werden muss. Manchmal auch mehrfach nacheinander, da in der kurzen aktiven Zeit nicht alle Befehle empfangen/gesendet werden können. Fertig ist der Sensor sobald die peerList korrekt gefüllt ist und keine Befehle mehr in der Warteschlange hängen (protState = CMDs_done).
Beispiele
Aktionen durchführen, wenn Fenster zu lange geöffnet ist
DOIF-Variante
Mit der nachfolgenden DOIF-Definition wird ein Log-Eintrag erzeugt. Eine Meldung auf der Dreambox angezeigt, falls diese angeschaltet ist, und eine Nachricht per Prowl (funktioniert vermutlich nur unter Linux) verschickt.
Der Code ist hier so angegeben, wie er in der Weboberfläche nach einem Klick auf das DEF-Feld übernommen werden kann. Das DOIF ist vorab zu definieren, zum Beispiel mit:
def DOIF_FensterOffenMsg DOIF ([HM_Fensterstatus_BadEG])
und kann dann anschließend in den Device-Details vervollständigt werden:
([HM_Fensterstatus_BadEG] eq "open") ({
Log 1, "Fenster seit mehr als 2 Stunden (7200 Sekunden) offen";;
system( "/path/to/prowl.pl -apikeyfile=/path/to/prowl-apikey -event=Info -notification='Fenster ist noch offen' &" );;
fhem( "set E2_Dreambox showText Fenster ist noch offen" ) if ReadingsVal("E2_Dreambox","state","") eq "on";;
})
DOELSE
Damit der Code-Block erst nach 7200 Sekunden getriggert wird, ist noch Folgendes auszuführen:
attr DOIF_FensterOffenMsg wait 7200:0
Watchdog-Variante
Alternativ zu der DOIF-Lösung gibt es eine einfache Lösung mit Watchdog. Dazu legt ihr einen Watchdog an:
define watchdogBadEG watchdog HM_Fenster_BadEG:open 00:15 HM_Fenster_BadEG:closed set myTelegram message Das Fenster ist seit 15 min offen!
Der Watchdog besagt, dass er beim Status "open" des Gerätes/Devices "HM_Fenster_BadEG" (also dem Fenstersensor) aktiviert wird. Nach 15 Minuten schickt er eine Nachricht über Telegram, es sei denn, es kommt zwischenzeitlich der Status "closed".
Anzeige des Zeitpunkts der letzten Öffnung im STATE
Das Reading contact beinhaltet die Zustände open und closed und der Zeitstempel der Änderung wird regelmäßig aktualisiert. Aus diesem Grund fällt die Nutzung des Attributs showtime hier weg. Wenigstens, wenn man nicht den Zeitpunkt des letzten Auslesens wissen will, sondern den der letzten Öffnung.
Folgende Schreibweise ermöglicht es, dass im STATE-Internal der Zeitpunkt des letzten open verbleibt (zum Übernehmen als Einzeiler kopieren):
attr Sensor stateFormat {if (ReadingsVal("HM_Fensterstatus_BadEG","contact","") =~ "open.*") {"open " . ReadingsTimestamp("HM_Fensterstatus_BadEG","contact","")} else {InternalVal("HM_Fensterstatus_BadEG","STATE","")}}
Ein Thread zu diesem Thema findet sich im Forum unter dem Titel HM-SEC-SCo: Letzte Türöffnung im State anzeigen.
Bekannte Probleme
- Es kann vorkommen, dass der HM-Sec-SCo nach Aufsetzen der Abdeckung anscheinend nicht funktioniert.
- Unter dem Titel "HM-Sec-SCo mit Abdeckung keine Funktion" wurde berichtet, dass von EQ3/ELV reparierte Geräte modifiziert zurückkamen.
- Die Reparatur bestand darin, dass um den Foto-Sensor eine Abdeckung gelegt wurde.
- Dieses Problem gibt es 2019 weiterhin.
- Bei (direkter) Sonneneinstrahlung kann es zu Fehlfunktionen kommen, die sich in schnell wechselnden Statusänderungen äußern.
- Teilweise (siehe Diskussion im Forum) werden die Fensterkontakte regelmäßig wiederkehrend als "dead" angezeigt.
- Grund ist, dass beim Anlernen ein actCycle von 50 Minuten eingetragen wird, während die Kontakte auch gerne mal länger brauchen, um sich bei der Zentrale zu melden.
2015-01-31_17:57:39 Fstr_AusgTerrasse alive: yes 2015-01-31_17:57:39 Fstr_AusgTerrasse battery: ok 2015-01-31_17:57:39 Fstr_AusgTerrasse sabotageError: off 2015-01-31_17:57:39 Fstr_AusgTerrasse closed 2015-01-31_17:57:39 Fstr_AusgTerrasse contact: closed (to HMLAN1) 2015-01-31_18:54:09 Fstr_AusgTerrasse Activity: dead 2015-01-31_18:58:03 Fstr_AusgTerrasse alive: yes 2015-01-31_18:58:03 Fstr_AusgTerrasse battery: ok 2015-01-31_18:58:03 Fstr_AusgTerrasse sabotageError: off 2015-01-31_18:58:03 Fstr_AusgTerrasse closed 2015-01-31_18:58:03 Fstr_AusgTerrasse contact: closed (to HMUSB) 2015-01-31_19:04:09 Fstr_AusgTerrasse Activity: alive
- Um Abhilfe zu schaffen, den actCycle auf 01:05 setzen:
attr <HM-SEC-SCo> actCycle 001:05
- Save config nicht vergessen.