Rauchmelder werden nach Update als dead erkannt

Begonnen von repix, 15 November 2017, 16:13:50

Vorheriges Thema - Nächstes Thema

repix

Hallo @ all,

ich habe am Freitag Fhem per Webinterface geupdated. Es kamm danach zu dem Problem das alle Melder mit der Zeit als dead markiert wurden obwohl sie eine Statusmeldung übermittelt haben.
Auch ein Probealarm löste alle eingestellten Benachrichtigungen aus. Allerdings ist das halt ungeschickt wenn die Melder dauerhaft auf dead stehen dann weiß man ja nie wann sie wirklich mal
ausgefallen sind.
Ich bin zur Zeit erstmal wieder zurück zur alten Version um die Fehlermeldungen aus unserer Monitoringsoftware zu entfernen.

Die Melder sind HM-SEC-SD und HM-SEC-WDS-2.

Gibt es da eine Möglichkeit wie ich die Aktivity automatisiert abfragen kann das die Melder nicht dauernd auf dead gesetzt werden?


Otto123

Hi,

Du solltest das nach Homematic verschieben?
Du meinst HM-SEC-SD-2 ? WDS kenne ich nicht  :-[ oder ist das was neues?

Die SD melden sich regelmäßig von selbst (Reading Activity)

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

repix

Hallo Otto,

die WDS sind Wassermelder.

Das sie sich regelmäßig selbst melden weiß ich allerdings kommt da immer nur

battery: ok
level: 0
off

und alle paar mal dann auch die Aktivity.

Ich habe halt das Gefühl das wenn die Aktivity nicht mitgesendet wird das dann der Melder auf dead gesetzt wird.
Das war vorher nicht so.

Otto123

Was sagt denn Dein Rauchmelder Log?
Die senden ja bloß alle paar Tage - hier bei mir:
2017-10-23_20:49:36 RmAZ Activity: alive
2017-10-23_20:50:07 RmAZ battery: ok
2017-10-23_20:50:07 RmAZ level: 1
2017-10-23_20:50:07 RmAZ off
2017-10-26_10:32:36 RmAZ battery: ok
2017-10-26_10:32:36 RmAZ level: 1
2017-10-26_10:32:36 RmAZ off
2017-10-29_05:40:17 RmAZ battery: ok
2017-10-29_05:40:17 RmAZ level: 1
2017-10-29_05:40:17 RmAZ off
2017-10-29_09:29:35 RmAZ Activity: alive
2017-10-29_09:30:15 RmAZ battery: ok
2017-10-29_09:30:15 RmAZ level: 1
2017-10-29_09:30:15 RmAZ off
2017-10-31_18:42:02 RmAZ battery: ok
2017-10-31_18:42:02 RmAZ level: 1
2017-10-31_18:42:02 RmAZ off
2017-11-04_08:23:26 RmAZ battery: ok
2017-11-04_08:23:26 RmAZ level: 1
2017-11-04_08:23:26 RmAZ off
2017-11-06_12:24:06 RmAZ Activity: alive


Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

repix

Der sieht bei mir genauso aus wie bei dir.
Bis auf bei einem den ich testweise auf eine Stunde gestellt habe (um mal zu schauen wie lange die Batterien das mitmachen)

Und sobald der actcycle abgelaufen ist und keine Activity alive Meldung kam geht er bei mir auf dead

Otto123

Das dead / alive macht ja er Actiondetector (denke ich) damit müsste der bei Dir ein Problem haben?

Wie gesagt, verschieb das besser nach Homematic. Vielleicht hat dort jemand eine Idee.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

repix

alles klar
bleibt nur die Frage wie ich es verschiebe weil da hab ich keinen Plan wie

Otto123

Dein Beitrag :) scroll nach unten - ganz links Thema verschieben ...  ;D
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Pfriemler

Zitat von: repix am 15 November 2017, 17:16:29
Bis auf bei einem den ich testweise auf eine Stunde gestellt habe (um mal zu schauen wie lange die Batterien das mitmachen)

Wo und wie hast Du den Rauchmelder auf stündliches Melden gestellt?
Nicht verwechseln mit Attribut actCycle: Das gibt dem Actiondetector das Intervall vor, in dem sich die Geräte normalerweise melden, erst nach dieser Zeit wird ein Gerät als "dead" erkannt. Diese Einstellung ändert aber nichts am Verhalten des Gerätes selbst. Man muss vielmehr actCycle immer an das Gebaren des Gerätes anpassen. Vielleicht ist das auch beim WDS so.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

repix

ah ok dann liegt da wohl das Problem.

ich habe nämlich den actCycle auf 1 Stunde gestellt. ( das hat bisher immer funktioniert)
Dann muss ich den wohl wieder hochsetzen um die dead Meldung zu verhindern.
Oder gibt es da noch eine andere Möglichkeit das zu bewerkstelligen?
Denn die Eventuellen drei Tage Ausfall sind meinem Chef zu lange deswegen habe ich ja auch die actCycle Einstellung gemacht.

automatisierer

Wenn du einen kürzeren Intervall haben willst, kannst du höchstens per at ein statusRequest machen.

Dann kannst du den actCycle entsprechend runter stellen...

Allerdings könnte das die Batterielebenszeit des SD verkürzen...


repix

ok also das scheint allerdings nicht zu funktionieren.

Denn als der Melder als dead gemeldet wurde habe ich erst mal einen statusRequest gemacht der allerdings nur die Werte

2017-01-01_05:47:41 BM_EINS battery: ok
2017-01-01_05:47:41 BM_EINS level: 0
2017-01-01_05:47:41 BM_EINS off

zurück geliefert hat und der Melder stand dann immernoch auf dead.



