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
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.
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
Zitat von: SuperJojo2001 am 05 Februar 2017, 15:00:05
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 (https://forum.fhem.de/index.php/topic,62086.msg534927.html#msg534927)
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.
Zitat... seit 4 Wochen problemlos.
hm, ... ???
Zitat von: SuperJojo2001 am 05 Februar 2017, 15:00:05
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.
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.
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!!!!
ZitatAlso 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.