HM-ES-PMSw1-Pl reagiert immer mal wieder nicht

silvio · 28 Mai 2015, 18:05:28

Hallo,

ich habe eine Steckdose mit Leistungsmessung (HM-ES-PMSw1-Pl), die auch oft funktioniert, aber leider bleibt der Status immer mal wieder auf set_on oder set_off stehen. Die Steckdose schaltet dann auch nicht. Es sieht also so aus, als ob sie das Signal nicht bekommt oder nicht annimmt. Ich kann dann mehrfach in FHEM auf on oder off klicken, aber es passiert nichts. Nach einer Weile geht es dann wieder. Wenn man alternativ direkt an der Steckdose manuell schaltet, erscheint der neue Status meistens in FHEM.

Die Steckdose habe ich schon recht lange und zwischenzeitlich einen Workaround gebastelt (extra Schalter dahinter), da ich Schalter und Leistungsmessung benötige. Nun wollte es aber noch einmal wissen und habe eine zweite Steckdose gekauft. Das Verhalten ist exakt gleich. Auch wenn ich die Steckdose in einem anderen Raum habe, kein Unterschied. Auch kein Unterschied auf einem Testsystem mit CUL V3 (statt HMLAN). Beide Steckdosen haben die gleiche Firmware 1.6. Die ältere Steckdose habe ich nun auf die aktuelle Firmware 2.5 aktualisiert. Hat auch nichts gebracht.
FHEM ist aktuell (latest Build von gestern).

Die zweite Steckdose werde ich nun zurückschicken. Aber hat jemand eine Idee, wie ich das mit der anderen Steckdose doch noch hinkriege?

Gruß
Silvio

frank · 28 Mai 2015, 18:36:37

was sagt der funk (rssi)?

silvio · 28 Mai 2015, 18:42:09

-49

Andere Geräte machen absolut keine Probleme, wie auch der nachgeschaltete Schalter (HM-LC-Sw1-FM), der direkt daneben hängt.

frank · 28 Mai 2015, 19:46:36

Zitatder direkt daneben hängt.

eigentlich sollen die ja einen gewissen abstand einhalten, aber das problem war ja schon vorher. dann sniffe mal die messages nach wikiart.

silvio · 28 Mai 2015, 20:37:59

Das kommt im Fehlerfall:
2015.05.28 20:30:53.493 0: HMLAN_Send: HMLAN1 S:S9BCA9282 stat: 00 t:00000000 d:01 r:9BCA9282 m:13 A011 F11234 2AB66A 0201C80000
2015.05.28 20:30:54.101 0: HMLAN_Parse: HMLAN1 R:R9BCA9282 stat:0008 t:00000000 d:FF r:7FFF m:13 A011 F11234 2AB66A 0201C80000
2015.05.28 20:30:54.102 0: HMLAN_Parse: HMLAN1 no ACK from 2AB66A
2015.05.28 20:30:55.544 0: HMLAN_Send: HMLAN1 S:S9BCA9A84 stat: 00 t:00000000 d:01 r:9BCA9A84 m:13 A011 F11234 2AB66A 0201C80000
2015.05.28 20:30:56.152 0: HMLAN_Parse: HMLAN1 R:R9BCA9A84 stat:0008 t:00000000 d:FF r:7FFF m:13 A011 F11234 2AB66A 0201C80000
2015.05.28 20:30:56.153 0: HMLAN_Parse: HMLAN1 no ACK from 2AB66A

Das, wenn es funktioniert:
2015.05.28 20:33:45.933 0: HMLAN_Send: HMLAN1 S:S9BCD3419 stat: 00 t:00000000 d:01 r:9BCD3419 m:15 A011 F11234 2AB66A 0201C80000
2015.05.28 20:33:46.098 0: HMLAN_Parse: HMLAN1 R:R9BCD3419 stat:0001 t:CB482FF7 d:FF r:FFCB m:15 8002 2AB66A F11234 0101C80027

frank · 29 Mai 2015, 10:04:28

dein log zeigt zumindestens, dass die befehle von fhem gesendet werden. die antwort kommt oder bleibt eben aus.

wenn ein zweites gerät das selbe verhalten zeigt, sollte es kein defekt sein. da du bei störung manuell schalten kannst, müsste es mit der funkstrecke zu tun haben. der funk eines benachbarten gerätes funktioniert aber tadellos. eventuell unterdrückt dein device den funk, weil die 1% grenze erreicht ist. abhängig vom messsignal und den einstellungen am gerät kann man die 1%-grenze sehr schnell erreichen. bei mir konnte ich das dann aber immer an einem speziellen blinkcode der geräte-led erkennen. nach vielleicht 10 minuten funktionierte es wieder eine weile, bis die grenze erneut erreicht war. wenn es daran liegen sollte, müsste ein kurzzeitiges ausstecken des messsteckers den trafficzähler zurücksetzen und anschliessend der funkverkehr wieder normal funktionieren.