automatisierer

#12
der ActionDetector prüft Zyklisch (alle 10 Minuten??), du kannst das Update auch Manuell anstoßen, mit:
set ActionDetector update

EDIT:

Der ActionDetector prüft zyklisch, ob sich ein Device seit der letzten Prüfung gemeldet hat und ob der Zeitstempel (also die vergangene Zeit seit der letzten Meldung) kleiner als actCycle ist.

Ist ein Device dead und sendet etwas, muss der ActionDetector also ersat wieder eine Prüfung machen.

repix


Otto123

Zitat von: repix am 16 November 2017, 08:55:03
Denn die Eventuellen drei Tage Ausfall sind meinem Chef zu lange deswegen
Wenn man zuviel weiß macht man sich eventuell zu viele falsche Gedanken  :-X ;)  :o ::)

Ein Rauchmelder fällt aus wegen der Batterie, die hält ein paar Jahre und ist dann nicht innerhalb von 3 Stunden "fort"
Ein Batteriefehler Alarm wird sofort abgesetzt! Und zwar ziemlich pissig  ;D

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

automatisierer

und falls man sicherheitsfanatiker ist kann man ja zwei SD's nebeneinander hängen

frank

ZitatactAutoTry actAutoTry 0_off,1_on
setting this option enables Action Detector to send a statusrequest in case of a device is going to be marked dead. The attribut may be useful in case a device is being checked that does not send messages regularely - e.g. an ordinary switch.
mit diesem attribut wird sogar ein automatischer statusrequest erzeugt.
mit diesem attribut, plus 1 stunde actCycle, sollte jede stunde ein statusrequest erfogen. dann aber, wie gesagt, neue batterien in reserve haben.

auch die updatezeit (10 min) lässt sich ändern:
ZitatactCycle actCycle <[hhh:mm]|off>
Supports 'alive' or better 'not alive' detection for devices. [hhh:mm] is the maximum silent time for the device. Upon no message received in this period an event will be raised "<device> is dead". If the device sends again another notification is posted "<device> is alive".
This actiondetect will be autocreated for each device with build in cyclic status report.
Controlling entity is a pseudo device "ActionDetector" with HMId "000000".
Due to performance considerations the report latency is set to 600sec (10min). It can be controlled by the attribute "actCycle" of "ActionDetector".
Once entered to the supervision the HM device has 2 attributes:

    actStatus: activity status of the device
    actCycle: detection period [hhh:mm]

The overall function can be viewed checking out the "ActionDetector" entity. The status of all entities is present in the READING section.
Note: This function can be enabled for devices with non-cyclic messages as well. It is up to the user to enter a reasonable cycletime.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

repix

hab jetzt mal n bissle rumprobiert.

wenn ich den actCycle auf 1:00 setze dann nimmt der actionDetector das als Wert.
Der Rauchmelder meldet sich aber irgendwie immer nur alle 1:10 ( sprich zu spät für den actionDetector)

wenn ich den actCycle auf 1:15 setze dann meldet sich der Rauchmelder nach 1:20

gibt es da ne Möglichkeit die unabhängig einzustellen?

automatisierer

Ich bin da bei dir, so richtig funktioniert das nicht.

1. Kann man die Update Zeit nicht verstellen.
So wie ich das aus der Commandref lese, soll man beim Device ActionDetector per Attribut "actCycle" die Update Zeit einstellen können. Das wird mit einer Fehlermeldung aller: actCycle ist nur für Devices und nicht für den ActionDetector zulässig" abgewiesen.

2. Das actAutoTry bleibt, wenn man es gesetzt hat, ohne erkennbare Wirkung. Der SD2 wird auf dead gesetzt, ohne das ein statusRequest gemacht wird.


Ich werde später mal noch ein bissl weiter Testen, aber für mich sieht das nach ein paar Bugs aus - Oder ich interpretiere die Commandref falsch.

automatisierer

also zu Punkt 1, würde ich behaupten, dass es diese Funktion nicht gibt. Also die Zeit vom Update-Zeit des ActionDetector ist nicht verstellbar.

zu Punkt 2, actAutoTry ist wirkungslos. Das Device geht immer wieder auf dead, es wird nicht automatisch ein statusRequest ausgelöst.

frank

actAutoTry funktioniert bei mir zumindestens bei schaltern.
wird denn der statusrequest gesendet?
ist beim io der batchlevel (40%) überschritten? dann würde der befehl eventuell verschoben werden.

das update interval habe ich noch nicht geändert. bin leider nicht zu hause.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

automatisierer

Zitat von: frank am 16 November 2017, 20:56:30
actAutoTry funktioniert bei mir zumindestens bei schaltern.
wird denn der statusrequest gesendet?
nein, wird es nicht.
Das mit den Schaltern werde ich mal testen - sind dann aber Geräte, die nicht automatisch zum ActionDetector hinzugefügt wurden, oder?
Zitat
ist beim io der batchlevel (40%) überschritten? dann würde der befehl eventuell verschoben werden.
nein, auch nicht.
Zitat
das update interval habe ich noch nicht geändert. bin leider nicht zu hause.
kein Stress...

frank

ZitatDas mit den Schaltern werde ich mal testen - sind dann aber Geräte, die nicht automatisch zum ActionDetector hinzugefügt wurden, oder?
genau. da habe ich actCycle beim schalter device nachträglich gesetzt.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

automatisierer

Moin,

ich habe mal einen Jalousieaktor HM-LC-Bl1PBU-FM mit actCycle versehen. Dieser wird genau so als dead gemeldet, wie auch alle anderen Geräte.

Also leider keine Funktion von actAutoTry.


frank

FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html