Hallo zusammen,
ich nutze derzeit zwei HM-LC-SW1-BA-PCB mit der bekannten Monacor Piezo-Sirene - beides betrieben mit einem 9V Block.
Ich hatte die letzten Tage das Problem, dass ich teilweise keine Verbindung mehr zum Aktor herstellen konnte.
Bspw. "set ... off/getconfig/.." führte lediglich zu einem Status "X CMD pending".
Der konfigurierte ActionDetector hat die Aktoren nach einiger Zeit (028:00) dann irgendwann ebenfalls als "dead" deklariert.
Eine Batteriewarnung (LowBatLimit = 8.0V) habe ich zuvor nicht erhalten.
Ich habe dann den Knopf auf dem HM-LC-SW1-BA-PCB betätigt, zunächst ging dann erstmal die Sirene los ;D und dann funktionierte die Verbindung zu FHEM wieder problemlos.
Anbei einige Daten zu CUL & CO:
VERSION V 1.20.01 a-culfw Build: 176 (2015-12-07_23-24-58) CUL868 (F-Band: 868MHz)
Sowie ein Auszug aus dem FileLog des Geräts:
2016-02-10_01:19:02 Alarmgeber_Piezo_Flur off
2016-02-10_01:19:02 Alarmgeber_Piezo_Flur timedOn: off
2016-02-10_01:29:02 Alarmgeber_Piezo_Flur Activity: alive
2016-02-10_18:34:02 Alarmgeber_Piezo_Flur aesKeyNbr: 04
2016-02-10_18:34:03 Alarmgeber_Piezo_Flur aesCommToDev: ok
2016-02-10_18:34:03 Alarmgeber_Piezo_Flur aesKeyNbr: 04
2016-02-10_18:34:03 Alarmgeber_Piezo_Flur aesCommToDev: ok
2016-02-10_18:34:03 Alarmgeber_Piezo_Flur aesKeyNbr: 04
2016-02-10_18:36:09 Alarmgeber_Piezo_Flur set_off
2016-02-11_19:24:49 Alarmgeber_Piezo_Flur set_off
2016-02-11_19:25:59 Alarmgeber_Piezo_Flur set_off
2016-02-11_19:26:06 Alarmgeber_Piezo_Flur set_off
2016-02-11_22:59:17 Alarmgeber_Piezo_Flur Activity: dead
2016-02-12_18:32:49 Alarmgeber_Piezo_Flur battery: ok
2016-02-12_18:32:49 Alarmgeber_Piezo_Flur deviceMsg: on (to VCCU_0)
2016-02-12_18:32:49 Alarmgeber_Piezo_Flur level: 100
2016-02-12_18:32:49 Alarmgeber_Piezo_Flur pct: 100
2016-02-12_18:32:49 Alarmgeber_Piezo_Flur on
2016-02-12_18:32:49 Alarmgeber_Piezo_Flur timedOn: off
2016-02-12_18:32:50 Alarmgeber_Piezo_Flur battery: ok
2016-02-12_18:32:50 Alarmgeber_Piezo_Flur deviceMsg: on (to VCCU_0)
2016-02-12_18:32:50 Alarmgeber_Piezo_Flur level: 100
2016-02-12_18:32:50 Alarmgeber_Piezo_Flur levelMissed: desired:0
2016-02-12_18:32:50 Alarmgeber_Piezo_Flur pct: 100
2016-02-12_18:32:50 Alarmgeber_Piezo_Flur on
2016-02-12_18:32:50 Alarmgeber_Piezo_Flur timedOn: off
2016-02-12_18:32:56 Alarmgeber_Piezo_Flur aesCommToDev: fail
2016-02-12_18:32:56 Alarmgeber_Piezo_Flur aesKeyNbr: 04
2016-02-12_18:32:57 Alarmgeber_Piezo_Flur aesCommToDev: ok
2016-02-12_18:32:57 Alarmgeber_Piezo_Flur battery: low
2016-02-12_18:32:57 Alarmgeber_Piezo_Flur deviceMsg: off (to VCCU_0)
2016-02-12_18:32:57 Alarmgeber_Piezo_Flur level: 0
2016-02-12_18:32:57 Alarmgeber_Piezo_Flur pct: 0
2016-02-12_18:32:57 Alarmgeber_Piezo_Flur off
2016-02-12_18:32:57 Alarmgeber_Piezo_Flur timedOn: off
2016-02-12_18:33:08 Alarmgeber_Piezo_Flur ResndFail
2016-02-12_18:33:08 Alarmgeber_Piezo_Flur RESPONSE TIMEOUT:RegisterRead
2016-02-12_18:33:57 Alarmgeber_Piezo_Flur R-pairCentral: 0x27D0E2
2016-02-12_18:33:57 Alarmgeber_Piezo_Flur R-sign: on
2016-02-12_18:39:25 Alarmgeber_Piezo_Flur Activity: alive
2016-02-12_18:39:58 Alarmgeber_Piezo_Flur aesKeyNbr: 04
2016-02-12_18:39:59 Alarmgeber_Piezo_Flur aesCommToDev: ok
2016-02-12_18:39:59 Alarmgeber_Piezo_Flur aesKeyNbr: 04
2016-02-12_18:39:59 Alarmgeber_Piezo_Flur aesCommToDev: ok
2016-02-12_18:39:59 Alarmgeber_Piezo_Flur aesKeyNbr: 04
2016-02-12_18:40:00 Alarmgeber_Piezo_Flur aesCommToDev: ok
Ich vermute das der Aktor "geschlafen" hat und nicht auf die Burstmessage des CUL reagiert hat, kann das sein?
Danke & viele Grüße,
ambiman
kenne ich so nicht. burst klappt.
Hallo,
ich habe gerade aktuelle wieder das gleiche Phänomen - einer der Piezo-Aktoren reagiert nicht mehr:
List des Device:
CUL_0_MSGCNT 39
CUL_0_RAWMSG A1120A0023C97BD27D0E2048E6D04EA70E704::-58.5:CUL_0
CUL_0_RSSI -58.5
CUL_0_TIME 2016-02-13 20:07:47
DEF 3C97BD
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 39
NAME Alarmgeber_Piezo_Kueche
NR 118
NTFY_ORDER 50-Alarmgeber_Piezo_Kueche
STATE set_off
TYPE CUL_HM
lastMsg No:20 - t:02 s:3C97BD d:27D0E2 048E6D04EA70E704
protCmdPend 2 CMDs_pending
protLastRcv 2016-02-13 20:07:47
protResnd 3 last_at:2016-02-12 18:36:25
protSnd 54 last_at:2016-02-13 20:07:47
protState CMDs_processing...
rssi_CUL_0 avg:-59.85 min:-73 max:-54 lst:-73 cnt:7
rssi_at_CUL_0 avg:-57.07 min:-71.5 max:-52.5 lst:-58.5 cnt:39
Readings:
2016-02-10 01:29:02 Activity alive
2016-02-13 15:33:46 CommandAccepted yes
2016-02-06 12:17:35 D-firmware 1.7
2016-02-06 12:17:35 D-serialNr MEQ0726799
2016-02-12 18:36:26 PairedTo 0x27D0E2
2016-02-06 23:45:05 R-pairCentral 0x27D0E2
2016-02-06 23:45:06 R-sign on
2016-02-12 18:36:26 RegL_00. 02:01 05:00 0A:27 0B:D0 0C:E2 12:50 00:00
2016-02-12 18:36:26 RegL_01. 08:01 00:00
2016-02-13 15:33:46 aesCommToDev ok
2016-02-13 20:07:47 aesKeyNbr 04
2016-02-13 15:33:46 battery ok
2016-02-13 15:33:46 deviceMsg off (to VCCU_0)
2016-02-13 15:33:46 level 0
2016-02-13 15:33:46 pct 0
2016-02-13 15:33:46 recentStateType ack
2016-02-14 16:13:49 state set_off
2016-02-13 15:33:46 timedOn off
cmdStack:
++A01127D0E23C97BD0201000000
++A01127D0E23C97BD0201000000
Helper:
AESreqAck 7391B4CA
HM_CMDNR 32
cSnd 1127D0E23C97BD0201000000,1127D0E23C97BD0201000000
dlvl 00
dlvlCmd ++A01127D0E23C97BD0201000000
mId 006C
peerIDsRaw ,00000000
rxType 2
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +3C97BD,00,02,00
nextSend 1455390467.80623
rxt 0
vccu VCCU_0
p:
3C97BD
00
02
00
prefIO:
CUL_0
Mrssi:
mNo 20
Io:
CUL_0 -56.5
Prt:
bErr 0
sProc 1
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
prs 1
Rssi:
Cul_0:
avg -59.8571428571429
cnt 7
lst -73
max -54
min -73
At_cul_0:
avg -57.0769230769231
cnt 39
lst -58.5
max -52.5
min -71.5
Shadowreg:
Attributes:
IODev CUL_0
IOgrp VCCU_0:CUL_0
actCycle 028:00
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.7
model HM-LC-SW1-BA-PCB
msgRepeat 1
peerIDs 00000000,
room Alarmanlage,Kueche
serialNr MEQ0726799
subType switch
webCmd statusRequest:toggle:on:off
FileLog:
016-02-13_15:33:45 Alarmgeber_Piezo_Kueche set_off
2016-02-13_15:33:46 Alarmgeber_Piezo_Kueche aesKeyNbr: 04
2016-02-13_15:33:46 Alarmgeber_Piezo_Kueche aesCommToDev: ok
2016-02-13_15:33:46 Alarmgeber_Piezo_Kueche battery: ok
2016-02-13_15:33:46 Alarmgeber_Piezo_Kueche deviceMsg: off (to VCCU_0)
2016-02-13_15:33:46 Alarmgeber_Piezo_Kueche level: 0
2016-02-13_15:33:46 Alarmgeber_Piezo_Kueche pct: 0
2016-02-13_15:33:46 Alarmgeber_Piezo_Kueche off
2016-02-13_15:33:46 Alarmgeber_Piezo_Kueche timedOn: off
2016-02-13_20:07:46 Alarmgeber_Piezo_Kueche set_off
2016-02-13_20:07:47 Alarmgeber_Piezo_Kueche aesKeyNbr: 04
2016-02-13_23:42:33 Alarmgeber_Piezo_Kueche set_off
2016-02-14_16:13:49 Alarmgeber_Piezo_Kueche set_off
Wenn ich jetzt den Knopf des Aktors betätigen würde, ist mit großer Wahrscheinlichkeit alles wieder in Ordnung.
Kann dies vielleicht an einer zu gerigen Batteriespannung liegen?
Wie bereits erwähnt, wurde das LowBat Limit auf 8V gestellt - eine Warnmeldung kam jedoch nicht.
Viele Grüße,
ambiman
Hallo zusammen,
vor einigen Tagen habe ich mal den 9V-Block zur Versorgung des Aktors und der Piezosirene gegen einen nagelneuen Block getauscht. Das hat einige Tage anstandslos funktioniert, dann hatte ich das gleiche Phänomen wieder. Der Aktor scheint definitiv nicht auf die Burst-Message zu reagieren.
Anbei einige Infos:
List des Aktors im "Dead" Status:
Internals:
CUL_0_MSGCNT 9
CUL_0_RAWMSG A1109A0023C97BD27D0E204B435EEFBF77504::-49.5:CUL_0
CUL_0_RSSI -49.5
CUL_0_TIME 2016-02-24 05:56:22
DEF 3C97BD
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 9
NAME Alarmgeber_Piezo_Kueche
NR 118
NTFY_ORDER 50-Alarmgeber_Piezo_Kueche
STATE set_off
TYPE CUL_HM
lastMsg No:09 - t:02 s:3C97BD d:27D0E2 04B435EEFBF77504
protCmdPend 4 CMDs_pending
protLastRcv 2016-02-24 05:56:22
protResnd 1 last_at:2016-02-24 03:53:41
protSnd 14 last_at:2016-02-24 05:56:22
protState CMDs_processing...
rssi_CUL_0 avg:-48.5 min:-49 max:-48 lst:-49 cnt:2
rssi_at_CUL_0 avg:-49 min:-49.5 max:-48.5 lst:-49.5 cnt:9
Readings:
2016-02-25 10:23:46 Activity dead
2016-02-22 20:28:36 CommandAccepted yes
2016-02-22 19:42:41 D-firmware 1.7
2016-02-22 19:42:41 D-serialNr MEQ0726799
2016-02-22 23:45:06 PairedTo 0x27D0E2
2016-02-22 23:45:06 R-pairCentral 0x27D0E2
2016-02-22 23:45:06 R-sign on
2016-02-22 23:45:06 RegL_00. 02:01 05:00 0A:27 0B:D0 0C:E2 12:50 00:00
2016-02-22 23:45:06 RegL_01. 08:01 00:00
2016-02-22 20:28:36 aesCommToDev ok
2016-02-24 05:56:22 aesKeyNbr 04
2016-02-24 03:53:42 battery ok
2016-02-24 03:53:42 deviceMsg off (to VCCU_0)
2016-02-24 03:53:42 level 0
2016-02-24 03:53:42 pct 0
2016-02-24 03:53:42 recentStateType info
2016-02-24 06:35:30 state set_off
2016-02-24 03:53:42 timedOn off
cmdStack:
++A01127D0E23C97BD0201000000
++A01127D0E23C97BD0201000000
++A00127D0E23C97BD010E
++A00127D0E23C97BD010E
Helper:
AESreqAck BEB7634F
HM_CMDNR 9
cSnd 0127D0E23C97BD010E,1127D0E23C97BD0201C80000E100
dlvl 00
dlvlCmd ++A01127D0E23C97BD0201000000
mId 006C
peerIDsRaw ,00000000
rxType 2
stateUpdatDly 180
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +3C97BD,00,02,00
nextSend 1456289782.43098
rxt 0
vccu VCCU_0
p:
3C97BD
00
02
00
prefIO:
CUL_0
Mrssi:
mNo 09
Io:
CUL_0 -47.5
Prt:
bErr 0
sProc 1
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
prs 1
Rssi:
Cul_0:
avg -48.5
cnt 2
lst -49
max -48
min -49
At_cul_0:
avg -49
cnt 9
lst -49.5
max -48.5
min -49.5
Shadowreg:
Attributes:
IODev CUL_0
IOgrp VCCU_0:CUL_0
actCycle 028:00
actStatus dead
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.7
model HM-LC-SW1-BA-PCB
msgRepeat 1
peerIDs 00000000,
room Alarmanlage,Kueche
serialNr MEQ0726799
subType switch
webCmd statusRequest:toggle:on:off
Sowie weitere Logauszüge:
Als der Aktor "Dead" war und bereits einige CMDs pending waren, hat der CUL auch keinerlei Messages (Burst?) verschickt? Ist das so gewollt? Siehe Log:
2016.02.25 18:35:59.834 3: CUL_HM set Alarmgeber_Piezo_Kueche off
2016.02.25 18:35:59.858 4: name: /fhem?cmd.Alarmgeber_Piezo_Kueche=set%20Alarmgeber_Piezo_Kueche%20off&room=Kueche&XHR=1&fw_id=1961 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
2016.02.25 18:37:42.398 5: Cmd: >set Alarmgeber_Piezo_Kueche statusRequest<
2016.02.25 18:37:42.404 3: CUL_HM set Alarmgeber_Piezo_Kueche statusRequest
2016.02.25 18:37:42.428 4: name: /fhem?cmd.Alarmgeber_Piezo_Kueche=set%20Alarmgeber_Piezo_Kueche%20statusRequest&room=Kueche&XHR=1&fw_id=1961 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
Nach dem Drücken des Tasters auf dem Aktor, ist dieser Erwacht und die Sirene ging prompt los, der CMD-Stack wurde anschließend abgearbeitet:
2016.02.25 18:38:30.368 4: CUL_Parse: CUL_0 A 0D 0B A410 3C97BD 27D0E2 0601C80032 -49
2016.02.25 18:38:30.384 3: CUL_HM Alarmgeber_Piezo_Kueche repeat, level C8 instead of 00
2016.02.25 18:38:30.471 4: CUL_send: CUL_0As 0E 0C A011 27D0E2 3C97BD 0201000000
2016.02.25 18:38:30.485 5: CUL_HM Alarmgeber_Piezo_Kueche protEvent:CMDs_processing... pending:8
2016.02.25 18:38:30.491 4: CUL_send: CUL_0As 0A 0B 8002 27D0E2 3C97BD 00
2016.02.25 18:38:30.504 5: CUL_HM Alarmgeber_Piezo_Kueche protEvent:CMDs_processing... pending:8
2016.02.25 18:38:30.506 5: CUL_HM Alarmgeber_Piezo_Kueche sent ACK:2
2016.02.25 18:38:30.518 5: Triggering Alarmgeber_Piezo_Kueche (6 changes)
2016.02.25 18:38:30.520 5: Notify loop for Alarmgeber_Piezo_Kueche battery: ok
Nun ist alles wieder in Ordnung :-\
Woran kann das liegen ?
Viele Grüße,
ambiman
fhem sendet bei Anforderung (Kommando). Stehen schon Kommandos in der Queue werden weiteren hinten eingestellt, der Mechanismus sollte schon laufen. Also kein Burst, das ist kontraproduktiv.
Nun kann es in Einzelfällen kompliziert werden. Wenn ein Burstdevice die Kommunikation abbricht oder erst garnicht beginnt. Dies automatisch zu wiederholen - insbesondere bei burst - kostet erheblich IO Resourcen.
Diese Fälle müssen also alle einzeln betrachtet und abgefangen werden. Einige sind es auch, es kann (wahrschienlich) noch Lücken geben.
User sollten sich darüber klar sein - HMInfo sollte hier die entsprechenden Alarme setzen. Nutzt man das nicht muss man seinen eigenen Weg finden.
Um die "Gesundheit" des Systems zu prüfen also HMInfo Seite ansehen. pending Kommandos werden als "warning level" angezeigt. Ist erst einmal nicht schlimm. Aber nicht üblich - auf dauer.
attr hm autoUpdate 0:3um hier aktuell zu bleiben.
nun hast du ein "pending" - also mal nachsehen
Zitatget hm protoEvents
da stehen mit unter auch alte Ereignisse drin. Es ist an dir, das zu "bestätigen". Das machst du, indem du alte Ereignisse löschst. Am einfachsten über alles:
set hm clearG msgEventsAchtung: a) das clearG baue ich erst heute ein - clear geht schon lange.
b) das kommando löscht auch die Kommand-queue. Also alle zum Senden anstehende messages.
=> Damit ist alles auf Los. Wenn du nun ein Kommando sendest wird ein Burst probiert.
Du kannst das ganze auch Selktiv am Device machen. Wenn du schon weist, dass da ein Problem ist. HMInfo zeigt einfach alle.
Wenn du den Fall nachstellst und zusammenfasst, in welchem Fall die Queue zum Erliegen kommt schicke die Info. Dann kann man überlegen, ob es automatisch gelöst werden kann oder ob der User einfach mal die Systemalarme auch auswerten sollte.