HM-Sen-LI-O stoppt Senden wenn FHEM-Server mal weg;nur Batterie raus/rein hilft

[SuperJojo2001]

Hallo,

ich habe den HM-Sen-LI-O mit FHEM und CUL auf einem Raspberry am laufen. Läuft prima. Es kommen alle 4-5 Minuten Helligkeitswerte.

Schalte ich den Raspberry, sprich den FHEM-Server aber ab, dann schickt der Sensor natürlich seine Werte weiter, doch der Server kann im diese nicht mehr quittieren.

Das scheint dem Sensor nicht zu "schmecken", denn er hört daraufhin auf zu senden. Auch wenn ich den Server wieder hochfahre, registriert mein CUL keine Aktivitäten.

Jetzt hilft nur noch die Batterien kurz vom Sensor zu entfernen und wieder reinzustecken. Dann fängt es beim laufendem FHEM-Server wieder an zu senden.

Kennt jemand das Verhalten? Kann man das Verhalten durch eine Variable im Sensor abschalten? Gibt es noch andere Sensoren mit gleichen Verhaltensmuster?

Danke
Jojo

[frank]

hört sich sehr seltsam an.

wie lange ist fhem down, wenn es nicht mehr funktioniert?
fängt der sensor eventuell nach einer "tiefschlafphase" (1-2 stunden) wieder von alleine an?
poste mal ein aktuelles list.

ich habe schon von devices gehört, bei denen anscheinend ein getconfig probleme macht. diese devices brauchen attr autoreadreg=0.

[SuperJojo2001]

So unten die list Ausgabe zum Sensor. Meine Pair-ID habe ich mit xxxxxx unkenntlich gemacht. Nicht wundern.

Ich habe ihn um 12:48 wieder spannungslos gemacht und wieder aktiviert. Seit dem läuft er wieder prima.

Es ist so das ich das SD-Kartenimage meines Raspberrys ab und zu sichere. Dazu fahre ich in runter, entnehme die SD-Karte und ziehe ne Kopie. Dann schalte ich ihn wieder an. Das macht dann insgesamt so 15 Minuten in der FHEM dann aus ist.

Ich versuchte nach dem FHEM-Start auch mal mit dem Kommando "set HM_521B0D reset" den Sensor zu restten. Im RAW event log sah man dann auch das der Sensor überhaupt nicht mehr antwortet.

Gut wie gesagt hier der list-Ausdruck:


Internals:
   CUL_0_MSGCNT 173
   CUL_0_RAWMSG A0F308653521B0D00000000C10000D038::-97:CUL_0
   CUL_0_RSSI -97
   CUL_0_TIME 2017-02-05 14:48:35
   DEF        521B0D
   IODev      CUL_0
   LASTInputDev CUL_0
   MSGCNT     173
   NAME       HM_521B0D
   NOTIFYDEV  global
   NR         174
   NTFY_ORDER 50-HM_521B0D
   STATE      B: 533.04
   TYPE       CUL_HM
   lastMsg    No:30 - t:53 s:521B0D d:000000 00C10000D038
   protCmdDel 1
   protLastRcv 2017-02-05 14:48:35
   protResnd  3 last_at:2017-02-05 10:02:38
   protResndFail 1 last_at:2017-02-05 10:02:43
   protSnd    7 last_at:2017-02-05 12:48:23
   protState  CMDs_done
   rssi_at_CUL_0 cnt:173 max:-83.5 lst:-97 min:-107.5 avg:-94.59
   Readings:
     2017-02-05 12:48:20   Activity        alive
     2017-02-05 12:48:22   CommandAccepted yes
     2017-02-05 12:48:20   D-firmware      1.1
     2017-02-05 12:48:20   D-serialNr      NEQ1358836
     2017-02-05 12:48:23   PairedTo        xxxxxx
     2017-01-25 10:12:25   R-cyclicInfoMsgDis 0
     2017-01-25 10:12:25   R-pairCentral   xxxxxx
     2017-01-25 10:12:25   R-sign          off
     2017-02-05 12:48:22   RegL_00.          02:01 0A:xx 0B:xx 0C:xx 11:00 14:06 18:00 00:00
     2017-02-05 12:48:23   RegL_01.          02:50 08:00 30:06 7B:08 AC:00 00:00
     2017-01-25 10:11:30   aesCommToDev    ok
     2017-01-25 10:11:30   aesKeyNbr       00
     2017-02-05 14:48:35   battery         ok
     2017-02-05 14:48:35   brightness      533.04
     2017-02-05 12:48:22   powerOn         2017-02-05 12:48:22
     2017-02-05 12:48:22   recentStateType info
     2017-02-05 14:48:35   state           B: 533.04
   Helper:
     HM_CMDNR   48
     PONtest    1
     cSnd       01xxxxxx521B0D00040000000000,01xxxxxx521B0D01040000000001
     getCfgListNo
     mId        00FD
     rxType     12
     supp_Pair_Rep 0
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +521B0D,00,02,00
       nextSend   1486302515.67934
       prefIO
       rxt        0
       vccu
       p:
         521B0D
         00
         02
         00
     Mrssi:
       mNo        30
       Io:
         CUL_0      -95
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_cul_0:
         avg        -94.5924855491329
         cnt        173
         lst        -97
         max        -83.5
         min        -107.5
     Shadowreg:
