Moin, moin,
ich habe folgendes Problem:
In meiner Küche setze ich einen Homematic Funk-Jalousieaktor ein. Dieser fährt den Rolladen bei Sonnenaufgang hoch und bei Sonnenuntergang wieder runter.
define ku_rollladen_vorne_hoch at *{sunrise("HORIZON=-1"),} set ku_rollladen_vorne on
attr ku_rollladen_vorne_hoch room Kueche
#########################################################################
define ku_rollladen_vorne_runter at *{sunset("HORIZON=-1"),} set ku_rollladen_vorne off
attr ku_rollladen_vorne_runter room Kueche
Das hat bisher auch die ganze Zeit einwandfrei funktioniert. Neuerdings fährt er weder hoch noch runter. Im Filelog steht "Missing ACK", was mich vermuten lässt das der Aktor nicht mehr kommuniziert. Leider bin ich dann mit meinem Latein auch schon am Ende. Kennt jemand das Problem und/oder die Lösung.
Wir hatten zwischendurch einen Stromausfall, wie reagieren die Homematic Komponenten auf so ein Ereignis? Sollten sie so wie bei mir ausfallen, wären die HM-Komponenten zur Automatisierung vollkommen ungeeignet, weil z.B. im Urlaub dann alle Rölläden des Nachts oben bleiben, was keinen wirksamen Einbruchsschutz mehr darstellt.
Hallo,
Homematic gerate haben eigentlich kein Problem mit Stromausfällen. Gegebenfalls musst Du aber voreinstellen was bei der Wiederkehr des stroms passieren soll.
Wenn Du also einen Lichtaktor hast, kannst Du einstellen, das nach der Stromzufuhr der Aktor 'ein' sein soll, also das licht an. Default ist Licht aus. In den meisten Fällen genügt die Default Einstellung.
Dein MissingAck liegt eher an FHEM.
Benutzt Du einen HMLAN oder einen USB stick? Eine Signatur würde vielleicht helfen.
Hast Du eine AES Signierte Kommunikation mit deinem Aktor? Wenn Du einen HMLAN verwendest, verliert der bei einem Stromausfall denn AES Signierungsschlüssel, wenn du ihn nicht in der fhem.cfg angegeben hast, gibt es dann keinen ACKs mehr.
Verwendest Du manchmal die Windows Software für den HMLAN (wenn du denn einen hast) ? Wenn nicht kann es auch nicht das AES problem sein.
Hast Du noch andere Komponenten und wenn ja, funktionieren die noch?
Also etwas mehr Infos dann kann man Dir vielleicht uach helfen ;)
Hi Samsi,
du hast Recht, bei Gelegenheit muss ich mal an die Signatur ran.
FHEM läuft auf einem Raspberry PI.
Die Kommunikation für die FS20 und HM-Komponenten erfolgt über je ein gesondertes CUL von busware.
Auf das web frontend greife ich per Safari Browser von meinem MacBook Pro zu.
Hier mal die aktuelle Fehlermeldung aus dem logfile:
2013-11-15_16:48:51 ku_rollladen_vorne set_off
2013-11-15_16:49:07 ku_rollladen_vorne MISSING ACK
Der Jalousieaktor reagiert auch nicht wenn ich das Kommando über das FHEM web frontend absetze. Lediglich auf das manuelle Schalten reagiert er.
Irgendwie sehe ich immer noch einen Zusammenhang mit dem Stromausfall. Wie kann ich an dem Aktor einstellen, was nach einem Stromausfall passieren soll?
Hallo,
das es mit dem Stromausfall zusammen hängt kann ich mir momentan nicht vorstellen. Es sei denn Du hast vielleicht irgend etwas in FHEM definiert (z.B. eine andere HMID gesetzt) und dann nicht gespeichert so das es bei dem Stromausfall verloren gegangen ist.
Du kannst das Verhalten was bei einem Stromausfall passiert über die Regsiter in FHEM einstellen, aber das hat nicht mit Deinem Problem zu tun, es sei denn Du willst das nach einem Stromausfall z.B. automatisch das licht an geht (oder der Rolladen hoch).
Also ich hatte bei mir Missing ACKs, wenn auf der Web-Seite auf der ich den Befehl sende gleichzeitig lange Berechnungen mache (z.B. einen Plot anzeigen.
Und ich hatte MissingACKs wenn etwas mit AES nicht stimmte. Aber da du den CUL verwendest kann es nicht an AES liegen, weil das kann der gar nicht, dann hätte es nämlich vorher auch nie funktioniert.
Hast Du nur die Jalousieaktoren oder hast Du noch andere HM-Komponenten? Wäre sicher interessant zu wissen ob nur die Jalousieaktoren betroffen sind.
Hi Samsi,
ich habe nur eine HM-Komponente und einige FS20-Funksteckdosen.
Neben dem Jalousieschalter wurden nach dem Stromausfall auch zwei Funksteckdosen über autocreate neu angelegt, andere widerum funktionierten problemlos weiter.
Ich bin im Moment etwas ratlos.
Hi revuethommen,
in nicht sicher, das sich alles verstanden habe, habe es nur überflogen. Generell überstehen HM devices stromausfall und die Konfiguration bleibt erhalten. Einen Fehler im Device kann man natürlich nicht ausschliessen.
Ich gehe davon aus, dass der Stromausfall am device war - (und/oder an der Zentrale?)
Ich würde sowieso erst einmal das Device stromlos machen.
wenn es danach nicht antwortet würde ich es neu pairen
wenn es immer noch nicht geht solltest du logs ziehen und hier posten. So lange das Device nicht kaputt gegangen ist sollten wir es dann wieder herstellen können
Gruss Martin
Ich kann mir nicht helfen, seit dem Stromausfall ist der Wurm im ganzen FHEM System.
Z.T. habe ich Einträge in der fhem.cfg die ich nie gesetzt habe.
Nach dem entfernen bestimmter Einträge bekomme ich nach einem rereead oder reread fhem.cfg einen Rattenschwanz an Fehlermeldungen:
u_rollladen_vorne: unknown attribute webCmd, choose one of verbose:0,1,2,3,4,5 room group comment alias eventMap userReadings IODev do_not_notify:1,0 ignore:1,0 dummy:1,0 showtime:1,0 loglevel:0,1,2,3,4,5,6 serialNr firmware rawToReadable unit peerIDs repPeers actCycle actStatus autoReadReg:1_restart,0_off,2_pon-restart,3_onChange,4_reqStatus expert:0_off,1_on,2_full param msgRepeat .stc .devInfo event-on-change-reading event-on-update-reading event-min-interval stateFormat model:ASH550,ASH550I,CMM,DORMA_BRC-H,DORMA_RC-H,DORMA_atent,HM-CC-RT-DN,HM-CC-SCD,HM-CC-TC,HM-CC-VD,HM-Dis-TD-T,HM-LC-BL1-FM,HM-LC-BL1-PB-FM,HM-LC-BL1-SM,HM-LC-Bl1PBU-FM,HM-LC-DDC1-PCB,HM-LC-DIM1L-CV,HM-LC-DIM1L-PL,HM-LC-DIM1T-CV,HM-LC-DIM1T-FM,HM-LC-DIM1T-PL,HM-LC-DIM2L-CV,HM-LC-DIM2L-SM,HM-LC-DIM2T-SM,HM-LC-Dim1L-CV,HM-LC-Dim1L-Pl,HM-LC-Dim1L-Pl-2,HM-LC-Dim1PWM-CV,HM-LC-Dim1T-CV,HM-LC-Dim1T-FM,HM-LC-Dim1T-Pl,HM-LC-Dim1T-Pl-2,HM-LC-Dim1TPBU-FM,HM-LC-Dim2L-SM,HM-LC-Dim2T-SM,HM-LC-SW1-BA-PCB,HM-LC-SW1-FM,HM-LC-SW1-PB-FM,HM-LC-SW1-PL,HM-LC-SW1-PL-OM54,HM-LC-SW1-PL2,HM-LC-SW1-SM,HM-LC-SW1-SM-ATMEGA168,HM-LC-SW2-DR,HM-LC-SW2-FM,HM-LC-SW2-PB-FM,HM-LC-SW2-SM,HM-LC-SW4-BA-PCB,HM-LC-SW4-DR,HM-LC-SW4-PCB,HM-LC-SW4-SM,HM-LC-SW4-SM-ATMEGA168,HM-LC-SW4-WM,HM-LC-Sw1PBU-FM,HM-OU-CF-PL,HM-OU-CFM-PL,HM-OU-CM-PCB,HM-OU-LED16,HM-PB-2-WM,HM-PB-2-WM55,HM-PB-4-WM,HM-PB-4DIS-WM,HM-PB-6-WM55,HM-PBI-4-FM,HM-RC-12,HM-RC-12-B,HM-RC-12-SW,HM-RC-19,HM-RC-19-B,HM-RC-19-SW,HM-RC-4,HM-RC-4-2,HM-RC-4-B,HM-RC-KEY3,HM-RC-KEY3-B,HM-RC-Key4-2,HM-RC-P1,HM-RC-SEC3,HM-RC-SEC3-B,HM-RC-Sec4-2,HM-SCI-3-FM,HM-SEC-KEY,HM-SEC-KEY-O,HM-SEC-KEY-S,HM-SEC-MDIR,HM-SEC-RHS,HM-SEC-SC,HM-SEC-SD,HM-SEC-SFA-SM,HM-SEC-TIS,HM-SEC-WDS,HM-SEC-WDS-2,HM-SEC-WIN,HM-SEN-EP,HM-SEN-MDIR-SM,HM-SWI-3-FM,HM-Sec-Cen,HM-Sen-MDIR-O,HM-Sen-RD-O,HM-Sen-Wa-Od,HM-Sys-sRP-Pl,HM-WDC7000,HM-WDS10-TH-O,HM-WDS100-C6-O,HM-WDS20-TH-O,HM-WDS30-OT2-SM,HM-WDS30-T-O,HM-WDS40-TH-I,HM-WS550,HM-WS550LCB,HM-WS550LCW,HM-WS550Tech,IS-WDS-TH-OD-S-R3,IS-WDS-TH-OD-S-R3,KFM-Display,KFM-Sensor,KS550,KS550LC,KS550TECH,KS888,PS-Th-Sens,PS-switch,ROTO_ZEL-STG-RM-DWT-10,ROTO_ZEL-STG-RM-FDK,ROTO_ZEL-STG-RM-FEP-230V,ROTO_ZEL-STG-RM-FSA,ROTO_ZEL-STG-RM-FST-UP4,ROTO_ZEL-STG-RM-FWT,ROTO_ZEL-STG-RM-FZS,ROTO_ZEL-STG-RM-FZS-2,ROTO_ZEL-STG-RM-HS-4,ROTO_ZEL-STG-RM-WT-2,Roto_ZEL-STG-RM-FFK,Roto_ZEL-STG-RM-FSS-UP3,S550IA,Schueco_263-130,Schueco_263-131,Schueco_263-132,Schueco_263-133,Schueco_263-134,Schueco_263-135,Schueco_263-144,Schueco_263-145,Schueco_263-146,Schueco_263-147,Schueco_263-155,Schueco_263-158,Schueco_263-160,Schueco_263-162,Schueco_263-xxx,WDF-solar,WS888 subType:AlarmControl,KFM100,THSensor,blindActuator,blindActuatorSol,dimmer,keyMatic,motionDetector,outputUnit,pushButton,remote,repeater,sensRain,sensor,singleButton,smokeDetector,swi,switch,thermostat,threeStateSensor,tipTronic,winMatic or use attr global userattr webCmd
wz_stehlampe: unknown attribute Wohnzimmer, choose one of verbose:0,1,2,3,4,5 room group comment alias eventMap userReadings IODev follow-on-for-timer:1,0 follow-on-timer do_not_notify:1,0 ignore:1,0 dummy:1,0 showtime:1,0 event-on-change-reading event-on-update-reading event-min-interval stateFormat model:dummyDimmer,dummySender,dummySimple,fs20as1,fs20as4,fs20bf,fs20bs,fs20di,fs20di10,fs20du,fs20fms,fs20hgs,fs20irl,fs20kse,fs20ls,fs20ms2,fs20pira,fs20piri,fs20piru,fs20rgbsa,fs20rst,fs20rsu,fs20s16,fs20s20,fs20s4,fs20s4a,fs20s4m,fs20s4u,fs20s4ub,fs20s8,fs20s8m,fs20sa,fs20sd,fs20sig,fs20sm4,fs20sm8,fs20sn,fs20sr,fs20ss,fs20st,fs20st2,fs20str,fs20su,fs20sv,fs20tc1,fs20tc6,fs20tfk,fs20tk,fs20ue1,fs20usr,fs20uts,fs20ws1,fs20ze or use attr global userattr Wohnzimmer
wz_tv_dvd_ambilight: unknown attribute Wohnzimmer, choose one of verbose:0,1,2,3,4,5 room group comment alias eventMap userReadings IODev follow-on-for-timer:1,0 follow-on-timer do_not_notify:1,0 ignore:1,0 dummy:1,0 showtime:1,0 event-on-change-reading event-on-update-reading event-min-interval stateFormat model:dummyDimmer,dummySender,dummySimple,fs20as1,fs20as4,fs20bf,fs20bs,fs20di,fs20di10,fs20du,fs20fms,fs20hgs,fs20irl,fs20kse,fs20ls,fs20ms2,fs20pira,fs20piri,fs20piru,fs20rgbsa,fs20rst,fs20rsu,fs20s16,fs20s20,fs20s4,fs20s4a,fs20s4m,fs20s4u,fs20s4ub,fs20s8,fs20s8m,fs20sa,fs20sd,fs20sig,fs20sm4,fs20sm8,fs20sn,fs20sr,fs20ss,fs20st,fs20st2,fs20str,fs20su,fs20sv,fs20tc1,fs20tc6,fs20tfk,fs20tk,fs20ue1,fs20usr,fs20uts,fs20ws1,fs20ze or use attr global userattr Wohnzimmer
sz_tv_hifi: unknown attribute Schlafzimmer, choose one of verbose:0,1,2,3,4,5 room group comment alias eventMap userReadings IODev follow-on-for-timer:1,0 follow-on-timer do_not_notify:1,0 ignore:1,0 dummy:1,0 showtime:1,0 event-on-change-reading event-on-update-reading event-min-interval stateFormat model:dummyDimmer,dummySender,dummySimple,fs20as1,fs20as4,fs20bf,fs20bs,fs20di,fs20di10,fs20du,fs20fms,fs20hgs,fs20irl,fs20kse,fs20ls,fs20ms2,fs20pira,fs20piri,fs20piru,fs20rgbsa,fs20rst,fs20rsu,fs20s16,fs20s20,fs20s4,fs20s4a,fs20s4m,fs20s4u,fs20s4ub,fs20s8,fs20s8m,fs20sa,fs20sd,fs20sig,fs20sm4,fs20sm8,fs20sn,fs20sr,fs20ss,fs20st,fs20st2,fs20str,fs20su,fs20sv,fs20tc1,fs20tc6,fs20tfk,fs20tk,fs20ue1,fs20usr,fs20uts,fs20ws1,fs20ze Wohnzimmer Wohnzimmer_map or use attr global userattr Schlafzimmer
sz_stehlampe1: unknown attribute Schlafzimmer, choose one of verbose:0,1,2,3,4,5 room group comment alias eventMap userReadings IODev follow-on-for-timer:1,0 follow-on-timer do_not_notify:1,0 ignore:1,0 dummy:1,0 showtime:1,0 event-on-change-reading event-on-update-reading event-min-interval stateFormat model:dummyDimmer,dummySender,dummySimple,fs20as1,fs20as4,fs20bf,fs20bs,fs20di,fs20di10,fs20du,fs20fms,fs20hgs,fs20irl,fs20kse,fs20ls,fs20ms2,fs20pira,fs20piri,fs20piru,fs20rgbsa,fs20rst,fs20rsu,fs20s16,fs20s20,fs20s4,fs20s4a,fs20s4m,fs20s4u,fs20s4ub,fs20s8,fs20s8m,fs20sa,fs20sd,fs20sig,fs20sm4,fs20sm8,fs20sn,fs20sr,fs20ss,fs20st,fs20st2,fs20str,fs20su,fs20sv,fs20tc1,fs20tc6,fs20tfk,fs20tk,fs20ue1,fs20usr,fs20uts,fs20ws1,fs20ze Wohnzimmer Wohnzimmer_map or use attr global userattr Schlafzimmer
sz_stehlampe2: unknown attribute Schlafzimmer, choose one of verbose:0,1,2,3,4,5 room group comment alias eventMap userReadings IODev follow-on-for-timer:1,0 follow-on-timer do_not_notify:1,0 ignore:1,0 dummy:1,0 showtime:1,0 event-on-change-reading event-on-update-reading event-min-interval stateFormat model:dummyDimmer,dummySender,dummySimple,fs20as1,fs20as4,fs20bf,fs20bs,fs20di,fs20di10,fs20du,fs20fms,fs20hgs,fs20irl,fs20kse,fs20ls,fs20ms2,fs20pira,fs20piri,fs20piru,fs20rgbsa,fs20rst,fs20rsu,fs20s16,fs20s20,fs20s4,fs20s4a,fs20s4m,fs20s4u,fs20s4ub,fs20s8,fs20s8m,fs20sa,fs20sd,fs20sig,fs20sm4,fs20sm8,fs20sn,fs20sr,fs20ss,fs20st,fs20st2,fs20str,fs20su,fs20sv,fs20tc1,fs20tc6,fs20tfk,fs20tk,fs20ue1,fs20usr,fs20uts,fs20ws1,fs20ze Wohnzimmer Wohnzimmer_map or use attr global userattr Schlafzimmer
Wenn ich mir unter Everything die Global ansehe, so findet sich folgender Eintrag:
userattr Schlafzimmer Schlafzimmer_map Wohnzimmer Wohnzimmer_map deleteattr
Der ist aber in der fhem.cfg gar nicht enthalten. Selbst nach einem deleteattr ist der Eintrag wieder vorhanden.
Dummer Weise habe ich mir die Einstellungen nicht gesichert, was ich in Zukunft wohl tun werde. Aber ich komme der Ursache nicht auf die Spur was mit meiner FHEM Installation los ist, sie lief über Wochen tadellos bis zu besagtem Stromausfall.
Hi revuethommen,
nun, eine sicherung ist immer gut ;-)
die erste Meldung
u_rollladen_vorne: unknown attribute webCmd
deutet darauf hin, dass u_rollladen_vorne VOR FHEMWEB definiert wird. Korrigiere die Reihenfolge in fhem.cfg - oder definieren FHEMWEB.
ansonsten sieht es aus, als ob du
attr sz_stehlampe2 Schlafzimmer
anstatt
attr sz_stehlampe2 room Schlafzimmer
nutzt
Gruss Martin
Hi Martin,
das kann es m.E. nicht sein.
FHEMWEB wird über include web.cfg eingebunden und das noch vor der kueche.cfg wo sich der Rolladen befindet:
attr global latitude 51.013
attr global logfile ./log/fhem-%Y-%m-%d.log
attr global longitude 6.853
attr global modpath .
attr global motd none
attr global statefile ./log/fhem.save
attr global verbose 3
# attr global autoload_undefined_devices 1
include /opt/fhem/FHEM/usbinterface.cfg
include /opt/fhem/FHEM/web.cfg
include /opt/fhem/FHEM/heizungskeller.cfg
include /opt/fhem/FHEM/kueche.cfg
include /opt/fhem/FHEM/wohnzimmer.cfg
include /opt/fhem/FHEM/flur_oben.cfg
include /opt/fhem/FHEM/schlafzimmer.cfg
include /opt/fhem/FHEM/wetter.cfg
# define autocreate autocreate
# attr autocreate autosave 1
# attr autocreate filelog ./log/%NAME-%Y.log
define Logfile FileLog ./log/fhem-%Y-%m-%d.log fakelog
# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
define telnetPort telnet 7072 global
Das attr sz_stehlampe2 room Schlafzimmer ist soweit ich sehe auch korrekt:
#########################################################################
## Aktor für Stehlampe links vom Bett
#########################################################################
define sz_stehlampe2 FS20 0303 02
attr sz_stehlampe2 Schlafzimmer sz_AllesAus
attr sz_stehlampe2 model fs20st
attr sz_stehlampe2 room Schlafzimmer
define FileLog_sz_stehlampe2 FileLog ./log/sz_stehlampe2-%Y.log sz_stehlampe2
attr FileLog_sz_stehlampe2 logtype text
attr FileLog_sz_stehlampe2 room Schlafzimmer
Was ich bisher gefunden und gefixed habe ist, das die Gruppe und die Rechte der Dateien heizungskeller.cfg, flur_oben.cfg und kueche.cfg nicht mehr gestimmt haben. Die Rechte sahen wie folgt aus:
-r--r--r-- 1 fhem dialout datei
Diese habe ich jetzt wieder geändert in:
-rw-rw-rw- 1 fhem root datei
Geholfen hat es nix und warum hier Rechte und Nutzer verändert waren kann ich mir auch nicht erklären.
Zitatunknown attribute webCmd
attr global webCmd
fehlt in deiner .cfg
fehlt nicht eher
define WEB FHEMWEB 8083 global
fhemweb sollte webCmd definieren.
define WEB FHEMWEB 8083 global wird in der web.cfg definiert und über include geladen.
Das Problem mit den Errormeldungen bezüglich der einzelnen Zimmer habe ich gelöst. In der jeweiligen *.cfg stand ein falscher attr-Eintrag.
Das verbleibende Hauptproblem ist nach wie vor der Jalousie-Aktor, der nur auf manuelles betätigen reagiert. Er fährt werder zur definierten Zeit den Rolladen, noch lässt er sich über das web frontend bedienen. Hier der letzte Eintrag aus dem Eventmonitor:
Events:
2013-11-16 17:03:18 CUL_HM ku_rollladen_vorne MISSING ACK
2013-11-16 17:03:35 CUL_HM ku_rollladen_vorne MISSING ACK
Hier mal ein Auszug aus dem logfile als der Aktor noch tadellos funktionierte vs. heutiger Zustand:
2013-11-09_16:57:27 ku_rollladen_vorne set_off
2013-11-09_16:57:27 ku_rollladen_vorne level: 100 %
2013-11-09_16:57:27 ku_rollladen_vorne deviceMsg: on (to xx_usbinterface_hm)
2013-11-09_16:57:27 ku_rollladen_vorne on
2013-11-09_16:57:27 ku_rollladen_vorne running: -
2013-11-09_16:57:27 ku_rollladen_vorne motor: down:on
2013-11-09_16:58:36 ku_rollladen_vorne level: 0 %
2013-11-09_16:58:36 ku_rollladen_vorne deviceMsg: off (to xx_usbinterface_hm)
2013-11-09_16:58:36 ku_rollladen_vorne off
2013-11-09_16:58:36 ku_rollladen_vorne running: -
2013-11-09_16:58:36 ku_rollladen_vorne motor: stop:off
2013-11-12_07:25:36 ku_rollladen_vorne level: 8.5 %
2013-11-12_07:25:36 ku_rollladen_vorne deviceMsg: 8.5 % (to broadcast)
2013-11-12_07:25:36 ku_rollladen_vorne 8.5 %
2013-11-12_07:25:36 ku_rollladen_vorne running: -
2013-11-12_07:25:36 ku_rollladen_vorne motor: up:8.5 %
2013-11-12_07:26:31 ku_rollladen_vorne level: 100 %
2013-11-12_07:26:31 ku_rollladen_vorne deviceMsg: on (to broadcast)
2013-11-12_07:26:31 ku_rollladen_vorne on
2013-11-12_07:26:31 ku_rollladen_vorne running: -
2013-11-12_07:26:31 ku_rollladen_vorne motor: stop:on
2013-11-12_07:40:01 ku_rollladen_vorne set_on
2013-11-12_07:40:18 ku_rollladen_vorne MISSING ACK
Vielleicht kann damit jemand etwas anfangen...
Unter protState des Aktors findet sich der Eintrag CMDs_done_events:4. Gemäss dem Manual FHEM für Einsteiger heißt das es gab 4 Problem und sei vom Anwender zu prüfen. Was auch immer zu prüfen ist.
CFGFN
/opt/fhem/FHEM/kueche.cfg
DEF
20A2A6
IODev
xx_usbinterface_hm
NAME
ku_rollladen_vorne
NR
75
STATE
MISSING ACK
TYPE
CUL_HM
protResnd
3 last_at:2013-11-16 18:58:10
protResndFail
1 last_at:2013-11-16 18:58:15
protSnd
1 last_at:2013-11-16 18:57:58
protState
CMDs_done_events:4
Die Register lassen sich auch nicht auslesen. set ku_rollladen_vorne getConfig führt zu folgendem Ergebnis:
2013-11-16 19:17:04 CUL_HM ku_rollladen_vorne RESPONSE TIMEOUT:RegisterRead
2013-11-16 19:17:25 CUL_HM ku_rollladen_vorne RESPONSE TIMEOUT:RegisterRead
2013-11-16 19:17:47 CUL_HM ku_rollladen_vorne RESPONSE TIMEOUT:PeerList
2013-11-16 19:18:27 CUL_HM ku_rollladen_vorne RESPONSE TIMEOUT:RegisterRead
2013-11-16 19:18:48 CUL_HM ku_rollladen_vorne RESPONSE TIMEOUT:RegisterRead
2013-11-16 19:19:10 CUL_HM ku_rollladen_vorne RESPONSE TIMEOUT:PeerList
Hallo Forum,
ich habe das Problem gelöst.
Ich habe den Aktor erneut "gepaired" (set ku_rollladen_vorne pair), danach ging es wieder.
Fazit:
Das der HM-Jalousieaktor nach einem Stromausfall die Verbindung dauerhaft verliert und erneut "gepaired" werden muss, macht ihn für mich ziemlich unattraktiv. Ein Rolladen ist zwar kein Einbruchsschutz, wirkt aber wenigstens einbruchshemmend. Ich stelle mir gerade das Szenario vor, dass ein Stromausfall während meines Urlaubes auftritt und dann meine Rollläden für 14 Tage offen bleiben. Sofern es dafür eine Lösung gibt, so wäre ich für einen Hinweis dankbar. Gut das ich erst einen Aktor zum testen bestellt habe...
Also diese Folgerung kann ich nicht ziehen: Habe hier den Nachteil häufigerer Stromausfälle (extern verursacht) und wegen Veränderungen der Hauselektrik auch in den letzten Wochen häufiger gewollte Stromausfälle.
In allen Fällen hatten meine 6 HM-LC-BL1-FM keine Probleme mit der Rückkehr. Was vereinzelt passierte, ist
a) das FHEM einen Timerbefehl ausgelassen hat, wenn die Stromwiederkehr um den von Sonnenuntergang beeinflussten jeden Tag sich verändernden Runterfahrzeitpunkt lag.
b) Ich vereinzelt beobachte, dass der Gruppenbefehl zum Rauf- oder Runterfahren nur von einem der 6 Aktoren nicht ausgeführt wird. Da suche ich in einem weiteren Thread noch nach Ratschlag.
Wichtig ist natürlich, dass die aktuelle Konfiguration in FHEM gesaved ist bevor es einen Stromausfall gibt/FHEM heruntergefahren wird.
Grüße
Christian
Hallo zusammen,
ich hatte das "MISSING ACK" Problem, bei einem von vier Aktoren (nach einem Stromausfall), ebenfalls.
Ich konnte es durch ein set gerätename pair
lösen.
Aktor: HM-LC-Bl1PBU-FM
Danke für den Tipp. Ist aber wirklich ärgerlich...
Danke ich hatte das gleiche Problem mit Missing Ack der Befehl " set <name> pair " hat auch bei mir funktioniert!
:) :) :)
Ich habe gerade einen ganz neuen Aktor HM-LC-Bl1PBU-FM ebenfalls mit MISSING ACT. Mehrmals unpair - Werkzustand - Pair... beim 3. mal hat es dann funktioniert. Immer wenn das Missing ACT da stand, war R-pairCentral 0x000000 was nicht der ID des HMLAN entsprach. Nach dem 3. mal stand die richtige ID drin.
Das Pairing scheint nicht immer zuverlässig zu sein.
Nach einem provozierten Stromausfall, kam der Aktor aber problemlos zurück.
Hallo liebes Forum,
möchte auch noch meine Erfahrung mit Missing ACK zum besten geben.
Ich habe zwei Rollladen/Jalousie Aktoren: HM-LC-Bl1PBU-FM. Der obere funktionierte perfekt, der untere wurde zwar von FHEM erfasst, wenn ich per Taster die Rollade rauf/runter fuhr, sonst las ich aber bei beliebigen Kommandos "Missing ACK".
Ich habe natürlich unpair/pair versucht, ich habe den Aktor via Seriennummer angelegt, ich habe ihn mehrfach in den Fabrikzustand zurückgesetzt, ich habe ihn vom Strom getrennt usw. Geholfen hat das alles nix.
Letztlich scheint es mir so, dass der Empfang zu schlecht war. Ich habe den CUL näher herangebracht und alles funktioniert.
Gruß
Axel
Bei mir exakt dasselbe. Es lag nur am Empfang.
Ich habe hier anscheinend genau das gleiche Problem.
3 von 9 Jalousieaktor melden immer öfter missing ack. Komischerweise haben sie ein paar Monate lange relativ zuverlässig funktioniert (bzw. ich habe es nicht gemerkt).
Zwei Fragen dazu:
1. Einer der missing ack Aktoren hat einen RSSI von -105, was wohl schlecht ist. Würde der Repeater (http://www.elv.de/homematic-selektiver-funk-zwischenstecker-repeater-hm-sys-srp-pl-fertiggeraet.html) in diesem Fall helfen? Ein Umzug des HMLAN stellt sich bei mir nicht soo einfach dar.
2. Vor ein paar Wochen sind 2 Lacrosse-Temperatur-Sensoren und ein JeeLink-Empfänger dazu gekommen, sowie ein paar Lichtschalter. Kann das der Grund für das immer häufiger auftretende missing ack sein?
Zum ersten: in einen gelösten Thread ein neues Problem posten ist eventuell nicht so zielführend. Da liest eventuell keiner mehr.
rssi unter -80 sind kritisch. -105 ist unterirdisch
ZitatEin Umzug des HMLAN stellt sich bei mir nicht soo einfach dar.
Du kannst die Antenne verbessern (http://heinz-otto.blogspot.de/2015/07/pimp-my-hmlan.html).
Repeater hilft natürlich auch, aber eventuell lieber ein zweiter HMLAN.
Andere Funker können auch stören und wenn die rssi unterirdisch sind dann ist alles möglich.
Gruß Otto
Zitat von: Otto123 am 19 August 2015, 20:19:03
Zum ersten: in einen gelösten Thread ein neues Problem posten ist eventuell nicht so zielführend. Da liest eventuell keiner mehr.
Was soll ich sagen... Du hast natürlich recht.
Mir ist gar nicht aufgefallen, dass im Titel "gelöst" steht.
Ich habe nach dem Problem gesucht und fand diesen Thread am passendsten. Und eine sehr gute Antwort ist ja doch innerhalb von ein paar Stunden gekommen ;)
Zitat von: Otto123 am 19 August 2015, 20:19:03rssi unter -80 sind kritisch. -105 ist unterirdisch Du kannst die Antenne verbessern (http://heinz-otto.blogspot.de/2015/07/pimp-my-hmlan.html).
"unterirdisch" wollte ich nicht unbedingt hören, aber das macht einem die Augen auf ;)
Da muss was passieren. Mich wundert halt nur, dass es ein paar Monate lang sehr gut ging.
Zitat von: Otto123 am 19 August 2015, 20:19:03Repeater hilft natürlich auch, aber eventuell lieber ein zweiter HMLAN.
Dann würde ich den Repeater zuerst probieren. Der zweite HMLAN muss dann auch konfiguriert werden, oder hängt man den in FHEM einfach mit rein. Ich geh mich mal einlesen.
Danke Dir auf jeden Fall schon mal!
Hast Du meinen Link gesehen? Ich würde erstmal die Antenne verbessern, oder ist Dir das zu kompliziert?
Bei rssi um die -100 kann alles möglich sein, das ist aber eben wackelig so wie bei Dir.
Ich würde sagen vom Aufwand in FHEM ist der Repeater und HMLAN etwa gleich. Der Repeater ist nicht wie ein Verstärker sondern eher wie ein selektives Device was konfiguriert werden muss.
Gruß Otto
Zitat von: Otto123 am 19 August 2015, 21:01:27
Hast Du meinen Link gesehen? Ich würde erstmal die Antenne verbessern, oder ist Dir das zu kompliziert?
Bei rssi um die -100 kann alles möglich sein, das ist aber eben wackelig so wie bei Dir.
Doch, sorry, da bin ich gar nicht drauf eingegangen.
Das werde ich als erstes dann versuchen, vor allem weil der Repeater ja anscheinend auch nicht nur Einstecken-Und-Loslegen bedeutet.
Ich gucke auch vielleicht, ob ich doch den HMLAN woanders hinstellen kann. Da muss ich mir Gedanken um's Kabel machen, damit der WAF nicht fällt ;)
Zitat von: Otto123 am 19 August 2015, 21:01:27
Ich würde sagen vom Aufwand in FHEM ist der Repeater und HMLAN etwa gleich. Der Repeater ist nicht wie ein Verstärker sondern eher wie ein selektives Device was konfiguriert werden muss.
Gut zu wissen, danke Otto!
ZitatIch gucke auch vielleicht, ob ich doch den HMLAN woanders hinstellen kann. Da muss ich mir Gedanken um's Kabel machen,
das geht auch kabellos mit powerlan steckdosen. ;)
Noch mehr Ideen:
Wlan Repeater mit LAN Anschluss.
Rasperry mit WLAN und HM USB Adapter
Aber ehrlich, wenn Du wirklich Probleme mit dem LAN Kabel hast, dann doch eher Repeater. Der braucht nur Strom und seinen Funk und ist als Bausatz sehr günstig.
Allerdings gibt es Einschränkungen, die Dich zunächst nicht treffen:
ZitatDer Repeater befindet sich zwischen Sender und Empfänger, empfängt deren Signale und sendet sie in neu aufbereiteter Form weiter, wodurch natürlich eine wesentlich größere Distanz überbrückt werden kann.
Dabei arbeitet der HomeMatic-Repeater nach Konfiguration durch eine Zentrale des HomeMatic-Systems selektiv. So sind die Wiederholungen auf eine Liste bestimmter, angemeldeter Verbindungen begrenzt. Denn es müssen ja in den meisten Anwendungsfällen nicht die Signale aller Systemgeräte über den Repeater weitergegeben werden, sondern nur die, bei denen Reichweitenprobleme auftreten.
Zusätzlich wird die Abgrenzung zu benachbarten gleichen Systemen strikter. Somit erhöht der Repeater auch die Stör- und Betriebssicherheit des Gesamtsystems und es werden unnötige Aussendungen vermieden.
Erhöhte überbrückbare Distanz zwischen Sender und Empfänger
Arbeitet nach Konfiguration durch eine Zentrale des HomeMatic-Systems selektiv
Erhöht die Stör- und Betriebssicherheit des Gesamtsystems
Unnötige Aussendungen werden vermieden
Hinweise:
AES-verschlüsselte Signale von Sicherheitskomponeten werden nicht repeatet
Der Repeater ist nicht kompatibel mit dem HomeMatic Rauchmelder HM-OU-CM-PCB
Die Low-Bat-Meldungen vom Sender werden nicht an die Zentrale CCU gesendet
Gruß Otto
am coolsten finde ich den hm-wlan-cfg. 8)
(http://git.zerfleddert.de/hmcfgusb/hm-cfg-usb-tl-mr3020-small.jpg)
Danke Euch für die weiteren Ideen.
Ich habe heute testweise mal den HMLAN näher bei den missing-ack Aktoren positioniert und bin (mal wieder ein bisschen überrascht).
Zwei der Drei Aktoren, die oft missing ack gemeldet haben, scheinen jetzt problemlos zu funktionieren.
Der dritte macht aber weiterhin Probleme. Interessanterweise ist es genau der, der jetzt am nächsten zum HMLAN liegt. Wenn ich den manuell antippe (also am Schalter) ist er kurz wieder da. Dann sehe ich auch, dass er einen RSSI von -57 hat, also liegt es wohl an was anderem.
Ein "set gerätename pair" hilft leider nicht. Ein unpair/pair leider auch nicht.
Ich werde die Tage mal den Aktor komplett aus fhem raus nehmen und erkennen lassen.
Das mache ich doch am besten mit "delete rolloABC" und danach normal "set hmlan hmPairForSec 60" und die Config-Taste am Aktor drücken, oder?
oder hmPairSerial
Du kannst beliebig oft pairen ohne zu löschen oder reset. Das löschen und reset macht nur Sinn wenn was wiirklich falsch ist.
Gruß Otto
Zitat von: ChrisK am 19 August 2015, 20:52:41
...Der zweite HMLAN muss dann auch konfiguriert werden, oder hängt man den in FHEM einfach mit rein. Ich geh mich mal einlesen...
Das Stichwort (für das Suche-Kästchen) ist VCCU.
Einmal definieren und Du kannst mit minimalem Aufwand IODevs (HMLAN,HMUSB,CUL) in Dein System einbinden.
Erhöht die Ausfallsicherheit und die "Reichweite".
Habe das gerade selber gemacht, nachdem mein HMLAN aktuell etwas zickt.
Jetzt habe ich noch einen HM-USB dazu und kann dadurch auch Firmware-Updates machen; coole Sache.
ZitatEin "set gerätename pair" hilft leider nicht. Ein unpair/pair leider auch nicht.
was soll das auch ändern? entweder ein device ist gepaired, oder nicht. da wird nur die hmid der zentrale im realen gerät gespeichert. ab dann "gehorcht" das device auf befehle, die von dieser zentrale gesendet werden.
wenn es also aus fhem mit dem schalten mal funktioniert und ein anderes mal nicht, weisst du garantiert, dass ein pairing mit fhem vorhanden sein muss. ansonsten würde es nie funktionieren.
also muss es störungen in der kommunikation geben. entweder timingprobleme oder funkprobleme. beides ist am besten über rawmessages erkennbar.
Zitat von: frank am 22 August 2015, 12:50:18
was soll das auch ändern? entweder ein device ist gepaired, oder nicht. da wird nur die hmid der zentrale im realen gerät gespeichert. ab dann "gehorcht" das device auf befehle, die von dieser zentrale gesendet werden.
So genau weiß ich nicht, was das ändern soll. Hab nur gelesen, dass das bei dem einen oder anderen geholfen hat. Bei mir aber nicht, wahrscheinlich aus den von Dir genannten Gründen.
Zitat von: frank am 22 August 2015, 12:50:18
wenn es also aus fhem mit dem schalten mal funktioniert und ein anderes mal nicht, weisst du garantiert, dass ein pairing mit fhem vorhanden sein muss. ansonsten würde es nie funktionieren.
Macht Sinn.
Ich sehe im dblog in der history, dass da auch Werte in state drin stehen, die nicht 'MISSING ACK', 'ResndFail', 'unreachable' sind. Also ist der Kontakt schon ab und zu da.
Zitat von: frank am 22 August 2015, 12:50:18
also muss es störungen in der kommunikation geben. entweder timingprobleme oder funkprobleme. beides ist am besten über rawmessages erkennbar.
Hmm, meinst Du mit "rawmessages" ein "list gerät"?
Das sieht im Moment so aus:
Internals:
CFGFN ./cfgfiles/rollos.cfg
DEF 2FF0E2
IODev HMLAN1
NAME ho_rollo1
NR 75
NTFY_ORDER 50-ho_rollo1
STATE MISSING ACK
TYPE CUL_HM
protCmdDel 22
protResnd 54 last_at:2015-08-23 11:37:17
protResndFail 18 last_at:2015-08-23 11:37:21
protSnd 18 last_at:2015-08-23 11:37:06
protState CMDs_done_Errors:1
CHANGETIME:
Helper:
Dblog:
State:
Mydblog:
TIME 1440322642.0947
VALUE MISSING ACK
Readings:
2015-08-17 10:00:22 CommandAccepted yes
2015-04-30 20:32:40 D-firmware 2.3
2015-04-30 20:32:40 D-serialNr LEQ1021207
2015-04-30 20:40:40 PairedTo 0x286507
2015-04-30 20:32:51 R-confBtnTime permanent
2015-04-30 20:40:36 R-driveDown 18 s
2015-04-30 20:40:36 R-driveTurn 0.5 s
2015-04-30 20:40:36 R-driveUp 20 s
2015-04-30 20:32:51 R-intKeyVisib invisib
2015-04-30 20:32:51 R-localResDis off
2015-08-20 22:46:28 R-pairCentral set_0x000000
2015-04-30 20:40:34 R-refRunCounter set_0
2015-04-30 20:40:36 R-sign off
2015-04-30 20:40:36 R-statusInfoMinDly 2 s
2015-04-30 20:40:36 R-statusInfoRandom 1 s
2015-04-30 20:40:36 R-transmitTryMax 6
2015-08-22 18:08:51 deviceMsg off (to broadcast)
2015-08-22 21:10:09 level set_0
2015-07-15 22:16:53 levelMissed desired:0
2015-08-22 18:08:51 motor stop:off
2015-08-22 18:08:51 pct 0
2015-08-22 18:08:51 recentStateType info
2015-08-23 11:37:22 state MISSING ACK
2015-08-22 18:08:51 timedOn off
Regl_00::
VAL
Helper:
HM_CMDNR 18
cSnd 012865072FF0E200040000000000,012865072FF0E2010E
getCfgList all
getCfgListNo ,3
mId 006A
rxType 1
Io:
newChn +2FF0E2,00,00,00
prefIO
rxt 0
vccu
p:
2FF0E2
00
00
00
Mrssi:
mNo
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
prs 1
Attributes:
IODev HMLAN1
autoReadReg 4_reqStatus
devStateIcon on:shutter_open off:shutter_closed 1\d.*:fts_shutter_90 2\d.*:fts_shutter_80 3\d.*:fts_shutter_70 4\d.*:fts_shutter_60 5\d.*:fts_shutter_50 6\d.*:fts_shutter_40 7\d.*:fts_shutter_30 8\d.*:fts_shutter_20 9\d.*:fts_shutter_10 \d.*:fts_shutter_90
expert 2_full
firmware 2.3
fp_home 728,228,0,
group Rollos
model HM-LC-Bl1PBU-FM
peerIDs 00000000,
room Hobby,xRollos
serialNr LEQ1021420
subType blindActuator
webCmd statusRequest:on:90:80:70:60:50:40:30:20:10:off:stop
Von Strom trennen habe ich noch nicht gemacht, aber ich habe das Gefühl, dass der Aktor nicht mehr will.
das reading R-pairCentral=set_0x000000 laesst vermuten, dass dein versuch mit set unpair erfolgreich war, denn die neueste message ging an broadcast. das nennt man wohl "verschlimmbesserung".
also pairen. am besten ueber die seriennummer.
rawmessages werden im wiki homematic sniffen beschrieben.
Zitat von: frank am 23 August 2015, 13:03:39
das reading R-pairCentral=set_0x000000 laesst vermuten, dass dein versuch mit set unpair erfolgreich war, denn die neueste message ging an broadcast. das nennt man wohl "verschlimmbesserung".
In der Tat ;) das war mir noch gar nicht aufgefallen.
Jetzt habe ich mal den Strom abgeklemmt, angeklemmt und neu gepaired (über den Config-Button am Schalter). Er ist jetzt sichtbar und vermisst keinen ACK mehr. Mal beobachten, wie lange es so bleibt.
Vielen Dank für Eure Hilfe!
Zitat von: frank am 23 August 2015, 13:03:39rawmessages werden im wiki homematic sniffen beschrieben.
Danke, gucke ich mir dann dort an.
ZitatJetzt habe ich mal den Strom abgeklemmt, angeklemmt und neu gepaired (über den Config-Button am Schalter).
ein einfaches "set hmPairSerial", ohne ausbau ..., bequem vom sessel, hätte gereicht. ;D
selbst schuld, denn frank schrieb extra, um dir das zu ersparen:
Zitatalso pairen. am besten ueber die seriennummer.
ZitatEr ist jetzt sichtbar
war er das nicht vorhin auch schon? ich vermute, du hast unnötigerweise auch noch das device deleted.
ZitatMal beobachten, wie lange es so bleibt.
solange, wie du nichts änderst und die vielen hinweise des devices beachtest. zb rssi.
setze autoreadreg=5_missing, dann hilft dir fhem ein wenig mehr.
gruss frank
Zitat von: frank am 23 August 2015, 17:28:27
ein einfaches "set hmPairSerial", ohne ausbau ..., bequem vom sessel, hätte gereicht. ;D
selbst schuld, denn frank schrieb extra, um dir das zu ersparen:
Ich hatte ja schon geschrieben, dass ein unpair und anschließendes neu pairen vorher nichts gebracht hatte.
Es scheint wohl etwas gebracht zu haben, dass ich den Strom zwischendurch komplett aus hatte.
Und soo unbequem war das jetzt auch nicht: Sicherung runter, wieder rauf, Taster-Adapter abziehen, set hmlan hmPairForSec 60, Config Taste drücke, feddig ;)
Zitat von: frank am 23 August 2015, 17:28:27
war er das nicht vorhin auch schon? ich vermute, du hast unnötigerweise auch noch das device deleted.
solange, wie du nichts änderst und die vielen hinweise des devices beachtest. zb rssi.
Sorry, habe ich falsch hingeschrieben. Sichtbar war er vorher auch schon, da hast Du recht. Jetzt ist aber der "state" wieder korrekt sichtbar und er kann angesteuert werden. Deleted habe ich nix, Ihr hattet mir ja geschrieben, dass es nicht viel bringt.
Was jetzt genau die "vielen Hinweise" sind, wäre interessant, bin ja lernwillig.
Der rssi liegt nach Umzug des HMLAN bei -65.
Zitat von: frank am 23 August 2015, 17:28:27
setze autoreadreg=5_missing, dann hilft dir fhem ein wenig mehr.
Ist jetzt auf 5. Mal schauen, was fhem mir jetzt mehr mitteilt.
Mit einem meiner BLS hatte ich ein paar mal ein Problem. Meldet sich nicht mehr, nicht mehr steuerbar. Einmal Sicherung raus,rein fertig. Pairen ist nicht erforderlich.
Leider kenne ich weder den Grund noch eine Methode es remote zu beheben.
Passiert sehr selten.
Ich gebe mal kurz meinen Senf dazu: Vor einigen Wochen flog bei mir der FI-Schalter ´raus, danach ließ sich nur noch die Hälfte aller Rollladenaktoren steuert, allerdings nur sporadisch. Das Problem lag an einem einzelnen Aktor, welcher wohl das ganze Funknetz "voll gespamt" hat. Den entsprechenden Raum einmal per Sicherung "neu gestartet" und es lief wieder alles... hat allerdings ein paar Stunden gedauert, bis ich darauf gekommen bin (dachte schon, mein HM-LAN hätte den Stromausfall nicht überlebt).
Mir ist nach einem Stromausfall schon mal passiert, dass zwei BLs ihre Programmierung komplett vergessen haben und auf Werkseinstellung waren - inkl. AES-Einstellungen (obwohl sie vorher einwandfrei eingebunden waren).
Ich kann das Verhalten, dass nach einer gewollten Unterbrechung der Stromversorgung eines Raums mit zwei Rollladenaktoren HM-LC-Bl1-FM einer seine "Zugehörigkeit" nach Rückkehr der Stromversorgung (Dauer der Unterbrechung ca. 30 Sekunden) vergessen hatte und "Missing ACK" angezeigt wurde. Erneute Kaltstarts brachten keine Besserung, auch nicht die anderen "Sesselhocker-Tipp"s im Thread. Ich musste den Rolladenkasten aufschrauben und den Aktor erneut pairen. Dann klappte alles wie zuvor.
Ist das ein Problem der Aktoren oder von fhem?
Grüße
Martin
Zitat von: martinp876 am 24 August 2015, 20:24:26
Mit einem meiner BLS hatte ich ein paar mal ein Problem. Meldet sich nicht mehr, nicht mehr steuerbar. Einmal Sicherung raus,rein fertig. Pairen ist nicht erforderlich.
Leider kenne ich weder den Grund noch eine Methode es remote zu beheben.
Passiert sehr selten.
Ich habe 13 BL im Einsatz, ich habe aktuell einen der hat das in den letzten Wochen zweimal getan. Und ich habe einen anderen der hat das bisher zweimal getan, einmal als er noch an der CCU1 hing, einmal nachdem ich auf FHEM umgestiegen war. Ist ca. drei Jahre her...
Dieser war der Grund dafür, dass ich die Rolläden beim Umbau meines Hauses vorsorglich auf eine extra Sicherung gelegt habe.
Gruß Otto
Hey zusammen,
ich stehe nun vor einem sehr ähnlichen Problem. Ich empfange alle Werte in FHEM instant aber wenn ich per FHEM Befehle absetze, bekomme ich nach wenigen Sekunden ein "MISSING ACK". D.h. der Empfang geht aber meine gesendeten Commands nimmt er nicht. Mein RSSI steht bei -52 und auch ein Repeater daneben verbessert nichts an der Lage (Peerlist meldet OK).
Nun könnte man denken er ist kaputt, aber der Schalter daneben (HM-LC-SW2-FM) quittiert mir die Commands ebenfalls mit "MISSNG ACK" oder "RESPONSE TIMEOUT:RegisterRead". Das wäre schon Zufall, ein HM-PB-2-WM55-2 geht problemlos.
Eine Stromtrennung hat leider auch nicht die gewünschte Hilfe gebracht :(
Hat irgend jemand noch eine Idee?
ciao Carlo
Hi,
zeig doch mal bitte ein list von beiden Geräten.
Gruß Otto
Hey Otto, klasse danke, dass du mitkämpfst :) Ich hab den Repeater mal wieder rausgenommen um eine Fehlerquelle auszuschließen:
Internals:
DEF 277D5D
IODev HMLAN1
NAME GaesteRollo
NOTIFYDEV global
NR 763
STATE MISSING ACK
TYPE CUL_HM
protCmdDel 6
protResnd 12 last_at:2017-02-11 14:19:14
protResndFail 4 last_at:2017-02-11 14:19:20
protSnd 4 last_at:2017-02-11 14:19:00
protState CMDs_done_Errors:1
Readings:
2017-02-06 01:14:02 D-firmware 1.7
2017-02-06 01:14:02 D-serialNr LEQ0199813
2017-02-11 13:56:37 R-pairCentral set_0x000000
2017-02-11 13:59:33 deviceMsg 91 (to broadcast)
2017-02-11 14:19:00 level set_90
2017-02-11 13:59:33 motor stop:91
2017-02-11 13:59:33 pct 91
2017-02-11 13:30:25 powerOn 2017-02-11 13:30:25
2017-02-11 13:59:33 recentStateType info
2017-02-11 14:19:20 state MISSING ACK
2017-02-11 13:59:33 timedOn off
Regl_00.:
VAL
Helper:
HM_CMDNR 5
cSnd 112B0B1C277D5D0201C8,112B0B1C277D5D0201B4
dlvlCmd ++A0112B0B1C277D5D0201B4
getCfgList all
getCfgListNo ,3
mId 0005
rxType 1
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +277D5D,00,00,00
prefIO
rxt 0
vccu
p:
277D5D
00
00
00
Mrssi:
mNo
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
prs 1
Attributes:
IODev HMLAN1
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.7
genericDeviceType blind
group Rollo
icon fts_shutter_90
model HM-LC-BL1-FM
peerIDs 00000000,
room EG,Gaeste
serialNr LEQ0199813
subType blindActuator
webCmd statusRequest:toggleDir:on:off:up:down:stop
Das Teil ist nicht mit FHEM gepaired:
2017-02-11 13:56:37 R-pairCentral set_0x000000
Gruß,
Stephan
Oh man :o - Wald Bäume... kennt ihr das? DAAAANKE! Jetzt stehen 3 HM-Sys-sRP-PI zum Verkauf ;)
Danke Stephan und Otto!
ciao Carlo
Zitat von: Calle78 am 11 Februar 2017, 15:03:00
Jetzt stehen 3 HM-Sys-sRP-PI zum Verkauf ;)
Hi Carlo, ich habe auch noch einen Original nicht zusammengebaut in der Kiste. Kam nie zum Einsatz.
Gruß Otto
Meine HM Tuerkontakte pairen sich nicth, Weder über set pair noch dden Weg über die Pairingtaste. Es erscheint immer R-pairCentral set_0x000000.
Was könnte ich noch tun ?
Clear msgevents
Dann noch einmal pairen.
Nicht zu nahe an das io legen. Min 1m Abstand
Ich habe clear readings gemacht und dann auf pairforsec und den Anlernknopf gedrückt. Hat aber nichts genutzt. Led hat zwar geblinkt aber in fhem selber hat sich nichts getan.
Moin en-trust,
so halbe Sätze und halbe Worte stiften nur Verwirrung.
Wie man einen gelösten Thread für den Jalousieaktor für Fensterkontakte kapern kann? :'(
Mach am Besten clear all
Dann Batterie raus.
Batterie wieder rein.
set <VCCU oder IO> hmPairForSec 120
configKnopf drücken und dabei nicht den Sensor auslösen
Die LED muss dabei hektisch und nicht gleichmäßig blinken.
Wenn die Datenübertragung abgeschlossen ist (grüne LED zum Schluss) und noch nicht alle Daten da sind, aber CMDs pending da steht ->
configKnopf drücken und dabei nicht den Sensor auslösen
Wenn die Datenübertragung abgeschlossen ist (grüne LED zum Schluss) und noch nicht alle Daten da sind, und nicht mehr CMDs pending da steht ->
set <Fensterkontakt> getConfig
configKnopf drücken und dabei nicht den Sensor auslösen
Die LED muss dabei hektisch und nicht gleichmäßig blinken.
Gruß Otto
Kein grün. Nur gleichmäßiges oranges Blinken.
Sorry, ich bin raus. Ich habe keine Lust in 3 unterschiedlichen Threads über das gleiche Problem aus halben Sätzen irgendetwas heraus zu raten.
Tschüss Otto
Ich verstehe Deine Reaktion nicht. Sorry das ich die Frage öfters gestellt habe. Aber wie oft werden hier Fragen doppelt gestellt und bleiben dennoch unbeantwortet.
Ich wollte nur sagen, dass dieses Pairing Verfahren bei beiden HM's nicth funktioniert. Die LED leuchtet gleichbleibend orange und am Ende rot.
Habe das alles so gemacth. Aber beim configButton erfolgt dann erst oranges Blinken und dann rot. Egal wie oft ich das mache.
Mach am Besten clear all
Dann Batterie raus.
Batterie wieder rein.
set <VCCU oder IO> hmPairForSec 120
configKnopf drücken und dabei nicht den Sensor auslösen
Die LED muss dabei hektisch und nicht gleichmäßig blinken.
Wenn die Datenübertragung abgeschlossen ist (grüne LED zum Schluss) und noch nicht alle Daten da sind, aber CMDs pending da steht ->
configKnopf drücken und dabei nicht den Sensor auslösen
Wenn die Datenübertragung abgeschlossen ist (grüne LED zum Schluss) und noch nicht alle Daten da sind, und nicht mehr CMDs pending da steht ->
set <Fensterkontakt> getConfig
configKnopf drücken und dabei nicht den Sensor auslösen
Die LED muss dabei hektisch und nicht gleichmäßig blinken.