Regelmäßige Ausfälle (missing ACK)

martinp876 · 11 November 2015, 20:24:55

set_on sollte immer kommen, auch wenn es kaum sichtbar ist.
das retry sollte in diesen Fall von FHEM kommen.
Die Statusabfrage sollte auch automatisch kommen. was steht in autoReadReg? alles aus? ja dann wäre es eben aus.

NewRasPi · 11 November 2015, 23:20:44

Hallo Gemeinde und Fhem- Profis
Ich würde mich hier auch gerne mal anhängen. Die Tipps hier habe ich versucht zu verstehen, aber für mich als Anfänger war noch kein nachvollziehbarer Lösungsansatz dabei.
Hier mein List beim Rauchmelder:

Code Auswählen

Internals: 
   CFGFN 
   DEF        733490 
   IODev      HMLAN1 
   NAME       DachbodenRauchmelder 
   NR         201 
   STATE      MISSING ACK 
   TYPE       CUL_HM 
   peerList   KinderzimmerRauchmelder, 
   protCmdDel 3 
   protResnd  6 last_at:2015-11-11 22:46:01 
   protResndFail 2 last_at:2015-11-11 22:46:07 
   protSnd    2 last_at:2015-11-11 22:45:47 
   protState  CMDs_done_Errors:1 
   Readings: 
     2015-11-11 22:46:07   state           MISSING ACK 
   Helper: 
     HM_CMDNR   5 
     cSnd       0123A3D973349000040000000000,1123A3D97334900400 
     Expert: 
       def        1 
       det        0 
       raw        1 
       tpl        0 
     Io: 
       newChn     +733490,00,00,00 
       prefIO 
       rxt        0 
       vccu 
       p: 
         733490 
         00 
         00 
         00 
     Mrssi: 
       mNo 
     Prt: 
       bErr       0 
       sProc      0 
     Q: 
       qReqConf 
       qReqStat 
     Role: 
       chn        1 
       dev        1 
Attributes: 
   IODev      HMLAN1 
   autoReadReg 4_reqStatus 
   expert     2_full 
   peerIDs    2F3ECA01 
   room       8.1_System,8.9_Rauchmelder 
   subType    smokeDetector 
   webCmd     statusRequest

Den ersten Rauchmelder mit diesem Fehler habe ich getauscht und genau den gleichen
STATE RESPONSE TIMEOUT:RegisterRead oder
MISSING ACK bekommt dieser eine von sieben Rauchmeldern wieder. (Dieser Rauchmelder liegt Testweise zwei Meter neben dem HMLAN-Adapter, was also die rissi Werte als Fehlerquelle ausschliessen sollte) Gibt es einen Zusammenhang mit dem neu Anschluß der HM Strommeßsteckdose die zum Beginn der Probleme angeschlossen wurde.
Das sich auch die Fenster- Türsensoren regelmäßg auf "dead" schalten, wenn die Fenster nicht mindestens ein mal am Tag geöffnet werden ist für einen Alarmsensor auch ein unsinniger Zustand. (Wenn man mal drei Tage weg ist muss ein Nachbar die Fenster und Türen öffnen und schliessen, damit die Sensoren sich nicht schlafen legen)
Sieht hier schon jemand den Fehler oder müsste dafür noch mehr Info "ausgelesen" werden?
Wenn die Begrenzung der Sendezeit das Limit der Sensoren vorgibt müsste man ja auch die unwichtigen Daten des HM Strommeßzwischenstecker auf die wichtigen Werte eingrenzen und alles andere "abschalten".
Ich bin Euch für jeden guten Tipp sehr dankbar.
Schöne Grüße

hanske · 12 November 2015, 09:10:14

Danke für den Tipp mit dem msgRepeat.
Ich dachte das wäre nur für die Meldungen vom Device.
Bei dem Status "set_on" weiß ich ja nicht, ob der Befehl überhaupt am Gerät angekommen ist.
Wenn Fhem damit aufgefordert wird, bei fehlendem Acknowledge nochmals zu senden, ist es genau das was ich brauche.