Attributes:
   IODev      CUL_0
   actCycle   002:50
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.1
   model      HM-Sen-LI-O
   room       Helligkeitaussen
   serialNr   NEQ1358836
   subType    senBright

[frank]

Meine Pair-ID habe ich mit xxxxxx unkenntlich gemacht. Nicht wundern.

sinnlos. wer sie braucht, sieht sie sowieso.

auffällig ist natürlich der extrem schlechte funk, was bei deinem "fehlerbild" nicht wirklich hilfreich ist.
schon mal frische batterien probiert?
https://forum.fhem.de/index.php/topic,62086.msg534927.html#msg534927

[SuperJojo2001]

Den Thread mit dem Stromverbrauch habe ich gelesen ... mein Lichtsensor läuft und läuft und läuft ... seit 4 Wochen problemlos. Nur nach dem FHEM-Stop eine Batterie kurz raus, dann wieder rein und die Kommunikation steht wieder.

Richtig ist natürlich das der Sensor und CUL durch 2 Häuserwände funken. Aber beide verstehen sich ja, insofern bin ich zufrieden.

[frank]

... seit 4 Wochen problemlos.

hm, ... 

[chem]

Es ist so das ich das SD-Kartenimage meines Raspberrys ab und zu sichere. Dazu fahre ich in runter, entnehme die SD-Karte und ziehe ne Kopie. Dann schalte ich ihn wieder an. Das macht dann insgesamt so 15 Minuten in der FHEM dann aus ist.

Ist zwar off-topic: Ein SD Card image kannst du auch machen ohne den raspberry runterzufahren. Dafür gibt es ein Utility (per default installiert) das im Laufenden Betrieb die SD Karte kopiert. Die zweite Karte kann dann z.B. über einen USB Card-Reader angeschlossen sein. Ich mache das immer so und die so geclonte Karte funktionierte (bisher) einwandfrei.

[SuperJojo2001]

Auch das mit dem Raspberry-Image und dem Utility ist richtig. Habe ich bislang nicht verwendet. Ich bin eher so ein koservativer typ. So landet mein Image über meinen Windows-Rechner direkt als image auf meinem NAS.

Das mit der SD-Kartenkopie "ziehen" ist ja auch nur ein Grund warum mein Raspberry mal stromlos wird ... es gäbe ja zig andere Gründe.

[SuperJojo2001]

Eine Analyse der raw Frames über mein CUL zeigt tatsächlich das der konstant weitersendet. Nicht der Sensor hat ein Problem, sondern FHEM:

Hier mal ein Auszug der Sensor-Nachrichten ... alle 3-4 Minuten eine Nachricht (Habe den Sensor abgedunkelt, deswegen Helligkeit 0000)