silvio · 29 Mai 2015, 11:13:44

Habe nun die Steckdose für den Test wieder woanders eingesteckt. Allerdings ging es dann sofort nicht. Die LED hat signalisiert, dass FHEM gefunden wurde, ich habe nicht manuell geschaltet, sondern sofort direkt in FHEM. Mehrere Versuche haben nicht funktioniert. Dann habe ich ein Mal manuell angeschaltet. In FHEM wurde das sofort erkannt und ich konnte dann 40-50 Mal in FHEM erfolgreich schalten. Dann war wieder Schluss.
Dann habe ich wieder manuell geschaltet -> Status ändert sich in FHEM -> Schalten in FHEM geht nun allerdings nicht.
Erneut manuell geschaltet -> Status ändert sich in FHEM -> Schalten in FHEM geht nicht.
Erneut manuell geschaltet -> Status ändert sich in FHEM -> Schalten in FHEM geht 2 Mal, dann wieder nicht. Vielleicht 30s später geht es dann 1 Mal und dann wieder nicht.
Dann habe ich sie kurz vom Strom genommen und wieder eingesteckt. Sie hat dann sofort ein paar Mal hin- und hergeschaltet. FHEM hatte wohl noch Versuche offen. Danach reagiert sie wieder nicht.

Gerade, dass sie nach dem Einstecken sofort nicht reagiert, spricht gegen die 1%-Grenze, oder?

frank · 29 Mai 2015, 11:31:34

ZitatGerade, dass sie nach dem Einstecken sofort nicht reagiert, spricht gegen die 1%-Grenze, oder?

eigentlich schon. vor allem sollte es ein blinkcode anzeigen. permanentes rotes blinken, lang kurz. falls die neueren fw updates das nicht geändert haben.

Zitatich konnte dann 40-50 Mal in FHEM erfolgreich schalten. Dann war wieder Schluss.

das würde wiederum dafür sprechen. oder ist dein hmlan im overload? poste ein list vom hmlan.

poste doch mal die lists des gerätes.

silvio · 29 Mai 2015, 12:40:41

Danke schon mal für die schnellen Antworten und Unterstützung. Ich bin jetzt aber nicht sicher, was genau ich machen soll. Soll ich vom HMLAN die Messages auslesen?

frank · 29 Mai 2015, 12:48:32

einfach das ergebnis von "list HMLAN1", um zu sehen, ob dieser im overload war und wieviel traffic er so zu senden hat. und die lists vom messschalter, um zu sehen, wie du ihn konfiguriert hast, ob der funk schwankt, ....

ein sniffen des messsteckers über eine gewisse zeit würde dir zeigen wie viel dieser senden muss.

silvio · 29 Mai 2015, 17:35:48

Am HMLAN kann es eigentlich auch nicht liegen, da es auch an einem Testsystem mit CUL auftrat, an dem nur die Steckdose registriert war. Hier ist dennoch der Output (lueftung ist die Steckdose, lueftung_ersatz der zusätzliche Schalter als Workaround):

