Wassermelder "MISSING ACK" von unterwegs beheben

Begonnen von dantist, 28 Dezember 2017, 08:45:38

Vorheriges Thema - Nächstes Thema

dantist

Hallo zusammen,

wir sind grade auf einem mehrtägigen Verwandtschaftsbesuch, und da wir in letzter Zeit ein paar mal Wasser in der Küche hatten, beobachte ich unseren Homematic-Wassermelder ganz genau.

Leider zeigt dieser seit gestern ein "MISSING ACK" als state. Das hatte er schon öfter, und meistens löst sich das Problem mit der nächsten Statusmeldung von selbst. Allerdings bin ich diesmal etwas nervös und frage mich, ob ich das Ding ohne physischen Zugriff reaktivieren kann. Lässt sich das irgendwie machen?

Schöne Grüße
Daniel

fiedel

Eher nicht, da das Teil nur sendet wenn es was zu melden gibt, oder alle paar Stunden. Du solltest später zu Hause die Empfangsbedingungen verbessern (z.B. VCCU + zusätzlicher abgesetzer Empfänger).

Wie kommt das Wasser denn dort hin? Vielleicht wäre ein Lekageschutz was für dich?
Es gibt da gerade was schönes Neues von Grohe.
Das ist leider die Kehrseite der tollen Haustechnik - umsomehr man per Handy (fehl-)gemeldet bekommt, um so stressiger kann der Urlaub werden... Ich kenne das auch.  ;)

Gruß
Frank
FeatureLevel: 6.1 auf Wyse N03D ; Deb. 11 ; Perl: v5.14.2 ; IO: HM-MOD-RPI-PCB + VCCU|CUL 868 V 1.66|LinkUSBi |TEK603
HM: SEC-SCO|SCI-3-FM|LC-SW4-PCB|ES-PMSW1-PL|RC-4-2|SEN-MDIR-O|SEC-WDS-2
CUL: HMS100TF|FS20 S4A-2 ; OWDevice: DS18S20|DS2401|DS2406|DS2423

frank

Zitat von: fiedel am 28 Dezember 2017, 10:09:11
Eher nicht, da das Teil nur sendet wenn es was zu melden gibt, oder alle paar Stunden. Du solltest später zu Hause die Empfangsbedingungen verbessern (z.B. VCCU + zusätzlicher abgesetzer Empfänger).
ausserdem würde ich mal schauen, warum fhem überhaupt etwas sendet. denn das missing ack ist ja aus fhem sicht zu verstehen. es wurde etwas gesendet und die empfangsbestätigung des sensors wird vermisst.

ich denke hminfo configcheck wird dazu etwas melden.

fhem wird aber nur versuchen etwas zu senden, wenn der sensor von selbst aufwacht und sich meldet. wahrscheinlich wurde erst die zyklische statusinfo empangen.
wenn also zu diesem zeitpunkt trocken gemeldet wurde, sollte alles ok sein.
entweder passte dann das timing beim senden nicht (cul?), oder der funk ist/war schlecht/gestört.

was sagt denn der actiondetector? empfängt er regelmässig die statusinfos?
wie sieht denn das list vom sensor aus?

weiteres senden zum sensor würde ich wahrscheinlich erstmal vermeiden, solange ich abwesend wäre und nicht genau wüsste, was los ist.
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

Pfriemler

Wenn da gerade je nach autoReadReg mal wieder Register vom Device gelesen werden sollten, während das Ding ein zyklisches "Hier bin ich" gesendet hat und die Kommunikation dabei gestört wurde, was schnell passieren kann, war's das schon mit dem Problem. Leider wird die nächste Meldung erst in einem Tag kommen, wenn es keinen Wassereinbruch gibt. Da das Ding ja sonst regelmäßig sendet, wenn es feucht oder nass ist, würde ich entspannt bleiben.

Keine andere Möglichkeit des Zugriffes? VPN? Telegram? in den Readings muss doch stehen was wann zuletzt los war.
"Ä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 ..."

dantist

