Hallo Martin,
folgendes habe ich beobachtet:
Die Devices sind Rauchmelder, mittels IOgrp nur auf vccu eingestellt ohne Preferred IO.
Zwei Devices werden nach dem periodischen StatusRequest auf unreachable gesetzt, obwohl eigentlich nur ein Device abgefragt wird, welches darüber hinaus nicht wirklich unerreichbar ist.
Internals:
DEF 2EF654
HMLAN0_MSGCNT 4
HMLAN0_RAWMSG E2EF654,0000,09291378,FF,FFD3,04A0102EF6541234560601010028
HMLAN0_RSSI -45
HMLAN0_TIME 2015-06-27 09:45:49
HMLAN1_MSGCNT 7
HMLAN1_RAWMSG R33FABF3F,0001,3C7EC341,FF,FFD4,04A0102EF6541234560601010028
HMLAN1_RSSI -44
HMLAN1_TIME 2015-06-27 09:45:48
HMLAN2_MSGCNT 3
HMLAN2_RAWMSG E2EF654,0000,07ADB9BF,FF,FFA4,04A0102EF6541234560601010028
HMLAN2_RSSI -92
HMLAN2_TIME 2015-06-27 09:45:48
HMUSB0_MSGCNT 5
HMUSB0_RAWMSG E2EF654,0000,8B328566,FF,FFC2,04A0102EF6541234560601010028
HMUSB0_RSSI -62
HMUSB0_TIME 2015-06-27 09:45:49
HMUSB1_MSGCNT 4
HMUSB1_RAWMSG E2EF654,0000,5F45671D,FF,FFB1,04A0102EF6541234560601010028
HMUSB1_RSSI -79
HMUSB1_TIME 2015-06-27 09:45:48
IODev HMLAN1
LASTInputDev HMUSB0
MSGCNT 23
NAME JWR_RM
NR 380
NTFY_ORDER 50-JWR_RM
STATE unreachable
TYPE CUL_HM
lastMsg No:04 - t:10 s:2EF654 d:123456 0601010028
peerList Rauchmelder_Team,
protLastRcv 2015-06-27 09:45:49
protSnd 10 last_at:2015-06-27 09:45:48
protState CMDs_done
rssi_HMLAN1 avg:-39.66 min:-40 max:-39 lst:-40 cnt:3
rssi_HMUSB0 avg:-60 min:-60 max:-60 lst:-60 cnt:1
rssi_at_HMLAN0 avg:-45 min:-45 max:-45 lst:-45 cnt:4
rssi_at_HMLAN1 avg:-44 min:-44 max:-44 lst:-44 cnt:7
rssi_at_HMLAN2 avg:-86.66 min:-92 max:-83 lst:-92 cnt:3
rssi_at_HMUSB0 avg:-62.2 min:-63 max:-61 lst:-62 cnt:5
rssi_at_HMUSB1 avg:-78.75 min:-79 max:-78 lst:-79 cnt:4
CHANGETIME:
Helper:
Dblog:
Activity:
Eventlog:
TIME 1435387493.91763
VALUE alive
Battery:
Eventlog:
TIME 1435391148.19032
VALUE ok
Level:
Eventlog:
TIME 1435391148.19032
VALUE 1
State:
Eventlog:
TIME 1435391152.6416
VALUE unreachable
Readings:
2015-06-27 08:44:53 Activity alive
2015-02-16 10:12:59 CommandAccepted yes
2015-02-16 10:15:34 D-firmware 1.1
2015-02-16 10:15:34 D-serialNr LEQ0726113
2015-02-16 10:18:30 PairedTo 0x123456
2015-02-16 10:11:01 R-pairCentral 0x123456
2015-02-16 10:18:30 RegL_00: 02:01 0A:12 0B:34 0C:56 00:00
2015-06-27 09:45:48 battery ok
2015-06-27 09:45:48 level 1
2015-06-27 08:44:53 peerList Rauchmelder_Team,
2015-02-16 10:18:29 powerOn 2015-02-16 10:18:29
2015-06-27 09:45:48 recentStateType info
2015-02-16 10:21:21 smoke_detect -
2015-06-27 09:45:52 state unreachable
2015-02-16 10:20:12 teamCall from Team_RM_Dev:1
Helper:
HM_CMDNR 4
cSnd 011234562EF654010E,011234562EF654010E
mId 0042
rxType 2
Io:
newChn +2EF654,00,01,00
nextSend 1435391149.24916
rxt 0
vccu CCU
p:
2EF654
00
01
00
Mrssi:
mNo 04
Io:
HMLAN0 -45
HMLAN1 -42
HMLAN2 -92
HMUSB0 -62
HMUSB1 -79
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO HMLAN1
flg A
ts 1435391148.58805
ack:
HASH(0x1f491e0)
0480021234562EF65400
Rssi:
Hmlan1:
avg -39.6666666666667
cnt 3
lst -40
max -39
min -40
Hmusb0:
avg -60
cnt 1
lst -60
max -60
min -60
At_hmlan0:
avg -45
cnt 4
lst -45
max -45
min -45
At_hmlan1:
avg -44
cnt 7
lst -44
max -44
min -44
At_hmlan2:
avg -86.6666666666667
cnt 3
lst -92
max -83
min -92
At_hmusb0:
avg -62.2
cnt 5
lst -62
max -61
min -63
At_hmusb1:
avg -78.75
cnt 4
lst -79
max -78
min -79
Attributes:
IODev HMLAN1
IOgrp CCU
actCycle 099:00
actStatus alive
alias Rauchmelder Waffenraum
autoReadReg 4_reqStatus
devStateIcon off:general_ok *:secur_alarm
expert 2_full
firmware 1.1
group Rauchmelder
icon secur_smoke_detector
model HM-SEC-SD
msgRepeat 1
peerIDs 00000000,11211201,
room Waffenraum
serialNr LEQ0726113
subType smokeDetector
webCmd statusRequest
Internals:
DEF 332154
HMLAN0_MSGCNT 5
HMLAN0_RAWMSG E332154,0000,0928CAF6,FF,FFC6,05A0103321541234560601000021
HMLAN0_RSSI -58
HMLAN0_TIME 2015-06-27 09:45:29
HMLAN1_MSGCNT 5
HMLAN1_RAWMSG E332154,0000,3C7E7ABA,FF,FFC8,05A0103321541234560601000021
HMLAN1_RSSI -56
HMLAN1_TIME 2015-06-27 09:45:29
HMLAN2_MSGCNT 5
HMLAN2_RAWMSG E332154,0000,07AD713D,FF,FFBA,05A0103321541234560601000021
HMLAN2_RSSI -70
HMLAN2_TIME 2015-06-27 09:45:29
HMUSB0_MSGCNT 10
HMUSB0_RAWMSG R33FA76B9,0001,8B323CEC,FF,FFDD,05A0103321541234560601000021
HMUSB0_RSSI -35
HMUSB0_TIME 2015-06-27 09:45:29
HMUSB1_MSGCNT 5
HMUSB1_RAWMSG E332154,0000,5F451EA0,FF,FFB2,05A0103321541234560601000021
HMUSB1_RSSI -78
HMUSB1_TIME 2015-06-27 09:45:29
IODev HMUSB0
LASTInputDev HMUSB1
MSGCNT 30
NAME ASR_RM
NR 545
NTFY_ORDER 50-ASR_RM
STATE unreachable
TYPE CUL_HM
lastMsg No:05 - t:10 s:332154 d:123456 0601000021
peerList Rauchmelder_Team,
protLastRcv 2015-06-27 09:45:29
protSnd 10 last_at:2015-06-27 09:45:29
protState CMDs_done
rssi_HMUSB0 avg:-33 min:-33 max:-33 lst:-33 cnt:5
rssi_at_HMLAN0 avg:-58 min:-58 max:-58 lst:-58 cnt:5
rssi_at_HMLAN1 avg:-55.8 min:-56 max:-55 lst:-56 cnt:5
rssi_at_HMLAN2 avg:-70.4 min:-72 max:-70 lst:-70 cnt:5
rssi_at_HMUSB0 avg:-35 min:-35 max:-35 lst:-35 cnt:10
rssi_at_HMUSB1 avg:-78.8 min:-79 max:-78 lst:-78 cnt:5
CHANGETIME:
Helper:
Dblog:
Activity:
Eventlog:
TIME 1435387491.49675
VALUE alive
Battery:
Eventlog:
TIME 1435391129.49294
VALUE ok
Level:
Eventlog:
TIME 1435391129.49294
VALUE 0
State:
Eventlog:
TIME 1435391133.95458
VALUE unreachable
Readings:
2015-06-27 08:44:51 Activity alive
2015-06-21 10:17:05 CommandAccepted yes
2015-06-21 10:17:13 D-firmware 1.1
2015-06-21 10:17:13 D-serialNr LEQ0724541
2015-06-21 10:20:46 PairedTo 0x123456
2015-06-21 10:12:25 R-pairCentral 0x123456
2015-06-21 10:20:46 RegL_00: 02:01 0A:12 0B:34 0C:56 00:00
2015-06-27 09:45:29 battery ok
2015-06-27 09:45:29 level 0
2015-06-27 08:44:51 peerList Rauchmelder_Team,
2015-06-21 10:20:39 powerOn 2015-06-21 10:20:39
2015-06-27 09:45:29 recentStateType info
2015-06-27 09:45:33 state unreachable
Helper:
HM_CMDNR 5
cSnd 01123456332154010E,01123456332154010E
mId 0042
rxType 2
Io:
newChn +332154,00,01,00
nextSend 1435391129.94802
rxt 0
vccu CCU
p:
332154
00
01
00
Mrssi:
mNo 05
Io:
HMLAN0 -58
HMLAN1 -56
HMLAN2 -70
HMUSB0 -33
HMUSB1 -78
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO HMLAN2
flg A
ts 1435391129.48255
ack:
HASH(0x27a05d8)
05800212345633215400
Rssi:
Hmusb0:
avg -33
cnt 5
lst -33
max -33
min -33
At_hmlan0:
avg -58
cnt 5
lst -58
max -58
min -58
At_hmlan1:
avg -55.8
cnt 5
lst -56
max -55
min -56
At_hmlan2:
avg -70.4
cnt 5
lst -70
max -70
min -72
At_hmusb0:
avg -35
cnt 10
lst -35
max -35
min -35
At_hmusb1:
avg -78.8
cnt 5
lst -78
max -78
min -79
Attributes:
IODev HMUSB0
IOgrp CCU
actCycle 099:00
actStatus alive
alias Rauchmelder Anschlussraum
autoReadReg 4_reqStatus
devStateIcon off:general_ok *:secur_alarm
expert 2_full
firmware 1.1
group Rauchmelder
icon secur_smoke_detector
model HM-SEC-SD
msgRepeat 1
peerIDs 00000000,11211201,
room Anschlussraum
serialNr LEQ0724541
subType smokeDetector
webCmd statusRequest
Verbose=5:
2015-06-27_10:19:59 ASR_RM battery: ok
2015-06-27_10:19:59 ASR_RM level: 0
2015-06-27_10:19:59 ASR_RM off
2015-06-27_10:45:44 ASR_RM battery: ok
2015-06-27_10:45:44 ASR_RM level: 0
2015-06-27_10:45:44 ASR_RM off
2015-06-27_10:45:49 ASR_RM unreachable
2015-06-27_10:20:09 JWR_RM battery: ok
2015-06-27_10:20:09 JWR_RM level: 1
2015-06-27_10:20:09 JWR_RM off
2015-06-27_10:46:01 JWR_RM battery: ok
2015-06-27_10:46:01 JWR_RM level: 1
2015-06-27_10:46:01 JWR_RM off
2015-06-27_10:46:05 JWR_RM unreachable
Man sieht schön, dass der Readings erfolgreich upgedated werden und trotzdem die RM 4 bzw. 5 Sekunden später unreachable bekommen?!
Nach Rückkehr zu den Versionen
# $Id: 10_CUL_HM.pm 8787 2015-06-20 23:18:22Z martinp876 $
# $Id: 00_HMLAN.pm 8768 2015-06-18 06:36:07Z martinp876 $
alles wieder bestens.
Hallo Martin,
die beiden neuen Versionen von 00_HMLAN.pm (8835 vom 26.06.2015 und 8816 vom 24.06.2015) und 10_CUL_HM.pm (8840 vom 26.06.2015 und 8806 vom 22.06.2015) verursachen bei mir im Log folgendes Problem:
2015.06.27 11:58:29 1: PERL WARNING: Use of uninitialized value $trafficHour in concatenation (.) or string at (eval 59) line 4.
2015.06.27 11:58:29 3: eval: {
my $trafficStr = InternalVal("HMLAN1","msgLoadEst","???");
my $trafficHour = $1 if($trafficStr =~ m/1hour:(.*)% 10min steps/);
fhem("set Log_Technik_IO hmTrfHour: ".$trafficHour." %");
}
Zugehöriger Codeausschnitt:
define a_hmlan_Min_by_Min at +*00:01:00 {\
my $trafficStr = InternalVal("HMLAN1","msgLoadEst","???");;\
my $trafficHour = $1 if($trafficStr =~ m/1hour:(.*)% 10min steps/);;\
fhem("set Log_Technik_IO hmTrfHour: ".$trafficHour." %");;\
}
Gehe ich auf die von Ralli genannten Versionen zurück, ist alles wieder i.O.
Grüße,
Nik
Hallo Mr.Flash,
das hat aber mit meinem Problem überhaupt nichts zu tun. Du musst einfach nur Deinen Code anpassen. Das Internal, was Du abfragst, gibt es nicht mehr. Dafür zwei andere.
Hallo Ralli,
sorry, war von den beiden betroffenen Dateien mit den gleichen Versionsabgaben "geblendet" 8).
Hab's inzwischen analysiert und werde den Code entspechend hintrimmen.
Grüße,
Nik
Hi Ralli,
ich hab das gleiche Probleme wie du state ist immer unreachable.
Zum Brand abfragen kann man ja wirklich smoke_detect nehmen.
Aber um den die Verfügbarkeit der Rauchmelder.
Komisch ist halt sobald man einen StatusRequest ausführt wird der Rauchmelder als off gekennzeichnet.
Gruß Robert
Ja, ist bei mir auch so. Wenn ich einen manuellen Statusrequest durchführe, ist alles gut.
Habe das gleiche Problem mit einem HM-ES-PMSw1-Pl (Firmware 1.6)
Nach dem Update bekomme ich MIssing-ACK.
ein Rollback auf die Vorversion von CUL_HMLAN und HMLAN hat dann geholfen.
Kann mir einer Kurz erklären, wie ich die alten Dateien wieder einspiele?
Bei mir sind es alle 3 Rauchmelder und der Repeater, bin auch eine Version zurück gegangen und alles ist gut. Rauchmelder hatten auch kein prefered IO (vccu) nur der Repeater ist mit HMLAN1 "verheiratet".
VG
Frank
der status request auf meinen rauchmelder scheint sauber zu funktionieren:
2015.06.27 18:16:54.129 0: HMLAN_Send: hmlan1 S:S35CEAEBB stat: 00 t:00000000 d:01 r:35CEAEBB m:03 B001 1ACE1F 52C4DF 010E
2015.06.27 18:16:54.536 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:00394BA4 d:FF r:FFD9 m:03 B001 1ACE1F 52C4DF 010E
2015.06.27 18:16:54.663 0: HMLAN_Parse: hmlan1 R:E52C4DF stat:0000 t:0910FB62 d:FF r:FFC3 m:03 A010 52C4DF 1ACE1F 060101003B
2015.06.27 18:16:54.987 0: HMLAN_Parse: hmlan1 R:R35CEAEBB stat:0001 t:0910FB67 d:FF r:FFC3 m:03 A010 52C4DF 1ACE1F 060101003B
2015.06.27 18:16:55.008 0: HMLAN_Parse: hmusb1 R:E52C4DF stat:0000 t:00394C2F d:FF r:FFC7 m:03 A010 52C4DF 1ACE1F 060101003B
2015.06.27 18:16:55.022 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:00394CAC d:FF r:FFDA m:03 8002 1ACE1F 52C4DF 00
im filelog wird aber immer 3-5s nach dem realen state (off) der state unreachable gemeldet:
2015-06-27_18:16:54 SD.AZ off
2015-06-27_18:16:59 SD.AZ unreachable
Bis zu Versionen
# $Id: 10_CUL_HM.pm 8829 2015-06-26 07:13:01Z martinp876 $
# $Id: 00_HMLAN.pm 8816 2015-06-24 18:59:46Z martinp876 $
ist alles gut.
sollte wieder alles gut sein (morgen oder heute aus SVN).
Da sind aber noch viele andere schöne Dinge mit eingeflossen :).
Teste morgen.
Sieht bis jetzt gut aus :)
P.S. zu früh gefreut, jetzt gehen meine vier HM-ES-PMSw1-Pl nach ca.5 min auf unreachable. Rauchmelder und Repeater waren OK. Ist jetzt etwas spät um zu loggen, bin erst mal wieder zurück auf die
# $Id: 10_CUL_HM.pm 8806 2015-06-22 20:10:21Z martinp876 $
# $Id: 00_HMLAN.pm 8796 2015-06-21 17:35:22Z martinp876 $
da ist bis jetzt alles OK
VG
Frank
VG
Frank
Bei mir bis jetzt alles gut:
# $Id: 10_CUL_HM.pm 8846 2015-06-27 18:06:00Z martinp876 $
# $Id: 00_HMLAN.pm 8835 2015-06-26 10:54:48Z martinp876 $
# $Id: 98_HMinfo.pm 8847 2015-06-27 18:34:45Z martinp876 $
Allerdings habe ich auch keine HM-ES-PMSw1-Pl.
Bei mir das gleiche...ich habe heute das Update eingespielt,aber meine drei HM-ES-PMSw1-Pl gehen nach ca.5 min auf unreachable :-[
VG
Falkes
Also bei den Rauchmeldern scheint es zu gehen.
Hab das update aber auch noch keine Halbe Stunde auf meinem system.
Ich habe ein Rollback auf die Vorversion von HMLAN gemacht,mit dieser läuft wieder alles wie es soll ohne Probleme.
VG
Falkes
Hatte ich gestern schon geschrieben, update gestern abend aus dem SVN, Rauchmelder und Repeater waren OK aber die Leistungsmesser HM-ES-PMSw1-Pl gehen nach ca. 5 min auf unreachable. Bin auch wieder auf eine Version vorher zurück gegangen.
Da müsste Martin nochmal drüber schauen.
VG
Frank
Oh...da habe ich mich wohl zu früh gefreut :( Selbst nach einen Rollback auf die Vorversion von HMLAN gehen meine HM-ES-PMSw1-Pl nach ca.5-8 min auf unreachable.
Da ist wohl doch mehr verändert worden als "nur" HMLAN und CUL_HMLAN ??? Bis vorgestern lief alles super,gestern Früh ein Update gemacht und kam dann der Fehler. Ich werde mal ein komplettes Backup vor dem Update gestern Früh vom Fhem wieder einspielen...
VG
Falkes
Rauchmelder geht auch bei mir, aber die ES-PMSw1-PL wollen noch nicht so richtig.
2015.06.28 10:44:13 3: CUL_HM set CUL_HM_HM_ES_PMSw1_Pl_2AB693_Sw statusRequest
2015.06.28 10:44:22 1: PERL WARNING: Argument "unreachable" isn't numeric in numeric lt (<) at (eval 2281) line 1.
2015.06.28 10:44:24 3: CUL_HM set CUL_HM_HM_ES_PMSw1_Pl_34260F_Sw statusRequest
Ich bin auf Version:
# $Id: 10_CUL_HM.pm 8806 2015-06-22 20:10:21Z martinp876 $
# $Id: 00_HMLAN.pm 8796 2015-06-21 17:35:22Z martinp876 $
Damit funktionieren die Rauchmelder, der Repeater und die Leistungsmesser. Was bleibt ist dann aber wieder das Overload Problem.
VG
Frank
Bei mir steht der Leistungsmesser zwar auf unreachable, lässt sich aber schalten.
Unreachable ist, wenn ein statusrequest nicht beantwortet wird. Schalten kann man dann immernoch.
Ich werde mir den leistungsmesser ansehen.
Bei mir ist es nach einem shutdown restart auch bei einem HM-LC-SW1-FM und bei einem HM-LC-Dim1TPBU-FM kurz zu einem unreachable gekommen, wenige Sekunden danach war dann der richtige Status aber da.
habe das Problem erkannt. Es tritt bei Devices mit mehr Kanälen auf - ist behoben
Jep .. bei mir geht der HM-ES-PMSw1-Pl nach ca. 5 Min auf unreachable.
Allerdings funktioniert er weiterhin einwandfrei.
Nur eben in der GUI steht er auf unreachable.
Hallo Martin,
vielen Dank - aber das Timing ist immer noch nicht perfekt:
2015-06-28 13:34:55 ANB_Aussensteckdosen CUL_HM deviceMsg: off (to CCU) deviceMsg off (to CCU)
2015-06-28 13:34:55 ANB_Aussensteckdosen CUL_HM level: 0 level 0
2015-06-28 13:34:55 ANB_Aussensteckdosen CUL_HM pct: 0 pct 0
2015-06-28 13:34:55 ANB_Aussensteckdosen CUL_HM off state off
2015-06-28 13:34:55 ANB_Aussensteckdosen CUL_HM timedOn: off timedOn off
2015-06-28 13:34:54 ANB_Aussensteckdosen CUL_HM unreachable state unreachable
Hierbei handelt es sich wohlgemerkt um einen HM-LC-SW1-FM, also ein Device mit nur einem Kanal.
Bei meinen HM-ES-PMSw1-Pl funktioniert es auch noch nicht richtig. Der selbe Problem wie vorher...
VG
Falkes
Und mit einer Output-Unit tritt nun auch ein Problem auf:
Mittendrin auf einmal ein unreachable.
2015-06-28 14:37:55 GEN_LED1 CUL_HM CMDs_done state CMDs_done
2015-06-28 14:37:54 GEN_LED1 CUL_HM color: AA966ABA color AA966ABA
2015-06-28 14:37:54 GEN_LED1 CUL_HM AA966ABA state AA966ABA
2015-06-28 14:37:54 GEN_LED1 CUL_HM color: AA966ABA color AA966ABA
2015-06-28 14:37:54 GEN_LED1 CUL_HM AA966ABA state AA966ABA
2015-06-28 14:37:53 GEN_LED1 CUL_HM color: AA966ABA color AA966ABA
2015-06-28 14:37:53 GEN_LED1 CUL_HM AA966ABA state AA966ABA
2015-06-28 14:37:52 GEN_LED1 CUL_HM color: AA966ABA color AA966ABA
2015-06-28 14:37:52 GEN_LED1 CUL_HM AA966ABA state AA966ABA
2015-06-28 14:37:51 GEN_LED1 CUL_HM color: AA966ABA color AA966ABA
2015-06-28 14:37:51 GEN_LED1 CUL_HM AA966ABA state AA966ABA
2015-06-28 14:37:51 GEN_LED1 CUL_HM color: AA966ABA color AA966ABA
2015-06-28 14:37:51 GEN_LED1 CUL_HM AA966ABA state AA966ABA
2015-06-28 14:37:51 GEN_LED1 CUL_HM color: AA966ABA color AA966ABA
2015-06-28 14:37:51 GEN_LED1 CUL_HM AA966ABA state AA966ABA
2015-06-28 14:37:51 GEN_LED1 CUL_HM color: AA966ABA color AA966ABA
2015-06-28 14:37:51 GEN_LED1 CUL_HM AA966ABA state AA966ABA
2015-06-28 14:37:51 GEN_LED1 CUL_HM color: AA966ABA color AA966ABA
2015-06-28 14:37:51 GEN_LED1 CUL_HM AA966ABA state AA966ABA
2015-06-28 14:37:51 GEN_LED1 CUL_HM color: AA966ABA color AA966ABA
2015-06-28 14:37:51 GEN_LED1 CUL_HM AA966ABA state AA966ABA
2015-06-28 14:37:51 GEN_LED1 CUL_HM color: AA966ABA color AA966ABA
2015-06-28 14:37:51 GEN_LED1 CUL_HM AA966ABA state AA966ABA
2015-06-28 14:37:49 GEN_LED1 CUL_HM color: AA966ABA color AA966ABA
2015-06-28 14:37:49 GEN_LED1 CUL_HM AA966ABA state AA966ABA
2015-06-28 14:37:48 GEN_LED1 CUL_HM unreachable state unreachable
2015-06-28 14:37:47 GEN_LED1 CUL_HM color: AA966ABA color AA966ABA
2015-06-28 14:37:47 GEN_LED1 CUL_HM AA966ABA state AA966ABA
2015-06-28 14:37:47 GEN_LED1 CUL_HM color: AA966ABA color AA966ABA
2015-06-28 14:37:47 GEN_LED1 CUL_HM AA966ABA state AA966ABA
Unreachable kommt 5sec nach dem request... wenn kein state gemeldet wurde.
Was habt ihr fuer einen trigger ausgeloest ?
Beim led ist es scheinbar jede menge....
Das Problem war bis einschließlich Freitag nicht da. Seit Samstag nach dem Update ist es bei meinen HM-ES-PMSw1-Pl so, nach ca. 5 Min auf unreachable.
Es ist sicherlich mehr bei dem Update verändert worden als HMLAN und CUL_HMLAN ...??? An meiner Konfiguration wurde rein gar nichts verändert.
VG
Falkes
Bei mir ist es so, dass ich erst seit kurzem wirklich auch auf unreachable triggere. Aber aufgefallen sind sie mir auch erst seit den letzten Updates. Und witzigerweise ja nun auch bei den Kollegen :).
Als "Laie" sieht es mir so aus, dass gerade dann, wenn tatsächlich recht viele Meldungen durch fhem abzuarbeiten sind, es insbesondere zu solchen unreachables kommen kann.
Das OU produziert sowieso Unmengen an Traffic bzw. Meldungen. Ist aber nur gepaired mit der vccu, keine Channels mit irgendwelchen Devices gepeered.
Jetzt beim LED:
2015.06.28 15:07:52 3: CUL_HM set GEN_LED1 statusRequest
2015.06.28 15:38:00 3: CUL_HM set GEN_LED1 statusRequest
2015-06-28 15:07:50 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:07:50 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:07:50 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:07:51 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:07:51 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:07:51 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:07:51 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:07:51 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:07:51 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:07:51 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:07:51 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:07:51 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:07:51 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:07:51 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:07:51 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:07:52 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:07:53 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:07:53 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:07:53 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:07:53 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:07:54 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:07:54 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:07:54 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:07:54 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:07:55 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:07:55 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:07:55 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:07:55 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:07:56 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:07:56 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:07:56 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:07:56 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:07:57 GEN_LED1 CUL_HM unreachable state unreachable
2015-06-28 15:07:57 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:07:57 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:07:58 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:07:58 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:07:58 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:07:58 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:07:59 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:07:59 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:07:59 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:07:59 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:08:00 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:08:00 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:08:01 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:08:01 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:08:01 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:08:01 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:08:01 GEN_LED1 CUL_HM CMDs_done state CMDs_done
2015-06-28 15:37:59 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:37:59 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:37:59 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:37:59 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:37:59 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:38:00 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:38:00 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:38:00 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:38:00 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:38:00 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:38:00 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:38:00 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:38:00 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:38:00 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:38:00 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:38:00 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 15:38:01 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:38:01 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:38:01 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:38:01 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:38:02 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:38:02 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:38:02 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:38:02 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:38:03 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:38:03 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:38:03 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:38:03 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:38:04 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:38:04 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:38:05 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:38:05 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:38:05 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:38:05 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:38:05 GEN_LED1 CUL_HM unreachable state unreachable
2015-06-28 15:38:06 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:38:06 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:38:06 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:38:06 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:38:07 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:38:07 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:38:09 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:38:09 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:38:09 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:38:09 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:38:09 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:38:09 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:38:09 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:38:09 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:38:10 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:38:10 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:38:10 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:38:10 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:38:11 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:38:11 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:38:11 GEN_LED1 CUL_HM color: AA966ABB color AA966ABB
2015-06-28 15:38:11 GEN_LED1 CUL_HM AA966ABB state AA966ABB
2015-06-28 15:38:11 GEN_LED1 CUL_HM CMDs_done state CMDs_done
Da kommen ja states. Aber trotzdem ist mittendrin nach den fünf Sekunden ein unreachable. Das passt doch nicht. Scheinbar bringt der auf jeden Fall nach fünf Sekunden ein unreachable, auch wenn vorher andere states angekommen sind.
um es klarzustellen: Ich habe es heute repariert CUL_HM Version 8849 ist notwendig. Das gibt es heute nur aus SVN - habt ihr schon - oder?
Selbstverständlich.
Und es geht weiter:
2015-06-28 16:56:28 GEN_LED1 CUL_HM CMDs_done state CMDs_done
2015-06-28 17:08:22 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:08:22 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:08:22 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:08:22 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:08:22 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:08:22 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:08:22 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:08:23 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:08:23 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:08:23 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:08:23 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:08:23 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:08:23 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:08:23 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:08:23 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:08:23 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:08:24 GEN_LED1 CUL_HM AA96AABB state AA96AABB
2015-06-28 17:08:24 GEN_LED1 CUL_HM AA96AABB state AA96AABB
2015-06-28 17:08:25 GEN_LED1 CUL_HM AA96AABB state AA96AABB
2015-06-28 17:08:25 GEN_LED1 CUL_HM AA96AABB state AA96AABB
2015-06-28 17:08:27 GEN_LED1 CUL_HM AA96AABB state AA96AABB
2015-06-28 17:08:27 GEN_LED1 CUL_HM AA96AABB state AA96AABB
2015-06-28 17:08:27 GEN_LED1 CUL_HM AA96AABB state AA96AABB
2015-06-28 17:08:28 GEN_LED1 CUL_HM AA96AABB state AA96AABB
2015-06-28 17:08:28 GEN_LED1 CUL_HM unreachable state unreachable
2015-06-28 17:08:29 GEN_LED1 CUL_HM AA96AABB state AA96AABB
2015-06-28 17:08:29 GEN_LED1 CUL_HM AA96AABB state AA96AABB
2015-06-28 17:08:30 GEN_LED1 CUL_HM AA96AABB state AA96AABB
2015-06-28 17:08:30 GEN_LED1 CUL_HM AA96AABB state AA96AABB
2015-06-28 17:08:31 GEN_LED1 CUL_HM AA96AABB state AA96AABB
2015-06-28 17:08:32 GEN_LED1 CUL_HM AA96AABB state AA96AABB
2015-06-28 17:08:32 GEN_LED1 CUL_HM AA96AABB state AA96AABB
2015-06-28 17:08:33 GEN_LED1 CUL_HM AA96AABB state AA96AABB
2015-06-28 17:08:33 GEN_LED1 CUL_HM CMDs_done state CMDs_done
2015-06-28 17:10:12 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:10:13 GEN_LED1 CUL_HM AA969ABB state AA969ABB
2015-06-28 17:10:13 GEN_LED1 CUL_HM CMDs_done state CMDs_done
2015-06-28 17:11:42 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:11:43 GEN_LED1 CUL_HM 6A969ABB state 6A969ABB
2015-06-28 17:11:43 GEN_LED1 CUL_HM CMDs_done state CMDs_done
2015-06-28 17:11:49 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:11:49 GEN_LED1 CUL_HM 6A96AABB state 6A96AABB
2015-06-28 17:11:49 GEN_LED1 CUL_HM CMDs_done state CMDs_done
2015-06-28 17:12:06 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:12:06 GEN_LED1 CUL_HM 6996AABB state 6996AABB
2015-06-28 17:12:06 GEN_LED1 CUL_HM CMDs_done state CMDs_done
2015.06.28 16:56:27 3: CUL_HM set GEN_LED1_07 led green
2015.06.28 17:08:23 3: CUL_HM set GEN_LED1 statusRequest
2015.06.28 17:10:12 3: led1_status(7)
2015.06.28 17:10:12 3: CUL_HM set GEN_LED1_07 led red
2015.06.28 17:10:13 3: set pushmsg message ÜEA: Garagentor Benachrichtigung : OK!
ÜEA: Garagentor Benachrichtigung
2015.06.28 17:11:42 3: led1_status(16)
2015.06.28 17:11:43 3: CUL_HM set GEN_LED1_16 led red
2015.06.28 17:11:49 3: led1_status(7)
2015.06.28 17:11:49 3: CUL_HM set GEN_LED1_07 led green
2015.06.28 17:12:06 3: led1_status(13)
2015.06.28 17:12:06 3: CUL_HM set GEN_LED1_13 led red
Wo genau kann man das SVN beziehen bzw herunterladen??
VG
Falkes
Ei im SVN halt.
http://sourceforge.net/p/fhem/code/HEAD/tree/
@Martin: das LED ist auf die vccu gepaired. Im IODev stand CUL0 (der aber ja inaktiv ist), in der IOgrp waren prefIOs eingetragen. Ich habe jetzt mal von Hand das IODev auf ein aktives IO geändert und die prefIOs rausgeworfen. Mal schauen.
Edit:
hat nichts gebracht.
2015.06.28 17:38:31 3: CUL_HM set GEN_LED1 statusRequest
2015-06-28 17:38:48 GEN_LED1 CUL_HM CMDs_done state CMDs_done
2015-06-28 17:38:47 GEN_LED1 CUL_HM color: 6956AABA color 6956AABA
2015-06-28 17:38:47 GEN_LED1 CUL_HM 6956AABA state 6956AABA
2015-06-28 17:38:46 GEN_LED1 CUL_HM color: 6956AABA color 6956AABA
2015-06-28 17:38:46 GEN_LED1 CUL_HM 6956AABA state 6956AABA
2015-06-28 17:38:46 GEN_LED1 CUL_HM color: 6956AABA color 6956AABA
2015-06-28 17:38:46 GEN_LED1 CUL_HM 6956AABA state 6956AABA
2015-06-28 17:38:45 GEN_LED1 CUL_HM color: 6956AABA color 6956AABA
2015-06-28 17:38:45 GEN_LED1 CUL_HM 6956AABA state 6956AABA
2015-06-28 17:38:44 GEN_LED1 CUL_HM color: 6956AABA color 6956AABA
2015-06-28 17:38:44 GEN_LED1 CUL_HM 6956AABA state 6956AABA
2015-06-28 17:38:40 GEN_LED1 CUL_HM color: 6956AABA color 6956AABA
2015-06-28 17:38:40 GEN_LED1 CUL_HM 6956AABA state 6956AABA
2015-06-28 17:38:39 GEN_LED1 CUL_HM color: 6956AABA color 6956AABA
2015-06-28 17:38:39 GEN_LED1 CUL_HM 6956AABA state 6956AABA
2015-06-28 17:38:38 GEN_LED1 CUL_HM color: 6956AABA color 6956AABA
2015-06-28 17:38:38 GEN_LED1 CUL_HM 6956AABA state 6956AABA
2015-06-28 17:38:36 GEN_LED1 CUL_HM color: 6956AABA color 6956AABA
2015-06-28 17:38:36 GEN_LED1 CUL_HM 6956AABA state 6956AABA
2015-06-28 17:38:36 GEN_LED1 CUL_HM unreachable state unreachable
2015-06-28 17:38:35 GEN_LED1 CUL_HM color: 6956AABA color 6956AABA
2015-06-28 17:38:35 GEN_LED1 CUL_HM 6956AABA state 6956AABA
2015-06-28 17:38:35 GEN_LED1 CUL_HM color: 6956AABA color 6956AABA
2015-06-28 17:38:35 GEN_LED1 CUL_HM 6956AABA state 6956AABA
2015-06-28 17:38:34 GEN_LED1 CUL_HM color: 6956AABA color 6956AABA
2015-06-28 17:38:34 GEN_LED1 CUL_HM 6956AABA state 6956AABA
2015-06-28 17:38:34 GEN_LED1 CUL_HM color: 6956AABA color 6956AABA
2015-06-28 17:38:34 GEN_LED1 CUL_HM 6956AABA state 6956AABA
2015-06-28 17:38:33 GEN_LED1 CUL_HM color: 6956AABA color 6956AABA
2015-06-28 17:38:33 GEN_LED1 CUL_HM 6956AABA state 6956AABA
2015-06-28 17:38:32 GEN_LED1 CUL_HM color: 6956AABA color 6956AABA
2015-06-28 17:38:32 GEN_LED1 CUL_HM 6956AABA state 6956AABA
2015-06-28 17:38:32 GEN_LED1 CUL_HM color: 6956AABA color 6956AABA
2015-06-28 17:38:32 GEN_LED1 CUL_HM 6956AABA state 6956AABA
2015-06-28 17:38:31 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:38:31 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:38:31 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:38:31 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:38:31 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:38:31 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:38:30 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:38:30 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:38:30 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:38:30 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:38:30 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:38:30 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:38:30 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:38:30 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:38:30 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
2015-06-28 17:38:30 GEN_LED1 CUL_HM CMDs_pending state CMDs_pending
Edit:
Ich habe jetzt mal die kompletten Logs seit einigen Monaten durchrecherchiert. Ein unreachable gab es definitiv bisher noch nie (!) - erst in den letzten beiden Tagen sind welche geloggt worden!
2015-06-27 08:45:20 ASR_RM CUL_HM unreachable state unreachable
2015-06-27 08:45:30 GEN_LED1 CUL_HM unreachable state unreachable
2015-06-27 08:45:31 GWC_Rollo CUL_HM unreachable state unreachable
2015-06-27 08:45:35 HWR_Wandleuchte CUL_HM unreachable state unreachable
2015-06-27 08:45:37 CUL_HM_HM_LC_Dim1TPBU_FM_26FBDB_ CUL_HM unreachable state unreachable
2015-06-27 08:45:38 CUL_HM_HM_LC_Dim1TPBU_FM_26FBDB_ CUL_HM unreachable state unreachable
2015-06-27 08:45:39 JWR_RM CUL_HM unreachable state unreachable
2015-06-27 08:45:49 KUC_Rollo_Ost CUL_HM unreachable state unreachable
2015-06-27 08:45:49 KUC_Rollo_Sued CUL_HM unreachable state unreachable
2015-06-27 08:45:49 SZ_Deckenlicht CUL_HM unreachable state unreachable
2015-06-27 08:45:50 Rauchmelder_Team CUL_HM unreachable state unreachable
2015-06-27 08:45:56 CUL_HM_HM_LC_Dim1TPBU_FM_26FB98_ CUL_HM unreachable state unreachable
2015-06-27 09:15:26 ASR_RM CUL_HM unreachable state unreachable
2015-06-27 09:15:37 GEN_LED1 CUL_HM unreachable state unreachable
2015-06-27 09:15:41 Rauchmelder_Team CUL_HM unreachable state unreachable
2015-06-27 09:15:46 JWR_RM CUL_HM unreachable state unreachable
2015-06-27 09:18:36 Rauchmelder_Team CUL_HM unreachable state unreachable
2015-06-27 09:45:33 ASR_RM CUL_HM unreachable state unreachable
2015-06-27 09:45:45 GEN_LED1 CUL_HM unreachable state unreachable
2015-06-27 09:45:48 Rauchmelder_Team CUL_HM unreachable state unreachable
2015-06-27 09:45:52 JWR_RM CUL_HM unreachable state unreachable
2015-06-27 10:03:53 Rauchmelder_Team CUL_HM unreachable state unreachable
2015-06-27 10:15:41 ASR_RM CUL_HM unreachable state unreachable
2015-06-27 10:15:53 GEN_LED1 CUL_HM unreachable state unreachable
2015-06-27 10:15:54 Rauchmelder_Team CUL_HM unreachable state unreachable
2015-06-27 10:15:59 JWR_RM CUL_HM unreachable state unreachable
2015-06-27 10:20:00 Rauchmelder_Team CUL_HM unreachable state unreachable
2015-06-27 10:45:49 ASR_RM CUL_HM unreachable state unreachable
2015-06-27 10:46:00 GEN_LED1 CUL_HM unreachable state unreachable
2015-06-27 10:46:01 Rauchmelder_Team CUL_HM unreachable state unreachable
2015-06-27 10:46:05 JWR_RM CUL_HM unreachable state unreachable
2015-06-27 10:52:30 Rauchmelder_Team CUL_HM unreachable state unreachable
2015-06-27 10:52:50 Rauchmelder_Team CUL_HM unreachable state unreachable
2015-06-28 08:03:51 GWC_Rollo CUL_HM unreachable state unreachable
2015-06-28 08:03:57 HWR_Wandleuchte CUL_HM unreachable state unreachable
2015-06-28 08:03:58 CUL_HM_HM_LC_Dim1TPBU_FM_26FBDB_ CUL_HM unreachable state unreachable
2015-06-28 08:04:00 CUL_HM_HM_LC_Dim1TPBU_FM_26FBDB_ CUL_HM unreachable state unreachable
2015-06-28 08:04:01 JWR_RM CUL_HM unreachable state unreachable
2015-06-28 08:04:03 KUC_Rollo_Ost CUL_HM unreachable state unreachable
2015-06-28 08:04:04 KUC_Rollo_Sued CUL_HM unreachable state unreachable
2015-06-28 08:04:05 SZ_Deckenlicht CUL_HM unreachable state unreachable
2015-06-28 08:04:09 TMO_Deckenlicht CUL_HM unreachable state unreachable
2015-06-28 08:04:09 CUL_HM_HM_LC_Dim1TPBU_FM_26FB98_ CUL_HM unreachable state unreachable
2015-06-28 08:04:11 CUL_HM_HM_LC_Dim1TPBU_FM_26FB98_ CUL_HM unreachable state unreachable
2015-06-28 08:04:22 WZ_Rollo_Erker_R CUL_HM unreachable state unreachable
2015-06-28 13:06:25 ANB_Aussensteckdosen CUL_HM unreachable state unreachable
2015-06-28 13:06:58 GWC_Rollo CUL_HM unreachable state unreachable
2015-06-28 13:07:05 HWR_Wandleuchte CUL_HM unreachable state unreachable
2015-06-28 13:07:07 CUL_HM_HM_LC_Dim1TPBU_FM_26FBDB_ CUL_HM unreachable state unreachable
2015-06-28 13:07:09 CUL_HM_HM_LC_Dim1TPBU_FM_26FBDB_ CUL_HM unreachable state unreachable
2015-06-28 13:07:10 JWR_RM CUL_HM unreachable state unreachable
2015-06-28 13:07:10 KUC_Rollo_Ost CUL_HM unreachable state unreachable
2015-06-28 13:07:12 KUC_Rollo_Sued CUL_HM unreachable state unreachable
2015-06-28 13:07:15 SZ_Deckenlicht CUL_HM unreachable state unreachable
2015-06-28 13:07:17 TMO_Deckenlicht CUL_HM unreachable state unreachable
2015-06-28 13:07:21 CUL_HM_HM_LC_Dim1TPBU_FM_26FB98_ CUL_HM unreachable state unreachable
2015-06-28 13:07:21 CUL_HM_HM_LC_Dim1TPBU_FM_26FB98_ CUL_HM unreachable state unreachable
2015-06-28 13:34:54 ANB_Aussensteckdosen CUL_HM unreachable state unreachable
2015-06-28 13:35:16 GEN_LED1 CUL_HM unreachable state unreachable
2015-06-28 13:35:17 GWC_Rollo CUL_HM unreachable state unreachable
2015-06-28 13:35:30 HWR_Wandleuchte CUL_HM unreachable state unreachable
2015-06-28 13:35:32 CUL_HM_HM_LC_Dim1TPBU_FM_26FBDB_ CUL_HM unreachable state unreachable
2015-06-28 13:35:35 CUL_HM_HM_LC_Dim1TPBU_FM_26FBDB_ CUL_HM unreachable state unreachable
2015-06-28 13:35:40 JWR_RM CUL_HM unreachable state unreachable
2015-06-28 13:35:40 KUC_Rollo_Ost CUL_HM unreachable state unreachable
2015-06-28 13:35:40 KUC_Rollo_Sued CUL_HM unreachable state unreachable
2015-06-28 13:35:47 SZ_Deckenlicht CUL_HM unreachable state unreachable
2015-06-28 13:35:47 TMO_Deckenlicht CUL_HM unreachable state unreachable
2015-06-28 13:35:53 CUL_HM_HM_LC_Dim1TPBU_FM_26FB98_ CUL_HM unreachable state unreachable
2015-06-28 13:35:57 CUL_HM_HM_LC_Dim1TPBU_FM_26FB98_ CUL_HM unreachable state unreachable
2015-06-28 14:05:23 GEN_LED1 CUL_HM unreachable state unreachable
2015-06-28 14:07:09 ASR_RM CUL_HM unreachable state unreachable
2015-06-28 14:07:40 GEN_LED1 CUL_HM unreachable state unreachable
2015-06-28 14:07:41 GWC_Rollo CUL_HM unreachable state unreachable
2015-06-28 14:07:46 HWR_Wandleuchte CUL_HM unreachable state unreachable
2015-06-28 14:07:48 CUL_HM_HM_LC_Dim1TPBU_FM_26FBDB_ CUL_HM unreachable state unreachable
2015-06-28 14:07:50 CUL_HM_HM_LC_Dim1TPBU_FM_26FBDB_ CUL_HM unreachable state unreachable
2015-06-28 14:07:51 JWR_RM CUL_HM unreachable state unreachable
2015-06-28 14:07:53 KUC_Rollo_Sued CUL_HM unreachable state unreachable
2015-06-28 14:07:55 SZ_Deckenlicht CUL_HM unreachable state unreachable
2015-06-28 14:37:48 GEN_LED1 CUL_HM unreachable state unreachable
2015-06-28 15:07:57 GEN_LED1 CUL_HM unreachable state unreachable
2015-06-28 15:38:05 GEN_LED1 CUL_HM unreachable state unreachable
2015-06-28 16:08:13 GEN_LED1 CUL_HM unreachable state unreachable
2015-06-28 16:38:21 GEN_LED1 CUL_HM unreachable state unreachable
2015-06-28 17:08:28 GEN_LED1 CUL_HM unreachable state unreachable
2015-06-28 17:38:36 GEN_LED1 CUL_HM unreachable state unreachable
Edit:
Ich bin jetzt auf 8829 von 10_CUL_HM.pm zurück. Damit ist alles wieder gut.
# $Id: 10_CUL_HM.pm 8829 2015-06-26 07:13:01Z martinp876 $
# $Id: 00_HMLAN.pm 8835 2015-06-26 10:54:48Z martinp876 $
wäre seltsam, wenn es letzte Woche schon war. Da war es nicht eingebaut.
hast du die messages dazu?
Wahrscheinlich meldet der LED1 etwas für das Device...
Bei mir funktioniert die Version
# $Id: 10_CUL_HM.pm 8849 2015-06-28 11:18:24Z martinp876 $
ohne den vorherigen Fehler.
Bei mir funktioniert bis jetzt auch wieder alles mit der CUL_HM Version 8849 ...
VG
Falkes
ist sicher eine Besonderheit des LED16. Da werden kommandos für das ganze Device abgesetzt, nicht nur für einzelne Kanäle. Das muss gesondert behandelt werden. Die Logs würden das verhalten klären, dann die Behebung.
Zu früh gefreut, beim Start von FHEM kam kein Fehler mehr, aber nach einer halben Stunde kommen sie wieder:
2015.06.28 19:57:32 3: CUL_HM set CUL_HM_HM_ES_PMSw1_Pl_2AB693_Pwr statusRequest
2015.06.28 19:57:34 3: CUL_HM set CUL_HM_HM_ES_PMSw1_Pl_2AB693_SenPwr statusRequest
2015.06.28 19:57:35 3: CUL_HM set CUL_HM_HM_ES_PMSw1_Pl_2AB693_SenI statusRequest
2015.06.28 19:57:36 3: CUL_HM set CUL_HM_HM_ES_PMSw1_Pl_2AB693_SenU statusRequest
2015.06.28 19:57:37 3: CUL_HM set CUL_HM_HM_ES_PMSw1_Pl_2AB693_SenF statusRequest
2015.06.28 19:57:38 3: CUL_HM set CUL_HM_HM_ES_PMSw1_Pl_34260F_Pwr statusRequest
2015.06.28 19:57:39 1: PERL WARNING: Argument "unreachable" isn't numeric in numeric lt (<) at (eval 913) line 1.
2015.06.28 19:57:39 3: CUL_HM set CUL_HM_HM_ES_PMSw1_Pl_34260F_SenPwr statusRequest
2015.06.28 19:57:40 3: CUL_HM set CUL_HM_HM_ES_PMSw1_Pl_34260F_SenI statusRequest
2015.06.28 19:57:41 3: CUL_HM set CUL_HM_HM_ES_PMSw1_Pl_34260F_SenU statusRequest
2015.06.28 19:57:42 3: CUL_HM set CUL_HM_HM_ES_PMSw1_Pl_34260F_SenF statusRequest
2015.06.28 19:57:44 1: PERL WARNING: Argument "unreachable" isn't numeric in numeric lt (<) at (eval 914) line 1.
aber im Device finde ich keinen state "unreachable" aber der Timestamp steht noch auf Startzeit von FHEM.
Das könnte natürlich sein, dass das OU eine Sonderbehandlung braucht.
Habe jetzt 8853 rein gebügelt.
Nach einem shutdown restart gibt es auch erst mal den einen oder anderen unreachable. Ich fürchte, da werden zu viele Devices zu flott nacheinander abgefragt, da kommt wohl irgendetwas nicht richtig hinterher oder das Timeout ist einfach zu kurz gewählt. Denn wirklich unreachable ist keines der Devices.
Mal schauen, wie es sonst damit läuft.
2015.06.28 20:29:42 0: Server started with 520 defined entities (version $Id: fhem.pl 8810 2015-06-23 18:40:53Z rudolfkoenig $, os linux, user fhem, pid 10197)
2015.06.28 20:29:42 1: HMLAN_Parse: HMUSB1 new condition ok
2015.06.28 20:29:47 1: HMLAN_Parse: HMUSB0 new condition ok
2015.06.28 20:29:48 1: HMLAN_Parse: HMLAN0 new condition ok
2015.06.28 20:29:50 1: HMLAN_Parse: HMLAN1 new condition ok
2015.06.28 20:29:50 1: HMLAN_Parse: HMLAN2 new condition ok
2015.06.28 20:29:51 3: CUL_HM set HWR_Aussenlicht_Terrasse statusRequest
2015.06.28 20:29:53 3: CUL_HM set ANB_Aussensteckdosen statusRequest
2015.06.28 20:29:54 3: CUL_HM set AB_Deckenlicht statusRequest
2015.06.28 20:29:55 3: CUL_HM set ASR_RM statusRequest
2015.06.28 20:29:56 3: CUL_HM set ASR_Rollo_Links statusRequest
2015.06.28 20:29:57 3: CUL_HM set ASR_Rollo_Rechts statusRequest
2015.06.28 20:30:03 3: CUL_HM set FL_Rollo statusRequest
2015.06.28 20:30:04 3: CUL_HM set FL_Treppenlicht statusRequest
2015.06.28 20:30:05 3: CUL_HM set GAR_Aussensteckdose statusRequest
2015.06.28 20:30:07 3: CUL_HM set GEN_4SW_Tueroeffner statusRequest
2015.06.28 20:30:09 3: CUL_HM set GEN_LED1 statusRequest
2015.06.28 20:30:10 3: CUL_HM set GWC_Rollo statusRequest
2015.06.28 20:30:11 3: CUL_HM set HWR_Rollo_Nord statusRequest
2015.06.28 20:30:12 3: CUL_HM set HWR_Rollo_Tuer statusRequest
2015.06.28 20:30:13 3: CUL_HM set HWR_Rollo_West statusRequest
2015.06.28 20:30:14 3: GEN_LED1 unreachable
2015.06.28 20:30:14 3: CUL_HM set HWR_Wandleuchte statusRequest
2015.06.28 20:30:15 3: GWC_Rollo unreachable
2015.06.28 20:30:15 3: CUL_HM set CUL_HM_HM_LC_Dim1TPBU_FM_26FBDB_Sw1_V_01 statusRequest
2015.06.28 20:30:17 3: CUL_HM set CUL_HM_HM_LC_Dim1TPBU_FM_26FBDB_Sw1_V_02 statusRequest
2015.06.28 20:30:18 3: CUL_HM set JWR_RM statusRequest
2015.06.28 20:30:19 3: CUL_HM set KUC_Rollo_Ost statusRequest
2015.06.28 20:30:21 3: HWR_Wandleuchte unreachable
2015.06.28 20:30:21 3: CUL_HM set KUC_Rollo_Sued statusRequest
2015.06.28 20:30:21 3: CUL_HM_HM_LC_Dim1TPBU_FM_26FBDB_Sw1_V_01 unreachable
2015.06.28 20:30:24 3: CUL_HM_HM_LC_Dim1TPBU_FM_26FBDB_Sw1_V_02 unreachable
2015.06.28 20:30:24 3: CUL_HM set SZ_Deckenlicht statusRequest
2015.06.28 20:30:24 3: JWR_RM unreachable
2015.06.28 20:30:25 3: KUC_Rollo_Ost unreachable
2015.06.28 20:30:25 3: CUL_HM set SZ_Rollo statusRequest
2015.06.28 20:30:26 3: CUL_HM set TMO_Deckenlicht statusRequest
2015.06.28 20:30:27 3: KUC_Rollo_Sued unreachable
2015.06.28 20:30:29 3: CUL_HM set CUL_HM_HM_LC_Dim1TPBU_FM_26FB98_Sw1_V_01 statusRequest
2015.06.28 20:30:29 3: SZ_Deckenlicht unreachable
2015.06.28 20:30:30 3: CUL_HM set CUL_HM_HM_LC_Dim1TPBU_FM_26FB98_Sw1_V_02 statusRequest
2015.06.28 20:30:32 3: CUL_HM set TMO_Rollo statusRequest
2015.06.28 20:30:32 3: TMO_Deckenlicht unreachable
2015.06.28 20:30:33 3: CUL_HM set WZ_Aussen_Licht1 statusRequest
2015.06.28 20:30:35 3: CUL_HM set WZ_Aussensteckdosen statusRequest
2015.06.28 20:30:35 3: CUL_HM_HM_LC_Dim1TPBU_FM_26FB98_Sw1_V_01 unreachable
2015.06.28 20:30:37 3: CUL_HM_HM_LC_Dim1TPBU_FM_26FB98_Sw1_V_02 unreachable
2015.06.28 20:30:37 3: CUL_HM set WZ_Rollo_Erker_L statusRequest
2015.06.28 20:30:38 3: CUL_HM set WZ_Rollo_Erker_R statusRequest
2015.06.28 20:30:39 3: CUL_HM set WZ_Rollo_Erker_Tuer statusRequest
2015.06.28 20:30:40 3: CUL_HM set WZ_Rollo_Sued statusRequest
2015.06.28 20:30:41 3: CUL_HM set WZ_Rollo_Terrassentuer statusRequest
2015.06.28 20:30:41 3: led1_status()
2015.06.28 20:30:42 3: WZ_Rollo_Erker_L unreachable
die Geschwindigkeit sollte hier ok sein. Ich brauche die rohmessages!
@stromer,
wenn unreachable im statefile steht und du einen restart machst bleibt es stehen. Bis du einen statusRequest machst.
mache ein
get hm param state
dann mache ein statusRequest wo notwendig.
Immer noch ein Problem?
Ich denke du nutzt state zum rechnen - das erzeugt den Fehler! wenn nicht erreichbar auch keine rechnung
Im state steht kein unreachable ebenso im statefile.
Es kommen nur die Meldungen im Log.
Die Perl Meldung kommt vom Statistik-Modul.
Hallo,
habe das gleiche Problem mit meinen HM-ES-PMSw1-Pl. Unreachable kannte ich vorher als state gar nicht. Seit dem update am Samstag habe ich es eigentlich durchgehend. Schalten funktioniert aber noch. Update heute morgen hat keine Veränderung gebracht.
schöne Grüße
Jo
Bei mir ist mit der 8853 außer den bereits erwähnten paar unreachables nach einem shutdown restart in den letzten Stunden folgendes passiert:
2015.06.28 23:00:53 3: GEN_LED1 unreachable
2015.06.28 23:03:23 3: led1_status(7)
2015.06.28 23:03:24 3: CUL_HM set GEN_LED1_07 led red
2015.06.28 23:03:27 3: led1_status(7)
2015.06.28 23:03:27 3: CUL_HM set GEN_LED1_07 led green
2015.06.28 23:30:55 3: CUL_HM set GEN_LED1 statusRequest
2015.06.28 23:31:00 3: GEN_LED1 unreachable
2015.06.29 00:01:03 3: CUL_HM set GEN_LED1 statusRequest
2015.06.29 00:01:08 3: GEN_LED1 unreachable
2015.06.29 00:31:10 3: CUL_HM set GEN_LED1 statusRequest
2015.06.29 00:31:15 3: GEN_LED1 unreachable
2015.06.29 01:01:18 3: CUL_HM set GEN_LED1 statusRequest
2015.06.29 01:01:24 3: GEN_LED1 unreachable
2015.06.29 01:31:26 3: CUL_HM set GEN_LED1 statusRequest
2015.06.29 01:31:31 3: GEN_LED1 unreachable
2015.06.29 02:01:34 3: CUL_HM set GEN_LED1 statusRequest
2015.06.29 02:01:39 3: GEN_LED1 unreachable
2015.06.29 02:31:42 3: CUL_HM set GEN_LED1 statusRequest
2015.06.29 02:31:47 3: GEN_LED1 unreachable
2015.06.29 03:01:49 3: CUL_HM set GEN_LED1 statusRequest
2015.06.29 03:01:55 3: GEN_LED1 unreachable
2015.06.29 03:31:58 3: CUL_HM set GEN_LED1 statusRequest
2015.06.29 03:32:03 3: GEN_LED1 unreachable
2015.06.29 04:02:05 3: CUL_HM set GEN_LED1 statusRequest
2015.06.29 04:02:11 3: GEN_LED1 unreachable
2015.06.29 04:32:13 3: CUL_HM set GEN_LED1 statusRequest
2015.06.29 04:32:18 3: GEN_LED1 unreachable
2015.06.29 05:00:00 3: CUL_HM set GEN_LED1 ilum 5 0
2015.06.29 05:00:06 3: CUL_HM set GEN_LED1 getConfig
2015.06.29 05:02:21 3: CUL_HM set GEN_LED1 statusRequest
2015.06.29 05:02:26 3: GEN_LED1 unreachable
2015.06.29 05:32:29 3: CUL_HM set GEN_LED1 statusRequest
2015.06.29 05:32:34 3: GEN_LED1 unreachable
2015.06.29 06:02:37 3: CUL_HM set GEN_LED1 statusRequest
2015.06.29 06:02:44 3: GEN_LED1 unreachable
ich meine beim HM-ES-PMSw1-Pl (24AF1D) stimmt etwas noch nicht mit version:
# $Id: 10_CUL_HM.pm 8853 2015-06-28 17:46:15Z martinp876 $
im 30 minuten rythmus melden chn2-chn6 unreachable. die stati von chn3-chn6 werden, denke ich, aus dem status von chn2 generiert. abgefragt werden die stati von chn2 und chn3, müssten wohl chn1 und chn2 sein.
2015.06.29 06:12:29.905 0: HMLAN_Send: hmlan1 S:+24AF1D,00,01,00
2015.06.29 06:12:29.907 0: HMLAN_Send: hmlan1 S:S3D84309C stat: 00 t:00000000 d:01 r:3D84309C m:0C A001 1ACE1F 24AF1D 020E
2015.06.29 06:12:29.976 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:01D6950F d:FF r:FFDB m:0C A001 1ACE1F 24AF1D 020E
2015.06.29 06:12:30.169 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:01D695D8 d:FF r:FFDB m:0C A001 1ACE1F 24AF1D 020E
2015.06.29 06:12:30.360 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:01D696A0 d:FF r:FFDB m:0C A001 1ACE1F 24AF1D 020E
2015.06.29 06:12:30.517 0: HMLAN_Parse: hmlan1 R:R3D84309C stat:0008 t:00000000 d:FF r:7FFF m:0C A001 1ACE1F 24AF1D 020E
2015.06.29 06:12:30.519 0: HMLAN_Parse: hmlan1 no ACK from 24AF1D
2015.06.29 06:12:32.136 0: HMLAN_Send: hmlan1 S:S3D843953 stat: 00 t:00000000 d:01 r:3D843953 m:0C A001 1ACE1F 24AF1D 020E
2015.06.29 06:12:32.139 0: HMLAN_Send: hmlan1 I:K
2015.06.29 06:12:32.166 0: HMLAN_Parse: hmlan1 V:03C4 sNo:JEQ0315335 d:1C671E O:1ACE1F t:021A9B17 IDcnt:0014 L:10 %
2015.06.29 06:12:32.184 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:01D69DC6 d:FF r:FFDC m:0C A001 1ACE1F 24AF1D 020E
2015.06.29 06:12:32.311 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:021A9BB0 d:FF r:FFA5 m:0C A45F 24AF1D 1ACE1F 80F0640000000000093CFD
2015.06.29 06:12:32.733 0: HMLAN_Parse: hmlan1 R:R3D843953 stat:0001 t:021A9BB5 d:FF r:FFA5 m:0C A45F 24AF1D 1ACE1F 80F0640000000000093CFD
2015.06.29 06:12:32.755 0: HMLAN_Send: hmlan1 S:+24AF1D,00,01,00
2015.06.29 06:12:32.757 0: HMLAN_Send: hmlan1 S:S3D843BBE stat: 00 t:00000000 d:01 r:3D843BBE m:0D A001 1ACE1F 24AF1D 030E
2015.06.29 06:12:32.767 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:01D69EC5 d:FF r:FFDB m:0C 8002 1ACE1F 24AF1D 00
2015.06.29 06:12:32.824 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:01D6A032 d:FF r:FFDC m:0D A001 1ACE1F 24AF1D 030E
2015.06.29 06:12:33.016 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:01D6A0FA d:FF r:FFDC m:0D A001 1ACE1F 24AF1D 030E
2015.06.29 06:12:33.208 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:01D6A1C2 d:FF r:FFDC m:0D A001 1ACE1F 24AF1D 030E
2015.06.29 06:12:33.412 0: HMLAN_Parse: hmlan1 R:R3D843BBE stat:0008 t:00000000 d:FF r:7FFF m:0D A001 1ACE1F 24AF1D 030E
2015.06.29 06:12:33.414 0: HMLAN_Parse: hmlan1 no ACK from 24AF1D
2015.06.29 06:12:34.175 0: HMLAN_Parse: hmlan1 R:E20DFE1 stat:0000 t:021AA2FB d:FF r:FFD3 m:37 8670 20DFE1 000000 00B34A
2015.06.29 06:12:34.207 0: HMLAN_Parse: hmusb1 R:E20DFE1 stat:0000 t:01D6A597 d:FF r:FFC9 m:37 8670 20DFE1 000000 00B34A
2015.06.29 06:12:37.178 0: HMLAN_Send: hmlan1 S:S3D844D05 stat: 00 t:00000000 d:01 r:3D844D05 m:0D A001 1ACE1F 24AF1D 030E
2015.06.29 06:12:37.240 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:01D6B177 d:FF r:FFDB m:0D A001 1ACE1F 24AF1D 030E
2015.06.29 06:12:37.432 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:01D6B23F d:FF r:FFDB m:0D A001 1ACE1F 24AF1D 030E
2015.06.29 06:12:37.624 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:01D6B307 d:FF r:FFDB m:0D A001 1ACE1F 24AF1D 030E
2015.06.29 06:12:37.788 0: HMLAN_Parse: hmlan1 R:R3D844D05 stat:0008 t:00000000 d:FF r:7FFF m:0D A001 1ACE1F 24AF1D 030E
2015.06.29 06:12:37.790 0: HMLAN_Parse: hmlan1 no ACK from 24AF1D
2015.06.29 06:12:38.147 0: HMLAN_Send: hmlan1 S:S3D8450CF stat: 00 t:00000000 d:01 r:3D8450CF m:12 A001 1ACE1F 285A44 010E
2015.06.29 06:12:38.200 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:01D6B540 d:FF r:FFDB m:12 A001 1ACE1F 285A44 010E
2015.06.29 06:12:38.392 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:01D6B608 d:FF r:FFDB m:12 A001 1ACE1F 285A44 010E
2015.06.29 06:12:38.616 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:01D6B6D0 d:FF r:FFDB m:12 A001 1ACE1F 285A44 010E
2015.06.29 06:12:38.756 0: HMLAN_Parse: hmlan1 R:R3D8450CF stat:0008 t:00000000 d:FF r:7FFF m:12 A001 1ACE1F 285A44 010E
2015.06.29 06:12:38.759 0: HMLAN_Parse: hmlan1 no ACK from 285A44
2015.06.29 06:12:39.175 0: HMLAN_Parse: hmlan1 R:E266EA5 stat:0000 t:021AB683 d:FF r:FFD1 m:45 805E 266EA5 1ACE1F 0000000000000000000000
2015.06.29 06:12:39.325 0: HMLAN_Parse: hmlan1 R:E6869B6 stat:0000 t:021AB6B0 d:FF r:FFBE m:68 A270 6869B6 1ACE1F 00BC4327CD0000006F0898
2015.06.29 06:12:39.501 0: HMLAN_Parse: hmusb1 R:E266EA5 stat:0000 t:01D6B91E d:FF r:FFCD m:45 805E 266EA5 1ACE1F 0000000000000000000000
2015.06.29 06:12:39.514 0: HMLAN_Parse: hmusb1 R:E6869B6 stat:0000 t:01D6B94B d:FF r:FFBD m:68 A270 6869B6 1ACE1F 00BC4327CD0000006F0898
2015.06.29 06:12:39.543 0: HMLAN_Send: hmusb1 I:K
2015.06.29 06:12:39.554 0: HMLAN_Parse: hmlan1 R:E1ACE1F stat:0000 t:021AB724 d:FF r:FFDE m:68 8002 1ACE1F 6869B6 00
2015.06.29 06:12:39.609 0: HMLAN_Parse: hmusb1 V:03C7 sNo:KEQ1111271 d:263408 O:1ACE1F t:01D6BABD IDcnt:0011 L:2 %
2015.06.29 06:12:40.380 0: HMLAN_Send: hmlan1 S:S3D845987 stat: 00 t:00000000 d:01 r:3D845987 m:12 A001 1ACE1F 285A44 010E
2015.06.29 06:12:40.440 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:01D6BDFA d:FF r:FFDB m:12 A001 1ACE1F 285A44 010E
2015.06.29 06:12:40.632 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:01D6BEC2 d:FF r:FFDC m:12 A001 1ACE1F 285A44 010E
2015.06.29 06:12:40.824 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:01D6BF8A d:FF r:FFDC m:12 A001 1ACE1F 285A44 010E
2015.06.29 06:12:40.990 0: HMLAN_Parse: hmlan1 R:R3D845987 stat:0008 t:00000000 d:FF r:7FFF m:12 A001 1ACE1F 285A44 010E
2015.06.29 06:12:40.992 0: HMLAN_Parse: hmlan1 no ACK from 285A44
2015.06.29 06:12:43.012 0: HMLAN_Send: hmlan1 S:S3D8463CF stat: 00 t:00000000 d:01 r:3D8463CF m:0D A001 1ACE1F 24AF1D 030E
2015.06.29 06:12:43.064 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:01D6C841 d:FF r:FFDC m:0D A001 1ACE1F 24AF1D 030E
2015.06.29 06:12:43.291 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:01D6C909 d:FF r:FFDC m:0D A001 1ACE1F 24AF1D 030E
2015.06.29 06:12:43.480 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:01D6C9D1 d:FF r:FFDB m:0D A001 1ACE1F 24AF1D 030E
2015.06.29 06:12:43.622 0: HMLAN_Parse: hmlan1 R:R3D8463CF stat:0008 t:00000000 d:FF r:7FFF m:0D A001 1ACE1F 24AF1D 030E
2015.06.29 06:12:43.624 0: HMLAN_Parse: hmlan1 no ACK from 24AF1D
2015.06.29 06:12:45.712 0: HMLAN_Send: hmlan1 S:S3D846E5B stat: 00 t:00000000 d:01 r:3D846E5B m:12 A001 1ACE1F 285A44 010E
2015.06.29 06:12:45.752 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:01D6D2CC d:FF r:FFDB m:12 A001 1ACE1F 285A44 010E
2015.06.29 06:12:45.976 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:01D6D394 d:FF r:FFDB m:12 A001 1ACE1F 285A44 010E
2015.06.29 06:12:46.168 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:01D6D45C d:FF r:FFDB m:12 A001 1ACE1F 285A44 010E
2015.06.29 06:12:46.320 0: HMLAN_Parse: hmlan1 R:R3D846E5B stat:0008 t:00000000 d:FF r:7FFF m:12 A001 1ACE1F 285A44 010E
2015.06.29 06:12:46.323 0: HMLAN_Parse: hmlan1 no ACK from 285A44
2015.06.29 06:12:47.728 0: HMLAN_Parse: hmlan1 R:E206487 stat:0000 t:021AD7ED d:FF r:FFB3 m:B2 8670 206487 000000 00BA43
2015.06.29 06:12:47.770 0: HMLAN_Parse: hmusb1 R:E206487 stat:0000 t:01D6DA86 d:FF r:FFAF m:B2 8670 206487 000000 00BA43
2015.06.29 06:12:48.682 0: HMLAN_Send: hmlan1 S:S3D8479F5 stat: 00 t:00000000 d:01 r:3D8479F5 m:0D A001 1ACE1F 24AF1D 030E
2015.06.29 06:12:48.728 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:01D6DE67 d:FF r:FFDB m:0D A001 1ACE1F 24AF1D 030E
2015.06.29 06:12:48.920 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:01D6DF2E d:FF r:FFDB m:0D A001 1ACE1F 24AF1D 030E
2015.06.29 06:12:49.144 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:01D6DFF6 d:FF r:FFDB m:0D A001 1ACE1F 24AF1D 030E
2015.06.29 06:12:49.291 0: HMLAN_Parse: hmlan1 R:R3D8479F5 stat:0008 t:00000000 d:FF r:7FFF m:0D A001 1ACE1F 24AF1D 030E
2015.06.29 06:12:49.293 0: HMLAN_Parse: hmlan1 no ACK from 24AF1D
2015-06-29_06:12:29 SwitchES01 CMDs_pending
2015-06-29_06:12:32 SwitchES01_Pwr eState: E: 6154 P: 0 I: 0 U: 236.4 f: 49.97
2015-06-29_06:12:32 SwitchES01_Pwr frequency: 49.97
2015-06-29_06:12:32 SwitchES01_Pwr voltage: 236.4
2015-06-29_06:12:32 SwitchES01_SenF 49.97
2015-06-29_06:12:32 SwitchES01_SenU 236.4
2015-06-29_06:12:34 SwitchES01_Pwr unreachable
2015-06-29_06:12:36 SwitchES01_SenPwr unreachable
2015-06-29_06:12:40 SwitchES01_SenI unreachable
2015-06-29_06:12:41 SwitchES01_SenU unreachable
2015-06-29_06:12:42 SwitchES01_SenF unreachable
2015-06-29_06:12:54 SwitchES01 ResndFail
2015-06-29_06:12:54 SwitchES01 CMDs_done_Errors:1
2015-06-29_06:12:54 SwitchES01 MISSING ACK
im eventlog werden die stati erst gemeldet und dann auf unreachable gesetzt. _Pwr, _SenPwr, _SenI werden im log nicht aufgeführt, da die events durch event-on-change unterdrückt werden. chn1 (_Sw) wird gar nicht behandelt.
Habe gerade eben das aktuelle Update eingespielt.
00_HMLAN.pm 8835
10_CUL_HM.pm 8853
Den MissingAck bei den HM-ES-PMSw1-Pl bekomme ich immer noch alle 30 Minuten :(
Werde wohl wieder zurück rollen müssen.
Habe das gleiche Problem. Meiner Ansicht nach spielt Homematic in der aktuellen Version etwas verrückt (Overload, Missing Ack, keine Schaltung). Mir fehlt leider die Zeit, das zu analysieren. Restore ist aktuell das Mittel der Wahl. Schade. Es war mal sehr stabil.
Zitat
Habe das gleiche Problem. Meiner Ansicht nach spielt Homematic in der aktuellen Version etwas verrückt (Overload, Missing Ack, keine Schaltung). Mir fehlt leider die Zeit, das zu analysieren. Restore ist aktuell das Mittel der Wahl. Schade. Es war mal sehr stabil.
zeit zum nörgeln wohl genug. ???
das Device 285A44 antwortet nicht. da ist unreachable angebracht.
warum ist mit unklar, jedenfalls keine antwort vom Device.
ein statusRequest bringt keine antwort - jedenfalls nicht immer - korrekt?
Zitat von: martinp876 am 30 Juni 2015, 21:21:14
das Device 285A44 antwortet nicht. da ist unreachable angebracht.
warum ist mit unklar, jedenfalls keine antwort vom Device.
ein statusRequest bringt keine antwort - jedenfalls nicht immer - korrekt?
genau. wegen dem 285A44 ist unreachable entstanden. der reale aktor liegt zur zeit auf dem schreibtisch.
die angesprochenen probleme gibt es mit HM-ES-PMSw1-Pl (
24AF1D), energie-mess-steckdose.
Also ich kann nur sagen, dass mein HM-ES-PMSw1-Pl mit den letzten Fixes von Martin von wieder ohne unreachable läuft.
Danke dafür. :)
Zitat von: volschin am 30 Juni 2015, 21:46:18
Also ich kann nur sagen, dass mein HM-ES-PMSw1-Pl mit den letzten Fixes von Martin von wieder ohne unreachable läuft.
Danke dafür. :)
ad 1: bei mir auch
ad 2: Danke, auch von mir.
Gruß
G.
Bei meiner OU-LED treten die die Probleme leider sehr zuverlässig alle 30 Minuten weiterhin auf. Bei anderen Devices konnte ich das Problem - ausser nach einem Restart - jedoch nicht mehr beobachten.
Bei mir funktioniert alles wieder ohne Fehler (update erst heute). OU-LED zeigt auch keinen Fehler bzw. kein unreachable, HM-ES-PMSw1-Pl ebenfalls OK.
VG
Frank
Hast Du vccu? Wieviele IOs?
@Ralli
Siehe list von vccu, OU-LED sind die einzelnen LED´s nur über notify getriggert, kein Peering.
Internals:
DEF 123ABC
HMLAN1_MSGCNT 46
HMLAN1_RAWMSG E123ABC,0000,01222555,FF,FFC4,67803F123ABC2221D002041D269F50
HMLAN1_RSSI -60
HMLAN1_TIME 2015-07-01 14:53:36
HMLAN2_MSGCNT 498
HMLAN2_RAWMSG E123ABC,0000,28F624BE,FF,FFC2,42A011123ABC1D481F800502
HMLAN2_RSSI -62
HMLAN2_TIME 2015-07-01 15:25:08
HMLAN3_MSGCNT 533
HMLAN3_RAWMSG E123ABC,0000,00F45A43,FF,FFC1,42A011123ABC1D481F800502
HMLAN3_RSSI -63
HMLAN3_TIME 2015-07-01 15:25:08
IODev HMLAN1
LASTInputDev HMLAN3
MSGCNT 1077
NAME vccu
NR 55
STATE HMLAN1:ok,HMLAN2:ok,HMLAN3:ok,
TYPE CUL_HM
assignedIOs HMLAN1,HMLAN2,HMLAN3
channel_01 vccu_Btn1
channel_02 vccu_Btn2
channel_03 vccu_Btn3
channel_04 vccu_Btn4
channel_05 vccu_Btn5
channel_06 vccu_Btn6
channel_07 vccu_Btn7
channel_08 vccu_Btn8
lastMsg No:42 - t:11 s:123ABC d:1D481F 800502
protLastRcv 2015-07-01 15:25:08
rssi_at_HMLAN1 avg:-59.62 min:-68 max:-40 lst:-60 cnt:40
rssi_at_HMLAN2 avg:-66.47 min:-79 max:-51 lst:-62 cnt:495
rssi_at_HMLAN3 avg:-50.81 min:-68 max:-42 lst:-63 cnt:528
rssi_at_rpt_HMLAN1 avg:-42.33 min:-49 max:-34 lst:-34 cnt:6
rssi_at_rpt_HMLAN2 avg:-77 min:-80 max:-74 lst:-74 cnt:3
rssi_at_rpt_HMLAN3 avg:-38.6 min:-69 max:-31 lst:-69 cnt:5
CHANGETIME:
Readings:
2015-07-01 15:25:03 CommandAccepted yes
2015-07-01 10:58:34 state HMLAN1:ok,HMLAN2:ok,HMLAN3:ok,
Helper:
HM_CMDNR 66
mId FFF0
rxType 1
Io:
nextSend 1435757108.95395
prefIO
vccu
ioList:
HMLAN1
HMLAN2
HMLAN3
Mrssi:
mNo 42
Io:
HMLAN2 -62
HMLAN3 -63
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
dev 1
Rssi:
At_hmlan1:
avg -59.625
cnt 40
lst -60
max -40
min -68
At_hmlan2:
avg -66.4707070707071
cnt 495
lst -62
max -51
min -79
At_hmlan3:
avg -50.8162878787879
cnt 528
lst -63
max -42
min -68
At_rpt_hmlan1:
avg -42.3333333333333
cnt 6
lst -34
max -34
min -49
At_rpt_hmlan2:
avg -77
cnt 3
lst -74
max -74
min -80
At_rpt_hmlan3:
avg -38.6
cnt 5
lst -69
max -31
min -69
Shadowreg:
Attributes:
DbLogExclude .*
IODev HMLAN1
IOList HMLAN1,HMLAN2,HMLAN3
expert 2_full
model CCU-FHEM
room HM-Adapter
subType virtual
webCmd virtual:update
VG
Frank
Zum led16 brauche ich die logs, oder habe ich die uebersehen. Der hat ein besonderes statehandling.
Die energiemessdose scheint hie und da nicht senden zu wollen. Evtl ein overloadschutz. Das sehe ich als das problem hier. Mal ueberlegen, wie man damit umgehen kann
Hallo Martin,
habe Dir ein Log mit RAW-Messages per PN geschickt.
geht es jetzt (morgen)?
Erst einmal danke, dass Du Dich der Sache annimmst bzw. angenommen hast.
Nach einem restart erst einmal einige unreachable; das bin ich ja mittlerweile gewöhnt - allerdings meine ich, dass hier einfach zu früh mit den ganzen StatusRequests begonnen wird. Mir ist dann aufgefallen, dass jetzt nicht nur das LED-Device an sich mit einem StatusRequest bedacht wird sondern alle einzelnen Channels.
Und hier sieht man auch schön, dass bereits ein DOIF ausgelöst wird, obwohl noch kein INITIALIZED da sein dürfte.
Morgen im Laufe des Tages bzw. Abends werde ich Rückmeldung geben können, ob weiter periodisch im normalen Betrieb entsprechende unreachables aufgetreten sind.
2015.07.02 21:24:32 1: Including fhem.cfg
2015.07.02 21:24:32 3: telnetPort: port 7072 opened
2015.07.02 21:24:32 3: WEB: port 8083 opened
2015.07.02 21:24:32 3: WEBphone: port 8084 opened
2015.07.02 21:24:32 3: WEBtablet: port 8085 opened
2015.07.02 21:24:33 2: eventTypes: loaded 7504 events from ./log/eventTypes.txt
2015.07.02 21:24:33 1: HMLAN_Parse: HMLAN0 new condition disconnected
2015.07.02 21:24:33 3: Opening HMLAN0 device 10.0.0.5:1000
2015.07.02 21:24:33 3: HMLAN0 device opened
2015.07.02 21:24:33 1: HMLAN_Parse: HMLAN0 new condition init
2015.07.02 21:24:33 1: HMLAN_Parse: HMLAN1 new condition disconnected
2015.07.02 21:24:33 3: Opening HMLAN1 device 10.0.0.6:1000
2015.07.02 21:24:33 3: HMLAN1 device opened
2015.07.02 21:24:33 1: HMLAN_Parse: HMLAN1 new condition init
2015.07.02 21:24:33 1: HMLAN_Parse: HMLAN2 new condition disconnected
2015.07.02 21:24:33 3: Opening HMLAN2 device 10.0.0.7:1000
2015.07.02 21:24:33 3: HMLAN2 device opened
2015.07.02 21:24:33 1: HMLAN_Parse: HMLAN2 new condition init
2015.07.02 21:24:33 1: HMLAN_Parse: HMUSB0 new condition disconnected
2015.07.02 21:24:33 3: Opening HMUSB0 device 127.0.0.1:1234
2015.07.02 21:24:33 3: HMUSB0 device opened
2015.07.02 21:24:33 1: HMLAN_Parse: HMUSB0 new condition init
2015.07.02 21:24:33 1: HMLAN_Parse: HMUSB1 new condition disconnected
2015.07.02 21:24:34 3: Opening HMUSB1 device 10.0.0.10:1000
2015.07.02 21:24:34 3: HMUSB1 device opened
2015.07.02 21:24:34 1: HMLAN_Parse: HMUSB1 new condition init
2015.07.02 21:24:34 3: Opening CUL0 device /dev/ttyACM0
2015.07.02 21:24:34 3: Can't open /dev/ttyACM0: Datei oder Verzeichnis nicht gefunden
2015.07.02 21:24:34 2: Switched CUL0 rfmode to HomeMatic
2015.07.02 21:24:35 3: additional HM config file loaded: ./FHEM/HMConfig_SenTHPL.pm
2015.07.02 21:24:35 3: Opening FRITZ device 10.0.0.1:2002
2015.07.02 21:24:35 3: FRITZ device opened
2015.07.02 21:24:35 1: FBAHA FRITZ registered with handle: 0000002a
2015.07.02 21:24:42 1: Including ./log/fhem.save
2015.07.02 21:24:46 3: Device AB_HK_Device added to ActionDetector with 000:10 time
2015.07.02 21:24:46 3: Device ANB_TSS_1 added to ActionDetector with 028:00 time
2015.07.02 21:24:47 3: Device ANB_TSS_2 added to ActionDetector with 028:00 time
2015.07.02 21:24:47 3: Device ASR_Fenster_links added to ActionDetector with 000:50 time
2015.07.02 21:24:47 3: Device ASR_Fenster_rechts added to ActionDetector with 000:50 time
2015.07.02 21:24:47 3: Device ASR_RM added to ActionDetector with 099:00 time
2015.07.02 21:24:47 3: Device BAD_Fenster added to ActionDetector with 028:00 time
2015.07.02 21:24:47 3: Device BAD_HK_Device added to ActionDetector with 000:10 time
2015.07.02 21:24:48 3: Device FL_DGK_Fenster added to ActionDetector with 028:00 time
2015.07.02 21:24:48 3: Device FL_MK_Haustuer added to ActionDetector with 028:00 time
2015.07.02 21:24:48 3: Device GAR_MK_Tor added to ActionDetector with 028:00 time
2015.07.02 21:24:48 3: Device GEN_Aussensensor added to ActionDetector with 000:10 time
2015.07.02 21:24:48 1: PERL WARNING: Use of uninitialized value $end in string gt at ./FHEM/98_DOIF.pm line 476.
2015.07.02 21:24:48 1: PERL WARNING: Use of uninitialized value $begin in string gt at ./FHEM/98_DOIF.pm line 476.
2015.07.02 21:24:48 1: PERL WARNING: Use of uninitialized value $begin in string ge at ./FHEM/98_DOIF.pm line 481.
2015.07.02 21:24:51 3: Device GWC_Fenster added to ActionDetector with 000:50 time
2015.07.02 21:24:51 3: Device HWR_HK_Device added to ActionDetector with 000:10 time
2015.07.02 21:24:51 3: Device JWR_Fenster added to ActionDetector with 000:50 time
2015.07.02 21:24:51 3: Device JWR_HK_Device added to ActionDetector with 000:10 time
2015.07.02 21:24:52 3: Device JWR_RM added to ActionDetector with 099:00 time
2015.07.02 21:24:52 3: Device KUC_Fenster_Ost added to ActionDetector with 000:50 time
2015.07.02 21:24:52 3: Device KUC_Fenster_links added to ActionDetector with 000:50 time
2015.07.02 21:24:52 3: Device KUC_Fenster_rechts added to ActionDetector with 000:50 time
2015.07.02 21:24:52 3: Device KUC_HK_Device added to ActionDetector with 000:10 time
2015.07.02 21:24:52 3: Device LNA_Fenster_links added to ActionDetector with 000:50 time
2015.07.02 21:24:52 3: Device LNA_Fenster_rechts added to ActionDetector with 000:50 time
2015.07.02 21:24:53 3: Device LNA_HK_Device added to ActionDetector with 000:10 time
2015.07.02 21:24:53 3: Device LNA_RM added to ActionDetector with 099:00 time
2015.07.02 21:24:53 3: Device SZ_DGK_Fenster_links added to ActionDetector with 028:00 time
2015.07.02 21:24:53 3: Device SZ_DGK_Fenster_rechts added to ActionDetector with 028:00 time
2015.07.02 21:24:53 3: Device SZ_HK_Device added to ActionDetector with 000:10 time
2015.07.02 21:24:54 3: Device SZ_RM added to ActionDetector with 099:00 time
2015.07.02 21:24:54 3: Device TMO_Fenster_links added to ActionDetector with 000:50 time
2015.07.02 21:24:54 3: Device TMO_Fenster_rechts added to ActionDetector with 000:50 time
2015.07.02 21:24:54 3: Device TMO_HK_Device added to ActionDetector with 000:10 time
2015.07.02 21:24:54 3: Device TMO_RM added to ActionDetector with 099:00 time
2015.07.02 21:24:55 3: Device WZ_DGK_Tuer_L added to ActionDetector with 028:00 time
2015.07.02 21:24:55 3: Device WZ_DGK_Tuer_R added to ActionDetector with 028:00 time
2015.07.02 21:24:55 3: Device WZ_Fenster_links added to ActionDetector with 000:50 time
2015.07.02 21:24:55 3: Device WZ_Fenster_rechts added to ActionDetector with 000:50 time
2015.07.02 21:24:55 3: Device WZ_HK_Fenster_Device added to ActionDetector with 000:10 time
2015.07.02 21:24:55 3: Device WZ_HK_Mitte_Device added to ActionDetector with 000:10 time
2015.07.02 21:24:56 3: Device WZ_RM added to ActionDetector with 099:00 time
2015.07.02 21:24:57 0: Featurelevel: 5.6
2015.07.02 21:24:57 0: Server started with 521 defined entities (version $Id: fhem.pl 8810 2015-06-23 18:40:53Z rudolfkoenig $, os linux, user fhem, pid 31679)
2015.07.02 21:24:58 1: HMLAN_Parse: HMUSB1 new condition ok
2015.07.02 21:24:59 1: HMLAN_Parse: HMUSB0 new condition ok
2015.07.02 21:25:00 1: HMLAN_Parse: HMLAN0 new condition ok
2015.07.02 21:25:00 1: HMLAN_Parse: HMLAN1 new condition ok
2015.07.02 21:25:01 1: HMLAN_Parse: HMLAN2 new condition ok
2015.07.02 21:25:04 3: CUL_HM set HWR_Aussenlicht_Terrasse statusRequest
2015.07.02 21:25:10 3: CUL_HM set ANB_Aussensteckdosen statusRequest
2015.07.02 21:25:11 3: CUL_HM set AB_Deckenlicht statusRequest
2015.07.02 21:25:18 3: CUL_HM set ASR_RM statusRequest
2015.07.02 21:25:19 3: CUL_HM set ASR_Rollo_Links statusRequest
2015.07.02 21:25:20 3: CUL_HM set ASR_Rollo_Rechts statusRequest
2015.07.02 21:25:27 3: CUL_HM set FL_Rollo statusRequest
2015.07.02 21:25:32 3: CUL_HM set FL_Treppenlicht statusRequest
2015.07.02 21:25:33 3: CUL_HM set GAR_Aussensteckdose statusRequest
2015.07.02 21:25:35 3: CUL_HM set GEN_4SW_Tueroeffner statusRequest
2015.07.02 21:25:37 3: CUL_HM set GEN_LED1 statusRequest
2015.07.02 21:25:39 3: CUL_HM set GWC_Rollo statusRequest
2015.07.02 21:25:42 3: CUL_HM set HWR_Rollo_Nord statusRequest
2015.07.02 21:25:43 3: GEN_LED1 unreachable
2015.07.02 21:25:43 3: CUL_HM set HWR_Rollo_Tuer statusRequest
2015.07.02 21:25:44 3: CUL_HM set HWR_Rollo_West statusRequest
2015.07.02 21:25:46 3: CUL_HM set HWR_Wandleuchte statusRequest
2015.07.02 21:25:47 3: CUL_HM set CUL_HM_HM_LC_Dim1TPBU_FM_26FBDB_Sw1_V_01 statusRequest
2015.07.02 21:25:48 3: CUL_HM set CUL_HM_HM_LC_Dim1TPBU_FM_26FBDB_Sw1_V_02 statusRequest
2015.07.02 21:25:49 3: ASR_Rollo_Links IOerr
2015.07.02 21:25:49 3: ASR_Rollo_Rechts IOerr
2015.07.02 21:25:49 3: GWC_Rollo IOerr
2015.07.02 21:25:49 3: KUC_Rollo_Ost IOerr
2015.07.02 21:25:50 3: CUL_HM set JWR_RM statusRequest
2015.07.02 21:25:52 3: HWR_Wandleuchte unreachable
2015.07.02 21:25:52 3: CUL_HM set KUC_Rollo_Ost statusRequest
2015.07.02 21:25:53 3: CUL_HM_HM_LC_Dim1TPBU_FM_26FBDB_Sw1_V_01 unreachable
2015.07.02 21:25:53 3: CUL_HM set KUC_Rollo_Sued statusRequest
2015.07.02 21:25:53 3: CUL_HM_HM_LC_Dim1TPBU_FM_26FBDB_Sw1_V_02 unreachable
2015.07.02 21:25:54 3: CUL_HM set SZ_Deckenlicht statusRequest
2015.07.02 21:25:56 3: CUL_HM set SZ_Rollo statusRequest
2015.07.02 21:25:56 3: JWR_RM unreachable
2015.07.02 21:25:58 3: CUL_HM set TMO_Deckenlicht statusRequest
2015.07.02 21:25:58 3: KUC_Rollo_Ost unreachable
2015.07.02 21:25:58 3: KUC_Rollo_Sued unreachable
2015.07.02 21:25:59 3: CUL_HM set CUL_HM_HM_LC_Dim1TPBU_FM_26FB98_Sw1_V_01 statusRequest
2015.07.02 21:26:00 3: SZ_Deckenlicht unreachable
2015.07.02 21:26:01 3: CUL_HM set CUL_HM_HM_LC_Dim1TPBU_FM_26FB98_Sw1_V_02 statusRequest
2015.07.02 21:26:01 3: CUL_HM KUC_Rollo_Ost repeat, level C8 instead of 42
2015.07.02 21:26:02 3: CUL_HM set TMO_Rollo statusRequest
2015.07.02 21:26:03 3: CUL_HM set WZ_Aussen_Licht1 statusRequest
2015.07.02 21:26:03 3: TMO_Deckenlicht unreachable
2015.07.02 21:26:10 3: CUL_HM set WZ_Aussensteckdosen statusRequest
2015.07.02 21:26:10 3: CUL_HM_HM_LC_Dim1TPBU_FM_26FB98_Sw1_V_01 unreachable
2015.07.02 21:26:10 3: CUL_HM_HM_LC_Dim1TPBU_FM_26FB98_Sw1_V_02 unreachable
2015.07.02 21:26:11 3: CUL_HM set WZ_Rollo_Erker_L statusRequest
2015.07.02 21:26:13 3: CUL_HM set WZ_Rollo_Erker_R statusRequest
2015.07.02 21:26:15 3: CUL_HM set WZ_Rollo_Erker_Tuer statusRequest
2015.07.02 21:26:19 3: CUL_HM set WZ_Rollo_Sued statusRequest
2015.07.02 21:26:20 3: CUL_HM set WZ_Rollo_Terrassentuer statusRequest
2015.07.02 21:26:24 3: CUL_HM set GEN_LED1_01 getConfig
2015.07.02 21:26:28 3: CUL_HM set GEN_LED1_02 getConfig
2015.07.02 21:26:33 3: CUL_HM set GEN_LED1_03 getConfig
2015.07.02 21:26:37 3: CUL_HM set GEN_LED1_04 getConfig
2015.07.02 21:26:41 3: CUL_HM set GEN_LED1_05 getConfig
2015.07.02 21:26:45 3: CUL_HM set GEN_LED1_06 getConfig
2015.07.02 21:26:54 3: CUL_HM set GEN_LED1_07 getConfig
2015.07.02 21:27:00 3: CUL_HM set GEN_LED1_08 getConfig
2015.07.02 21:27:04 3: CUL_HM set GEN_LED1_09 getConfig
2015.07.02 21:27:08 3: CUL_HM set GEN_LED1_10 getConfig
2015.07.02 21:27:17 3: CUL_HM set GEN_LED1_11 getConfig
2015.07.02 21:27:22 3: CUL_HM set GEN_LED1_12 getConfig
2015.07.02 21:27:26 3: CUL_HM set GEN_LED1_13 getConfig
2015.07.02 21:27:30 3: CUL_HM set GEN_LED1_14 getConfig
2015.07.02 21:27:34 3: CUL_HM set GEN_LED1_15 getConfig
2015.07.02 21:27:38 3: CUL_HM set GEN_LED1_16 getConfig
Edit:
Nach ersten Beobachtungen tritt das Problem mit dem Device immer noch auf, allerdings wurden für die Channels keine StatusRequests nach der halben Stunde ausgelöst:
2015.07.02 21:55:46 3: CUL_HM set GEN_LED1 statusRequest
2015.07.02 21:55:51 3: GEN_LED1 unreachable
2015.07.02 22:25:53 3: CUL_HM set GEN_LED1 statusRequest
2015.07.02 22:25:59 3: GEN_LED1 unreachable
2015.07.02 22:56:01 3: CUL_HM set GEN_LED1 statusRequest
2015.07.02 22:56:06 3: GEN_LED1 unreachable
2015.07.02 23:26:09 3: CUL_HM set GEN_LED1 statusRequest
2015.07.02 23:26:15 3: GEN_LED1 unreachable
2015.07.02 23:56:18 3: CUL_HM set GEN_LED1 statusRequest
2015.07.02 23:56:23 3: GEN_LED1 unreachable
2015.07.03 00:26:26 3: CUL_HM set GEN_LED1 statusRequest
2015.07.03 00:26:31 3: GEN_LED1 unreachable
2015.07.03 00:56:33 3: CUL_HM set GEN_LED1 statusRequest
2015.07.03 00:56:38 3: GEN_LED1 unreachable
2015.07.03 01:26:41 3: CUL_HM set GEN_LED1 statusRequest
2015.07.03 01:26:47 3: GEN_LED1 unreachable
2015.07.03 01:56:50 3: CUL_HM set GEN_LED1 statusRequest
2015.07.03 01:56:55 3: GEN_LED1 unreachable
2015.07.03 02:26:58 3: CUL_HM set GEN_LED1 statusRequest
2015.07.03 02:27:03 3: GEN_LED1 unreachable
2015.07.03 02:57:05 3: CUL_HM set GEN_LED1 statusRequest
2015.07.03 02:57:10 3: GEN_LED1 unreachable
2015.07.03 03:27:13 3: CUL_HM set GEN_LED1 statusRequest
2015.07.03 03:27:18 3: GEN_LED1 unreachable
2015.07.03 03:57:20 3: CUL_HM set GEN_LED1 statusRequest
2015.07.03 03:57:26 3: GEN_LED1 unreachable
2015.07.03 04:27:28 3: CUL_HM set GEN_LED1 statusRequest
2015.07.03 04:27:33 3: GEN_LED1 unreachable
2015.07.03 04:57:38 3: CUL_HM set GEN_LED1 statusRequest
2015.07.03 04:57:43 3: GEN_LED1 unreachable
Moin,
habe festgestellt, daß mein HM-OU-CFM-PL nach dem Update ständig unreachable ist und im Log vermehrt statusRequests auftauchen.
Hatte gestern alte Versionen von 10_CUL und 00_HMLAN eingespielt - die Requests blieben aus.
Nach Update ware sie wieder da...
Sonnige Grüße
Kai
Werde ich wohl einmal suchen muessen. Bei den led16 wurde in deinem log bereits fuer jeden kanal ein statusrequest ausgeloest. Das sollte normal sein. Wenn ein system einen neustart macht koennen stati verloren gegangen sein. Es koenntn alte eingespielt werden.... alles koennte. Nach einem start muss fhem zwingend den status der aktoren einholen. Die dargestellte info ist sonst nur vielleicht korrekt. Geht garnicht bei mir zumindest.
Bei registern kann man es anders sehen, das ist konfig - aber hier kein thema.
Zu frueh verstehe ich nicht. Vor ende init geht nichts. Wenn das io disconnected ist auch nicht.
Doif hat nichts mit culhm zu tun. Wenn hier zu frueh gesendet wird.... muss ich dies evtl verriegeln. Sollte eigentlich doif machen.
Ich werde das device / channel handling bei statusrequest ueberdenken und vereinfachen. Da sollte etwas gehen. Wenn sich hier zeigt, dass manche devices nicht reagieren ist es ein problem des device. Das hatten wir hier schon
Zitat von: martinp876 am 01 Juli 2015, 21:03:32
Die energiemessdose scheint hie und da nicht senden zu wollen. Evtl ein overloadschutz. Das sehe ich als das problem hier. Mal ueberlegen, wie man damit umgehen kann
das sehe ich, wie bereits gesagt anders. um es noch mehr zu verdeutlichen, habe ich beim device und allen 6 channels verbose=5 gesetzt und event-on-change gelöscht.
2015.07.06 19:08:52.080 5: CUL_HM SwitchES01 protEvent:CMDs_pending pending:1
2015.07.06 19:08:52.084 3: CUL_HM set SwitchES01_Pwr statusRequest
2015.07.06 19:08:52.095 0: HMLAN_Send: hmlan1 S:S64577E47 stat: 00 t:00000000 d:01 r:64577E47 m:32 A001 1ACE1F 24AF1D 020E
2015.07.06 19:08:52.098 0: HMLAN_Send: hmlan1 I:K
2015.07.06 19:08:52.110 5: CUL_HM SwitchES01 protEvent:CMDs_processing... pending:0
2015.07.06 19:08:52.126 0: HMLAN_Parse: hmlan1 V:03C4 sNo:JEQ0315335 d:1C671E O:1ACE1F t:036E94BB IDcnt:000D L:10 %
2015.07.06 19:08:52.162 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:022CD290 d:FF r:FFCF m:32 A001 1ACE1F 24AF1D 020E
2015.07.06 19:08:52.269 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:036E953F d:FF r:FFA8 m:32 A45F 24AF1D 1ACE1F 8003B90000000000092701
2015.07.06 19:08:52.291 5: CUL_HM SwitchES01 protEvent:CMDs_done
2015.07.06 19:08:52.293 5: CUL_HM SwitchES01 sent ACK:2
2015.07.06 19:08:53.085 0: HMLAN_Parse: hmlan1 R:R64577E47 stat:0001 t:036E9544 d:FF r:FFA8 m:32 A45F 24AF1D 1ACE1F 8003B90000000000092701
2015.07.06 19:08:53.100 5: CUL_HM SwitchES01 protEvent:CMDs_done
2015.07.06 19:08:53.101 4: CUL_HM SwitchES01 dupe: repeat 2 ack, dont process
2015.07.06 19:08:53.227 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:022CD391 d:FF r:FFCE m:32 8002 1ACE1F 24AF1D 00
2015.07.06 19:08:53.506 5: CUL_HM SwitchES01 protEvent:CMDs_pending pending:1
2015.07.06 19:08:53.508 3: CUL_HM set SwitchES01_SenPwr statusRequest
2015.07.06 19:08:53.515 0: HMLAN_Send: hmlan1 S:+24AF1D,00,00,00
2015.07.06 19:08:53.518 0: HMLAN_Send: hmlan1 S:S645783D6 stat: 00 t:00000000 d:01 r:645783D6 m:33 A001 1ACE1F 24AF1D 030E
2015.07.06 19:08:53.524 5: CUL_HM SwitchES01 protEvent:CMDs_processing... pending:0
2015.07.06 19:08:53.569 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:022CD820 d:FF r:FFD0 m:33 A001 1ACE1F 24AF1D 030E
2015.07.06 19:08:53.761 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:022CD8E8 d:FF r:FFD0 m:33 A001 1ACE1F 24AF1D 030E
2015.07.06 19:08:53.985 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:022CD9B0 d:FF r:FFD0 m:33 A001 1ACE1F 24AF1D 030E
2015.07.06 19:08:54.127 0: HMLAN_Parse: hmlan1 R:R645783D6 stat:0008 t:00000000 d:FF r:7FFF m:33 A001 1ACE1F 24AF1D 030E
2015.07.06 19:08:54.129 0: HMLAN_Parse: hmlan1 no ACK from 24AF1D
2015.07.06 19:08:55.215 3: CUL_HM set SwitchES01_SenI statusRequest
2015.07.06 19:08:57.985 4: CUL_HM_Resend: SwitchES01 nr 2
2015.07.06 19:08:57.990 0: HMLAN_Send: hmlan1 S:S64579551 stat: 00 t:00000000 d:01 r:64579551 m:33 A001 1ACE1F 24AF1D 030E
2015.07.06 19:08:58.049 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:022CE999 d:FF r:FFCE m:33 A001 1ACE1F 24AF1D 030E
2015.07.06 19:08:58.241 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:022CEA61 d:FF r:FFCE m:33 A001 1ACE1F 24AF1D 030E
2015.07.06 19:08:58.433 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:022CEB29 d:FF r:FFCE m:33 A001 1ACE1F 24AF1D 030E
2015.07.06 19:08:58.659 0: HMLAN_Parse: hmlan1 R:R64579551 stat:0008 t:00000000 d:FF r:7FFF m:33 A001 1ACE1F 24AF1D 030E
2015.07.06 19:08:58.661 0: HMLAN_Parse: hmlan1 no ACK from 24AF1D
2015.07.06 19:08:59.060 0: HMLAN_Send: hmusb1 I:K
2015.07.06 19:08:59.106 0: HMLAN_Parse: hmusb1 V:03C7 sNo:KEQ1111271 d:263408 O:1ACE1F t:022CEDBB IDcnt:0012 L:3 %
2015.07.06 19:08:59.759 3: CUL_HM set SwitchES01_SenU statusRequest
2015.07.06 19:09:00.783 3: CUL_HM set SwitchES01_SenF statusRequest
2015.07.06 19:09:02.779 4: CUL_HM_Resend: SwitchES01 nr 3
2015.07.06 19:09:02.785 0: HMLAN_Send: hmlan1 S:S6457A80B stat: 00 t:00000000 d:01 r:6457A80B m:33 A001 1ACE1F 24AF1D 030E
2015.07.06 19:09:02.849 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:022CFC53 d:FF r:FFCE m:33 A001 1ACE1F 24AF1D 030E
2015.07.06 19:09:03.041 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:022CFD1B d:FF r:FFCE m:33 A001 1ACE1F 24AF1D 030E
2015.07.06 19:09:03.233 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:022CFDE3 d:FF r:FFCE m:33 A001 1ACE1F 24AF1D 030E
2015.07.06 19:09:03.393 0: HMLAN_Parse: hmlan1 R:R6457A80B stat:0008 t:00000000 d:FF r:7FFF m:33 A001 1ACE1F 24AF1D 030E
2015.07.06 19:09:03.396 0: HMLAN_Parse: hmlan1 no ACK from 24AF1D
2015.07.06 19:09:07.004 1: Perfmon: possible freeze starting at 19:09:06, delay is 1.003
2015.07.06 19:09:07.768 4: CUL_HM_Resend: SwitchES01 nr 4
2015.07.06 19:09:07.779 0: HMLAN_Send: hmlan1 S:S6457BB88 stat: 00 t:00000000 d:01 r:6457BB88 m:33 A001 1ACE1F 24AF1D 030E
2015.07.06 19:09:07.841 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:022D0FD7 d:FF r:FFCE m:33 A001 1ACE1F 24AF1D 030E
2015.07.06 19:09:08.032 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:022D109F d:FF r:FFCE m:33 A001 1ACE1F 24AF1D 030E
2015.07.06 19:09:08.225 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:022D1167 d:FF r:FFCE m:33 A001 1ACE1F 24AF1D 030E
2015.07.06 19:09:08.389 0: HMLAN_Parse: hmlan1 R:R6457BB88 stat:0008 t:00000000 d:FF r:7FFF m:33 A001 1ACE1F 24AF1D 030E
2015.07.06 19:09:08.392 0: HMLAN_Parse: hmlan1 no ACK from 24AF1D
2015.07.06 19:09:13.525 5: CUL_HM SwitchES01 protEvent:CMDs_done_Errors:1
2015-07-06_19:08:51 SwitchES01 CMDs_pending
2015-07-06_19:08:52 SwitchES01 CMDs_done
2015-07-06_19:08:52 SwitchES01_Pwr eState: E: 95.3 P: 0 I: 0 U: 234.3 f: 50.01
2015-07-06_19:08:52 SwitchES01_Pwr frequency: 50.01
2015-07-06_19:08:52 SwitchES01_Pwr 95.3
2015-07-06_19:08:52 SwitchES01_Pwr voltage: 234.3
2015-07-06_19:08:52 SwitchES01_SenF 50.01
2015-07-06_19:08:52 SwitchES01_SenI 0
2015-07-06_19:08:52 SwitchES01_SenPwr 0
2015-07-06_19:08:52 SwitchES01_SenU 234.3
2015-07-06_19:08:53 SwitchES01 CMDs_done
2015-07-06_19:08:53 SwitchES01 CMDs_pending
2015-07-06_19:08:57 SwitchES01_Pwr unreachable
2015-07-06_19:08:58 SwitchES01_SenPwr unreachable
2015-07-06_19:09:00 SwitchES01_SenI unreachable
2015-07-06_19:09:05 SwitchES01_SenU unreachable
2015-07-06_19:09:06 SwitchES01_SenF unreachable
2015-07-06_19:09:13 SwitchES01 ResndFail
2015-07-06_19:09:13 SwitchES01 CMDs_done_Errors:1
2015-07-06_19:09:13 SwitchES01 MISSING ACK
1. statusrequest "020E", halbstündig
dieser request auf chn2 (_Pwr) wird regelmässig beantwortet. allerdings mit einem msgtype "A45F". vielleicht ist das ein problem. das eventlog meldet für chn2 (_Pwr) aber regelmässig zuerst den status und anschliessend unreachable.
2. statusrequest "030E", halbstündig
dieser statusrequest wurde noch nie beantwortet. ich habe die vermutung, dass das device das nicht kann.
3. statusrequest "040E", "050E", "060E", halbstündig
im fhem.log gibt es auch hinweise auf die statusrequest's für chn4, chn5 und chn6. die entsprechenden messages werden aber nie gesendet.
2015.07.06 19:08:55.215 3: CUL_HM set SwitchES01_SenI statusRequest
2015.07.06 19:08:59.759 3: CUL_HM set SwitchES01_SenU statusRequest
2015.07.06 19:09:00.783 3: CUL_HM set SwitchES01_SenF statusRequest
4. statusrequest "030E", "040E", "050E", "060E", manuell abgesetzt:
bei manueller ausführung dieser request's werden die messages gesendet, aber ebenfals, wie bei "030E" nie beantwortet. daher auch hier die vermutung, dass statusrequest's auf die sensor-channels grundsätzlich vom messstecker unbeantwortet bleiben.
2015.07.06 19:26:07.104 0: HMLAN_Send: hmlan1 S:+24AF1D,00,00,00
2015.07.06 19:26:07.106 0: HMLAN_Send: hmlan1 S:S6467494A stat: 00 t:00000000 d:01 r:6467494A m:39 A001 1ACE1F 24AF1D 040E
2015.07.06 19:26:07.109 0: HMLAN_Send: hmlan1 I:K
2015.07.06 19:26:07.118 5: CUL_HM SwitchES01 protEvent:CMDs_processing... pending:0
2015.07.06 19:26:07.137 0: HMLAN_Parse: hmlan1 V:03C4 sNo:JEQ0315335 d:1C671E O:1ACE1F t:037E6049 IDcnt:000D L:9 %
2015.07.06 19:26:07.152 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:023C9D8A d:FF r:FFCE m:39 A001 1ACE1F 24AF1D 040E
2015.07.06 19:26:07.524 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:023C9E52 d:FF r:FFCE m:39 A001 1ACE1F 24AF1D 040E
2015.07.06 19:26:07.567 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:023C9F1A d:FF r:FFCE m:39 A001 1ACE1F 24AF1D 040E
2015.07.06 19:26:07.716 0: HMLAN_Parse: hmlan1 R:R6467494A stat:0008 t:00000000 d:FF r:7FFF m:39 A001 1ACE1F 24AF1D 040E
2015.07.06 19:26:07.718 0: HMLAN_Parse: hmlan1 no ACK from 24AF1D
2015.07.06 19:26:10.505 4: CUL_HM_Resend: SwitchES01 nr 2
2015.07.06 19:26:10.510 0: HMLAN_Send: hmlan1 S:S64675699 stat: 00 t:00000000 d:01 r:64675699 m:39 A001 1ACE1F 24AF1D 040E
2015.07.06 19:26:10.575 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:023CAAD5 d:FF r:FFCE m:39 A001 1ACE1F 24AF1D 040E
2015.07.06 19:26:11.204 0: HMLAN_Parse: hmlan1 R:R64675699 stat:0008 t:00000000 d:FF r:7FFF m:39 A001 1ACE1F 24AF1D 040E
2015.07.06 19:26:11.205 0: HMLAN_Parse: hmlan1 no ACK from 24AF1D
2015.07.06 19:26:11.223 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:023CAB9E d:FF r:FFD0 m:39 A001 1ACE1F 24AF1D 040E
2015.07.06 19:26:11.240 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:023CAC66 d:FF r:FFD0 m:39 A001 1ACE1F 24AF1D 040E
2015.07.06 19:26:15.923 4: CUL_HM_Resend: SwitchES01 nr 3
2015.07.06 19:26:15.928 0: HMLAN_Send: hmlan1 S:S64676BC3 stat: 00 t:00000000 d:01 r:64676BC3 m:39 A001 1ACE1F 24AF1D 040E
2015.07.06 19:26:15.983 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:023CC000 d:FF r:FFCE m:39 A001 1ACE1F 24AF1D 040E
2015.07.06 19:26:16.175 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:023CC0C8 d:FF r:FFCE m:39 A001 1ACE1F 24AF1D 040E
2015.07.06 19:26:16.399 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:023CC18F d:FF r:FFCE m:39 A001 1ACE1F 24AF1D 040E
2015.07.06 19:26:16.537 0: HMLAN_Parse: hmlan1 R:R64676BC3 stat:0008 t:00000000 d:FF r:7FFF m:39 A001 1ACE1F 24AF1D 040E
2015.07.06 19:26:16.540 0: HMLAN_Parse: hmlan1 no ACK from 24AF1D
2015.07.06 19:26:20.877 4: CUL_HM_Resend: SwitchES01 nr 4
2015.07.06 19:26:20.882 0: HMLAN_Send: hmlan1 S:S64677F1D stat: 00 t:00000000 d:01 r:64677F1D m:39 A001 1ACE1F 24AF1D 040E
2015.07.06 19:26:20.943 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:023CD359 d:FF r:FFD0 m:39 A001 1ACE1F 24AF1D 040E
2015.07.06 19:26:21.135 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:023CD422 d:FF r:FFCF m:39 A001 1ACE1F 24AF1D 040E
2015.07.06 19:26:21.327 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:023CD4EA d:FF r:FFCE m:39 A001 1ACE1F 24AF1D 040E
2015.07.06 19:26:21.492 0: HMLAN_Parse: hmlan1 R:R64677F1D stat:0008 t:00000000 d:FF r:7FFF m:39 A001 1ACE1F 24AF1D 040E
2015.07.06 19:26:21.494 0: HMLAN_Parse: hmlan1 no ACK from 24AF1D
2015.07.06 19:26:26.374 5: CUL_HM SwitchES01 protEvent:CMDs_done_Errors:1
eigentlich sollte doch nur ein statusrequest auf chn2 ausreichen, um die stati für chn2 und die sensor-channels (chn3-chn6) zu erhalten, da durch diese eine antwort bereits die stati für chn3-6 generiert werden können. bei manuellem absetzen des statusrequest auf chn2 werden ebenfalls diese 5 stati gesetzt. hier mal der manuelle statusrequest auf chn2:
2015.07.07 11:38:19.048 5: CUL_HM SwitchES01 protEvent:CMDs_pending pending:1
2015.07.07 11:38:19.051 3: CUL_HM set SwitchES01_Pwr statusRequest
2015.07.07 11:38:19.062 0: HMLAN_Send: hmlan1 S:+24AF1D,00,00,00
2015.07.07 11:38:19.065 0: HMLAN_Send: hmlan1 S:S67E15C81 stat: 00 t:00000000 d:01 r:67E15C81 m:BA A001 1ACE1F 24AF1D 020E
2015.07.07 11:38:19.072 5: CUL_HM SwitchES01 protEvent:CMDs_processing... pending:0
2015.07.07 11:38:19.120 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:05B6AD82 d:FF r:FFD3 m:BA A001 1ACE1F 24AF1D 020E
2015.07.07 11:38:19.312 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:05B6AE4A d:FF r:FFD3 m:BA A001 1ACE1F 24AF1D 020E
2015.07.07 11:38:19.660 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:06F89340 d:FF r:FFA7 m:BA A45F 24AF1D 1ACE1F 8005940000000000095001
2015.07.07 11:38:19.679 5: CUL_HM SwitchES01 protEvent:CMDs_done
2015.07.07 11:38:19.682 5: CUL_HM SwitchES01 sent ACK:2
2015.07.07 11:38:20.648 0: HMLAN_Parse: hmlan1 R:R67E15C81 stat:0001 t:06F89345 d:FF r:FFA7 m:BA A45F 24AF1D 1ACE1F 8005940000000000095001
2015.07.07 11:38:20.663 5: CUL_HM SwitchES01 protEvent:CMDs_done
2015.07.07 11:38:20.665 4: CUL_HM SwitchES01 dupe: repeat 2 ack, dont process
2015.07.07 11:38:20.786 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:05B6AF49 d:FF r:FFD3 m:BA 8002 1ACE1F 24AF1D 00
2015-07-07_11:38:18 SwitchES01 CMDs_pending
2015-07-07_11:38:19 SwitchES01 CMDs_done
2015-07-07_11:38:19 SwitchES01_Pwr boot: off
2015-07-07_11:38:19 SwitchES01_Pwr current: 0
2015-07-07_11:38:19 SwitchES01_Pwr eState: E: 142.8 P: 0 I: 0 U: 238.4 f: 50.01
2015-07-07_11:38:19 SwitchES01_Pwr energy: 142.8
2015-07-07_11:38:19 SwitchES01_Pwr energyCalc: 7560.3
2015-07-07_11:38:19 SwitchES01_Pwr frequency: 50.01
2015-07-07_11:38:19 SwitchES01_Pwr power: 0
2015-07-07_11:38:19 SwitchES01_Pwr 142.8
2015-07-07_11:38:19 SwitchES01_Pwr voltage: 238.4
2015-07-07_11:38:20 SwitchES01_SenF 50.01
2015-07-07_11:38:20 SwitchES01_SenI 0
2015-07-07_11:38:20 SwitchES01_SenPwr 0
2015-07-07_11:38:20 SwitchES01_SenU 238.4
2015-07-07_11:38:20 SwitchES01 CMDs_done
gruss frank
ich habe statusrequest für alleKanäle einzelnprobiert - es kommt eine Antwort - leider nicht immer.
die Messages werden abgesetzt. Habe es gerade getestet.
dennoch - evtl sollte ich es einfach sperren - es ist zu unzuverlässig - da stimmt etwas nicht
Zitat von: martinp876 am 08 Juli 2015, 20:33:29
ich habe statusrequest für alleKanäle einzelnprobiert - es kommt eine Antwort - leider nicht immer.
dein fhem ist aktuell? ;)
spass beiseite, das kann ich nicht glauben. ich gehe mal davon aus, dein messstecker hat auch fw2.5. ich verbuche deine erhaltenen "antworten" als täuschungen, die durch normal gesendete powerevents "A45F" mitunter "falsch" verbucht werden. du kannst zum testen alle powerevents abschalten.
set <chn2> regSet txThrCur unused
set <chn2> regSet txThrFrq unused
set <chn2> regSet txThrPwr unused
set <chn2> regSet txThrVlt unused
jetzt sollten nur noch cyclische powerevents "845E" an broadcast kommen (2-3 min) und
ein powerevent "A45F" als antwort auf ein statusrequest auf channel2 (_Pwr). statusrequests auf channel3-6 bleiben nun (hoffentlich auch bei dir) unbeantwortet.
------------------------------------------------------------------------------------------------------------------------
ich habe mal einen blick in die rf_es_pmsw.xml datei riskiert. wenn ich dort nach den statusrequests schaue, hier werden sie durch
"LEVEL_GET" gekennzeichnet, sind sämtliche statusrequests, die sich auf die messwerte beziehen unter der kategorie
<channel index="2" type="POWERMETER"> aufgeführt und beantwortet werden sie mit powerevent.
<get request="LEVEL_GET" response="POWER_EVENT" process_as_event="true"/>
das deckt sich vollkommen mit meiner beobachtung, dass nur statusrequests auf chn2 mit powerevent "A45F" regelmässig beantwortet werden. macht ja auch keinen sinn, die anderen channel abzufragen, wenn alle infos bereits mit der einen antwort erfragt werden können.
ein weiteres indiz ist das verhalten der steckdose nach dem einstecken. sie sendet ein statusinfo für chn1 und das powerevent für alle messwerte. damit sind alle infos abgedeckt.
2015.07.09 18:43:10.696 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:008B5216 d:FF r:FFCA m:01 A410 24AF1D 1ACE1F 06010000
2015.07.09 18:43:10.793 0: HMLAN_Send: hmlan1 S:S73B30D52 stat: 00 t:00000000 d:01 r:73B30D52 m:01 8002 1ACE1F 24AF1D 00
2015.07.09 18:43:10.879 0: HMLAN_Parse: hmlan1 R:R73B30D52 stat:0002 t:00000000 d:FF r:7FFF m:01 8002 1ACE1F 24AF1D 00
2015.07.09 18:43:12.661 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:008B59C4 d:FF r:FFCA m:02 A45F 24AF1D 1ACE1F 8000000000000000094580
2015.07.09 18:43:14.852 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:00040D3A d:FF r:FFD4 m:02 8002 1ACE1F 24AF1D 00
Zitatdie Messages werden abgesetzt. Habe es gerade getestet.
manuell werden bei mir auch die messages abgesetzt. nur beim halbstündigen automatischen statusrequest fehlen die messages für channel 4-6.
Zitatdennoch - evtl sollte ich es einfach sperren - es ist zu unzuverlässig - da stimmt etwas nicht
nach meinen beobachtungen ist es äusserst zuverlässig.
du musst eigentlich nur die statusrequest für chn 3-6 abschalten, denn sie werden nicht beantwortet und die messwerte werden ja bereits mit dem statusrequest auf chn 2 geliefert.
bleibt nur der bug, dass das powerevent als antwort auf den statusrequest von chn2 trotzdem nach 3-5 sekunden "unreachable" liefert.
gruss frank
nun - unzuverlässig sind die Statusrequests auf Kanäle 3-6 - die kommen manchmal. Das es antworten sind kann man an den Messagenummern erkennen.
und natürlich werden/wurden nur die Kanäle gesperrt die es nicht beantworten.
Deine Interpretation des XML ist wohl korrekt - die Info nehme ich auch von dort. Leider enthält das XML nur ein subset der Messages eines Devices.
Sollte jetzt erledigt sein
Zitatnun - unzuverlässig sind die Statusrequests auf Kanäle 3-6 - die kommen manchmal. Das es antworten sind kann man an den Messagenummern erkennen.
das sagt mir, dass du meinen vorgeschlagenen test nicht versucht hast. denn sonst hättest du erkannt, dass chn3-6 zuverlässig keine antworten geben. schade.
############################################################################
hier aber mal ein schönes beispiel, das als indiz herangezogen werden kann, dass die antwort "falsch verbucht" wird, wenn die powerevents "A45F" eingeschaltet sind. vielleicht machst du den test ja hiernach. ;)
vorweg noch die feststellung, dass der powermeter 2 (mindestens) messagecounter haben muss. die msgnummern der cyclischen powerevents laufen über einen separaten counter, denn unabhängig von allen anderen aktionen läuft dieser counter brav vor sich hin. wenn fhem eine msg sendet, wird die msgnummer der zuletzt empfangenen message verwendet und um 1 erhöht. je nachdem welcher msgcounter des devices die letzte message gesendet hat, übernimmt fhem den einen oder anderen wert zu erzeugung seiner eigenen messages. in diesem beispiel wird fhem die msgnummern des nicht cyclischen counters verwenden, der im beispiel mit m:7E beginnt. der cyclische counter beginnt hier mit m:55.
ich habe am device einige einstellungen vorgenommen, die akurat immer sofort beantwortet werden. ich habe das ddevice auch extra reingeholt, um beste funkbedingungen zu haben. diese aktionen laufen bis m:86. zwischendurch sendet das device permanent eigene powerevents, die ebenfalls diesen nicht cyclischen msgcounter verwenden. keine msg nummer fehlt.
jetzt aufgepasst!. nun sende ich einen manuellen statusrequest auf chn6 mit m:87. diese msg wird 2 mal nicht beantwortet, trotz der bis hierhin optimalen bedingungen. erst nach ca. 3 sekunden, fhem hat bereits gerade "no ack" auf den 2. versuch vermeldet, kommt plötzlich, wie aus heiterem himmel, doch noch eine "antwort" (würdest du behaupten).
meine interpretation dazu ist, dass dieses powerevent auch ohne statusrequest gekommen wäre. und es hätte die selbe msgnummer gehabt. daher meine formulierung mit den täuschungen der antworten. beweisen kann ich meine behauptung hierdurch natürlich nicht. es spricht aber alles dafür. auch ohne den statusrequest hätte der logverlauf genau so ausgesehen.
das beispiel läuft noch ein bisschen weiter, um den cyclischen counter noch mal zu sehen.
2015.07.09 12:30:04.436 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:05662E2D d:FF r:FFAD m:7E A45F 24AF1D 1ACE1F 80091600CAFF0A3D093801
2015.07.09 12:30:05.312 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:0032BCE3 d:FF r:FFD3 m:7E 8002 1ACE1F 24AF1D 00
2015.07.09 12:30:17.140 0: HMLAN_Send: hmlan1 I:K
2015.07.09 12:30:17.151 0: HMLAN_Parse: hmlan1 V:03C4 sNo:JEQ0315335 d:1C671E O:1ACE1F t:05665FE0 IDcnt:000C L:20 %
2015.07.09 12:30:23.079 0: HMLAN_Send: hmusb1 I:K
2015.07.09 12:30:23.144 0: HMLAN_Parse: hmusb1 V:03C7 sNo:KEQ1111271 d:263408 O:1ACE1F t:00330571 IDcnt:0013 L:12 %
2015.07.09 12:30:26.470 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:05668344 d:FF r:FFAC m:7F A45F 24AF1D 1ACE1F 80093400C3390A04093CFF
2015.07.09 12:30:27.414 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:003311F7 d:FF r:FFD4 m:7F 8002 1ACE1F 24AF1D 00
2015.07.09 12:30:30.925 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:056695AA d:FF r:FFAC m:55 845E 24AF1D 000000 80093B00C4240A09093AFF
2015.07.09 12:30:32.038 1: Perfmon: possible freeze starting at 12:30:31, delay is 1.038
2015.07.09 12:30:33.437 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:05669F7A d:FF r:FFAC m:80 A45F 24AF1D 1ACE1F 80093F00CCA00A4D093BFF
2015.07.09 12:30:34.223 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:00332E2B d:FF r:FFD3 m:80 8002 1ACE1F 24AF1D 00
2015.07.09 12:30:34.564 0: HMLAN_Send: hmlan1 S:+24AF1D,00,00,00
2015.07.09 12:30:34.566 0: HMLAN_Send: hmlan1 S:S725DEC8F stat: 00 t:00000000 d:01 r:725DEC8F m:81 A001 1ACE1F 24AF1D 02050000000001
2015.07.09 12:30:34.632 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:0033324A d:FF r:FFD3 m:81 A001 1ACE1F 24AF1D 02050000000001
2015.07.09 12:30:34.729 0: HMLAN_Parse: hmlan1 R:R725DEC8F stat:0001 t:0566A48C d:FF r:FFAB m:81 8002 24AF1D 1ACE1F 00
2015.07.09 12:30:34.832 0: HMLAN_Send: hmlan1 S:S725DED46 stat: 00 t:00000000 d:01 r:725DED46 m:82 A001 1ACE1F 24AF1D 02087B01
2015.07.09 12:30:35.102 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:003333DB d:FF r:FFD3 m:82 A001 1ACE1F 24AF1D 02087B01
2015.07.09 12:30:35.132 0: HMLAN_Parse: hmlan1 R:R725DED46 stat:0001 t:0566A61F d:FF r:FFAB m:82 8002 24AF1D 1ACE1F 00
2015.07.09 12:30:35.236 0: HMLAN_Send: hmlan1 S:S725DEED9 stat: 00 t:00000000 d:01 r:725DEED9 m:83 A001 1ACE1F 24AF1D 0206
2015.07.09 12:30:35.432 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:0033356D d:FF r:FFD3 m:83 A001 1ACE1F 24AF1D 0206
2015.07.09 12:30:35.629 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:00333635 d:FF r:FFD3 m:83 A001 1ACE1F 24AF1D 0206
2015.07.09 12:30:35.742 0: HMLAN_Parse: hmlan1 R:R725DEED9 stat:0001 t:0566A87B d:FF r:FFAD m:83 8002 24AF1D 1ACE1F 00
2015.07.09 12:30:36.266 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:0566AA82 d:FF r:FFAD m:84 A441 24AF1D 285A54 040FC8
2015.07.09 12:30:36.879 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:0566ACEE d:FF r:FFAD m:84 A441 24AF1D 285A54 040FC8
2015.07.09 12:30:37.479 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:0566AF46 d:FF r:FFAD m:84 A441 24AF1D 285A54 040FC8
2015.07.09 12:30:38.079 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:0566B19E d:FF r:FFAD m:84 A441 24AF1D 285A54 040FC8
2015.07.09 12:30:38.802 0: HMLAN_Send: hmlan1 S:S725DFD1C stat: 00 t:00000000 d:01 r:725DFD1C m:85 A001 1ACE1F 24AF1D 02040000000001
2015.07.09 12:30:38.821 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:0566B3F6 d:FF r:FFAD m:84 A441 24AF1D 285A54 040FC8
2015.07.09 12:30:38.856 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:003342D6 d:FF r:FFD3 m:85 A001 1ACE1F 24AF1D 02040000000001
2015.07.09 12:30:38.977 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:0566B51D d:FF r:FFAD m:85 A010 24AF1D 1ACE1F 0208007A017B017C007D007E00
2015.07.09 12:30:39.086 0: HMLAN_Parse: hmlan1 R:R725DFD1C stat:0001 t:0566B522 d:FF r:FFAD m:85 A010 24AF1D 1ACE1F 0208007A017B017C007D007E00
2015.07.09 12:30:39.112 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:003343D0 d:FF r:FFD3 m:85 8002 1ACE1F 24AF1D 00
2015.07.09 12:30:39.448 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:0566B6F6 d:FF r:FFAC m:85 A010 24AF1D 1ACE1F 0208007A017B017C007D007E00
2015.07.09 12:30:39.593 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:003345A4 d:FF r:FFD3 m:85 8002 1ACE1F 24AF1D 00
2015.07.09 12:30:39.697 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:0566B7F0 d:FF r:FFAC m:86 A010 24AF1D 1ACE1F 027F0080328100820083000000
2015.07.09 12:30:40.025 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:0033469E d:FF r:FFD3 m:86 8002 1ACE1F 24AF1D 00
2015.07.09 12:30:42.146 0: HMLAN_Send: hmlan1 I:K
2015.07.09 12:30:42.157 0: HMLAN_Parse: hmlan1 V:03C4 sNo:JEQ0315335 d:1C671E O:1ACE1F t:0566C193 IDcnt:000C L:21 %
2015.07.09 12:30:48.086 0: HMLAN_Send: hmusb1 I:K
2015.07.09 12:30:48.137 0: HMLAN_Parse: hmusb1 V:03C7 sNo:KEQ1111271 d:263408 O:1ACE1F t:00336710 IDcnt:0013 L:12 %
2015.07.09 12:30:50.951 0: HMLAN_Send: hmlan1 S:+24AF1D,00,00,00
2015.07.09 12:30:50.953 0: HMLAN_Send: hmlan1 S:S725E2C90 stat: 00 t:00000000 d:01 r:725E2C90 m:87 A001 1ACE1F 24AF1D 060E
2015.07.09 12:30:51.015 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:00337249 d:FF r:FFD3 m:87 A001 1ACE1F 24AF1D 060E
2015.07.09 12:30:51.333 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:00337311 d:FF r:FFD3 m:87 A001 1ACE1F 24AF1D 060E
2015.07.09 12:30:51.399 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:003373D9 d:FF r:FFD2 m:87 A001 1ACE1F 24AF1D 060E
2015.07.09 12:30:51.562 0: HMLAN_Parse: hmlan1 R:R725E2C90 stat:0008 t:00000000 d:FF r:7FFF m:87 A001 1ACE1F 24AF1D 060E
2015.07.09 12:30:51.564 0: HMLAN_Parse: hmlan1 no ACK from 24AF1D
2015.07.09 12:30:52.961 0: HMLAN_Send: hmlan1 S:S725E346D stat: 00 t:00000000 d:01 r:725E346D m:87 A001 1ACE1F 24AF1D 060E
2015.07.09 12:30:53.031 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:00337A22 d:FF r:FFD4 m:87 A001 1ACE1F 24AF1D 060E
2015.07.09 12:30:53.224 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:00337AE9 d:FF r:FFD4 m:87 A001 1ACE1F 24AF1D 060E
2015.07.09 12:30:53.415 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:00337BB1 d:FF r:FFD4 m:87 A001 1ACE1F 24AF1D 060E
2015.07.09 12:30:53.571 0: HMLAN_Parse: hmlan1 R:R725E346D stat:0008 t:00000000 d:FF r:7FFF m:87 A001 1ACE1F 24AF1D 060E
2015.07.09 12:30:53.573 0: HMLAN_Parse: hmlan1 no ACK from 24AF1D
2015.07.09 12:30:53.789 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:0566EEFC d:FF r:FFAE m:87 A45F 24AF1D 1ACE1F 80095C00C5F60A160939FE
2015.07.09 12:30:54.950 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:0566F104 d:FF r:FFAC m:88 A45F 24AF1D 1ACE1F 80095D00C1AA09E3092CFF
2015.07.09 12:30:55.895 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:00337DA9 d:FF r:FFD3 m:87 8002 1ACE1F 24AF1D 00
2015.07.09 12:30:55.913 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:00337FB1 d:FF r:FFD3 m:88 8002 1ACE1F 24AF1D 00
2015.07.09 12:30:55.931 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:0033849C d:FF r:FFD3 m:88 8002 1ACE1F 24AF1D 00
2015.07.09 12:30:56.444 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:0566F5F0 d:FF r:FFAB m:88 A45F 24AF1D 1ACE1F 80095F00C1AA09E3092CFF
2015.07.09 12:31:07.153 0: HMLAN_Send: hmlan1 I:K
2015.07.09 12:31:07.163 0: HMLAN_Parse: hmlan1 V:03C4 sNo:JEQ0315335 d:1C671E O:1ACE1F t:05672345 IDcnt:000C L:21 %
2015.07.09 12:31:07.266 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:056723A5 d:FF r:FFAD m:89 A45F 24AF1D 1ACE1F 80096F00B9E909AF0933FF
2015.07.09 12:31:08.058 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:0033B250 d:FF r:FFD3 m:89 8002 1ACE1F 24AF1D 00
2015.07.09 12:31:13.093 0: HMLAN_Send: hmusb1 I:K
2015.07.09 12:31:13.160 0: HMLAN_Parse: hmusb1 V:03C7 sNo:KEQ1111271 d:263408 O:1ACE1F t:0033C8CF IDcnt:0013 L:12 %
2015.07.09 12:31:19.266 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:05675287 d:FF r:FFAD m:8A A45F 24AF1D 1ACE1F 80097F00AFA409640934FF
2015.07.09 12:31:20.152 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:0033E130 d:FF r:FFD3 m:8A 8002 1ACE1F 24AF1D 00
2015.07.09 12:31:32.160 0: HMLAN_Send: hmlan1 I:K
2015.07.09 12:31:32.171 0: HMLAN_Parse: hmlan1 V:03C4 sNo:JEQ0315335 d:1C671E O:1ACE1F t:056784F9 IDcnt:000C L:21 %
2015.07.09 12:31:38.102 0: HMLAN_Send: hmusb1 I:K
2015.07.09 12:31:38.151 0: HMLAN_Parse: hmusb1 V:03C7 sNo:KEQ1111271 d:263408 O:1ACE1F t:00342A6E IDcnt:0013 L:13 %
2015.07.09 12:31:48.367 0: HMLAN_Send: hmlan1 I:K
2015.07.09 12:31:48.394 0: HMLAN_Parse: hmlan1 V:03C4 sNo:JEQ0315335 d:1C671E O:1ACE1F t:0567C45D IDcnt:000C L:21 %
2015.07.09 12:31:52.266 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:0567D373 d:FF r:FFAD m:8B A45F 24AF1D 1ACE1F 8009A800D17C0A6D0930FD
2015.07.09 12:31:53.262 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:00346217 d:FF r:FFD4 m:8B 8002 1ACE1F 24AF1D 00
2015.07.09 12:31:53.288 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:0567D75B d:FF r:FFAC m:8C A45F 24AF1D 1ACE1F 8009AA00E3D20B10092FFE
2015.07.09 12:31:54.342 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:0567DB44 d:FF r:FFAC m:8D A45F 24AF1D 1ACE1F 8009AB00EF640B7A092DFE
2015.07.09 12:31:55.252 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:003465FE d:FF r:FFD4 m:8C 8002 1ACE1F 24AF1D 00
2015.07.09 12:31:55.271 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:003469E7 d:FF r:FFD3 m:8D 8002 1ACE1F 24AF1D 00
2015.07.09 12:31:55.304 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:0567DF2C d:FF r:FFAC m:8E A45F 24AF1D 1ACE1F 8009AD00FE180C03092BFE
2015.07.09 12:31:56.198 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:00346DCF d:FF r:FFD3 m:8E 8002 1ACE1F 24AF1D 00
2015.07.09 12:31:56.266 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:0567E314 d:FF r:FFA9 m:8F A45F 24AF1D 1ACE1F 8009AF0112DE0CCC0929FE
2015.07.09 12:31:58.005 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:0567E6FC d:FF r:FFAB m:90 A45F 24AF1D 1ACE1F 8009B1011E030D390929FD
2015.07.09 12:31:59.044 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:003471B7 d:FF r:FFD4 m:8F 8002 1ACE1F 24AF1D 00
2015.07.09 12:31:59.078 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:0034759F d:FF r:FFD2 m:90 8002 1ACE1F 24AF1D 00
2015.07.09 12:31:59.313 1: Perfmon: possible freeze starting at 12:31:58, delay is 1.313
2015.07.09 12:32:00.266 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:0567F2B4 d:FF r:FFAC m:91 A45F 24AF1D 1ACE1F 8009B70124D20D7C0927FD
2015.07.09 12:32:01.138 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:00348156 d:FF r:FFD3 m:91 8002 1ACE1F 24AF1D 00
2015.07.09 12:32:02.266 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:0567FA85 d:FF r:FFAC m:92 A45F 24AF1D 1ACE1F 8009BB0106D50C63092BFD
2015.07.09 12:32:03.192 0: HMLAN_Send: hmusb1 I:K
2015.07.09 12:32:03.204 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:00348927 d:FF r:FFD3 m:92 8002 1ACE1F 24AF1D 00
2015.07.09 12:32:03.239 0: HMLAN_Parse: hmusb1 V:03C7 sNo:KEQ1111271 d:263408 O:1ACE1F t:00348C6D IDcnt:0013 L:13 %
2015.07.09 12:32:03.266 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:0567FE6D d:FF r:FFAE m:93 A45F 24AF1D 1ACE1F 8009BD00ECB30B62092CFD
2015.07.09 12:32:04.239 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:00348D0F d:FF r:FFD3 m:93 8002 1ACE1F 24AF1D 00
2015.07.09 12:32:04.266 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:05680255 d:FF r:FFAC m:94 A45F 24AF1D 1ACE1F 8009BF00E6E80B2C092DFD
2015.07.09 12:32:05.093 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:003490F7 d:FF r:FFD3 m:94 8002 1ACE1F 24AF1D 00
2015.07.09 12:32:06.266 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:05680A25 d:FF r:FFAC m:95 A45F 24AF1D 1ACE1F 8009C200E1140AF8092DFD
2015.07.09 12:32:07.037 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:003498C6 d:FF r:FFD3 m:95 8002 1ACE1F 24AF1D 00
2015.07.09 12:32:11.627 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:05681F16 d:FF r:FFAC m:96 A45F 24AF1D 1ACE1F 8009CA00DB830AC3092BFD
2015.07.09 12:32:13.509 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:0034ADB7 d:FF r:FFD3 m:96 8002 1ACE1F 24AF1D 00
2015.07.09 12:32:13.552 0: HMLAN_Send: hmlan1 I:K
2015.07.09 12:32:13.562 0: HMLAN_Parse: hmlan1 V:03C4 sNo:JEQ0315335 d:1C671E O:1ACE1F t:056826AD IDcnt:000C L:22 %
2015.07.09 12:32:18.267 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:05683907 d:FF r:FFA9 m:97 A45F 24AF1D 1ACE1F 8009D500D3AF0A7E092DFD
2015.07.09 12:32:19.185 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:0034C7A7 d:FF r:FFD3 m:97 8002 1ACE1F 24AF1D 00
2015.07.09 12:32:28.199 0: HMLAN_Send: hmusb1 I:K
2015.07.09 12:32:28.262 0: HMLAN_Parse: hmusb1 V:03C7 sNo:KEQ1111271 d:263408 O:1ACE1F t:0034EE2C IDcnt:0013 L:13 %
2015.07.09 12:32:33.267 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:056873A1 d:FF r:FFAD m:98 A45F 24AF1D 1ACE1F 8009EB00CCF30A480932FC
2015.07.09 12:32:34.193 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:0035023E d:FF r:FFD3 m:98 8002 1ACE1F 24AF1D 00
2015.07.09 12:32:38.267 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:0568872A d:FF r:FFAE m:99 A45F 24AF1D 1ACE1F 8009F200D5E60A950930FD
2015.07.09 12:32:39.189 0: HMLAN_Send: hmlan1 I:K
2015.07.09 12:32:39.202 0: HMLAN_Parse: hmlan1 V:03C4 sNo:JEQ0315335 d:1C671E O:1ACE1F t:05688AD5 IDcnt:000C L:22 %
2015.07.09 12:32:39.209 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:003515C7 d:FF r:FFD3 m:99 8002 1ACE1F 24AF1D 00
2015.07.09 12:32:42.266 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:056896CA d:FF r:FFAD m:9A A45F 24AF1D 1ACE1F 8009F800DC590ACE0931FD
2015.07.09 12:32:43.066 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:00352566 d:FF r:FFD3 m:9A 8002 1ACE1F 24AF1D 00
2015.07.09 12:32:46.247 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:0568A657 d:FF r:FFAC m:56 845E 24AF1D 000000 8009FD00E0D80AF70935FD
2015.07.09 12:32:51.500 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:0568BADD d:FF r:FFAC m:9B A441 24AF1D 285A54 0410C8
2015.07.09 12:32:52.119 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:0568BD49 d:FF r:FFAD m:9B A441 24AF1D 285A54 0410C8
2015.07.09 12:32:52.719 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:0568BFA1 d:FF r:FFAC m:9B A441 24AF1D 285A54 0410C8
2015.07.09 12:32:53.205 0: HMLAN_Send: hmusb1 I:K
2015.07.09 12:32:53.254 0: HMLAN_Parse: hmusb1 V:03C7 sNo:KEQ1111271 d:263408 O:1ACE1F t:00354FCB IDcnt:0013 L:13 %
2015.07.09 12:32:53.319 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:0568C1F9 d:FF r:FFAD m:9B A441 24AF1D 285A54 0410C8
2015.07.09 12:32:53.919 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:0568C451 d:FF r:FFAC m:9B A441 24AF1D 285A54 0410C8
2015.07.09 12:32:54.519 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:0568C6A9 d:FF r:FFAC m:9B A441 24AF1D 285A54 0410C8
2015.07.09 12:33:02.267 0: HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:0568E4ED d:FF r:FFAC m:9C A45F 24AF1D 1ACE1F 800A1800D65E0A90092AFE
2015.07.09 12:33:03.192 0: HMLAN_Parse: hmusb1 R:E1ACE1F stat:0000 t:00357386 d:FF r:FFD3 m:9C 8002 1ACE1F 24AF1D 00
Zitatund natürlich werden/wurden nur die Kanäle gesperrt die es nicht beantworten.
chn3-6 hoffe ich.
ZitatSollte jetzt erledigt sein
sieht noch nicht so aus, denn nach restart kommt jetzt nur noch ein status request auf chn1. chn2 fehlt jetzt ungerechter weise, obwohl hier ja immer artig mit powerevent geantwortet wird.
gruss frank
Zur Abwechslung lässt sich seit dem Update heute bei mir wieder der Pwr nicht mehr schalten. Zum Glück geht's noch direkt aus einem Homematic Taster. Irgendwie steht das Device unter keinem guten Stern.
nicht mehr schalten? hm meiner schon. Nur Channel 01, klar oder
statusrequest geht wieder bei Chan 02.
Ich habe heute nochmal ein Update gemacht und on und off für chn1 sind wieder da. Scheint also ein Fehler aus dem gestrigen Update gewesen zu sein.
Zitatstatusrequest geht wieder bei Chan 02.
gut, danke.
jetzt bitte noch automatisch nach restart für chn2.
Also ich habe mit meinem LED immer noch in halbstündigem Abstand ein unreachable - aber das Teil arbeitet einwandfrei.
Übrigens:
2015.07.13 08:10:27 1: PERL WARNING: Use of uninitialized value $cq in hash element at ./FHEM/10_CUL_HM.pm line 7671.
2015.07.14 08:03:46 1: PERL WARNING: Use of uninitialized value in numeric lt (<) at ./FHEM/10_CUL_HM.pm line 2954.
in Version
# $Id: 10_CUL_HM.pm 8944 2015-07-12 11:12:11Z martinp876 $
Guten Abend,
ich habe heute zuerst ein Update gemacht, dann einen HM-MOD-Re-8 installiert(HM-CFG-LAN am Raspi) und gepaired:
2015.08.06 18:32:44 3: CUL_HM pair: HM_353DC1 switch, model HM-MOD-Re-8 serialNr
2015.08.06 18:32:51 3: CUL_HM set HM_353DC1_Sw_01 statusRequest
2015.08.06 18:32:52 3: CUL_HM set HM_353DC1_Sw_02 statusRequest
2015.08.06 18:32:53 3: CUL_HM set HM_353DC1_Sw_03 statusRequest
2015.08.06 18:32:54 3: CUL_HM set HM_353DC1_Sw_04 statusRequest
2015.08.06 18:32:55 3: CUL_HM set HM_353DC1_Sw_05 statusRequest
2015.08.06 18:32:56 3: CUL_HM set HM_353DC1_Sw_06 statusRequest
2015.08.06 18:32:57 3: CUL_HM set HM_353DC1_Sw_07 statusRequest
2015.08.06 18:32:58 3: CUL_HM set HM_353DC1_Sw_08 statusRequest
2015.08.06 18:33:28 1: HMLAN_Parse: hmusb new condition Warning-HighLoad
2015.08.06 18:33:35 1: HMLAN_Parse: hmusb new condition ERROR-Overload
2015.08.06 18:34:28 3: CUL_HM set HM_353DC1_Sw_01 on
2015.08.06 18:34:35 3: CUL_HM set HM_353DC1_Sw_01 off
Lässt sich aus fhem nicht schalten. Wenn ich manuell per Taster (die auf der Platine) schalte:
2015-08-06 18:45:38 HMLAN hmusb loadLvl: low
2015-08-06 18:45:40 CUL_HM HM_353DC1_Sw_02 deviceMsg: on (to broadcast)
2015-08-06 18:45:40 CUL_HM HM_353DC1_Sw_02 level: 100
2015-08-06 18:45:40 CUL_HM HM_353DC1_Sw_02 pct: 100
2015-08-06 18:45:40 CUL_HM HM_353DC1_Sw_02 on
2015-08-06 18:45:40 CUL_HM HM_353DC1_Sw_02 timedOn: off
2015-08-06 18:45:44 CUL_HM HM_353DC1_Sw_02 deviceMsg: off (to broadcast)
2015-08-06 18:45:44 CUL_HM HM_353DC1_Sw_02 level: 0
2015-08-06 18:45:44 CUL_HM HM_353DC1_Sw_02 pct: 0
2015-08-06 18:45:44 CUL_HM HM_353DC1_Sw_02 off
2015-08-06 18:45:44 CUL_HM HM_353DC1_Sw_02 timedOn: off
2015-08-06 18:45:51 CUL_HM HM_353DC1_Sw_01 deviceMsg: on (to broadcast)
2015-08-06 18:45:51 CUL_HM HM_353DC1_Sw_01 level: 100
2015-08-06 18:45:51 CUL_HM HM_353DC1_Sw_01 pct: 100
2015-08-06 18:45:51 CUL_HM HM_353DC1_Sw_01 on
2015-08-06 18:45:51 CUL_HM HM_353DC1_Sw_01 timedOn: off
2015-08-06 18:45:56 CUL_HM HM_353DC1_Sw_01 deviceMsg: off (to broadcast)
2015-08-06 18:45:56 CUL_HM HM_353DC1_Sw_01 level: 0
2015-08-06 18:45:56 CUL_HM HM_353DC1_Sw_01 pct: 0
2015-08-06 18:45:56 CUL_HM HM_353DC1_Sw_01 off
2015-08-06 18:45:56 CUL_HM HM_353DC1_Sw_01 timedOn: off
2015-08-06 18:46:03 HMLAN hmusb loadLvl: low
Hat das etwas mit dem in diesem Thread beschrieben zu tun oder mache ich einen anderen Fehler (hatte gerade drei Monate fhem-Abstinenz wg. Auslandsaufenthalts)?
Grüße
Martin
kein wunder! ;)
2015.08.06 18:33:35 1: HMLAN_Parse: hmusb new condition ERROR-Overload
Zitat von: frank am 06 August 2015, 19:00:28
kein wunder! ;)
Lasst mich nicht dumm den Hitzetod sterben... Hat das Pairing nicht geklappt? Aktuell lese ich im Log:
2015.08.06 19:30:16 1: HMLAN_Parse: hmusb [b]new condition ok[/b]
2015.08.06 19:35:45 3: CUL_HM set CUL_HM_HM_SEC_SD_299A2F statusRequest
2015.08.06 19:40:28 3: CUL_HM set HM_353DC1_Sw_03 statusRequest
2015.08.06 19:40:29 3: CUL_HM set HM_353DC1_Sw_04 statusRequest
2015.08.06 19:44:45 3: CUL_HM set HM_353DC1_Sw_02 on
2015.08.06 19:44:47 3: CUL_HM set HM_353DC1_Sw_02 off
2015.08.06 19:44:49 3: CUL_HM set HM_353DC1_Sw_01 on
2015.08.06 19:44:51 3: CUL_HM set HM_353DC1_Sw_01 off
ZitatAktuell lese ich im Log:
das sieht ja schon ganz anders aus. ich gehe jetzt mal davon aus, dass es immer noch nicht geht.
ZitatHat das Pairing nicht geklappt?
wahrscheinlich nicht. das könnte man an einem list vom device erkennen. und versuche besser die methode ohne seriennummer.
Nein, reagiert in der Tat immer noch nicht. Habe autoReadReg 0_off gesetzt und ansonsten nur noch einen HM Rauhcmelder mit 4_reqStatus.
fhem.cfg sagt:
define HM_353DC1 CUL_HM 353DC1
attr HM_353DC1 IODev hmusb
attr HM_353DC1 autoReadReg 0_off
attr HM_353DC1 expert 2_full
attr HM_353DC1 firmware 1.0
attr HM_353DC1 model HM-MOD-Re-8
attr HM_353DC1 msgRepeat 1
attr HM_353DC1 room CUL_HM
attr HM_353DC1 serialNr LEQ1521719
attr HM_353DC1 subType switch
attr HM_353DC1 webCmd getConfig:clear msgEvents
define FileLog_HM_353DC1 FileLog ./log/HM_353DC1-%Y.log HM_353DC1
attr FileLog_HM_353DC1 logtype text
attr FileLog_HM_353DC1 room CUL_HM
define HM_353DC1_Sw_01 CUL_HM 353DC101
attr HM_353DC1_Sw_01 model HM-MOD-Re-8
attr HM_353DC1_Sw_01 peerIDs
attr HM_353DC1_Sw_01 room Arbeitszimmer
attr HM_353DC1_Sw_01 webCmd statusRequest:toggle:on:off
define HM_353DC1_Sw_02 CUL_HM 353DC102
attr HM_353DC1_Sw_02 model HM-MOD-Re-8
attr HM_353DC1_Sw_02 room Arbeitszimmer
attr HM_353DC1_Sw_02 webCmd statusRequest:toggle:on:off
define HM_353DC1_Sw_03 CUL_HM 353DC103
attr HM_353DC1_Sw_03 model HM-MOD-Re-8
attr HM_353DC1_Sw_03 webCmd statusRequest:toggle:on:off
define HM_353DC1_Sw_04 CUL_HM 353DC104
attr HM_353DC1_Sw_04 model HM-MOD-Re-8
attr HM_353DC1_Sw_04 webCmd statusRequest:toggle:on:off
define HM_353DC1_Sw_05 CUL_HM 353DC105
attr HM_353DC1_Sw_05 model HM-MOD-Re-8
attr HM_353DC1_Sw_05 webCmd statusRequest:toggle:on:off
define HM_353DC1_Sw_06 CUL_HM 353DC106
attr HM_353DC1_Sw_06 model HM-MOD-Re-8
attr HM_353DC1_Sw_06 webCmd statusRequest:toggle:on:off
define HM_353DC1_Sw_07 CUL_HM 353DC107
attr HM_353DC1_Sw_07 model HM-MOD-Re-8
attr HM_353DC1_Sw_07 webCmd statusRequest:toggle:on:off
define HM_353DC1_Sw_08 CUL_HM 353DC108
attr HM_353DC1_Sw_08 model HM-MOD-Re-8
attr HM_353DC1_Sw_08 webCmd statusRequest:toggle:on:off
in die befehlseingabe "list HM_353DC1" eintippen und posten.
list ergibt
Arbeitszimmer
Bad
Kueche
Schlafzimmer
Wohnzimmer
TV
WC
KS300
Wetter
Terrassen
CUL_HM
FHT
FS20
Favourites
Plots
Terrasssen
Unsorted
icoEverything Everything
Logfile
Commandref
Remote doc
Edit files
Select style
Event monitor
Internals:
DEF 353DC1
IODev hmusb
NAME HM_353DC1
NR 307
NTFY_ORDER 50-HM_353DC1
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
channel_01 HM_353DC1_Sw_01
channel_02 HM_353DC1_Sw_02
channel_03 HM_353DC1_Sw_03
channel_04 HM_353DC1_Sw_04
channel_05 HM_353DC1_Sw_05
channel_06 HM_353DC1_Sw_06
channel_07 HM_353DC1_Sw_07
channel_08 HM_353DC1_Sw_08
protCmdDel 53
protResnd 4 last_at:2015-08-06 20:27:28
protResndFail 4 last_at:2015-08-06 20:27:34
protSnd 4 last_at:2015-08-06 20:27:23
protState CMDs_done_Errors:1
Readings:
2015-08-06 18:32:44 D-firmware 1.0
2015-08-06 18:32:44 D-serialNr LEQ1521719
2015-08-06 18:32:44 R-intKeyVisib set_invisib
2015-08-06 18:32:44 R-pairCentral set_0x424242
2015-08-06 20:28:00 RegL_00:
2015-08-06 20:27:34 state RESPONSE TIMEOUT:RegisterRead
Helper:
HM_CMDNR 5
cSnd 01424242353DC100040000000000,01424242353DC100040000000000
mId 00BE
rxType 2
Io:
newChn +353DC1,00,00,00
prefIO
rxt 0
vccu
p:
353DC1
00
00
00
Mrssi:
mNo
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
dev 1
Attributes:
IODev hmusb
autoReadReg 0_off
expert 2_full
firmware 1.0
model HM-MOD-Re-8
msgRepeat 1
room CUL_HM
serialNr LEQ1521719
subType switch
webCmd getConfig:clear msgEvents
set hm configCheck ergibt
configCheck done:
missing register list
HM_353DC1: RegL_00:
HM_353DC1_Sw_01: RegL_01:
HM_353DC1_Sw_02: RegL_01:
HM_353DC1_Sw_03: RegL_01:
HM_353DC1_Sw_04: RegL_01:
HM_353DC1_Sw_05: RegL_01:
HM_353DC1_Sw_06: RegL_01:
HM_353DC1_Sw_07: RegL_01:
HM_353DC1_Sw_08: RegL_01:
peer list incomplete. Use getConfig to read it.
incomplete: HM_353DC1_Sw_01:
incomplete: HM_353DC1_Sw_02:
incomplete: HM_353DC1_Sw_03:
incomplete: HM_353DC1_Sw_04:
incomplete: HM_353DC1_Sw_05:
incomplete: HM_353DC1_Sw_06:
incomplete: HM_353DC1_Sw_07:
incomplete: HM_353DC1_Sw_08:
2015-08-06 18:32:44 R-pairCentral set_0x424242
wenn das set_ vor der hmid weg ist, hast du richtig gepaired. und die missing registerlisten sind dann auch weg. also keine devices löschen einfach solange pairen, bis es passt. funk ist ok? vielleicht etwas dichter, 2-3 meter.
Die Distanz zwischen Raspi und dem Modul ist recht groß, Luftlinie etwa 8 Meter und von einem Geschoss ins darunterliegende (alte Holzdecken/Böden. Das Modul näher zu bringen ist auch nicht ganz einfach, da ich es in einen Hutschienenverteiler mit Hutschienennetzteil eingebaut habe. Aber natürlich machbar, wenn Du denkst, dass das das Problem ist. Aber damit ich etwas dazulerne: das Pairing hat nicht geklappt, trotz aller Einträge?
Devices senden, ob gepairt oder nicht. Der inhalt kann sich gelegentlich etwas aendern. Fhem empfaengt alles und stellt es dar. Ob gepairt ist wird nicht automatisch geprueft.
Also : immer das pairing pruefen. Hminfo befragen !
ok, aber während der Pairing-Phase bekomme ich so etwas:
Events (Filter:.*):
2015-08-06 22:02:51 HMLAN hmusb loadLvl: low
2015-08-06 22:03:03 HMLAN hmusb loadLvl: low
2015-08-06 22:03:09 HMLAN hmusb cond: Warning-HighLoad
2015-08-06 22:03:09 HMLAN hmusb Xmit-Events: ok:1 disconnected:11 init:11 Warning-HighLoad:2
2015-08-06 22:03:09 HMLAN hmusb prot_Warning-HighLoad: last
2015-08-06 22:03:18 HMLAN hmusb overload
2015-08-06 22:03:18 HMLAN hmusb cond: ERROR-Overload
2015-08-06 22:03:18 HMLAN hmusb Xmit-Events: ERROR-Overload:1 ok:1 disconnected:11 init:11 Warning-HighLoad:2
2015-08-06 22:03:18 HMLAN hmusb prot_ERROR-Overload: last
2015-08-06 22:03:28 HMLAN hmusb loadLvl: low
verbunden mit "unreachable" in den Kanälen - direkt nach Löschen des Device in der fhem.cfg, Neustart, Stromlosmachen des Sticks
Kann man daraus etwas schließen?
Nur damit ich da nicht völlig daneben liege: Habe das Modul nun in ca. 2 m Entfernung zum Stick. Ich gebe ein:
set hmusb hmPairForSec 600
(was mich wundert, dass nach Abschicken des Befehls im WebUI dieses "kommentarlos" auf die Startseite wechselt).
Dann setze ich das Modul durch Drücken der Kanaltaste 1 (5 Sec) in den Anlernmodus, LED beginnt zu blinken.
Mache ich soweit etwas falsch?
Im Log des Device finde ich I/O errors:
2015-08-06_22:55:56 HM_353DC1 CMDs_pending
2015-08-06_22:58:38 HM_353DC1 D-firmware: 1.0
2015-08-06_22:58:38 HM_353DC1 D-serialNr: LEQ1521719
2015-08-06_22:58:38 HM_353DC1 R-pairCentral: set_0x424242
2015-08-06_22:58:38 HM_353DC1 CMDs_pending
2015-08-06_23:02:23 HM_353DC1 D-firmware: 1.0
2015-08-06_23:02:23 HM_353DC1 D-serialNr: LEQ1521719
2015-08-06_23:02:23 HM_353DC1 R-intKeyVisib: set_invisib
2015-08-06_23:02:23 HM_353DC1 R-pairCentral: set_0x424242
2015-08-06_23:02:23 HM_353DC1 CMDs_pending
2015-08-06_23:04:38 HM_353DC1 IOerr
2015-08-06_23:04:38 HM_353DC1 CMDs_done_Errors:1
Zitatdirekt nach Löschen des Device in der fhem.cfg
das ist unnötig. einfach "drüber-pairen".
2015-08-06 22:03:03 HMLAN hmusb loadLvl: low
2015-08-06 22:03:09 HMLAN hmusb cond: Warning-HighLoad
das ist schon allerhand. wenn du das loadlvl attr nicht verändert hast, "springt" die load quasi von 0 (1) auf 90 in 6 sek. rekordverdächtig. eigentlich müsste es auch noch andere loadlvl events geben.
poste mal ein list vom hmusb.
ausserdem solltest du mal die raw-messages vom pairing sniffen, wie im wiki homematic sniffen beschrieben ist.
2015-08-06 22:03:18 HMLAN hmusb prot_ERROR-Overload: last
2015-08-06 22:03:28 HMLAN hmusb loadLvl: low
und 10 sek nach overload soll loadlvl schon wieder low sein. auch nicht schlecht.
das update hat funktioniert? auch restart gemacht? poste mal die versionsangaben.
Das Update war erfolgreich, Restart gemacht.
list hmusb:
Internals:
DEF 127.0.0.1:1234
DeviceName 127.0.0.1:1234
FD 65
NAME hmusb
NR 269
NTFY_ORDER 50-hmusb
PARTIAL
RAWMSG R04EF8933,0001,00010CC6,FF,FFC6,02A010299A2F4242420601000035
RSSI -58
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDsCnt 3
hmusb_MSGCNT 2
hmusb_TIME 2015-08-06 23:34:12
msgKeepAlive dlyMax:1.014 bufferMin:3
msgLoadCurrent 0
msgLoadHistory 5min steps: 0/0/-/-/-/-/-/-/-/-/-/-
owner 424242
uptime 000 00:01:59.622
Readings:
2015-08-06 23:34:10 D-HMIdAssigned 424242
2015-08-06 23:34:10 D-HMIdOriginal 1EBD70
2015-08-06 23:34:10 D-firmware 0.967
2015-08-06 23:34:10 D-serialNr JEQ0700605
2015-08-06 23:34:10 Xmit-Events ok:1 disconnected:1 init:1
2015-08-06 23:34:10 cond ok
2015-08-06 23:35:02 loadLvl low
2015-08-06 23:03:36 prot_ERROR-Overload last
2015-08-06 23:05:10 prot_Warning-HighLoad last
2015-08-06 23:33:46 prot_disconnected last
2015-08-06 23:33:46 prot_init last
2015-08-06 23:34:10 prot_ok last
2015-08-06 23:33:46 state opened
Helper:
assIdCnt 3
assIdRep 3
info 03C7,JEQ0700605,1EBD70,424242
setTime 43911
Cnd:
0 1
253 1
255 1
Ids:
107841:
name RC19
299a2f:
chn 01
flg 0
msg
name CUL_HM_HM_SEC_SD_299A2F
to 1438896852.91719
353dc1:
chn 00
flg 0
msg
name HM_353DC1
to 1438896869.543
K:
BufMin 3
DlyMax 1.014
Next 1438896927.28857
Start 1438896902.28857
Loadlvl:
bl 40
a:
99
90
40
0
H:
0 low
40 batchLevel
90 high
99 suspended
Log:
all 0
sys 0
ids:
ARRAY(0x1bade40)
Q:
HMcndN 0
answerPend 0
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
loadLast 0
loadNo 7
scnt 6
apIDs:
Ref:
hmtL 119622
kTs 0
Attributes:
hmId 424242
hmLanQlen 1_min
loadLevel 0:low,40:batchLevel,90:high,99:suspended
Das gesniffte Log erschreckt vom Ausmaß her, daher als txt:
dass die loadlvl events fehlen ist kein wunder, wenn der hmusb keinen status liefert. ich habe keine ahnung, was diese hmlan_delay meldungen bedeuten. jedenfalls kann der hmusb nicht durch die wenigen gesendeten messages des logs in overload gehen. es macht den eindruck, als hätte er einen "nebenjob".
2015.08.06 23:39:12.414 0: HMLAN_Parse: hmusb V:03C7 sNo:JEQ0700605 d:1EBD70 O:424242 t:0005A324 IDcnt:0003 L:0 %
2015.08.06 23:39:17.561 0: HMLAN_Parse: hmusb R:R04F42196 stat:0208 t:00000000 d:FF r:7FFF m:01 B001 424242 353DC1 00050000000000
2015.08.06 23:39:17.562 1: HMLAN_Parse: hmusb new condition Warning-HighLoad
also wirklich, msgload in 5 sek von 0% auf 90% (highload).
wo hängt der hmusb dran? bekommt er genügend strom? ist hmland aktuell? läuft der hmland eventuell mehrmals? greifen noch andere dienste/programme auf den hmusb zu? eq3-sw oder die tools von mgernoth. vielleicht würde ein debug-log vom hmland etwas mitteilen. wie startest du den hmland?
Zitatwo hängt der hmusb dran?
Direkt am Raspi-USB-Port.
Zitatbekommt er genügend strom?
Das weiß ich nicht, allerdings hat er mit der RC19 ohne Probleme funktioniert.
list RC19:
Readings:
2015-01-31 16:17:30 CommandAccepted yes
2015-01-26 23:13:37 D-firmware 1.0
2015-01-26 23:13:37 D-serialNr EEQ0035939
2015-02-14 15:59:26 PairedTo 0x424242
2015-01-26 23:13:39 R-backAtCharge off
2015-01-26 23:13:39 R-backAtKey on
2015-01-26 23:13:39 R-backAtMotion on
2015-01-26 23:13:39 R-backOnTime 5 s
2015-01-26 23:13:39 R-language English
2015-01-26 23:13:39 R-pairCentral 0x424242
2015-02-14 15:59:26 RegL_00: 02:01 07:00 0A:42 0B:42 0C:42 0D:C0 0E:05 00:00
2015-02-14 15:59:21 alive yes
2015-02-14 15:59:21 battery ok
2015-02-14 15:59:21 powerOn 2015-02-14 15:59:21
2015-02-14 15:59:21 recentStateType info
2015-02-14 15:59:44 state CMDs_done
ist hmland aktuell?
Wenn das das ist, was in /opt/hmcfgusb/version.h steht: #define VERSION "0.097-git"
HMLAN.pm ist: 9012 2015-08-02 08:41:25Z martinp876 $
Zitatgreifen noch andere dienste/programme auf den hmusb zu? eq3-sw oder die tools von mgernoth.
Nicht dass ich wüsste, kann mich nicht erinnern, da jemals manuell herumgebastelt zu haben. Bei mir läuft fast alles noch auf FS20, außer einem Rauchmelder und der RC19, die aber nicht wirklich aktiv im Einsatz ist.
Zitatvielleicht würde ein debug-log vom hmland etwas mitteilen.
Das werde ich heute Abend mal versuchen (über verbose...?)
Zitatwie startest du den hmland?
Ich nehme an, das ist es (aus etc/init.d/fhem
case "$1" in
'start')
echo "Starting fhem..."
/opt/hmcfgusb/hmland -d -p 1234
perl fhem.pl fhem.cfg
RETVAL=$?
ps ax ergibt:
root@raspberrypi:~# ps ax
PID TTY STAT TIME COMMAND
1 ? Ss 0:03 init [2]
2 ? S 0:00 [kthreadd]
3 ? S 0:00 [ksoftirqd/0]
4 ? S 0:00 [kworker/0:0]
5 ? S< 0:00 [kworker/0:0H]
7 ? S 0:00 [rcu_preempt]
8 ? S 0:00 [rcu_bh]
9 ? S 0:00 [rcu_sched]
10 ? S< 0:00 [khelper]
11 ? S 0:00 [kdevtmpfs]
12 ? S< 0:00 [netns]
13 ? S< 0:00 [writeback]
14 ? S< 0:00 [bioset]
15 ? S< 0:00 [crypto]
16 ? S< 0:00 [kblockd]
17 ? S 0:00 [khubd]
18 ? S 0:10 [kworker/0:1]
19 ? S< 0:00 [rpciod]
20 ? S 0:00 [khungtaskd]
21 ? S 0:00 [kswapd0]
22 ? S 0:00 [fsnotify_mark]
23 ? S< 0:00 [nfsiod]
29 ? S< 0:00 [kthrotld]
30 ? S< 0:00 [VCHIQ-0]
31 ? S< 0:00 [VCHIQr-0]
32 ? S< 0:00 [VCHIQs-0]
33 ? S< 0:00 [iscsi_eh]
34 ? S< 0:00 [dwc_otg]
35 ? S< 0:00 [DWC Notificatio]
37 ? S< 0:00 [deferwq]
39 ? S 0:02 [mmcqd/0]
40 ? S 0:01 [jbd2/mmcblk0p6-]
41 ? S< 0:00 [ext4-rsv-conver]
156 ? Ss 0:00 udevd --daemon
316 ? S 0:00 udevd --daemon
669 ? S 0:00 udevd --daemon
1638 ? S 0:04 /usr/sbin/ifplugd -i lo -q -f -u0 -d10 -w -I
1646 ? S 0:23 /usr/sbin/ifplugd -i eth0 -q -f -u0 -d10 -w -I
1803 ? S 0:15 /opt/hmcfgusb/hmland -d -p 1234
1922 ? Ss 0:00 dhclient -v -pf /run/dhclient.eth0.pid -lf /var/lib/d
1976 ? Sl 0:00 /usr/sbin/rsyslogd -c5
2023 ? Ss 0:00 /usr/sbin/cron
2053 ? Ss 0:00 /usr/bin/dbus-daemon --system
2088 ? S 5:58 perl fhem.pl fhem.cfg
2095 ? Ss 0:00 startpar -f -- fhem
2109 ? Ss 0:06 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -c /var/lib/nt
2173 ? Ss 0:00 /usr/sbin/lircd --driver=uirt2_raw --device=/dev/ttyU
2217 ? Ss 0:00 /usr/sbin/sshd
2246 ? Ss 0:00 /usr/sbin/thd --daemon --triggers /etc/triggerhappy/t
2257 tty1 Ss+ 0:00 /sbin/getty --noclear 38400 tty1
2258 tty2 Ss+ 0:00 /sbin/getty 38400 tty2
2259 tty3 Ss+ 0:00 /sbin/getty 38400 tty3
2260 tty4 Ss+ 0:00 /sbin/getty 38400 tty4
2261 tty5 Ss+ 0:00 /sbin/getty 38400 tty5
2262 tty6 Ss+ 0:00 /sbin/getty 38400 tty6
2263 ttyAMA0 Ss+ 0:00 /sbin/getty -L ttyAMA0 115200 vt100
2448 ? S 0:00 [kworker/u2:0]
2464 ? S 0:00 [kworker/u2:2]
2472 ? Ss 0:00 sshd: root@notty
2476 ? Ss 0:00 /usr/lib/openssh/sftp-server
2477 ? Ss 0:00 sshd: root@pts/0
2481 pts/0 Ss 0:00 -bash
2491 pts/0 R+ 0:00 ps ax
In der fhem.cfg:
define hmusb HMLAN 127.0.0.1:1234
attr hmusb hmId 424242
attr hmusb hmLanQlen 1_min
attr hmusb loadLevel 0:low,40:batchLevel,90:high,99:suspended
attr hmusb logIDs sys,all
Ist es denn denkbar, dass ich mich bei der Hardware "verlötet" habe? Das Modul verhält sich beim Start etwas merkwürdig: die erste LED blinkt lang-kurz-kurz, was lt. Manual "Gerät defekt (z. B. TRX868 lässt sich nicht initialisieren)" bedeutet, Nach Unterbrechung der Stromversorgung startet es dann immer normal. Und senden tut es ja, ebenso wie über die Taster schalten.
EDIT: Ergänzung: Stick-Firmware = 0.967
deepthought [~/hmcfgusb]> ./hmland -h
Syntax: ./hmland options
Possible options:
-D debug mode
-d daemon mode
-h this help
-I pretend to be HM-LAN-IF for compatibility with client-software (previous default)
-i interactive mode (connect HM-CFG-USB to terminal)
-l ip listen on given IP address only (for example 127.0.0.1)
-L logfile log network-communication to logfile
-P create PID file /var/run/hmland.pid in daemon mode
-p n listen on port n (default: 1000)
-r n reboot HM-CFG-USB after n seconds (0: no reboot, default: 86400 if FW < 0.967, 0 otherwise)
hh:mm reboot HM-CFG-USB daily at hh:mm
-v verbose mode
-V show version (0.101)
deepthought [~/hmcfgusb]> ./hmland -D -p 1234
letzte zeile: starten im debug mode.
ZitatIst es denn denkbar, dass ich mich bei der Hardware "verlötet" habe? Das Modul verhält sich beim Start etwas merkwürdig: die erste LED blinkt lang-kurz-kurz, was lt. Manual "Gerät defekt (z. B. TRX868 lässt sich nicht initialisieren)" bedeutet, Nach Unterbrechung der Stromversorgung startet es dann immer normal. Und senden tut es ja, ebenso wie über die Taster schalten.
hört sich nicht gut an. in deinem letzten log waren jedenfalls keine messages von dem device, bis auf eine anlernmessage.
vielleicht liefert verbose=5 beim hmusb noch was neues.
Zitatin deinem letzten log waren jedenfalls keine messages von dem device
Doch, wenn man auf einen Taster drückt, erscheint brav die Message unter Events.
Müsste sich das nicht gem. http://fhemwiki.de/wiki/HomeMatic_Devices_pairen manuell per
set hmusb hmPairSerial LEQ1521719
pairen lassen (muss dazu der Empfänger im Anlernmode sein?)? Oder habe ich da etwas falsch verstanden?
Ich habe jetzt auch mal die aktuelle hmland installiert.
Mit Verbose=5 und dem manuellen Pairing über WebUI steht im Log:
2015.08.07 11:27:08 0: Server started with 205 defined entities (version $Id: fhem.pl 9002 2015-07-29 05:46:10Z rudolfkoenig $, os linux, user fhem, pid 2291)
2015.08.07 11:27:08 5: HMLAN_Send: hmusb I:+299A2F,00,00,00
2015.08.07 11:27:08 5: HMLAN_Send: hmusb I:+353DC1,00,00,00
2015.08.07 11:27:08 5: HMLAN_Send: hmusb I:+107841,00,00,00
2015.08.07 11:27:08 3: CUL_HM set CUL_HM_HM_SEC_SD_299A2F statusRequest
2015.08.07 11:27:08 5: HMLAN_Send: hmusb I:K
2015.08.07 11:27:08 3: Opening Denon device 192.168.50.31:23
2015.08.07 11:27:09 5: HMLAN/RAW: /HHM-USB-IF,03C7,JEQ0700605,1EBD70,424242,0025A7F4,0003,49
I00,00,00,00
I00,00,00,00
I00,00,00,00
R077BCE12,0002,00000000,FF,7FFF,998112999999000000
HHM-USB-IF,03C7,JEQ0700605,1EBD70,424242,00261FF4,0003,49
2015.08.07 11:27:09 5: HMLAN_Parse: hmusb V:03C7 sNo:JEQ0700605 d:1EBD70 O:424242 t:0025A7F4 IDcnt:0003 L:73 %
2015.08.07 11:27:09 5: HMLAN_Parse: hmusb R:R077BCE12 stat:0002 t:00000000 d:FF r:7FFF m:99 8112 999999 000000
2015.08.07 11:27:09 1: HMLAN_Parse: hmusb new condition ok
2015.08.07 11:27:09 5: HMLAN_Parse: hmusb V:03C7 sNo:JEQ0700605 d:1EBD70 O:424242 t:00261FF4 IDcnt:0003 L:73 %
2015.08.07 11:27:09 5: HMLAN_Send: hmusb S:+299A2F,00,00,00
2015.08.07 11:27:09 5: HMLAN_Send: hmusb S:S077C498B stat: 00 t:00000000 d:01 r:077C498B m:02 B001 424242 299A2F 010E
2015.08.07 11:27:09 3: CUL_HM set HM_353DC1_Sw_01 statusRequest
2015.08.07 11:27:10 3: CUL_HM set HM_353DC1_Sw_02 statusRequest
2015.08.07 11:27:10 5: HMLAN/RAW: /E299A2F,0000,00262597,FF,FFC6,02A010299A2F4242420601000035
R077C498B,0001,0026259C,FF,FFC6,02A010299A2F4242420601000035
2015.08.07 11:27:10 5: HMLAN_Parse: hmusb R:E299A2F stat:0000 t:00262597 d:FF r:FFC6 m:02 A010 299A2F 424242 0601000035
2015.08.07 11:27:10 5: hmusb dispatch A0E02A010299A2F4242420601000035::-58:hmusb
2015.08.07 11:27:10 5: HMLAN: Skip ACK
2015.08.07 11:27:10 5: HMLAN_Parse: hmusb R:R077C498B stat:0001 t:0026259C d:FF r:FFC6 m:02 A010 299A2F 424242 0601000035
2015.08.07 11:27:10 5: hmusb dispatch A0E02A010299A2F4242420601000035::-58:hmusb
2015.08.07 11:27:10 5: HMLAN_Send: hmusb S:+353DC1,00,00,00
2015.08.07 11:27:10 5: HMLAN_Send: hmusb S:S077C4EDE stat: 00 t:00000000 d:01 r:077C4EDE m:02 B001 424242 353DC1 010E
2015.08.07 11:27:11 3: CUL_HM set HM_353DC1_Sw_03 statusRequest
2015.08.07 11:27:12 5: HMLAN_Delay: hmusb 353DC1
2015.08.07 11:27:12 3: CUL_HM set HM_353DC1_Sw_04 statusRequest
2015.08.07 11:27:13 5: HMLAN_Send: hmusb S:+000000,00,00,00
2015.08.07 11:27:13 5: HMLAN_Send: hmusb S:S077C58B0 stat: 00 t:00000000 d:01 r:077C58B0 m:01 8401 424242 000000 010A4c455131353231373139
2015.08.07 11:27:13 5: HMLAN/RAW: /R077C58B0,0002,00000000,FF,7FFF,018401424242000000010A4C455131353231373139
R077C4EDE,0008,00000000,FF,7FFF,02B001424242353DC1010E
2015.08.07 11:27:13 5: HMLAN_Parse: hmusb R:R077C58B0 stat:0002 t:00000000 d:FF r:7FFF m:01 8401 424242 000000 010A4C455131353231373139
2015.08.07 11:27:13 5: HMLAN_Parse: hmusb R:R077C4EDE stat:0008 t:00000000 d:FF r:7FFF m:02 B001 424242 353DC1 010E
2015.08.07 11:27:13 5: HMLAN_Parse: hmusb no ACK from 353DC1
2015.08.07 11:27:13 3: CUL_HM set HM_353DC1_Sw_05 statusRequest
2015.08.07 11:27:14 3: CUL_HM set HM_353DC1_Sw_06 statusRequest
2015.08.07 11:27:15 3: CUL_HM set HM_353DC1_Sw_07 statusRequest
2015.08.07 11:27:16 3: CUL_HM set HM_353DC1_Sw_08 statusRequest
2015.08.07 11:27:20 4: HMLAN_ack: timeout - clear queue
2015.08.07 11:27:33 5: HMLAN_Send: hmusb I:K
2015.08.07 11:27:33 5: HMLAN/RAW: /HHM-USB-IF,03C7,JEQ0700605,1EBD70,424242,00268126,0003,4D
2015.08.07 11:27:33 5: HMLAN_Parse: hmusb V:03C7 sNo:JEQ0700605 d:1EBD70 O:424242 t:00268126 IDcnt:0003 L:77 %
2015.08.07 11:27:58 5: HMLAN_Send: hmusb I:K
2015.08.07 11:27:58 5: HMLAN/RAW: /HHM-USB-IF,03C7,JEQ0700605,1EBD70,424242,0026E2D3,0003,4D
2015.08.07 11:27:58 5: HMLAN_Parse: hmusb V:03C7 sNo:JEQ0700605 d:1EBD70 O:424242 t:0026E2D3 IDcnt:0003 L:77 %
Zitat(muss dazu der Empfänger im Anlernmode sein?)
nein. er muss aber aufwachen und antworten. aber das habe ich bei deinem device noch nicht gesehen. wenn ich das richtig in erinnerung habe, kann das ding keinen burst, obwohl es vorgesehen ist. müsstes du mal die threads genauer durchstöbern.
mach mal noch ein log während du an den tasten des device schaltest. mal sehen wie der hmusb reagiert.
edit:
ZitatBei mir läuft fast alles noch auf FS20
dafür hast du sicherlich einen cul. mit dem könntest du zum testen mal monitoren, was der hmusb so sendet, während er sich "verausgabt". (verbose=4 und slowrfmode=homematic am cul)
Zitatwenn ich das richtig in erinnerung habe, kann das ding keinen burst
Im Wiki steht:
ZitatDas Modul befindet sich gewöhnlich im Stromsparmodus und muss zur Konfiguration und zum Schalten vom Sender per Burst "aufgeweckt" werden.
Zitatmach mal noch ein log während du an den tasten des device schaltest. mal sehen wie der hmusb reagiert.
ok, wenn ich heute Abend wieder vor Ort bin.
Aber wenn in fhem das Device mit seinen 8 Kanälen usw. angelegt wird: Heißt das nicht, dass es sendet?
Zitat(verbose=4 und slowrfmode=homematic am cul)
Also statt
define CUL_0 CUL /dev/ttyACM0@9600 1034
dann
define CUL_0 CUL /dev/ttyACM0@9600 1034
attr CUL_0 verbose 4
attr CUL_0 rfmode homematic
?
ZitatAber wenn in fhem das Device mit seinen 8 Kanälen usw. angelegt wird: Heißt das nicht, dass es sendet?
doch, das war die bisher einzige message, die ich in deinen logs gesehen habe. und ein paar sekunden später war der hmusb im overload. meine vermutung ist, dass dein device ein problem hat.
define CUL_0 CUL /dev/ttyACM0@9600 1034
attr CUL_0 verbose 4
attr CUL_0 rfmode HomeMatic
Hallo,
Zitat von: dadoc am 07 August 2015, 10:14:02
ist hmland aktuell?
Wenn das das ist, was in /opt/hmcfgusb/version.h steht: #define VERSION "0.097-git"
Du brauchst eine neuere hmland-Version, damit der richtige Loadlevel an Fhem übertragen wird. 0.101 ist aktuell.
Zitat
EDIT: Ergänzung: Stick-Firmware = 0.967
Gut, die brauchst Du für korrekte Loadmeldungen auch.
Gruß
Michael
Hatte die neueste hmland-Version ja wie w.o. geschrieben heute aus der Ferne installiert, konnte aber natürlich nicht gleich testen. Jetzt (vor Ort) habe ich mir das Modul noch einmal mit der Uhrmacherbrille angeschaut und eine (vermutlich) kalte Lötstelle am Funkmodul nachgelötet (bin kein wirklicher Löt-Profi).
Danach klappte das Pairen innerhalb von 2 Sekunden - ich tippe auf die Lötstelle, da das Modul beim Erst-Connecten auch nicht mehr den Fehlercode blinkt, aber vielleicht war es ja auch beides.
Vielen Dank für Eure Hilfe - werde demnächst "auf vielfachen Wunsch" noch posten, wofür und vor allem wie ich das Ganze gemacht habe (Polwendungs-Lösung für Velux 24V-Rolläden).
Schönes WE
Martin