2017.02.28 22:28:27.675 5 : CUL/RAW: /A0F048653521B0D00000000C1000000001D
2017.02.28 22:28:27.675 4 : CUL_Parse: CUL_0 A 0F 04 8653 521B0D 000000 00C1000000001D -59.5
2017.02.28 22:28:27.677 5 : CUL_0: dispatch A0F048653521B0D00000000C100000000::-59.5:CUL_0

2017.02.28 22:31:04.429 5 : CUL/RAW: /A0F058653521B0D00000000C1000000001D
2017.02.28 22:31:04.429 4 : CUL_Parse: CUL_0 A 0F 05 8653 521B0D 000000 00C1000000001D -59.5
2017.02.28 22:31:04.431 5 : CUL_0: dispatch A0F058653521B0D00000000C100000000::-59.5:CUL_0

2017.02.28 22:33:26.932 5 : CUL/RAW: /A0F068653521B0D00000000C1000000001F
2017.02.28 22:33:26.952 4 : CUL_Parse: CUL_0 A 0F 06 8653 521B0D 000000 00C1000000001F -58.5
2017.02.28 22:33:26.954 5 : CUL_0: dispatch A0F068653521B0D00000000C100000000::-58.5:CUL_0

Dabei erhöht der Sensor einen Nachrichtenzähler pro Nachricht an der 3'ten Stelle 04 ... 05 ... 06 usw. Der Rest der Nachricht ist immer gleich weil Helligkeit = 0. Mit jedem dieser Nachrichten bekomme ich im Normalfall auch ein "Notify". Aber nur wenn der Sensor und FHEM neu gestartet wurden.

Dieser Zähler jedenfalls scheint dem FHEM-Server wichtig zu sein ... denn wird der Server separat neu gestartet scheint der Server die Sensor-Nachrichten wieder ab dem Zähler 01 ... zu erwarten, während der Sensor aber mit 07 ... 08 .... usw. munter weiter macht

2017.02.28 22:36:32.441 5 : CUL/RAW: /A0F078653521B0D00000000C1000000001D
2017.02.28 22:36:32.442 4 : CUL_Parse: CUL_0 A 0F 08 8653 521B0D 000000 00C1000000001D -59.5
2017.02.28 22:36:32.443 5 : CUL_0: dispatch A0F088653521B0D00000000C100000000::-59.5:CUL_0

2017.02.28 22:38:32.441 5 : CUL/RAW: /A0F088653521B0D00000000C1000000001D
2017.02.28 22:38:32.442 4 : CUL_Parse: CUL_0 A 0F 08 8653 521B0D 000000 00C1000000001D -59.5
2017.02.28 22:38:32.443 5 : CUL_0: dispatch A0F088653521B0D00000000C100000000::-59.5:CUL_0

Also suchte ich am FHEM-Server un den Einstellung. Dabei habe ich bemerkt das FHEM den Sensor beim "autocreate" nicht richtig angelegt hatte. Das war alles was ich vorgefunden hatte:

define HM_521B0D CUL_HM 521B0D
attr HM_521B0D IODev CUL_0

Nachdem ich alle sonstigen üblichen Werte manuell nachgetragen habe

define HM_521B0D CUL_HM 521B0D
attr HM_521B0D IODev CUL_0
attr HM_521B0D autoReadReg 4_reqStatus
attr HM_521B0D expert 2_raw
attr HM_521B0D msgRepeat 1
attr HM_521B0D actStatus alive
attr HM_521B0D room Helligkeitaussen
attr HM_521B0D serialNr NEQ1358836
attr HM_521B0D model HM-Sen-LI-O
attr HM_521B0D subType senBright

laufen nun auch die Notify-Nachricht auch nach dem FHEM-Neustart.

Gelöst!!!!

[frank]

Also suchte ich am FHEM-Server un den Einstellung. Dabei habe ich bemerkt das FHEM den Sensor beim "autocreate" nicht richtig angelegt hatte. Das war alles was ich vorgefunden hatte:

vermutlich hast du ihn nie gepairt.