Hallo zusammen,
ich habe ein HM-CC-RT-DN und ein HM-SEC-RHS.
Beide Komponenten sollen sowohl mit der Zentrale (FHEM auf FB über CUL) als auch direkt miteinander kommunizieren können.
Leider meldet der RHS nach jedem Senden einen Fehler (langes orange endet in kurzem rot).
Trotz der Meldung erkennt das RT-DN den Wechsel und geht entsprechend in der Fenster auf/zu Modus.
Da ich die Gerätekonstallation in verschiedenen Räumen habe und auch vorher schon so meine Pair/Peer Probleme hatte, habe ich hier in verschiedenen Räumen verschiedene Wege ausprobiert (A und B), wobei beide zum selben Ergebnis führen:
A. Direktkommunikation vor Zentrale
- RHS - Anlerntaste
RT-DN - Anlerntaste
ok - FHEM - hmPairForSec
RT-DN - Anlerntaste
ok - FHEM - hmPairForSec
RHS - Anlerntaste
ok
B. Direktkommunikation nach Zentrale
- FHEM - hmPairForSec
RT-DN - Anlerntaste
ok - FHEM - hmPairForSec
RHS - Anlerntaste
ok - FHEM - PeerChan set RHS peerChan 0 RT-DN_WindowRec single
RHS - Anlerntaste (zum Verarbeiten der pending CMDs)
RT-DN - Anlerntaste (zum Verarbeiten der pending CMDs)
ok
Beides endet im beschriebenen Problem :-\
Die Readings des RHS verraten:
PairedTo 0xF11034 (CUL?)
R-pairCentral 0xF11034 (CUL?)
peerList RT-DN_WindowRecDie Readings des RT-DN verraten:
PairedTo 0xF11034 (CUL?)
R-pairCentral 0xF11034 (CUL?)Die Readings des RT-DN_WindowRec verraten:
peerList RHSDie Readings sehen für mich schlüssig aus und auch die generelle Logik (alle Geräte mit der Zentrale pairen, zudem die Geräte miteinander peeren).
Ich hab das Gefühl, dass der RHS auf ein ACK von der Zentrale wartet (warum auch immer), was er nicht bekommt...
Es funktioniert übrigens (kurzes orange endet in kurzem grün bei jedem Senden des RHS), wenn ich im Falle A den Schritt 3 entfallen lasse.
Somit ist der RHS allerdings nur mit dem RT-DN gepeert (von dem er scheinbar ein ACK bekommt), nicht aber mit der Zentrale gepairt :-\
Mache ich etwas falsch, übersehe ich etwas, hab ich was völlig falsch verstanden?
Grüße,
snx
das kurze orange zeigt, dass die Aktion gestartet wurde und auf ein Ergebnis gewartet wird. Danach kommt rot, grün oder auch Gelb (falls nichts zu tun war).
Mir scheint, dass der RHS die Zentrale informieren will, diese aber nicht antwortet.
Kannst du einmal die rohmessages loggen? Du nutzt HMLAN oder CUL?
Ich nutze einen CUL.
Die Farben sind mir schon klar, ist mein Grundverständnis (im oberen Post) denn in Ordnung?
Hier mal meine Logs...
Ich habe einen RT-DN und einen RHS mit der Zentrale gepairt:
Zentrale: F11034
RHS: 238E8F > MG.BZ.FT
RT-DN: 24041B > MG.BZ.HT
Bevor ich die beiden peere, sieht eine RHS-Änderung wiefolgt aus:
2014.04.09 18:03:42 5: CUL/RAW: /A0C06A441238E8FF110340106642C
2014.04.09 18:03:42 4: CUL_Parse: cul A 0C 06 A441 238E8F F11034 0106642C -52
2014.04.09 18:03:42 5: cul dispatch A0C06A441238E8FF11034010664::-52:cul
2014.04.09 18:03:42 5: cul sending As0D068002F11034238E8F0101C800
2014.04.09 18:03:42 5: CUL 238E8F dly:87ms
2014.04.09 18:03:42 5: Triggering MG.BZ.FT (2 changes)
2014.04.09 18:03:42 5: Notify loop for MG.BZ.FT tilted
2014.04.09 18:03:42 4: CUL_send: culAs 0D 06 8002 F11034 238E8F 0101C800
Nachdem ich beide mittels
set MG.BZ.FT peerChan 0 MG.BZ.HT_WindowRec single
gepeert habe, ergibt sich folgendes bei einer RHS-Änderung:
2014.04.09 18:09:33 5: CUL/RAW: /A0C09A441238E8FF1103401090025
2014.04.09 18:09:33 4: CUL_Parse: cul A 0C 09 A441 238E8F F11034 01090025 -55.5
2014.04.09 18:09:33 5: cul dispatch A0C09A441238E8FF11034010900::-55.5:cul
2014.04.09 18:09:33 5: cul sending As0D098002F11034238E8F0101C800
2014.04.09 18:09:33 5: CUL 238E8F dly:85ms
2014.04.09 18:09:33 5: Triggering MG.BZ.FT (2 changes)
2014.04.09 18:09:33 5: Notify loop for MG.BZ.FT closed
2014.04.09 18:09:33 5: Triggering MG.BZ.HT_WindowRec (2 changes)
2014.04.09 18:09:33 5: Notify loop for MG.BZ.HT_WindowRec trig_MG.BZ.FT: closed
2014.04.09 18:09:33 4: CUL_send: culAs 0D 09 8002 F11034 238E8F 0101C800
2014.04.09 18:09:34 5: CUL/RAW: /A0C0AB041238E8F24041B01090022
2014.04.09 18:09:34 4: CUL_Parse: cul A 0C 0A B041 238E8F 24041B 01090022 -57
2014.04.09 18:09:34 5: cul dispatch A0C0AB041238E8F24041B010900::-57:cul
2014.04.09 18:09:34 5: Triggering MG.BZ.FT (2 changes)
2014.04.09 18:09:34 5: Notify loop for MG.BZ.FT closed
2014.04.09 18:09:34 5: Triggering MG.BZ.HT_WindowRec (2 changes)
2014.04.09 18:09:34 5: Notify loop for MG.BZ.HT_WindowRec trig_MG.BZ.FT: closed
2014.04.09 18:09:34 5: CUL/RAW: /A0A0A800224041B238E8F0010
A0C09A041238E8FF1103401090017
2014.04.09 18:09:34 4: CUL_Parse: cul A 0A 0A 8002 24041B 238E8F 0010 -66
2014.04.09 18:09:34 5: cul dispatch A0A0A800224041B238E8F00::-66:cul
2014.04.09 18:09:34 4: CUL_Parse: cul A 0C 09 A041 238E8F F11034 01090017 -62.5
2014.04.09 18:09:34 5: cul dispatch A0C09A041238E8FF11034010900::-62.5:cul
2014.04.09 18:09:34 5: cul sending As0D098002F11034238E8F0101C800
2014.04.09 18:09:34 5: CUL 238E8F dly:84ms
2014.04.09 18:09:34 5: Triggering MG.BZ.FT (2 changes)
2014.04.09 18:09:34 5: Notify loop for MG.BZ.FT closed
2014.04.09 18:09:34 5: Triggering MG.BZ.HT_WindowRec (2 changes)
2014.04.09 18:09:34 5: Notify loop for MG.BZ.HT_WindowRec trig_MG.BZ.FT: closed
2014.04.09 18:09:34 4: CUL_send: culAs 0D 09 8002 F11034 238E8F 0101C800
2014.04.09 18:09:34 5: CUL/RAW: /A0C09A041238E8FF1103401090013
2014.04.09 18:09:34 4: CUL_Parse: cul A 0C 09 A041 238E8F F11034 01090013 -64.5
2014.04.09 18:09:34 5: cul dispatch A0C09A041238E8FF11034010900::-64.5:cul
2014.04.09 18:09:34 4: CUL_HM MG.BZ.FT dup: dont process
2014.04.09 18:09:36 5: CUL/RAW: /A0C09A041238E8FF1103401090012
2014.04.09 18:09:36 4: CUL_Parse: cul A 0C 09 A041 238E8F F11034 01090012 -65
2014.04.09 18:09:36 5: cul dispatch A0C09A041238E8FF11034010900::-65:cul
2014.04.09 18:09:36 4: CUL_HM MG.BZ.FT dup: dont process
2014.04.09 18:09:38 5: CUL/RAW: /A0C09A041238E8FF11034010900F8
2014.04.09 18:09:38 4: CUL_Parse: cul A 0C 09 A041 238E8F F11034 010900F8 -78
2014.04.09 18:09:38 5: cul dispatch A0C09A041238E8FF11034010900::-78:cul
2014.04.09 18:09:38 4: CUL_HM MG.BZ.FT dup: dont process
2014.04.09 18:09:42 5: CUL/RAW: /A0C09A041238E8FF1103401090007
2014.04.09 18:09:42 4: CUL_Parse: cul A 0C 09 A041 238E8F F11034 01090007 -70.5
2014.04.09 18:09:42 5: cul dispatch A0C09A041238E8FF11034010900::-70.5:cul
2014.04.09 18:09:42 4: CUL_HM MG.BZ.FT dup: dont process
tausche einmal die Zeile 1908
push @ack,$shash,$mNo."8002".$dst.$src."0101".(($recChn&1)?"C8":"00")."00";
gegen
push @ack,$shash,$mNo."8002".$dst.$src."00";
und berichte.
Ich bin jetzt erst zum Testen gekommen, aber nach der Änderung sieht es gut aus...
Ich hab zwar das Gefühl, dass es recht lange dauert (orange für ca. 4 sek), aber es gibt in jedem Fall ein grünes Ende ;)
die 4 sec sind nicht sinnvoll.Evtl kannst du noch einmal loggen.
Ich werden das wohl als default einbauen - dass hier ein "Wert" gemeldet wurde ist schon uralt - ich habe keinen Anhaltspunkt, dass dies notwendig ist.
Ich warte noch deine Logs ab
Musste feststellen, dass der ein oder andere doch noch auf einen Fehler läuft (gefühlt immer der erste Versuch, nach längerer Pause, danach dann immer die 4s grün). Hier der Auszug der auf grün endenden Aktionen:
2014.04.12 23:23:51 5: CUL/RAW: /A0C14A441238E8FF11034010EC81C
2014.04.12 23:23:51 4: CUL_Parse: cul A 0C 14 A441 238E8F F11034 010EC81C -60
2014.04.12 23:23:51 5: cul dispatch A0C14A441238E8FF11034010EC8::-60:cul
2014.04.12 23:23:51 5: CUL_HM MG.BZ.FT prep ACK for 1
2014.04.12 23:23:51 5: cul sending As0A148002F11034238E8F00
2014.04.12 23:23:51 5: CUL 238E8F dly:86ms
2014.04.12 23:23:51 4: CUL_send: culAs 0A 14 8002 F11034 238E8F 00
2014.04.12 23:23:51 5: CUL_HM MG.BZ.FT protEvent:CMDs_done
2014.04.12 23:23:51 5: CUL_HM MG.BZ.FT sent ACK:2
2014.04.12 23:23:52 5: Triggering MG.BZ.FT (2 changes)
2014.04.12 23:23:52 5: Notify loop for MG.BZ.FT open
2014.04.12 23:23:52 5: Triggering MG.BZ.HT_WindowRec (2 changes)
2014.04.12 23:23:52 5: Notify loop for MG.BZ.HT_WindowRec trig_MG.BZ.FT: open
2014.04.12 23:23:52 5: CUL/RAW: /A0C15B041238E8F24041B010EC816
2014.04.12 23:23:52 4: CUL_Parse: cul A 0C 15 B041 238E8F 24041B 010EC816 -63
2014.04.12 23:23:52 5: cul dispatch A0C15B041238E8F24041B010EC8::-63:cul
2014.04.12 23:23:52 5: Triggering MG.BZ.FT (2 changes)
2014.04.12 23:23:52 5: Notify loop for MG.BZ.FT open 2014.04.12 23:23:52 5: Triggering MG.BZ.HT_WindowRec (2 changes)
2014.04.12 23:23:52 5: Notify loop for MG.BZ.HT_WindowRec trig_MG.BZ.FT: open
2014.04.12 23:23:52 5: CUL/RAW: /A0A15800224041B238E8F002D
2014.04.12 23:23:52 4: CUL_Parse: cul A 0A 15 8002 24041B 238E8F 002D -51.5
2014.04.12 23:23:52 5: cul dispatch A0A15800224041B238E8F00::-51.5:cul
wenn du verbose 4 nimmst, anstatt 5 kannst du die Logs auf sinnvolle Inhalte eingrenzen
2014.04.12 23:23:51 4: CUL_Parse: cul A 0C 14 A441 238E8F F11034 010EC8
2014.04.12 23:23:51 4: CUL_send: culAs 0A 14 8002 F11034 238E8F 00
2014.04.12 23:23:52 4: CUL_Parse: cul A 0C 15 B041 238E8F 24041B 010EC8
2014.04.12 23:23:52 4: CUL_Parse: cul A 0A 15 8002 24041B 238E8F 00
alles prime. Der 238E8F triggert 2 IDs, beide antworten, alles ok.
Wenn du einen mit rot hast kann ich den einmal ansehen.
Also es sieht so aus, als wenn nicht die Zentrale, sondern die RT-DNs die seltenen negative Ergebnisse verursachen.
Ich habs mit verschiedenen Devices getestet, eigentlich immer gabs, die ordentlichen 4er Päckchen:
2014.04.14 18:42:41 4: CUL_Parse: cul A 0C 18 A441 238E8F F11034 0110C81E -59
2014.04.14 18:42:41 4: CUL_send: culAs 0A 18 8002 F11034 238E8F 00
2014.04.14 18:42:41 4: CUL_Parse: cul A 0C 19 B041 238E8F 24041B 0110C81D -59.5
2014.04.14 18:42:42 4: CUL_Parse: cul A 0A 19 8002 24041B 238E8F 0029 -53.5
2014.04.14 18:42:48 4: CUL_Parse: cul A 0C 15 A441 238F25 F11034 010CC811 -65.5
2014.04.14 18:42:49 4: CUL_send: culAs 0A 15 8002 F11034 238F25 00
2014.04.14 18:42:49 4: CUL_Parse: cul A 0C 16 B041 238F25 2403A4 010CC80D -67.5
2014.04.14 18:42:49 4: CUL_Parse: cul A 0A 16 8002 2403A4 238F25 0039 -45.5
Lediglich bei einem trat der Fehler auf, wobei die Zentralenoch ordentlich ACKed...
2014.04.14 18:42:55 4: CUL_Parse: cul A 0C 47 A441 238DD1 F11034 0128C827 -54.5
2014.04.14 18:42:55 4: CUL_send: culAs 0A 47 8002 F11034 238DD1 00
2014.04.14 18:42:56 4: CUL_Parse: cul A 0C 48 B041 238DD1 2403F1 0128C828 -54
2014.04.14 18:42:57 4: CUL_Parse: cul A 0C 48 B041 238DD1 2403F1 0128C828 -54
2014.04.14 18:42:57 4: CUL_HM EG.K.FT dupe: dont process
2014.04.14 18:42:58 4: CUL_Parse: cul A 0C 48 B041 238DD1 2403F1 0128C828 -54
2014.04.14 18:42:58 4: CUL_HM EG.K.FT dupe: dont process
2014.04.14 18:43:00 4: CUL_Parse: cul A 0C 48 B041 238DD1 2403F1 0128C828 -54
2014.04.14 18:43:00 4: CUL_HM EG.K.FT dupe: dont process
2014.04.14 18:43:03 4: CUL_Parse: cul A 0C 48 B041 238DD1 2403F1 0128C828 -54
2014.04.14 18:43:03 4: CUL_HM EG.K.FT dupe: dont process
2014.04.14 18:43:07 4: CUL_Parse: cul A 0C 48 B041 238DD1 2403F1 0128C827 -54.5
2014.04.14 18:43:07 4: CUL_HM EG.K.FT dupe: dont process
Die darauffolgenden versuche endeten dann immer wieder grün (bei allen devices) :-/
Demnach würde ich sagen, die Codeanpassung ist generell korrekt und funktioniert.
Hast du denn eine Idee was die Ursache für den Fall hier sein könnte? (Ich hab leider nicht nachgesehen, ob der RT-DN in den WindowOpen-Modus gegangen ist).
Also da kann ich nichts machen. Der RT ist einfach nicht aufgewacht - FHEM ist sauber.
Warum der nicht antwortet... überlast? Tiefschlaf, Funkstörung?.
Hast du RSSI werte vom Schalter zum Aktor? Was sagt die RSSI tabelle?
die beiden rot markierten, sind der RHS (FT) und der RT-DN (HT):
rssi done:
Device :receive from last avg min<max count
EG.EZ.FT :cul EG.EZ.FT -69.0 -57.0 -80.0< -47.5 89
EG.EZ.SA :EG.EZ.SA EG.WZ.WT -55.0 -55.9 -68.0< -48.0 255
EG.EZ.SA :cul EG.EZ.SA -47.0 -46.5 -65.0< -44.5 267
EG.K.FT :cul EG.K.FT -51.0 -53.7 -54.5< -51.0 9
EG.K.HT :cul EG.K.HT -51.5 -53.2 -68.0< -49.5 1638
EG.WZ.FTk :cul EG.WZ.FTk -87.0 -83.3 -95.0< -71.5 31
EG.WZ.SAk :EG.WZ.SAk EG.WZ.WT -64.0 -61.9 -84.0< -56.0 682
EG.WZ.SAk :EG.WZ.SAk living.temp -60.0 -60.3 -62.0< -60.0 6
EG.WZ.SAk :cul EG.WZ.SAk -83.0 -61.1 -99.0< -43.0 699
EG.WZ.SAs :EG.WZ.SAs EG.WZ.WT -58.0 -55.7 -67.0< -51.0 680
EG.WZ.SAs :EG.WZ.SAs living.temp -57.0 -57.0 -57.0< -57.0 5
EG.WZ.SAs :cul EG.WZ.SAs -64.5 -60.2 -72.0< -48.5 697
EG.WZ.WT :EG.WZ.WT cul -58.0 -54.4 -58.0< -50.0 39
EG.WZ.WT :cul EG.WZ.WT -61.0 -57.2 -80.5< -48.0 3465
KG.F.HT :cul KG.F.HT -66.0 -57.3 -81.5< -47.5 1681
KG.HK.SDzp :KG.HK.SDzp cul -51.0 -51.6 -56.0< -49.0 68
KG.HK.SDzp :cul KG.HK.SDzp -50.5 -51.6 -55.5< -48.5 136
MG.BZ.FT :cul MG.BZ.FT -63.0 -58.2 -72.5< -46.0 39
MG.BZ.HT :cul MG.BZ.HT -54.0 -52.6 -69.0< -46.5 1645
MG.GZ.RS :MG.GZ.RS cul -46.0 -48.2 -50.0< -46.0 10
MG.GZ.RS :cul MG.GZ.RS -45.5 -48.0 -51.5< -45.5 16
OG.BZ.HT :cul OG.BZ.HT -49.5 -49.5 -59.5< -45.0 1657
OG.SZ.FT :cul OG.SZ.FT -61.0 -63.9 -67.5< -61.0 4
OG.SZ.HT :cul OG.SZ.HT -47.5 -45.0 -51.5< -41.5 1645
OG.SZ.LS :OG.SZ.LS cul -62.0 -65.2 -69.0< -62.0 17
OG.SZ.LS :cul OG.SZ.LS -63.5 -65.3 -69.0< -63.0 28
schade - keine Wert für EG.K.FT nach EG.K.HT oder umgekehrt ausgewertet
Ich werds mal weiter beobachten...
Gibts da Anhaltspunkte welche Werte gut bzw. schlecht sind?
Ich denke mal die -80, -90 die ich an einigen Stellen habe sind schon nicht prickelnd, aber genau mit den beiden gibts gar keine Probleme.
leider nein.
Zum einen habe ich keine Infos über die Qualität der Messungen, und schon gar keine über die Störungen um Umfeld.
Ich würde behaupten, dass es eine reine Feldstärkenmessung ist - das keinen signal-rauschabstand berücksichtigt. Auf solch fehlende Daten führe ich die Diskrepanz zwischen gutem RSSI aber schlechtem Empfang zurück. Dei primäre Qualität des einzelnen Empfängers kann man an dessen Empfangsleistung erkennen - das kann also nicht das Problem sein
noch eine Frage, woher weiß ich ab wann ich wieder updaten kann ohne das meine Anpassung in der 10_CUL_HM.pm verloren geht?
Also ab wann ist die Korrektur auch darin enthalten (bei einem fhem update)?
jetzt