Hallo zusammen,
leider muss ich mich seit heute einreihen in die Liste derer, die Problemen mit nicht-schaltenden HM Aktoren haben. Zunächst dachte ich, mein Problem hat die Ursache wie im Beitrag Link (http://forum.fhem.de/index.php?topic=11942.0) beschrieben. Nach etwas experimentieren und loggen fürchte (oder hoffe) ich aber, dass mein Problem andere Ursachen hat. Daher hab ich mal einen neuen aufgemacht - ich hoffe das ist OK.
Situation (zur Übersichtlichkeit hier eine reduzierte und inhaltlich nicht unbedingt ,,sinnvolle" Konfiguration , im Produktivsystem ist das ganze aber ein wenig komplizierter das Fehlerbild ist auch in der reduzierten Konfig eindeutig):
1 x HMLAN (HMLAN1)
1 x schaltbare Steckdose HM-LC-SW1-PL (BUR_SD1)
1 x 3-Kanal-FB HM-RC-SEC3-B (RemoteD1 ist das Device, Remote1_1...3 sind die Kanäle)
Steckdose und FB sind mit HMLAN gepairt aber _nicht_ gepeert. D.h. Die Remote sendet ihre Befehle nach Broadcast.
Per Notify soll die Steckdose nach Druck auf die Taste 2 der FB nach 5 Sekunden einschalten und nach weiteren 3 Sekunden ausschalten.
define NOT_tmp1 notify remote1_2.Short.* define tmp1 at +00:00:05 set BUR_SD1 on;define tmp2 at +00:00:08 set BUR_SD1 off
Ich weiß, das ginge auch mit ,,on-for-timer", in meiner Live-Konfiguration ist das aber nicht ganz so einfach möglich.
Das ganze funktioniert einwandfrei. Irgendwann nach Schmökern hier im Forum hab ich dann gelesen, dass es möglich ist, die FB mit virtuellen Devices zu peeren und damit Acks auf die Tastenmeldungen zu bekommen (d.h. Grüne LED an der FB). Toll dachte ich, das macht es sicherer. Also ein virtuelles Gerät angelegt
define virtHM CUL_HM 999998
set virtHM virtual 4 und die FB damit gepeert:set remote1_2 peerChan 1 virtHM_Btn1 single set Das funktioniert auch, die FB meldet den Empfang eines ACK vom HMLAN grün.
ABER: die Steckdose wird nicht mehr korrekt geschalten. Konkret: Das Anschalten funktioniert nicht, das Ausschalten scheinbar schon, aber wenn vorher nicht angeschlaten wurde, bleibt die Steckdose halt aus. Zur Verdeutlichung unten die Logs kommentiert. Interessant ist, dass der Befehl zum Anschalten gesendet wird und von der SD auch bestätigt wird, nur mit dem Status ,,off". Der Befehl scheint also angekommen zu sein das sch... Ding schaltet nur nicht und meldet stoisch ,,off" zurück !?!
Wenn man statt ,,set on" und ,,set off" ,,toggle" verwendet, ist das Verhalten grundsätzlich identisch. Das erste toggle nach 5sec funktioniert nicht, das zweite nach 8sec dann schon.
Ich hab testweise die Intervalle noch länger (10sec/20sec) gemacht nicht dass hier irgendwelche Kollisionen auf der Luftschnittstelle die Ursache sind - keine Änderung.
Merkwürdig ist, dass beide Schaltvorgänge das erste Mal mit der FB funktionieren, sobald vorher _manuell_ im Web-Interface die Steckdose geschaltet wurde. Nach dem ersten mal Schalten mittels FB geht dann aber nichts mehr.
Sobald man die Fernbedienung resetet und und diese dann wieder an Broadcast sendet, funktioniert das Schalten einwandfrei. Ich weiss, das klingt ziemlich mystisch, mehr als unten geloggt und hier beschrieben, habe ich leider nicht herausfinden können.
Martin, ich denke die Frage geht an Dich: ist das für dich irgendwie nachvollziehbar / kann ich irgendwie weitere Infos liefern um den Fehler einzugrenzen? Wäre toll, wenn man das irgendwie in Griff bekommen kann, da die Idee mit dem peeren mit virtuellen Devices sehr gut finde.
Gruß Tobi
Logfile: Schalten mit nicht gepeerter Remote
#Taste 2 Gedrückt, wird an BC gesendet und die beiden Timer angelegt.
2013-04-17 22:37:37.320 Global global DEFINED tmp1
2013-04-17 22:37:37.364 Global global DEFINED tmp2
2013-04-17 22:37:37.373 CUL_HM remote1_2 Short (to broadcast)
2013-04-17 22:37:37.373 CUL_HM remote1_2 trigger: Short_133
2013-04-17 22:37:37.422 CUL_HM remoteD1 battery: low
2013-04-17 22:37:37.422 CUL_HM remoteD1 remote1_2 Short (to broadcast)
#Nach 5sec wird angeschalten und die SD meldet "on"
2013-04-17 22:37:42.348 CUL_HM BUR_SD1 set_on
2013-04-17 22:37:42.395 Global global DELETED tmp1
2013-04-17 22:37:42.571 CUL_HM BUR_SD1 CommandAccepted: yes
2013-04-17 22:37:42.625 CUL_HM BUR_SD1 level: 100 %
2013-04-17 22:37:42.625 CUL_HM BUR_SD1 deviceMsg: on (to HMLAN1)
2013-04-17 22:37:42.625 CUL_HM BUR_SD1 on
#Nach weiteren 3sec wird ausgeschalten und die SD meldet "off"
2013-04-17 22:37:45.378 CUL_HM BUR_SD1 set_off
2013-04-17 22:37:45.425 Global global DELETED tmp2
2013-04-17 22:37:45.601 CUL_HM BUR_SD1 CommandAccepted: yes
2013-04-17 22:37:45.655 CUL_HM BUR_SD1 level: 0 %
2013-04-17 22:37:45.655 CUL_HM BUR_SD1 deviceMsg: off (to HMLAN1)
2013-04-17 22:37:45.655 CUL_HM BUR_SD1 off
Logfile: Schalten mit gepeerter Remote
#Taste 2 Gedrückt, wird an das virt. Gerät gesendet und die beiden Timer angelegt.
2013-04-17 22:41:15.279 Global global DEFINED tmp1
2013-04-17 22:41:15.323 Global global DEFINED tmp2
2013-04-17 22:41:15.332 CUL_HM remote1_2 Short (to virtHM)
2013-04-17 22:41:15.332 CUL_HM remote1_2 trigger: Short_135
2013-04-17 22:41:15.396 CUL_HM virtHM_Btn1 ON
2013-04-17 22:41:15.396 CUL_HM virtHM_Btn1 virtActState: ON
2013-04-17 22:41:15.396 CUL_HM virtHM_Btn1 virtActTrigger: remote1_2
2013-04-17 22:41:15.396 CUL_HM virtHM_Btn1 virtActTrigType: short_Release
2013-04-17 22:41:15.396 CUL_HM virtHM_Btn1 virtActTrigRpt: 1
2013-04-17 22:41:15.396 CUL_HM virtHM_Btn1 virtActTrigNo: 135
2013-04-17 22:41:15.445 CUL_HM remoteD1 battery: low
2013-04-17 22:41:15.445 CUL_HM remoteD1 remote1_2 Short (to virtHM)
#Nach 5sec wird angeschalten und die SD meldet "on", aber die SD meldet OFF !?!
2013-04-17 22:41:20.309 CUL_HM BUR_SD1 set_on
2013-04-17 22:41:20.357 Global global DELETED tmp1
2013-04-17 22:41:20.533 CUL_HM BUR_SD1 CommandAccepted: yes
2013-04-17 22:41:20.587 CUL_HM BUR_SD1 level: 0 %
2013-04-17 22:41:20.587 CUL_HM BUR_SD1 deviceMsg: off (to HMLAN1)
2013-04-17 22:41:20.587 CUL_HM BUR_SD1 off
#Nach weiteren 3sec wird ausgeschalten und die SD meldet "off"
2013-04-17 22:41:23.338 CUL_HM BUR_SD1 set_off
2013-04-17 22:41:23.386 Global global DELETED tmp2
2013-04-17 22:41:23.561 CUL_HM BUR_SD1 CommandAccepted: yes
2013-04-17 22:41:23.616 CUL_HM BUR_SD1 level: 0 %
2013-04-17 22:41:23.616 CUL_HM BUR_SD1 deviceMsg: off (to HMLAN1)
2013-04-17 22:41:23.616 CUL_HM BUR_SD1 off
Hi,
super auswertung, schon einmal danke dafuer :-)
Seltsames verhalten. Evtl reagiert der BUR_SD1 doch direkt. Mache ein getConfig auf den BUR_SD1 und dann ein attr expert 2 und eine List. Mal sehen, ob der einen Peer hat.
Dann die Messages aufzeichnen mit
attr global verbose 1
attr global mseclog 1
attr <hmlan> loglgevel 1
Die Logs sind dann im hauptlogfile
Gruss
Martin
Hi Martin,
danke schon mal für dein Feedback!
Direkt gepairt ist er offensichtlich nicht. Unten die Ausgabe von List (RSSI ist zwar recht schwach, aber gestern hatte ich die SD an anderer Stelle eingesteckt ziemlich nahm am HMLAN) und auch die Logfiles. Sowohl mit gepeerter FB also auch mit ungepeerter FB (wie gestern).
Übrigens: den Aktor hab ich auch resetet und neu gepairt. Mit einem anderen Aktor (4 Kanal Relaisplatine) tritt dasselbe Fehlerbild auf. Am Aktor liegt es also nicht.
Hast Du ne Idee?
Gruß
Tobi
Internals:
CFGFN /opt/fhem/fhem_hm.cfg
DEF 1A33B1
EVENTS 6
HMLAN1_MSGCNT 8
HMLAN1_RAWMSG R1E0DD0EA,0001,51AB3413,FF,FFAC,0480021A33B17DE3B70101000053
HMLAN1_RSSI -84
HMLAN1_TIME 2013-04-18 18:50:22
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 8
NAME BUR_SD1
NR 28
NTFY_TRIGGERTIME 2013-04-18 18:50:22
STATE off
TYPE CUL_HM
lastMsg No:04 - t:02 s:1A33B1 d:7DE3B7 0101000053
protLastRcv 2013-04-18 18:50:21
protSnd 4 last_at:2013-04-18 18:50:21
protState CMDs_done
rssi_HMLAN1 avg:-84 min:-85 max:-83 lst:-83 cnt:2
rssi_at_HMLAN1 avg:-50.5 min:-87 max:-29 lst:-84 cnt:8
Readings:
2013-04-18 18:50:21 CommandAccepted yes
2013-04-18 18:40:36 PairedTo 0x7DE3B7
2013-04-18 18:40:36 R-intKeyVisib invisib
2013-04-18 18:40:36 R-pairCentral 0x7DE3B7
2013-04-18 18:40:36 RegL_00: 02:01 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:7D 0B:E3 0C:B7 00:00
2013-04-18 18:50:22 deviceMsg off (to HMLAN1)
2013-04-18 18:50:22 level 0 %
2013-01-22 23:49:08 noReceiver src:1A33B1 (A010) 030000
2013-04-18 18:48:34 powerOn -
2013-04-18 18:50:22 state off
Helper:
mId 0011
peerIDsRaw ,00000000
rxType 1
Respwait:
Role:
chn 1
dev 1
Rssi:
Hmlan1:
avg -84
cnt 2
lst -83
max -83
min -85
At_hmlan1:
avg -50.5
cnt 8
lst -84
max -29
min -87
Shadowreg:
Attributes:
expert 2_full
firmware 1.9
fp_03_EG 494,885,0,
fp_04_UG 494,885,0,
fp_99_Bedienfeld 178,1172,0,
group Steckdosen
model HM-LC-SW1-PL
peerIDs 00000000,
room 00_Buero
serialNr JEQ0036741
subType switch
webCmd toggle:on:off:statusRequest
Schlechtfall (remote mit virt. Dev. gepeert)2013.04.18 19:08:39.975 1: HMLAN/RAW: /E123973,0000,51BBF3AB,FF,FF9D,2DA44012397399999882B9
2013.04.18 19:08:39.976 1: HMLAN_Parse: HMLAN1 R:E123973 stat:0000 t:51BBF3AB d:FF r:FF9D m:2D A440 123973 999998 82B9
2013.04.18 19:08:39.993 1: RCV L:0B N:2D F:A4 CMD:40 SRC:remoteD1 DST:virtHM 82B9 (REMOTE BUTTON:2 LONG:0 LOWBAT:1 COUNTER:0xB9) (,CFG,BIDI,RPTEN)
2013.04.18 19:08:40.080 1: HMLAN_Send: HMLAN1 S:S1E1E932A stat: 00 t:00000000 d:01 r:1E1E932A m:2D 8002 999998 123973 01010000
2013.04.18 19:08:40.084 1: SND L:0D N:2D F:80 CMD:02 SRC:virtHM DST:remoteD1 01010000 (ACK_STATUS CHANNEL:0x01 STATUS:0x00 UP:0 DOWN:0 LOWBAT:0) (,RPTEN)
2013.04.18 19:08:40.390 1: HMLAN/RAW: /R1E1E932A,0002,00000000,FF,7FFF,2D800299999812397301010000
2013.04.18 19:08:40.391 1: HMLAN_Parse: HMLAN1 R:R1E1E932A stat:0002 t:00000000 d:FF r:7FFF m:2D 8002 999998 123973 01010000
2013.04.18 19:08:40.392 1: HMLAN_Parse: HMLAN1 discard
2013.04.18 19:08:45.244 1: HMLAN_Send: HMLAN1 S:S1E1EA779 stat: 00 t:00000000 d:01 r:1E1EA779 m:2E A011 7DE3B7 1A33B1 0201C80000
2013.04.18 19:08:45.247 1: SND L:0E N:2E F:A0 CMD:11 SRC:7DE3B7 DST:BUR_SD1 0201C80000 (SET CHANNEL:0x01 VALUE:0xC8 RAMPTIME:2) (,BIDI,RPTEN)
# -> Befehl zum anschalten (C8)
2013.04.18 19:08:45.401 1: HMLAN/RAW: /R1E1EA779,0001,51BC08E3,FF,FFA5,2E80021A33B17DE3B7010100005B
2013.04.18 19:08:45.402 1: HMLAN_Parse: HMLAN1 R:R1E1EA779 stat:0001 t:51BC08E3 d:FF r:FFA5 m:2E 8002 1A33B1 7DE3B7 010100005B
2013.04.18 19:08:45.420 1: RCV L:0E N:2E F:80 CMD:02 SRC:BUR_SD1 DST:7DE3B7 010100005B (ACK_STATUS CHANNEL:0x01 STATUS:0x00 UP:0 DOWN:0 LOWBAT:0 RSSI:-91) (,RPTEN)
# -> ACK mit Status off (00) !!!
2013.04.18 19:08:48.280 1: HMLAN_Send: HMLAN1 S:S1E1EB356 stat: 00 t:00000000 d:01 r:1E1EB356 m:2F A011 7DE3B7 1A33B1 0201000000
2013.04.18 19:08:48.284 1: SND L:0E N:2F F:A0 CMD:11 SRC:7DE3B7 DST:BUR_SD1 0201000000 (SET CHANNEL:0x01 VALUE:0x00 RAMPTIME:2) (,BIDI,RPTEN)
2013.04.18 19:08:48.438 1: HMLAN/RAW: /R1E1EB356,0001,51BC14C0,FF,FFA5,2F80021A33B17DE3B7010100005C
2013.04.18 19:08:48.439 1: HMLAN_Parse: HMLAN1 R:R1E1EB356 stat:0001 t:51BC14C0 d:FF r:FFA5 m:2F 8002 1A33B1 7DE3B7 010100005C
2013.04.18 19:08:48.456 1: RCV L:0E N:2F F:80 CMD:02 SRC:BUR_SD1 DST:7DE3B7 010100005C (ACK_STATUS CHANNEL:0x01 STATUS:0x00 UP:0 DOWN:0 LOWBAT:0 RSSI:-92) (,RPTEN)
Gutfall (peering aufgehoben)2013.04.18 19:17:16.058 1: HMLAN/RAW: /E123973,0000,51C3D3E5,FF,FF9F,34844012397300000082BC
2013.04.18 19:17:16.060 1: HMLAN_Parse: HMLAN1 R:E123973 stat:0000 t:51C3D3E5 d:FF r:FF9F m:34 8440 123973 000000 82BC
2013.04.18 19:17:16.076 1: RCV L:0B N:34 F:84 CMD:40 SRC:remoteD1 DST:broadcast 82BC (REMOTE BUTTON:2 LONG:0 LOWBAT:1 COUNTER:0xBC) (,CFG,RPTEN)
2013.04.18 19:17:16.341 1: HMLAN_Send: HMLAN1 I:K
2013.04.18 19:17:16.345 1: HMLAN/RAW: /HHM-LAN-IF,03C1,IEQ0245375,173F3A,7DE3B7,51C3D509,0005
2013.04.18 19:17:16.346 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245375 d:173F3A O:7DE3B7 m:51C3D509 IDcnt:0005
2013.04.18 19:17:21.242 1: HMLAN_Send: HMLAN1 S:S1E268717 stat: 00 t:00000000 d:01 r:1E268717 m:89 A011 7DE3B7 1A33B1 0201C80000
2013.04.18 19:17:21.245 1: SND L:0E N:89 F:A0 CMD:11 SRC:7DE3B7 DST:BUR_SD1 0201C80000 (SET CHANNEL:0x01 VALUE:0xC8 RAMPTIME:2) (,BIDI,RPTEN)
2013.04.18 19:17:21.399 1: HMLAN/RAW: /R1E268717,0001,51C3E8C7,FF,FFAD,8980021A33B17DE3B70101C80058
2013.04.18 19:17:21.400 1: HMLAN_Parse: HMLAN1 R:R1E268717 stat:0001 t:51C3E8C7 d:FF r:FFAD m:89 8002 1A33B1 7DE3B7 0101C80058
2013.04.18 19:17:21.417 1: RCV L:0E N:89 F:80 CMD:02 SRC:BUR_SD1 DST:7DE3B7 0101C80058 (ACK_STATUS CHANNEL:0x01 STATUS:0xC8 UP:0 DOWN:0 LOWBAT:0 RSSI:-88) (,RPTEN)
2013.04.18 19:17:24.273 1: HMLAN_Send: HMLAN1 S:S1E2692EE stat: 00 t:00000000 d:01 r:1E2692EE m:8A A011 7DE3B7 1A33B1 0201000000
2013.04.18 19:17:24.276 1: SND L:0E N:8A F:A0 CMD:11 SRC:7DE3B7 DST:BUR_SD1 0201000000 (SET CHANNEL:0x01 VALUE:0x00 RAMPTIME:2) (,BIDI,RPTEN)
2013.04.18 19:17:24.430 1: HMLAN/RAW: /R1E2692EE,0001,51C3F49F,FF,FFA2,8A80021A33B17DE3B70101000057
2013.04.18 19:17:24.431 1: HMLAN_Parse: HMLAN1 R:R1E2692EE stat:0001 t:51C3F49F d:FF r:FFA2 m:8A 8002 1A33B1 7DE3B7 0101000057
2013.04.18 19:17:24.449 1: RCV L:0E N:8A F:80 CMD:02 SRC:BUR_SD1 DST:7DE3B7 0101000057 (ACK_STATUS CHANNEL:0x01 STATUS:0x00 UP:0 DOWN:0 LOWBAT:0 RSSI:-87) (,RPTEN)
Hi Tobi,
ist seltsam, da die Messages identisch sind.
Der 123973 hat mir dem 1A33B1 eigentlich nichts zu tun. Zeitlich ist es auch entkoppelt. Das Kommando ist auch eindeutig.
Da faellt mir eine Reihe von tests ein:
define NOT_tmp1 notify remote1_2.Short.* define tmp1 at +00:00:05 set BUR_SD1 on;define tmp3 at +00:00:10 set BUR_SD1 on;define tmp2 at +00:00:15 set BUR_SD1 off
klappt es beim 2. Setzen?
Ausserdem: kannst du die HMId von 999998 aendern auf 111222? Nur ein test ob das eine besondere Bedeutung hat bei HM. Also jedenfalls etwas kleiner 7fffff.
Und noch einer
define NOT_tmp1 notify remote1_2.Short.* define tmp1 at +00:00:05 set BUR_SD1 raw ++A0117DE3B71A33B10201C8;define tmp2 at +00:00:15 set BUR_SD1 off
Mein tip stehe aktuell auf der HMID.
Gruss
Martin
Hi Martin,
ist wirklich sehr merkwürdig.
Das Ändern der HM-ID des virt. Devices hat nichts gebracht.
Auch nicht das senden der Rohdaten.
Was geht, ist das Kommando zweimal zu senden. Das erste "on" wird nicht umgesetzt, das zweite klappt dann. Auch das off. Als Workaround für mich käme dann in Frage, einfach stumpf 2xon hintereinander zu senden. Trotzdem sehr komisch. Sieht irgendwie so aus als ob nach dem Signal der FB der HMLAN das jeweils erste Kommando nicht korrekt ausführt ?!?
Was ich noch nicht probiert habe ist ein Reset des HMLAN, vielleicht hat der sich irgendwie verschluckt. Probiere ich gleich mal.
Gruß
Tobi
Hi Tobi,
werde mal ein setup zusammenbauen. Ist schon kritisch wenn nach der virtual Aktion eine Nachricht verloren gehen wuerde.
Ein Test waere :
set BUR_SD1 raw ++800299999812397301010000
set BUR_SD1 raw ++A0117DE3B71A33B10201C80000
klappt das? Kannst du es aufzeichnen?
Gruss
Martin
Hi Martin,
hab es gerade ausprobiert, mit den Rohdaten schaltet der Aktor.
Allerdings habe ich 999998 in 111222 geändert, der virteuelle Aktor hat ja jetzt die neue ID.
Gruß Tobi
2013.04.19 13:39:32.821 1: HMLAN_Send: HMLAN1 S:S22179D93 stat: 00 t:00000000 d:01 r:22179D93 m:59 8002 111222 123973 01010000
2013.04.19 13:39:32.825 1: SND L:0D N:59 F:80 CMD:02 SRC:virtHM DST:remoteD1 01010000 (ACK_STATUS CHANNEL:0x01 STATUS:0x00 UP:0 DOWN:0 LOWBAT:0) (,RPTEN)
2013.04.19 13:39:32.871 1: HMLAN/RAW: /R22179D93,0002,00000000,FF,7FFF,59800211122212397301010000
2013.04.19 13:39:32.872 1: HMLAN_Parse: HMLAN1 R:R22179D93 stat:0002 t:00000000 d:FF r:7FFF m:59 8002 111222 123973 01010000
2013.04.19 13:39:32.873 1: HMLAN_Parse: HMLAN1 discard
2013.04.19 13:39:36.802 1: HMLAN_Send: HMLAN1 I:K
2013.04.19 13:39:36.806 1: HMLAN/RAW: /HHM-LAN-IF,03C1,IEQ0245375,173F3A,7DE3B7,00242A0A,0005
2013.04.19 13:39:36.807 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0245375 d:173F3A O:7DE3B7 m:00242A0A IDcnt:0005
2013.04.19 13:39:55.120 1: HMLAN_Send: HMLAN1 S:S2217F4AD stat: 00 t:00000000 d:01 r:2217F4AD m:5A A011 7DE3B7 1A33B1 0201C80000
2013.04.19 13:39:55.123 1: SND L:0E N:5A F:A0 CMD:11 SRC:7DE3B7 DST:BUR_SD1 0201C80000 (SET CHANNEL:0x01 VALUE:0xC8 RAMPTIME:2) (,BIDI,RPTEN)
2013.04.19 13:39:55.325 1: HMLAN/RAW: /R2217F4AD,0001,00247234,FF,FFAF,5A80021A33B17DE3B70101C80053
2013.04.19 13:39:55.326 1: HMLAN_Parse: HMLAN1 R:R2217F4AD stat:0001 t:00247234 d:FF r:FFAF m:5A 8002 1A33B1 7DE3B7 0101C80053
2013.04.19 13:39:55.344 1: RCV L:0E N:5A F:80 CMD:02 SRC:BUR_SD1 DST:7DE3B7 0101C80053 (ACK_STATUS CHANNEL:0x01 STATUS:0xC8 UP:0 DOWN:0 LOWBAT:0 RSSI:-83) (,RPTEN)
Hallo Martin,
hattest Du mal Gelegenheit das Problem nachzustellen bzw. hast Du neue Erkenntnisse?
Ich habe gesehen dass ähnlich Probleme in anderen Threads auch diskutiert werden, vermute dort aber andere Ursachen und habe diese nicht so im Detail gelesen um ehrlich zu sein. Daher die Nachfrage hier...
Danke für Deine Unterstützung und Gruß
Tobi
Hi Tobi,
leider hatte ich noch keine Idee. Das nichtschalten im anderen Fall hat hiermit nichts zu tun, da liegst du richtig.
Das Problem bei dir besteht also immer noch, bin etwas ratlos...
kannst du einmal alle Register auslesen?
Setze einmal intKeyVisib auf visible und mache ein getConfig.
Attribut expert auf 2 und dann ein list auf das Device und den channel
Moeglich waere, dass der Aktor eine einschaltverzögerung programmiert hat.... vielleicht.
Gruss
Martin
Hi Martin,
die Register habe ich wie von Dir beschrieben ausgelesen - siehe unten. Die BUR_SD1 ist ein Zwischenstecker mit nur einem Kanal, daher ist er bei mir nur als Device angelegt. Nach Einschalteverzögerung sieht das aber denke ich nicht aus...
Ich würde fast weniger vermuten, dass es an den Aktoren liegt. Das Problem tritt mit dem Zwischenstecker und auch mit einem anderen Aktor (HM-LC-SW4-PCB) auf. Ist vll eher das Problem beim HMLAN - möglich, dass der irgend einen "Müll" sendet oder intern macht? Weisst Du zufällig auswendig ob und wie man auf dem HMLAN ein FW Update machen kann?
Gruß und danke schon mal
Tobi
Internals:
CFGFN /opt/fhem/fhem_hm.cfg
CHANGED
DEF 1A33B1
EVENTS 49
HMLAN1_MSGCNT 57
HMLAN1_RAWMSG E1A33B1,0000,54040640,FF,FFAE,8CA0101A33B17DE3B7030000
HMLAN1_RSSI -82
HMLAN1_TIME 2013-05-05 20:29:21
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 57
NAME BUR_SD1
NR 28
NTFY_TRIGGERTIME 2013-05-05 20:29:21
STATE off
TYPE CUL_HM
lastMsg No:8C - t:10 s:1A33B1 d:7DE3B7 030000
protCmdDel 1
protLastRcv 2013-05-05 20:29:21
protResnd 8 last_at:2013-05-01 16:58:12
protResndFail 3 last_at:2013-05-01 16:58:14
protSnd 47 last_at:2013-05-05 20:29:19
protState CMDs_done
rssi_HMLAN1 avg:-87.13 min:-93 max:-82 lst:-84 cnt:29
rssi_at_HMLAN1 avg:-85.98 min:-99 max:-81 lst:-82 cnt:57
Readings:
2013-05-05 20:28:50 CommandAccepted yes
2013-05-05 20:29:19 PairedTo 0x7DE3B7
2013-05-05 20:29:19 R-intKeyVisib visib
2013-05-05 20:28:49 R-pairCentral 0x7DE3B7
2013-05-05 20:29:21 R-self01-lgActionType jmpToTarget
2013-05-05 20:29:21 R-self01-lgCtDlyOff geLo
2013-05-05 20:29:21 R-self01-lgCtDlyOn geLo
2013-05-05 20:29:21 R-self01-lgCtOff geLo
2013-05-05 20:29:21 R-self01-lgCtOn geLo
2013-05-05 20:29:21 R-self01-lgCtValHi 100
2013-05-05 20:29:21 R-self01-lgCtValLo 50
2013-05-05 20:29:21 R-self01-lgMultiExec on
2013-05-05 20:29:21 R-self01-lgOffDly 0 s
2013-05-05 20:29:21 R-self01-lgOffTime 111600 s
2013-05-05 20:29:21 R-self01-lgOffTimeMode absolut
2013-05-05 20:29:21 R-self01-lgOnDly 0 s
2013-05-05 20:29:21 R-self01-lgOnTime 111600 s
2013-05-05 20:29:21 R-self01-lgOnTimeMode absolut
2013-05-05 20:29:21 R-self01-lgSwJtDlyOff off
2013-05-05 20:29:21 R-self01-lgSwJtDlyOn on
2013-05-05 20:29:21 R-self01-lgSwJtOff dlyOn
2013-05-05 20:29:21 R-self01-lgSwJtOn dlyOff
2013-05-05 20:29:21 R-self01-shActionType jmpToTarget
2013-05-05 20:29:21 R-self01-shCtDlyOff geLo
2013-05-05 20:29:21 R-self01-shCtDlyOn geLo
2013-05-05 20:29:21 R-self01-shCtOff geLo
2013-05-05 20:29:21 R-self01-shCtOn geLo
2013-05-05 20:29:21 R-self01-shCtValHi 100
2013-05-05 20:29:21 R-self01-shCtValLo 50
2013-05-05 20:29:21 R-self01-shOffDly 0 s
2013-05-05 20:29:21 R-self01-shOffTime 111600 s
2013-05-05 20:29:21 R-self01-shOffTimeMode absolut
2013-05-05 20:29:21 R-self01-shOnDly 0 s
2013-05-05 20:29:21 R-self01-shOnTime 111600 s
2013-05-05 20:29:21 R-self01-shOnTimeMode absolut
2013-05-05 20:29:21 R-self01-shSwJtDlyOff off
2013-05-05 20:29:21 R-self01-shSwJtDlyOn on
2013-05-05 20:29:21 R-self01-shSwJtOff dlyOn
2013-05-05 20:29:21 R-self01-shSwJtOn dlyOff
2013-05-05 20:29:19 RegL_00: 02:81 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:7D 0B:E3 0C:B7 00:00
2013-05-05 20:29:21 RegL_03:self01 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:14 8C:63 00:00
2013-05-04 17:10:16 deviceMsg off (to HMLAN1)
2013-05-04 17:10:16 level 0 %
2013-01-22 23:49:08 noReceiver src:1A33B1 (A010) 030000
2013-05-05 20:29:19 peerList self01,
2013-04-23 07:54:51 powerOn -
2013-05-04 17:10:16 state off
Helper:
mId 0011
peerIDsRaw ,1A33B101,00000000
rxType 1
Respwait:
Role:
chn 1
dev 1
Rpt:
IO HMLAN1
msg A0C8CA0101A33B17DE3B7030000::-82:HMLAN1
ts 1367778561.07058
ack:
HASH(0x2e1940)
8C80027DE3B71A33B100
Rssi:
Hmlan1:
avg -87.1379310344828
cnt 29
lst -84
max -82
min -93
At_hmlan1:
avg -85.9824561403509
cnt 57
lst -82
max -81
min -99
Shadowreg:
Attributes:
expert 2_full
firmware 1.9
fp_03_EG 494,885,0,
fp_04_UG 494,885,0,
fp_99_Bedienfeld 178,1172,0,
group Steckdosen
model HM-LC-SW1-PL
peerIDs 00000000,1A33B101,
room 00_Buero
serialNr JEQ0036741
subType switch
webCmd toggle:on:off:statusRequest
Hi Tobi,
du kannst schon recht haben.
Einen FW update kann man mit der HM config SW machen, die auf windows laeuft. Es wird aber nur auf die SW auf der CD upgedated, wenn ich es richtig verstehe.
Dass HMLAN die messages in dieser From veraendert waere seltsam. Keine schicken verstehe ich, oder einmal ein ack... aber den Nachrichteninhalt zu aendern ist nicht ok.
Vielleicht kriegst du einen update hin..
Gruss
Martin