@martinp876
Ich habe das DOIF gerade erst vor kurzem entdeckt und verwende es jetzt gerne für alles was ich vorher mit komplizierten notifys gelöst habe.
Mir scheint aber das es ein Problem gibt, wenn sich der Status innerhalb weniger ms nacheinander ändert.
Dann bekommt es nur das erste mit.

Bei meinem DOIF:

Code Auswählen

define di DOIF ([sw_hm_hz_main] eq "set_on") (set sw_hm_hz_main on)
DOELSEIF ([sw_hm_hz_main] eq "set_off") (set sw_hm_hz_main off)
attribute di wait 120

bin ich davon ausgegangen, dass es nur triggert wenn der Status für 2 Minuten auf "set_on" oder "set_off" bleibt.
Es triggert aber auch wenn "set_on" direkt von "on" abgelöst wird.

autoReadReg steht auf "4_reqStatus"

hanske · 12 November 2015, 09:17:14

@NewRasPi

Du kannst bei Deinem HM LAN Adapter mal den Status oder die Logs überprüfen.
Dann siehst Du, ob der manchmal im "Overload" ist.
Meine Fensterkontakte (HM-SEC-SCo) melden sich automatisch ca. 1x pro Stunde mit Ihrem Zustand.
Das kann man meiner Meinung nach auch gar nicht ändern.

Schöne Grüße

frank · 12 November 2015, 10:00:00

@NewRasPi

ich denke, du solltest besser einen eigenen thread aufmachen.
im wiki pairen wird erlärt, woran du erkennst, dass dein device nicht gepaired ist.
ausserdem solltest du als bekennender anfänger deine devices beim pairen automatisch anlegen lassen, damit alle wichtigen attribute vorhanden sind.
bei fk muss das register cyclicInfoMsg=on sein, damit regelmässig der status gesendet wird.

hanske · 12 November 2015, 14:16:24

@frank

Ich habe das msgRepeat eingebaut. Das hilft wahrscheinlich schon.

Statt des DOIF benutze ich jetzt auch ein watchdog:

Code Auswählen

define wd watchdog sw_hm_hz_main:set_off 00:02 sw_hm_hz_main:off set sw_hm_hz_main off

Das funktioniert leider auch nicht richtig.

Bei normalem Verhalten, also schneller Übergang von "set_off" nach "off" bekommt er das "off" wohl nicht mehr mit.
Es ist dann das gleiche Problem wie beim DOIF.
Es triggert bei jedem Schalten.

Schöne Grüße

frank · 12 November 2015, 14:34:14

Code Auswählen

define wd watchdog sw_hm_hz_main.set_off 00:02 sw_hm_hz_main.off set sw_hm_hz_main off;; trigger wd .
so vielleicht besser.

hanske · 12 November 2015, 15:36:36

Ich glaube nicht,
er triggert ja jetzt schon zu viel.

Er soll ja nur triggern, wenn der Zustand "sw_hm_hz_main.set_off" sich innerhalb von 2 Minuten nicht ändert.
Im Normalfall kommt aber direkt nach "sw_hm_hz_main.set_off" das "sw_hm_hz_main.off".
Das bekommt der Watchdog wohl nicht mit und triggert jedes mal.

frank · 12 November 2015, 15:54:07

zeig doch mal, was im eventmonitor passiert.

ausgelöst werden sollte der wd erst 2min nach dem letzen set_on (falls es mehrere gibt), denn jedes weitere set_on setzt den timer neu. der triggerbefehl dient dazu, dass der wd nach dem auslösen (triggered) wieder auf defined gestellt wird, damit der nächste set_on ihn aktivieren kann.

edit: hauptsächlich ging es erstmal um das ändern der doppelpunkte in punkte bei den regex.

hanske · 13 November 2015, 08:46:13

@frank

danke, jetzt funktioniert es mit dem watchdog.
Ich hatte vergessen, dass ich noch eine Eventmap im Schalter hatte.
Es kam dann also nie "on", sondern "auto".

@ DOIF Experte

Ich habe dann nochmal das DOIF getestet, das geht aber immer noch nicht.

Code Auswählen

define di_hz_checkMainStatus([sw_hm_hz_main] =~"set_on") (set sw_hm_hz_main on) 
               DOELSEIF ([sw_hm_hz_main] =~ "set_off") (set sw_hm_hz_main off) 
