Hallo
ist schalte bei bestimmten Aktionen einen den HM Aktor mit "set Beet_Innenhof_Switch on-for-timer 600" ein. Leider schaltet er sich nicht wieder von alleine aus. Der Wert timedOn wird auf on gestezt. Aber nicht passiert
Ändere ich dagegen die 600 in z.b. 20 geht alles. Jemand eine Idee. Gibt es eine maximale Zeit für on-for-timer?
habe es gerade probiert. Bei meinem einfachen schalter haben die 600 sec sauber funktioniert - 10 min eben.
Kannst du es noch einmal probieren und die rohmessages loggen?
Zwischendurch gerne einmal ein statusRequest schicken!
anbei die Rohmessages
2014.08.11 16:54:35.839 4: CUL_send: CUL_0As 10 01 A011 F11234 23E7D5 0201C80000BB82
2014.08.11 16:54:38.047 4: CUL_send: CUL_0As 10 01 A011 F11234 23E7D5 0201C80000BB82
2014.08.11 16:54:43.627 4: CUL_send: CUL_0As 10 01 A011 F11234 23E7D5 0201C80000BB82
2014.08.11 16:54:43.784 4: CUL_Parse: CUL_0 A 0E 01 8002 23E7D5 F11234 0101C84061D8 -94
2014.08.11 16:55:25.986 4: CUL_send: CUL_0As 0B 02 A001 F11234 23E7D5 010E
2014.08.11 16:55:26.143 4: CUL_Parse: CUL_0 A 0E 02 A410 23E7D5 F11234 0601C84060DB -92.5
2014.08.11 16:55:26.244 4: CUL_send: CUL_0As 0A 02 8002 F11234 23E7D5 00
2014.08.11 16:56:33.917 4: CUL_Parse: CUL_0 A 0C 10 8670 29DABA 000000 00E564F1 -81.5
2014.08.11 16:57:30.814 4: CUL_send: CUL_0As 0B 03 A001 F11234 23E7D5 010E
2014.08.11 16:57:30.971 4: CUL_Parse: CUL_0 A 0E 03 A410 23E7D5 F11234 0601C84062D8 -94
2014.08.11 16:57:31.072 4: CUL_send: CUL_0As 0A 03 8002 F11234 23E7D5 00
2014.08.11 16:58:46.417 4: CUL_Parse: CUL_0 A 0C 11 8670 29DABA 000000 00E664F1 -81.5
2014.08.11 17:00:47.553 4: CUL_send: CUL_0As 0B 04 A001 F11234 23E7D5 010E
2014.08.11 17:00:52.135 4: CUL_send: CUL_0As 0B 04 A001 F11234 23E7D5 010E
2014.08.11 17:00:56.908 4: CUL_send: CUL_0As 0B 04 A001 F11234 23E7D5 010E
2014.08.11 17:00:57.065 4: CUL_Parse: CUL_0 A 0E 04 A410 23E7D5 F11234 0601C8405DE6 -87
2014.08.11 17:00:57.166 4: CUL_send: CUL_0As 0A 04 8002 F11234 23E7D5 00
2014.08.11 17:01:48.418 4: CUL_Parse: CUL_0 A 0C 12 8670 29DABA 000000 00E964F1 -81.5
2014.08.11 17:02:38.013 4: CUL_send: CUL_0As 0B 05 A001 F11234 23E7D5 010E
2014.08.11 17:02:42.271 4: CUL_send: CUL_0As 0B 05 A001 F11234 23E7D5 010E
2014.08.11 17:02:42.428 4: CUL_Parse: CUL_0 A 0E 05 A410 23E7D5 F11234 0601C8405FE2 -89
2014.08.11 17:02:42.529 4: CUL_send: CUL_0As 0A 05 8002 F11234 23E7D5 00
2014.08.11 17:04:35.919 4: CUL_Parse: CUL_0 A 0C 13 8670 29DABA 000000 00EB64F2 -81
2014.08.11 17:06:29.528 4: CUL_send: CUL_0As 0B 06 A001 F11234 23E7D5 010E
2014.08.11 17:06:29.686 4: CUL_Parse: CUL_0 A 0E 06 A410 23E7D5 F11234 0601000060DA -93
2014.08.11 17:06:29.787 4: CUL_send: CUL_0As 0A 06 8002 F11234 23E7D5 00
Kann es sein, dass der Satus des Devices nicht automatisch wieder zurückgesetzt wird, und dass erst mit dem letzten statusrequest der wirkliche Status aktualisret wurde?
Ein Aktor sollte, wenn sich der Zustand ändert, immer die Zentrale informieren. Das tut deiner nicht. Also bei 20sec wohl schon, nicht aber nach 10min... So sehe ich es aus den Logs und von deiner Beschreibung des 20sec tests.
Probiere in Zeile ~1655
if(($err&0x70) == 0x10 || ($err&0x70) == 0x20){
nach
if(($err&0x70) == 0x10 || ($err&0x70) == 0x20|| $err&0x40){
zu ändern.
FHEM sollte dann einmal nachfragen, ob der timer nicht endlich zu ende ist. Die Wartezeit ist dynamisch du solltest beim test kein statusRequest dazwischen schicken - sonst wird es nach hinten verschoben (verzögert).
Wenn Du mir jetzt noch sagt in welcher Datei ich suchen soll, probiere ich das gleich mal aus.
ZitatWenn Du mir jetzt noch sagt in welcher Datei ich suchen soll
fhem/FHEM/10_CUL_HM.pm
die rssi sind auch ziehmlich hoch. vielleicht den funk verbessern?
gruss frank
macht leider keinen Unterschied. Zustand bleibt unverändert bis zu einem requestupdate
Antenne drehen ist schwierig, steht eigentlich nicht weit weg vom cul. alle anderen haben besser Werte. Unter 80 wäre besser, richtig?
ZitatUnter 80 wäre besser, richtig?
ja. muss aber nichts bedeuten. ist alles relativ. was steht denn unter internals beim switch zu den rssi.
ZitatAntenne drehen ist schwierig, steht eigentlich nicht weit weg vom cul. alle anderen haben besser Werte.
usb verlängerung. zu dicht ist auch nicht gut.
rssi verbessern ist immer gut. Das Problem hier scheint aber zu sein, dass das Device unter gewissen Umständen einfach keinen statusupdate von sich aus sendet und man ggf nachfragen muss. Daher ist der test interessant, der dies erreichen soll
Soll ich jetzt noch etwas anderes testen? Benötigst Du noch Infos von mir?
heute morgen sind die rssi ein wenig besser
rssi_CUL_0 lst:-89 max:-88 cnt:2 avg:-88.5 min:-89
rssi_at_CUL_0 avg:-84.54 max:-82 cnt:12 lst:-82 min:-91
cul steht so ca. 1m über dem nuc.
die verbindung an den standort im innenhof wird einfach nicht gut sein
Ist das Problem gelöst?
Wir kamen vom " das Device sendet keinen automatischen Update, wenn das Licht nach on-for-timer 10min ". Jetzt hast du den RSSI verbessert - was ist mit dem eigentlichen Problem? Ist dies erledigt? Wenn nicht, hast du den codechange schon probiert?
Hatte ich doch oben schon geschrieben. EDventuell etwas mißverfständlich
rssi Verbesserung hat das Problemnicht gelöst
codechange hat das Problem nicht gelöst. Gleiches Verhalten wie vorher
Problem ist nach wie vor vorhanden.
Ich kann das Problem auch bei anderen HM Aktoren (auch mit deutlich besserem rssi) reproduzieren.
ZitatIch kann das Problem auch bei anderen HM Aktoren (auch mit deutlich besserem rssi) reproduzieren.
wir sollten das untersuchen.
Auch bei schlechten rssi-werten sollte ein Endzustand gemeldet werden. Wenn es nicht kommt, sollte FHEM "nachfragen" - automatisch.
wenn du also ein paar Beispiele loggen kannst und sagst, welches Device/model es ist?
Ich hätte gerne den log gesehen, wenn du die Änderung eingebaut hast. Nur mit deinem Kommentar kann ich nichts sehen.
jetzt habe ich das mit dem Patch noch einmal geloggt
2014.08.12 14:11:22.530 4: CUL_send: CUL_0As 10 01 A011 F11234 23E7D5 0201C80000BB82
2014.08.12 14:11:25.721 4: CUL_send: CUL_0As 10 01 A011 F11234 23E7D5 0201C80000BB82
2014.08.12 14:11:25.879 4: CUL_Parse: CUL_0 A 0E 01 8002 23E7D5 F11234 010100005EE1 -89.5
2014.08.12 14:11:30.089 4: CUL_send: CUL_0As 10 02 A011 F11234 23E7D5 0201C80000BB82
2014.08.12 14:11:30.245 4: CUL_Parse: CUL_0 A 0E 02 8002 23E7D5 F11234 0101C8405DEC -84
2014.08.12 14:11:34.497 4: CUL_send: CUL_0As 10 02 A011 F11234 23E7D5 0201C80000BB82
2014.08.12 14:12:25.893 4: CUL_Parse: CUL_0 A 0C 07 8670 29DABA 000000 00E564FA -77
2014.08.12 14:14:40.211 4: CUL_Parse: CUL_0 A 0C 08 8670 29DABA 000000 00E864F9 -77.5
2014.08.12 14:17:44.054 4: CUL_Parse: CUL_0 A 0C 09 8670 29DABA 000000 00E464FA -77
2014.08.12 14:20:33.574 4: CUL_Parse: CUL_0 A 0C 0A 8670 29DABA 000000 00E264F9 -77.5
2014.08.12 14:21:36.051 4: CUL_Parse: CUL_0 A 0D 03 8410 23E7D5 000000 06010000E2 -89
Diesmal hat es funktioniert. Beim ersten mal nicht. Ich werde es mit unterschiedlichen Divices vom gleichen Typ HM-LC-SW1-FM noch einmal testen ob es zufällig war oder es nun wirklich eine Besserung gebracht hat
so hier noch mal der Log mit mehreren Devices. Beim ersten Versuch sind zwar alle augegangen haben aber kein Feedback gegeben. Beim zweiten Versuch sind ebenfalls alle ausgegangen allerding hat der eine mit dem schlechten rssi kein Feedback gegeben. Die anderen schon.
2014.08.12 14:23:08.575 4: CUL_Parse: CUL_0 A 0C 0B 8670 29DABA 000000 00E964F9 -77.5
2014.08.12 14:25:25.593 4: CUL_send: CUL_0As 10 02 A011 F11234 23E7D5 0201C80000BB82
2014.08.12 14:25:28.506 4: CUL_send: CUL_0As 10 02 A011 F11234 23E7D5 0201C80000BB82
2014.08.12 14:25:29.075 4: CUL_Parse: CUL_0 A 0C 0C 8670 29DABA 000000 00ED64F9 -77.5
2014.08.12 14:25:33.006 4: CUL_send: CUL_0As 10 02 A011 F11234 23E7D5 0201C80000BB82
2014.08.12 14:25:38.641 4: CUL_send: CUL_0As 10 02 A011 F11234 23E7D5 0201C80000BB82
2014.08.12 14:25:38.798 4: CUL_Parse: CUL_0 A 0E 02 8002 23E7D5 F11234 010100005EE1 -89.5
2014.08.12 14:25:43.859 4: CUL_send: CUL_0As 10 03 A011 F11234 23E831 0201C80000BB82
2014.08.12 14:25:44.015 4: CUL_Parse: CUL_0 A 0E 03 8002 23E831 F11234 0101C8404009 -69.5
2014.08.12 14:26:35.976 4: CUL_send: CUL_0As 10 04 A011 F11234 1CACD0 0201C80000BB82
2014.08.12 14:26:36.132 4: CUL_Parse: CUL_0 A 0E 04 8002 1CACD0 F11234 0101C84050F5 -79.5
2014.08.12 14:27:35.327 4: CUL_Parse: CUL_0 A 0C 0D 8670 29DABA 000000 00E964FA -77
2014.08.12 14:30:31.076 4: CUL_Parse: CUL_0 A 0C 0E 8670 29DABA 000000 00ED64F9 -77.5
2014.08.12 14:33:12.328 4: CUL_Parse: CUL_0 A 0C 0F 8670 29DABA 000000 00EC64FB -76.5
2014.08.12 14:35:39.079 4: CUL_Parse: CUL_0 A 0C 10 8670 29DABA 000000 00F164F9 -77.5
2014.08.12 14:36:39.625 4: CUL_Parse: CUL_0 A 0D 05 8410 1CACD0 000000 06010000EF -82.5
2014.08.12 14:36:47.594 4: CUL_send: CUL_0As 0B 05 A001 F11234 23E831 010E
2014.08.12 14:36:52.163 4: CUL_send: CUL_0As 0B 05 A001 F11234 23E831 010E
2014.08.12 14:36:52.320 4: CUL_Parse: CUL_0 A 0E 05 A410 23E831 F11234 060100004019 -61.5
2014.08.12 14:36:52.421 4: CUL_send: CUL_0As 0A 05 8002 F11234 23E831 00
2014.08.12 14:37:00.403 4: CUL_send: CUL_0As 0B 06 A001 F11234 23E7D5 010E
2014.08.12 14:37:03.165 4: CUL_send: CUL_0As 0B 06 A001 F11234 23E7D5 010E
2014.08.12 14:37:03.323 4: CUL_Parse: CUL_0 A 0E 06 A410 23E7D5 F11234 060100005EE1 -89.5
2014.08.12 14:37:03.423 4: CUL_send: CUL_0As 0A 06 8002 F11234 23E7D5 00
2014.08.12 14:37:13.073 4: CUL_send: CUL_0As 10 07 A001 F11234 23E7D5 00040000000000
2014.08.12 14:37:13.261 4: CUL_Parse: CUL_0 A 16 07 A010 23E7D5 F11234 03020100000000000000F11234E0 -90
2014.08.12 14:37:13.362 4: CUL_send: CUL_0As 0A 07 8002 F11234 23E7D5 00
2014.08.12 14:37:13.808 4: CUL_Parse: CUL_0 A 0C 08 A010 23E7D5 F11234 030000E1 -89.5
2014.08.12 14:37:13.909 4: CUL_send: CUL_0As 0A 08 8002 F11234 23E7D5 00
2014.08.12 14:37:13.920 4: CUL_send: CUL_0As 10 08 A001 F11234 23E7D5 01040000000001
2014.08.12 14:37:14.088 4: CUL_Parse: CUL_0 A 0C 08 A010 23E7D5 F11234 030800E0 -90
2014.08.12 14:37:14.189 4: CUL_send: CUL_0As 0A 08 8002 F11234 23E7D5 00
2014.08.12 14:37:14.344 4: CUL_Parse: CUL_0 A 0C 09 A010 23E7D5 F11234 030000E1 -89.5
2014.08.12 14:37:14.445 4: CUL_send: CUL_0As 0A 09 8002 F11234 23E7D5 00
2014.08.12 14:37:14.457 4: CUL_send: CUL_0As 0B 09 A001 F11234 23E7D5 0103
2014.08.12 14:37:14.920 4: CUL_Parse: CUL_0 A 0E 09 A010 23E7D5 F11234 0100000000E3 -88.5
2014.08.12 14:37:15.021 4: CUL_send: CUL_0As 0A 09 8002 F11234 23E7D5 00
2014.08.12 14:37:51.579 4: CUL_Parse: CUL_0 A 0C 11 8670 29DABA 000000 00EC64F9 -77.5
2014.08.12 14:37:56.130 4: CUL_send: CUL_0As 10 0A A011 F11234 23E7D5 0201C80000BB82
2014.08.12 14:37:56.286 4: CUL_Parse: CUL_0 A 0E 0A 8002 23E7D5 F11234 0101C8405EEC -84
2014.08.12 14:38:05.349 4: CUL_send: CUL_0As 10 0B A011 F11234 23E831 0201C80000BB82
2014.08.12 14:38:05.506 4: CUL_Parse: CUL_0 A 0E 0B 8002 23E831 F11234 0101C840400B -68.5
2014.08.12 14:40:53.580 4: CUL_Parse: CUL_0 A 0C 12 8670 29DABA 000000 00E864FA -77
2014.08.12 14:43:41.080 4: CUL_Parse: CUL_0 A 0C 13 8670 29DABA 000000 00E964FA -77
2014.08.12 14:46:14.333 4: CUL_Parse: CUL_0 A 0C 14 8670 29DABA 000000 00E864FB -76.5
2014.08.12 14:48:08.915 4: CUL_Parse: CUL_0 A 0D 0C 8410 23E831 000000 0601000018 -62
2014.08.12 14:48:33.083 4: CUL_Parse: CUL_0 A 0C 15 8670 29DABA 000000 00E564FA -77
2014.08.12 14:49:26.262 4: CUL_send: CUL_0As 0B 0C A001 F11234 23E7D5 010E
2014.08.12 14:49:29.159 4: CUL_send: CUL_0As 0B 0C A001 F11234 23E7D5 010E
2014.08.12 14:49:34.037 4: CUL_send: CUL_0As 0B 0C A001 F11234 23E7D5 010E
2014.08.12 14:49:34.195 4: CUL_Parse: CUL_0 A 0E 0C A410 23E7D5 F11234 0601000053F0 -82
2014.08.12 14:49:34.296 4: CUL_send: CUL_0As 0A 0C 8002 F11234 23E7D5 00
das sieht erst einmal garnicht gut aus.
1. test: FHEM bekommt bei der 1. Wiederholung eine Meldung on-for-ever, darauf noch ein Versuch, hier die Korrekte Antwort
2. test FHEM bekommt bei der 3. Wiederholung eine Meldung on-for-ever. Öfter wird hier nicht probiert.Nach 10 min eine Abfrage - das licht war schon aus.
3. dann ein getConfig
4. kommando beim ersten mal angekommen. Nach 11min eine Abfrage - 3 Versuche - licht ist aus.
die tests mit 23E831 sehen gut aus - der statusreuest wird erfolgreiche nach 10 min abgesetzt.
Die Abfrage scheint als Sinnvoll, wird deine Kommunikationsprobleme nicht komplett lösen
ok, dann werd ich wohl eine noch größere Antenne brauchen:-)
Bauchst Du den Patch ein, oder muss ich meine cul_hm selber patchen?
Ich werde es noch einmal prüfen.
Das Problem sind manche Einstellungen in denen lange Rampen und timer messages generieren. User mögen diese vielen messages nicht ( so etwa alle 2 min). Ich kann leider nicht erkennen, ob eine message fehlt und ob der timer schon zu ende sein sollte.