Hey.
Ich habe leider des öfteren das Problem, dass Homematic Befehle von einzelnen Aktoren nicht erhalten werden. Die jeweiligen Aktoren melden dann ein "Missing ACK". Sogar bei Befehlen die Zeitgleich ausgeführt werden - und von anderen Aktoren erhalten werden.
FHEM ist aktuell.
Ich habe bereits das Loglevel erhöht (wie in einem anderen Thread empfohlen), versteh aber leider nur Bahnhof. Vielleicht kann jemand etwas damit anfangen? Über Hilfe wäre ich sehr dankbar.
Ps. Die letzte Meldung wird ununterbrochen im Minutentakt angezeigt, seitdem ich das Loglevel (vor zwei Tagen) erhört habe. Kann ja auch nichts gutes bedeuten ?!
2015.11.11 08:30:00.002 0: HMLAN_Send: HM_Control S:+3DAF97,00,00,00
2015.11.11 08:30:00.002 0: HMLAN_Send: HM_Control S:SF5738612 stat: 00 t:00000000 d:01 r:F5738612 m:03 A011 424242 3DAF97 0201C80000
2015.11.11 08:30:00.279 0: HMLAN_Parse: HM_Control R:RF5738612 stat:0001 t:2A49A3FE d:FF r:FFC8 m:03 8002 3DAF97 424242 0101001038
2015.11.11 08:30:00.281 0: HMLAN_Send: HM_Control S:+3D989B,00,00,00
2015.11.11 08:30:00.281 0: HMLAN_Send: HM_Control S:SF5738728 stat: 00 t:00000000 d:01 r:F5738728 m:03 A011 424242 3D989B 0201C80000
2015.11.11 08:30:00.535 0: HMLAN_Parse: HM_Control R:RF5738728 stat:0001 t:2A49A51D d:FF r:FFC5 m:03 8002 3D989B 424242 0101001052
2015.11.11 08:30:00.536 0: HMLAN_Send: HM_Control S:+41DDE2,00,00,00
2015.11.11 08:30:00.536 0: HMLAN_Send: HM_Control S:SF5738828 stat: 00 t:00000000 d:01 r:F5738828 m:03 A011 424242 41DDE2 0201C80000
2015.11.11 08:30:01.239 0: HMLAN_Parse: HM_Control R:RF5738828 stat:0008 t:00000000 d:FF r:7FFF m:03 A011 424242 41DDE2 0201C80000
2015.11.11 08:30:01.239 0: HMLAN_Parse: HM_Control no ACK from 41DDE2
2015.11.11 08:30:01.339 0: HMLAN_Send: HM_Control S:+3B689C,00,00,00
2015.11.11 08:30:01.339 0: HMLAN_Send: HM_Control S:SF5738B4B stat: 00 t:00000000 d:01 r:F5738B4B m:03 A011 424242 3B689C 0201C80000
2015.11.11 08:30:01.591 0: HMLAN_Parse: HM_Control R:RF5738B4B stat:0001 t:2A49A93D d:FF r:FFC3 m:03 8002 3B689C 424242 010100103D
2015.11.11 08:30:02.036 0: HMLAN_Send: HM_Control S:SF5738E03 stat: 00 t:00000000 d:01 r:F5738E03 m:03 A011 424242 41DDE2 0201C80000
2015.11.11 08:30:02.036 0: HMLAN_Send: HM_Control I:K
2015.11.11 08:30:02.135 0: HMLAN_Parse: HM_Control V:03C4 sNo:MEQ0232277 d:372F40 O:424242 t:2A49AB44 IDcnt:0005 L:0 %
2015.11.11 08:30:02.647 0: HMLAN_Parse: HM_Control R:RF5738E03 stat:0008 t:00000000 d:FF r:7FFF m:03 A011 424242 41DDE2 0201C80000
2015.11.11 08:30:02.647 0: HMLAN_Parse: HM_Control no ACK from 41DDE2
2015.11.11 08:30:07.243 0: HMLAN_Send: HM_Control S:SF573A25B stat: 00 t:00000000 d:01 r:F573A25B m:03 A011 424242 41DDE2 0201C80000
2015.11.11 08:30:07.863 0: HMLAN_Parse: HM_Control R:RF573A25B stat:0008 t:00000000 d:FF r:7FFF m:03 A011 424242 41DDE2 0201C80000
2015.11.11 08:30:07.863 0: HMLAN_Parse: HM_Control no ACK from 41DDE2
2015.11.11 08:30:12.406 0: HMLAN_Send: HM_Control S:SF573B686 stat: 00 t:00000000 d:01 r:F573B686 m:03 A011 424242 41DDE2 0201C80000
2015.11.11 08:30:13.047 0: HMLAN_Parse: HM_Control R:RF573B686 stat:0008 t:00000000 d:FF r:7FFF m:03 A011 424242 41DDE2 0201C80000
2015.11.11 08:30:13.047 0: HMLAN_Parse: HM_Control no ACK from 41DDE2
2015.11.11 08:30:26.455 0: HMLAN_Parse: HM_Control R:E3DAF97 stat:0000 t:2A4A0A44 d:FF r:FFC5 m:04 A410 3DAF97 424242 0601C800
2015.11.11 08:30:27.037 0: HMLAN_Send: HM_Control I:K
2015.11.11 08:30:27.095 0: HMLAN_Parse: HM_Control V:03C4 sNo:MEQ0232277 d:372F40 O:424242 t:2A4A0CC3 IDcnt:0005 L:0 %
2015.11.11 08:30:36.919 0: HMLAN_Parse: HM_Control R:E3B689C stat:0000 t:2A4A3335 d:FF r:FFC5 m:04 A410 3B689C 424242 0601C800
2015.11.11 08:30:52.051 0: HMLAN_Send: HM_Control I:K
2015.11.11 08:30:52.087 0: HMLAN_Parse: HM_Control V:03C4 sNo:MEQ0232277 d:372F40 O:424242 t:2A4A6E63 IDcnt:0005 L:0 %
2015.11.11 08:30:57.975 0: HMLAN_Parse: HM_Control R:E3D989B stat:0000 t:2A4A8563 d:FF r:FFC6 m:04 A410 3D989B 424242 0601C800
2015.11.11 08:31:17.061 0: HMLAN_Send: HM_Control I:K
2015.11.11 08:31:17.111 0: HMLAN_Parse: HM_Control V:03C4 sNo:MEQ0232277 d:372F40 O:424242 t:2A4AD022 IDcnt:0005 L:0 %
2015.11.11 08:31:42.080 0: HMLAN_Send: HM_Control I:K
2015.11.11 08:31:42.135 0: HMLAN_Parse: HM_Control V:03C4 sNo:MEQ0232277 d:372F40 O:424242 t:2A4B31E2 IDcnt:0005 L:0 %
2015.11.11 08:32:07.080 0: HMLAN_Send: HM_Control I:K
2015.11.11 08:32:07.127 0: HMLAN_Parse: HM_Control V:03C4 sNo:MEQ0232277 d:372F40 O:424242 t:2A4B9381 IDcnt:0005 L:0 %
2015.11.11 08:32:32.081 0: HMLAN_Send: HM_Control I:K
2015.11.11 08:32:32.119 0: HMLAN_Parse: HM_Control V:03C4 sNo:MEQ0232277 d:372F40 O:424242 t:2A4BF520 IDcnt:0005 L:0 %
2015.11.11 08:32:57.105 0: HMLAN_Send: HM_Control I:K
2015.11.11 08:32:57.143 0: HMLAN_Parse: HM_Control V:03C4 sNo:MEQ0232277 d:372F40 O:424242 t:2A4C56E0 IDcnt:0005 L:0 %
2015.11.11 08:33:22.110 0: HMLAN_Send: HM_Control I:K
2015.11.11 08:33:22.167 0: HMLAN_Parse: HM_Control V:03C4 sNo:MEQ0232277 d:372F40 O:424242 t:2A4CB89F IDcnt:0005 L:0 %
2015.11.11 08:33:47.134 0: HMLAN_Send: HM_Control I:K
2015.11.11 08:33:47.191 0: HMLAN_Parse: HM_Control V:03C4 sNo:MEQ0232277 d:372F40 O:424242 t:2A4D1A5F IDcnt:0005 L:0 %
2015.11.11 08:34:12.135 0: HMLAN_Send: HM_Control I:K
2015.11.11 08:34:12.183 0: HMLAN_Parse: HM_Control V:03C4 sNo:MEQ0232277 d:372F40 O:424242 t:2A4D7BFF IDcnt:0005 L:0 %
2015.11.11 08:34:37.148 0: HMLAN_Send: HM_Control I:K
2015.11.11 08:34:37.207 0: HMLAN_Parse: HM_Control V:03C4 sNo:MEQ0232277 d:372F40 O:424242 t:2A4DDDBE IDcnt:0005 L:0 %
2015.11.11 08:35:02.151 0: HMLAN_Send: HM_Control I:K
2015.11.11 08:35:02.199 0: HMLAN_Parse: HM_Control V:03C4 sNo:MEQ0232277 d:372F40 O:424242 t:2A4E3F5D IDcnt:0005 L:0 %
2015.11.11 08:35:27.154 0: HMLAN_Send: HM_Control I:K
2015.11.11 08:35:27.191 0: HMLAN_Parse: HM_Control V:03C4 sNo:MEQ0232277 d:372F40 O:424242 t:2A4EA0FD IDcnt:0005 L:0 %
2015.11.11 08:35:52.178 0: HMLAN_Send: HM_Control I:K
ZitatPs. Die letzte Meldung wird ununterbrochen im Minutentakt angezeigt, seitdem ich das Loglevel (vor zwei Tagen) erhört habe. Kann ja auch nichts gutes bedeuten ?!
du meinst das keepalive von fhem an den hmlan? das kommt default alle 25 sek.
device 41DDE2 meldet sich einfach nicht. auch mit 3-facher wiederholung nicht.
poste mal ein list von diesem device. ist der funk und das pairing ok?
So etwas hatte ich vor kurzem auch mit Rolladen-Aktoren. Lag an der Reichweite. Merkwürdigerweise trat das Problem bei Aktoren auf, die näher zum HMLAN waren als andere, die dieses Problem nicht hatten.
Ich habe HMLAN in einen anderen Raum verlegt, seitdem keine Probleme mehr
Vielen Dank
Zitat von: frank am 11 November 2015, 09:31:32
device 41DDE2 meldet sich einfach nicht. auch mit 3-facher wiederholung nicht.
poste mal ein list von diesem device. ist der funk und das pairing ok?
Ich denke eigentlich nicht, dass es an dem Aktor liegt, da mindestens ein anderer auch, sporadisch, das selbe Problem hat.
2015-11-11_08:30:00 WC_Rollladen set_on
2015-11-11_08:30:17 WC_Rollladen ResndFail
2015-11-11_08:30:17 WC_Rollladen MISSING ACK
2015-11-11_08:55:11 WC_Rollladen level: set_100
2015-11-11_08:55:11 WC_Rollladen set_100
Zitat von: pula am 11 November 2015, 09:46:02
So etwas hatte ich vor kurzem auch mit Rolladen-Aktoren. Lag an der Reichweite. Merkwürdigerweise trat das Problem bei Aktoren auf, die näher zum HMLAN waren als andere, die dieses Problem nicht hatten.
Ich habe HMLAN in einen anderen Raum verlegt, seitdem keine Probleme mehr
Hm.... Das is ja auch mal abenteuerlich^^ Benutze nur leider einen HM-Stick. Dann werde ich wohl mal ein HMLAN anschaffen und gucken ob es besser wird.. Oder tut sich da von der Antenne nicht viel?
"Näher" ist relativ ;) kommt immer darauf an welche Wände dazwischen liegen und welche Störer in der Nähe sind
Beim HMLAN kann man einen verbesserte Antenne installieren, ist allerdings etwas Bastelarbeit und Löten ... aber schau dir doch zuerst mal die RSSI Werte an ... in den Internals des Devices oder als Übersicht in HMInfo und dort "get <name> rssi"
Zitat von: frank am 11 November 2015, 09:31:32
poste mal ein list von diesem device.
"list name_vom_device" in die befehlszeile von fhem.
Zitat von: frank am 11 November 2015, 12:18:47
"list name_vom_device" in die befehlszeile von fhem.
Internals:
DEF 41DDE2
HM_Control_MSGCNT 6
HM_Control_RAWMSG E41DDE2,0000,2A6101DD,FF,FFB8,06A41041DDE24242420601C800
HM_Control_RSSI -72
HM_Control_TIME 2015-11-11 08:55:31
IODev HM_Control
LASTInputDev HM_Control
MSGCNT 6
NAME WC_Rollladen
NR 29
NTFY_ORDER 50-WC_Rollladen
STATE on
TYPE CUL_HM
lastMsg No:06 - t:10 s:41DDE2 d:424242 0601C800
protCmdDel 1
protLastRcv 2015-11-11 08:55:31
protResnd 3 last_at:2015-11-11 08:30:12
protResndFail 1 last_at:2015-11-11 08:30:17
protSnd 7 last_at:2015-11-11 08:55:31
protState CMDs_done
rssi_HM_Control min:-82 avg:-76.33 lst:-71 cnt:3 max:-71
rssi_at_HM_Control min:-82 cnt:6 max:-69 avg:-74.83 lst:-72
Readings:
2015-11-11 08:55:11 CommandAccepted yes
2015-10-31 22:29:27 D-firmware 2.8
2015-10-31 22:29:27 D-serialNr MEQ0737693
2015-10-31 22:29:43 PairedTo 0x424242
2015-10-31 22:29:44 R-driveDown 16.7 s
2015-10-31 22:29:44 R-driveTurn 0.5 s
2015-10-31 22:29:44 R-driveUp 16.7 s
2015-10-31 22:29:43 R-pairCentral 0x424242
2015-10-31 22:29:44 R-sign off
2015-10-31 22:29:43 RegL_00: 02:01 0A:42 0B:42 0C:42 15:FF 18:00 00:00
2015-10-31 22:29:44 RegL_01: 08:00 09:00 0A:00 0B:00 0C:A7 0D:00 0E:A7 0F:05 10:00 30:06 57:24 56:00 00:00
2015-11-11 08:55:31 deviceMsg on (to HM_Control)
2015-11-11 08:55:31 level 100
2015-11-11 08:55:31 motor stop:on
2015-11-11 08:55:31 pct 100
2015-11-11 08:55:31 recentStateType info
2015-11-11 08:55:31 state on
2015-11-11 08:55:31 timedOn off
Helper:
HM_CMDNR 6
cSnd 1142424241DDE20201C8,0142424241DDE2010E
dlvlCmd ++A01142424241DDE20201C8
mId 006A
rxType 1
Dir:
cur stop
rct up
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +41DDE2,00,00,00
nextSend 1447228531.77317
prefIO
rxt 0
vccu
p:
41DDE2
00
00
00
Mrssi:
mNo 06
Io:
HM_Control -70
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
prs 1
Rpt:
IO HM_Control
flg A
ts 1447228531.67407
ack:
HASH(0x18722f0)
06800242424241DDE200
Rssi:
Hm_control:
avg -76.3333333333333
cnt 3
lst -71
max -71
min -82
At_hm_control:
avg -74.8333333333333
cnt 6
lst -72
max -69
min -82
Attributes:
IODev HM_Control
alias WC_Rollladen
autoReadReg 4_reqStatus
devStateIcon on:fts_shutter_10@green off:fts_shutter_100@black 9\d.*:fts_shutter_10 8\d.*:fts_shutter_20 7\d.*:fts_shutter_30 6\d.*:fts_shutter_40 5\d.*:fts_shutter_50 4\d.*:fts_shutter_60 3\d.*:fts_shutter_70 2\d.*:fts_shutter_80 1\d.*:fts_shutter_90 0\d.*:fts_shutter_100
expert 2_full
firmware 2.8
group Rollläden
icon fts_shutter_updown
model HM-LC-Bl1PBU-FM
peerIDs 00000000,
room GästeWC
serialNr MEQ0737693
subType blindActuator
webCmd on:off:pct
Zitat von: Nobby1805 am 11 November 2015, 12:16:36
... in den Internals des Devices oder als Übersicht in HMInfo und dort "get <name> rssi"
Könntest du dass bitte noch einmal genauer erläutern ? Bin einfach noch zu frisch in FHEM:
"get WC_Rollladen rssi"
-> Unknown argument rssi, choose one of cmdList param reg regList regVal saveConfig
normalerweise sollte es mit den rssi schon funktionieren. das pairing ist wohl auch ok.
spendiere deinem hmusb doch mal eine usb verlängerung, damit er von störfeldern weiter weg kommt und eine bessere position bekommt.
Hallo,
die RSSI-Werte (https://de.wikipedia.org/wiki/Received_Signal_Strength_Indication) geben Auskunft zur Signalstärke des Funksignals.
Zitat von: snickers2k am 11 November 2015, 13:23:44
rssi_HM_Control min:-82 avg:-76.33 lst:-71 cnt:3 max:-71
Bei Dir sind die Werte relativ schlecht. Du kannst versuchen, die Position des CUL zu verändern, um den Empfang zu verbessern.
VG
Sven
Meine 3 Cent:
Der RSSI Wert ist zwar grenzwertig, sollte aber eigentlich für einen netzbetriebenen Aktor ausreichen.
Hast du das Problem nur mit dem einen Rollladen? Dann könnte es auch ein Hardwareproblem des Aktors sein.
Ich habe hier einen Rollladenaktor, der geht morgens rauf, abends auf MissingAck. Dann bediene ich ihn von Hand, dann geht er wieder zweimal, dann wieder MissingAck. Der schläft einfach irgendwann ein. Es gab mal so ein Problem in der Firmware, ich habe allerdings die neuste drauf. Jetzt "streichele" ich ihn den ganzen Tag mit at alle 60 Minuten mittels statusRequest. Seitdem ist das Problem weg.
Zitat von: frank am 11 November 2015, 13:34:16
normalerweise sollte es mit den rssi schon funktionieren. das pairing ist wohl auch ok.
spendiere deinem hmusb doch mal eine usb verlängerung, damit er von störfeldern weiter weg kommt und eine bessere position bekommt.
Zitat von: SvenJust am 11 November 2015, 13:39:07
Hallo,
die RSSI-Werte (https://de.wikipedia.org/wiki/Received_Signal_Strength_Indication) geben Auskunft zur Signalstärke des Funksignals.
Bei Dir sind die Werte relativ schlecht. Du kannst versuchen, die Position des CUL zu verändern, um den Empfang zu verbessern.
VG
Sven
Alles klar. Das klingt nach nem Plan. Wird sofort in die Tat umgesetzt.
Ich werd nochmal ne Rückmeldung in ein paar Tagen geben, ob sich was getan hat.
@Deudi; Leider betrifft es mindestens zwei Aktoren... Dein Tip mit dem statusRequest werde ich mir auf jedenfall merken.
Vielen dank euch allen!
Zitat von: Deudi am 11 November 2015, 13:50:15
Ich habe hier einen Rollladenaktor, der geht morgens rauf, abends auf MissingAck. Dann bediene ich ihn von Hand, dann geht er wieder zweimal, dann wieder MissingAck. Der schläft einfach irgendwann ein. Es gab mal so ein Problem in der Firmware, ich habe allerdings die neuste drauf. Jetzt "streichele" ich ihn den ganzen Tag mit at alle 60 Minuten mittels statusRequest. Seitdem ist das Problem weg.
ich habe festgestellt, dass die rssi zb auch abhängig vom zustand der rollos sind.
mein hmlan hängt an einer innenwand ca. 1,5 meter vor einem fenster. wenn ich hier das rollo schliesse, wirkt sich das seltsamerweise negativ auf die rssi aus. ich kann mir das nur mit störenden reflexionen erklären.
das erklärt natürlich nicht, dass ein regelmässiger statusrequest hier abhilfe schafft. hast du mal einen werksreset nach dem update versucht?
Zitat von: frank am 11 November 2015, 14:17:59
das erklärt natürlich nicht, dass ein regelmässiger statusrequest hier abhilfe schafft. hast du mal einen werksreset nach dem update versucht?
Hallo Frank,
bisher noch nicht. Sollte ich mal machen. War bisher zu faul. Melde mich mit dem Ergebnis wieder.
Grüße
Ich habe auch ein ähnliches Problem,
mein "HM-LC-SW4-BA-PCB" ist hinter eine Metallabdeckung und reagiert deshalb manchmal nicht.
statt "on" steht er dann auf "set_on".
Nach einem erneuten Setzen geht es dann.
Ich dachte, ich könnte das mit einem DOIF automatisieren:
define di DOIF ([sw_hm_hz_main] eq "set_on") (set sw_hm_hz_main on)
DOELSEIF ([sw_hm_hz_main] eq "set_off") (set sw_hm_hz_main off)
attribute di wait 120
aber das löst leider immer ein Command aus, auch wenn der Status direkt von "set_on" auf "on" geht.
Zitat von: hanske am 11 November 2015, 14:40:09
Ich habe auch ein ähnliches Problem
erhöhe doch mal attr msgRepeat. vielleicht hilft das schon. im aktor gibt es eventuell auch register zum wiederholen von messages, die du erhöhen könntest.
bei einem fk gibt es dafür zb:
0: transmDevTryMax | 1 to 10 | | max message re-transmit
1: transmitTryMax | 1 to 10 | | max message re-transmit ansonsten würde ich das über watchdog machen, um erst nach einer gewissen zeit zu wiederholen, falls es nicht funktioniert hat. geht aber sicherlich auch mit doif.
set_on sollte immer kommen, auch wenn es kaum sichtbar ist.
das retry sollte in diesen Fall von FHEM kommen.
Die Statusabfrage sollte auch automatisch kommen. was steht in autoReadReg? alles aus? ja dann wäre es eben aus.
Hallo Gemeinde und Fhem- Profis
Ich würde mich hier auch gerne mal anhängen. Die Tipps hier habe ich versucht zu verstehen, aber für mich als Anfänger war noch kein nachvollziehbarer Lösungsansatz dabei.
Hier mein List beim Rauchmelder:
Internals:
CFGFN
DEF 733490
IODev HMLAN1
NAME DachbodenRauchmelder
NR 201
STATE MISSING ACK
TYPE CUL_HM
peerList KinderzimmerRauchmelder,
protCmdDel 3
protResnd 6 last_at:2015-11-11 22:46:01
protResndFail 2 last_at:2015-11-11 22:46:07
protSnd 2 last_at:2015-11-11 22:45:47
protState CMDs_done_Errors:1
Readings:
2015-11-11 22:46:07 state MISSING ACK
Helper:
HM_CMDNR 5
cSnd 0123A3D973349000040000000000,1123A3D97334900400
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +733490,00,00,00
prefIO
rxt 0
vccu
p:
733490
00
00
00
Mrssi:
mNo
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Attributes:
IODev HMLAN1
autoReadReg 4_reqStatus
expert 2_full
peerIDs 2F3ECA01
room 8.1_System,8.9_Rauchmelder
subType smokeDetector
webCmd statusRequest
Den ersten Rauchmelder mit diesem Fehler habe ich getauscht und genau den gleichen
STATE RESPONSE TIMEOUT:RegisterRead oder
MISSING ACK bekommt dieser eine von sieben Rauchmeldern wieder. (Dieser Rauchmelder liegt Testweise zwei Meter neben dem HMLAN-Adapter, was also die rissi Werte als Fehlerquelle ausschliessen sollte) Gibt es einen Zusammenhang mit dem neu Anschluß der HM Strommeßsteckdose die zum Beginn der Probleme angeschlossen wurde.
Das sich auch die Fenster- Türsensoren regelmäßg auf "dead" schalten, wenn die Fenster nicht mindestens ein mal am Tag geöffnet werden ist für einen Alarmsensor auch ein unsinniger Zustand. (Wenn man mal drei Tage weg ist muss ein Nachbar die Fenster und Türen öffnen und schliessen, damit die Sensoren sich nicht schlafen legen)
Sieht hier schon jemand den Fehler oder müsste dafür noch mehr Info "ausgelesen" werden?
Wenn die Begrenzung der Sendezeit das Limit der Sensoren vorgibt müsste man ja auch die unwichtigen Daten des HM Strommeßzwischenstecker auf die wichtigen Werte eingrenzen und alles andere "abschalten".
Ich bin Euch für jeden guten Tipp sehr dankbar.
Schöne Grüße
Danke für den Tipp mit dem msgRepeat.
Ich dachte das wäre nur für die Meldungen vom Device.
Bei dem Status "set_on" weiß ich ja nicht, ob der Befehl überhaupt am Gerät angekommen ist.
Wenn Fhem damit aufgefordert wird, bei fehlendem Acknowledge nochmals zu senden, ist es genau das was ich brauche.
@martinp876
Ich habe das DOIF gerade erst vor kurzem entdeckt und verwende es jetzt gerne für alles was ich vorher mit komplizierten notifys gelöst habe.
Mir scheint aber das es ein Problem gibt, wenn sich der Status innerhalb weniger ms nacheinander ändert.
Dann bekommt es nur das erste mit.
Bei meinem DOIF:
define di DOIF ([sw_hm_hz_main] eq "set_on") (set sw_hm_hz_main on)
DOELSEIF ([sw_hm_hz_main] eq "set_off") (set sw_hm_hz_main off)
attribute di wait 120
bin ich davon ausgegangen, dass es nur triggert wenn der Status für 2 Minuten auf "set_on" oder "set_off" bleibt.
Es triggert aber auch wenn "set_on" direkt von "on" abgelöst wird.
autoReadReg steht auf "4_reqStatus"
@NewRasPi
Du kannst bei Deinem HM LAN Adapter mal den Status oder die Logs überprüfen.
Dann siehst Du, ob der manchmal im "Overload" ist.
Meine Fensterkontakte (HM-SEC-SCo) melden sich automatisch ca. 1x pro Stunde mit Ihrem Zustand.
Das kann man meiner Meinung nach auch gar nicht ändern.
Schöne Grüße
@NewRasPi
ich denke, du solltest besser einen eigenen thread aufmachen.
im wiki pairen wird erlärt, woran du erkennst, dass dein device nicht gepaired ist.
ausserdem solltest du als bekennender anfänger deine devices beim pairen automatisch anlegen lassen, damit alle wichtigen attribute vorhanden sind.
bei fk muss das register cyclicInfoMsg=on sein, damit regelmässig der status gesendet wird.
@frank
Ich habe das msgRepeat eingebaut. Das hilft wahrscheinlich schon.
Statt des DOIF benutze ich jetzt auch ein watchdog:
define wd watchdog sw_hm_hz_main:set_off 00:02 sw_hm_hz_main:off set sw_hm_hz_main off
Das funktioniert leider auch nicht richtig.
Bei normalem Verhalten, also schneller Übergang von "set_off" nach "off" bekommt er das "off" wohl nicht mehr mit.
Es ist dann das gleiche Problem wie beim DOIF.
Es triggert bei jedem Schalten.
Schöne Grüße
define wd watchdog sw_hm_hz_main.set_off 00:02 sw_hm_hz_main.off set sw_hm_hz_main off;; trigger wd .
so vielleicht besser.
Ich glaube nicht,
er triggert ja jetzt schon zu viel.
Er soll ja nur triggern, wenn der Zustand "sw_hm_hz_main.set_off" sich innerhalb von 2 Minuten nicht ändert.
Im Normalfall kommt aber direkt nach "sw_hm_hz_main.set_off" das "sw_hm_hz_main.off".
Das bekommt der Watchdog wohl nicht mit und triggert jedes mal.
zeig doch mal, was im eventmonitor passiert.
ausgelöst werden sollte der wd erst 2min nach dem letzen set_on (falls es mehrere gibt), denn jedes weitere set_on setzt den timer neu. der triggerbefehl dient dazu, dass der wd nach dem auslösen (triggered) wieder auf defined gestellt wird, damit der nächste set_on ihn aktivieren kann.
edit: hauptsächlich ging es erstmal um das ändern der doppelpunkte in punkte bei den regex.
@frank
danke, jetzt funktioniert es mit dem watchdog.
Ich hatte vergessen, dass ich noch eine Eventmap im Schalter hatte.
Es kam dann also nie "on", sondern "auto".
@ DOIF Experte ;)
Ich habe dann nochmal das DOIF getestet, das geht aber immer noch nicht.
define di_hz_checkMainStatus([sw_hm_hz_main] =~"set_on") (set sw_hm_hz_main on)
DOELSEIF ([sw_hm_hz_main] =~ "set_off") (set sw_hm_hz_main off)
attr di_hz_checkMainStatus wait 120,120
Eventlog:
2015-11-12 21:44:06 DOIF di_hz_checkMainStatus wait_timer: 12.11.2015 21:46:06 cmd_1 sw_hm_hz_main
2015-11-12 21:44:06 CUL_HM sw_hm_hz_main set_on
2015-11-12 21:44:09 CUL_HM sw_hm_hz_main deviceMsg: auto (to vccu)
2015-11-12 21:44:09 CUL_HM sw_hm_hz_main level: 100
2015-11-12 21:44:09 CUL_HM sw_hm_hz_main pct: 100
2015-11-12 21:44:09 CUL_HM sw_hm_hz_main auto
2015-11-12 21:46:06 DOIF di_hz_checkMainStatus cmd_event: sw_hm_hz_main
Wie man sieht triggert das "set_on" den timer.
Der sich nach 3 Sekunden ändernde Status nach "auto" löscht den Timer aber nicht.
Nach dem Beispiel "Waschmaschine fertig" aus der Commandref hatte ich erwarte, dass der Timer zurückgesetzt wird,
wenn die Bedingung [sw_hm_hz_main] =~"set_on" nicht mehr erfüllt ist.
bin kein DOIF-Experte... was mir auf den ersten Blick auffiel ist das Komma zwischen den Zeiten.
attr di_hz_checkMainStatus wait 120,120
Aus commandref
attr <DOIF-modul> wait <Sekunden für Befehlsfolge des ersten DO-Falls>:<Sekunden für Befehlsfolge des zweiten DO-Falls>:...
Komma-Trennung innerhalb einens DO-Falls bei mehreren Befehlen
Doppelpunkt-Trennung zwischen den DO-Falls
Hoffe ich liege richtig :)
Wieder was dazu gelernt, danke
Allerdings hatte ich in früheren Tests auch nur eine Zeit eingetragen. Da ging es auch schon nicht.
Ich ändere es mal und warte ab.
Hat sich leider nicht geändert.
Wenn 3 Sekunden nach "set_off" ein anderer Status gesetzt wird, wird der Timer immer noch nicht gelöscht.
define di_hz_checkMainStatus([sw_hm_hz_main] =~"set_on") (set sw_hm_hz_main on)
DOELSEIF ([sw_hm_hz_main] =~ "set_off") (set sw_hm_hz_main off)
attr di_hz_checkMainStatus wait 120,120
in deinem Code fehlt das DOIF, aber daran wird es ja nicht liegen... :D
setzte mal bitte ein Leerzeichen nach dem ersten Operator =~
nach dem zweiten ist es ja vorhanden
([sw_hm_hz_main] =~ "set_on") (set sw_hm_hz_main on) DOELSEIF ([sw_hm_hz_main] =~ "set_off") (set sw_hm_hz_main off)
Ach so, das DOIF hatte ich vergessen hierüber zu kopieren.
So sieht es wirklich aus:
define di_hz_checkMainStatus DOIF ([sw_hm_hz_main] =~ "set_on") (set sw_hm_hz_main on)
DOELSEIF ([sw_hm_hz_main] =~ "set_off") (set sw_hm_hz_main off)
attr di_hz_checkMainStatus wait 120,120
Am fehlenden Leerzeichen lag es auch nicht.
Man kann es auch so schreiben:
define di_hz_checkMainStatus DOIF ([sw_hm_hz_main] eq "set_on") (set sw_hm_hz_main on)
DOELSEIF ([sw_hm_hz_main] eq "set_off") (set sw_hm_hz_main off)
Aber leider wird immer ein Kommando ausgeführt, auch wenn sich der Status kurz nach dem Triggern wieder ändert.
Ich habe mir jetzt einen "Workaround" gebaut:
DOIF ([sw_hm_hz_main] =~ "set_on") (set sw_hm_hz_main on)
DOELSEIF ([sw_hm_hz_main] =~ "set_off") (set sw_hm_hz_main off)
DOELSEIF ([sw_hm_hz_main] =~ "(on|off)") (set di_hz_checkMainStatus initialize)
die dritte Bedingung setzt den Timer wieder zurück.
Auch wenn der Thread schon lange gehijacked wurde ;D, nochmal die Rückmeldung meines Problems: Die Missing ACK Probleme wurden bei einem Aktor durch eine 2.3 Firmware, statt einer 2.8 verursacht. Nach Update auf 2.8 keine Missing ACKs mehr. Bei dem anderen Aktor war es tatsächlich die Entfernung. 4 Meter näher dran - und auch hier war das Problem gelöst. Jetzt habe ich mir ein CUL mit monströser Antenne bestellt, damit solche Probleme auch Zukünftig kein Problem mehr sind :)
Nochmal danke für eure Hilfe.