attr di_hz_checkMainStatus wait 120,120

Eventlog:

Code Auswählen

2015-11-12 21:44:06 DOIF di_hz_checkMainStatus wait_timer: 12.11.2015 21:46:06 cmd_1 sw_hm_hz_main
2015-11-12 21:44:06 CUL_HM sw_hm_hz_main set_on
2015-11-12 21:44:09 CUL_HM sw_hm_hz_main deviceMsg: auto (to vccu)
2015-11-12 21:44:09 CUL_HM sw_hm_hz_main level: 100
2015-11-12 21:44:09 CUL_HM sw_hm_hz_main pct: 100
2015-11-12 21:44:09 CUL_HM sw_hm_hz_main auto
2015-11-12 21:46:06 DOIF di_hz_checkMainStatus cmd_event: sw_hm_hz_main

Wie man sieht triggert das "set_on" den timer.
Der sich nach 3 Sekunden ändernde Status nach "auto" löscht den Timer aber nicht.
Nach dem Beispiel "Waschmaschine fertig" aus der Commandref hatte ich erwarte, dass der Timer zurückgesetzt wird,
wenn die Bedingung [sw_hm_hz_main] =~"set_on" nicht mehr erfüllt ist.

kumue · 13 November 2015, 09:05:13

bin kein DOIF-Experte... was mir auf den ersten Blick auffiel ist das Komma zwischen den Zeiten.

Code Auswählen

attr di_hz_checkMainStatus wait 120,120

Aus commandref
attr <DOIF-modul> wait <Sekunden für Befehlsfolge des ersten DO-Falls>:<Sekunden für Befehlsfolge des zweiten DO-Falls>:...

Komma-Trennung innerhalb einens DO-Falls bei mehreren Befehlen
Doppelpunkt-Trennung zwischen den DO-Falls

Hoffe ich liege richtig

hanske · 13 November 2015, 09:39:30

Wieder was dazu gelernt, danke

Allerdings hatte ich in früheren Tests auch nur eine Zeit eingetragen. Da ging es auch schon nicht.

Ich ändere es mal und warte ab.

hanske · 13 November 2015, 11:57:06

Hat sich leider nicht geändert.

Wenn 3 Sekunden nach "set_off" ein anderer Status gesetzt wird, wird der Timer immer noch nicht gelöscht.

kumue · 13 November 2015, 12:47:57

Code Auswählen

define di_hz_checkMainStatus([sw_hm_hz_main] =~"set_on") (set sw_hm_hz_main on)
               DOELSEIF ([sw_hm_hz_main] =~ "set_off") (set sw_hm_hz_main off)
attr di_hz_checkMainStatus wait 120,120

in deinem Code fehlt das DOIF, aber daran wird es ja nicht liegen...

setzte mal bitte ein Leerzeichen nach dem ersten Operator =~
nach dem zweiten ist es ja vorhanden

Code Auswählen

([sw_hm_hz_main] =~ "set_on") (set sw_hm_hz_main on) DOELSEIF ([sw_hm_hz_main] =~ "set_off") (set sw_hm_hz_main off)

hanske · 16 November 2015, 08:49:52

Ach so, das DOIF hatte ich vergessen hierüber zu kopieren.
So sieht es wirklich aus:

Code Auswählen

define di_hz_checkMainStatus DOIF ([sw_hm_hz_main] =~ "set_on") (set sw_hm_hz_main on)
               DOELSEIF ([sw_hm_hz_main] =~ "set_off") (set sw_hm_hz_main off)
attr di_hz_checkMainStatus wait 120,120

Am fehlenden Leerzeichen lag es auch nicht.

Man kann es auch so schreiben:

Code Auswählen

define di_hz_checkMainStatus DOIF ([sw_hm_hz_main] eq "set_on") (set sw_hm_hz_main on)
               DOELSEIF ([sw_hm_hz_main] eq "set_off") (set sw_hm_hz_main off)

Aber leider wird immer ein Kommando ausgeführt, auch wenn sich der Status kurz nach dem Triggern wieder ändert.