Internals:
DEF 192.168.178.51:1000
DeviceName 192.168.178.51:1000
FD 10
HMLAN1_MSGCNT 6992
HMLAN1_TIME 2015-05-29 17:32:48
HM_CMDNR 120
NAME HMLAN1
NR 26
NTFY_ORDER 50-HMLAN1
PARTIAL
RAWMSG E1A768E,0000,CFC91087,FF,FFAE,4D86021A768E1F48BB00E6BA8493
RSSI -82
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDsCnt 18
msgKeepAlive dlyMax:5.855 bufferMin:0
msgLoadEst 1hour:0% 10min steps: 0/0/0/0/0/0
msgParseDly min:3 max:5341 last:11 cnt:6961
owner F11234
uptime 040 968:21:23.649
Readings:
2015-05-28 20:46:39 D-HMIdAssigned F11234
2015-05-28 20:46:39 D-HMIdOriginal 2BAD0F
2015-05-28 20:46:39 D-firmware 0.964
2015-05-28 20:46:39 D-serialNr LEQ0579012
2015-05-28 20:46:39 Xmit-Events ok:1 disconnected:1 init:1
2015-05-28 20:46:39 cond ok
2015-05-28 20:46:29 prot_disconnected last
2015-05-28 20:46:29 prot_init last
2015-05-25 18:04:26 prot_keepAlive last
2015-05-28 20:46:39 prot_ok last
2015-04-09 22:14:18 prot_timeout last
2015-05-28 20:46:29 state opened
Helper:
assIdCnt 18
assIdRep 18
info 03C4,LEQ0579012,2BAD0F,F11234
setTime 43729
Cnd:
0 1
253 1
255 1
Dly:
cnt 6961
lst 11
max 5341
min 3
Ids:
220517:
chn 02
flg 0
msg
name RL_Schlaf
to 1432877812.81883
220539:
chn 02
flg 0
msg
name RL_Bad
to 1432877812.48287
22195d:
chn 02
flg 0
msg
name RL_KindGar
to 1432877812.65072
22edbd:
name A_Temp
26209f:
name RemoteCntrl1
26c9a5:
chn 02
flg 0
msg
name RL_ArbeitStr
to 1432877812.31493
26c9d4:
chn 02
flg 0
msg
name RL_Kind
to 1432877872.84845
26c9dd:
chn 02
flg 0
msg
name RL_ArbeitGar
to 1432877812.14598
277b28:
chn 02
flg 0
msg
name RL_NiklasKlein
to 1432877802.14547
277b53:
chn 02
flg 0
msg
name RL_KuecheTuer
to 1432877801.97545
277b56:
chn 02
flg 0
msg
name RL_KuecheKlein
to 1432877801.80555
277c32:
chn 02
flg 0
msg
name RL_NiklasTuer
to 1432877802.31592
295823:
chn 02
flg 0
msg
name RL_WohnGar2
to 1432877802.66028
2958fb:
chn 02
flg 0
msg
name RL_WohnGar1
to 1432877800.78592
296e88:
chn 02
flg 0
msg
name RL_WohnKlein
to 1432877802.83052
2a5c30:
chn 02
flg 0
msg
name lueftung_ersatz
to 1432908902.02541
2a5c7d:
chn 01
flg 0
msg
name Pumpe
to 1432838802.918
2ab66a:
chn 02
flg 0
msg
name lueftung
to 1432913617.23576
K:
BufMin 0
DlyMax 5.855
Next 1432913616.43253
Start 1432913591.43253
Log:
all 0
sys 0
ids:
ARRAY(0x1f79370)
Q:
HMcndN 0
answerPend 0
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
apIDs:
Cap:
0 0
1 0
2 0
3 225
4 0
5 0
last 3
sum 225
Ref:
drft -0.000199936020473448
hmtL 3486083649
kTs 0
offL 1429427507787
sysL 1432913591436
Attributes:
hmId F11234
hmLanQlen 1_min

martinp876 · 29 Mai 2015, 18:56:51

Im log hat hmlan gesendet. Kein 1% problem.
Das device antwortet nicht. Was sagt das rssi am device ? Ist das aehnlich dem des hmlan ?
Wenn das device nach einstecken nicht antwortet hat es auch kein 1% problem.
Das device sollte regelmaessig senden. Macht es das ?

silvio · 29 Mai 2015, 19:55:18

Hier sind die RSSI-Daten:
Device receive from last avg min<max count
lueftung HMLAN1 lueftung -51.0 -52.8 -75.0< -46.0 625
lueftung lueftung HMLAN1 -67.0 -65.2 -70.0< -41.0 53

Verbrauchsdaten kommen in FHEM an. Da habe ich nie Probleme festgestellt. Ich habe mir nun das Log aber mal genauer angesehen. Eigenartig ist, dass die Werte nicht immer im gleichen Zeitabstand ankommen. Das schwankt zwischen 2:20 und 3:10 Minuten.

martinp876 · 29 Mai 2015, 20:54:33

kann man sehen - 600 messages empfangen
HMLAN empfängt im Schnitt 13dB besser - das ist möglich, aber nicht unbedingt ein gutes Zeichen.

vielleicht kann man die Antenne etwas verbessern? Ich denke es liegt schlicht an der Empfangsleistung des Aktors.
Jedenfalls ist es kein Problem mit den 1%

silvio · 29 Mai 2015, 22:11:21

Habe die Antenne aus dem Gehäuse rausgeführt. Jetzt ist der Wert auf -47 gestiegen.
Es scheint auch tatsächlich besser zu sein, es tritt aber immer noch auf. Vielleicht komme ich jetzt aber an die 1% Grenze durch die vielen Tests. Nach kurzer Zeit geht es auch wieder. Werde es beobachten.

Danke schon mal.