Ich habe mich grade noch einmal eingeloggt, und siehe da, der Status steht wieder auf "dry", ziemlich genau 24h nach dem MISSING ACK. Aber so ganz in Ordnung scheint es doch noch nicht zu sein, denn der protState steht auf "CMDs_pending":

Internals:
   DEF        3D3362
   IODev      hmusb
   LASTInputDev hmusb
   MSGCNT     1
   NAME       Wassermelder
   NOTIFYDEV  global
   NR         258
   NTFY_ORDER 50-Wassermelder
   STATE      dry
   TYPE       CUL_HM
   hmusb_MSGCNT 1
   hmusb_RAWMSG E3D3362,0000,2A78FDDB,FF,FFCA,1F86103D336200000006010000
   hmusb_RSSI -54
   hmusb_TIME 2017-12-28 15:03:34
   lastMsg    No:1F - t:10 s:3D3362 d:000000 06010000
   protCmdPend 3 CMDs pending
   protLastRcv 2017-12-28 15:03:34
   protResnd  1 last_at:2017-12-28 15:03:38
   protSnd    1 last_at:2017-12-28 15:03:34
   protState  CMDs_pending
   rssi_at_hmusb max:-54 cnt:1 avg:-54 lst:-54 min:-54
   READINGS:
     2017-12-27 17:46:27   Activity        alive
     2017-05-20 13:44:11   CommandAccepted yes
     2017-07-31 18:03:14   D-firmware      1.4
     2017-07-31 18:03:14   D-serialNr      MEQ0590682
     2017-07-31 18:03:16   PairedTo        0x000000
     2017-07-31 18:03:14   R-cyclicInfoMsg on
     2017-07-31 18:03:14   R-pairCentral   0x000000
     2017-07-31 18:03:15   R-sign          off
     2017-12-28 15:03:34   alive           yes
     2017-12-28 15:03:34   battery         ok
     2017-12-28 15:03:34   contact         dry (to broadcast)
     2017-12-28 15:03:34   cover           closed
     2017-12-28 15:03:34   recentStateType info
     2017-12-28 15:03:34   state           dry
     2017-08-26 11:15:39   trigger_cnt     67
   cmdStack:
     ++A0015553423D336200040000000000
     ++A0015553423D336201040000000001
     ++A0015553423D33620103
   helper:
     HM_CMDNR   32
     getCfgList all
     getCfgListNo ,4
     mId        00B2
     rxType     12
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +3D3362,02,00,00
       nextSend   1514469814.20456
       prefIO     
       rxt        2
       vccu       
       p:
         3D3362
         00
         00
         00
     mRssi:
       mNo        1F
       io:
         hmusb      -52
     prt:
       bErr       0
       sProc      2
       wuReSent   2
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     rssi:
       at_hmusb:
         avg        -54
         cnt        1
         lst        -54
         max        -54
         min        -54
Attributes:
   IODev      hmusb
   actCycle   028:00
   actStatus  alive
   autoReadReg 4_reqStatus
   event-on-change-reading state,battery
   expert     2_raw
   firmware   1.4
   icon       humidity
   model      HM-SEC-WDS-2
   room       03 - Homematic
   serialNr   MEQ0590682
   subType    threeStateSensor


Der Wassermelder steht vier Meter Luftlinie vom Raspberry Pi mit HM USB-Stick, getrennt von einer einzelnen Wand. Von allen Sensoren ist er der nächste, die Sende- und Empfangsbedingungen sollten also gut sein.

OT: Das Wasser kommt übrigens durch den Ablauf in die Waschmaschine und von da in die Küche.Der Zulauf war bei allen Vorfällen abgedreht. Ein Monteur konnte keinen Fehler bei den Rohren in der Wohnung finden, und die Hausverwaltung weist jede Verantwortung von sich. Komplizierte Sache, und da ich von sanitären Einrichtungen keine Ahnung habe, wüsste ich auch nicht, ob ein Rückflussventil o.ä. helfen würde, geschweige denn, wie es installiert wird.

frank

wenn du nach hause kommst, solltest du erst einmal pairen.
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