Tür-/Fensterkontakt HM-SEC-SCo liefert falschen Status

plin · 19 Februar 2016, 20:28:23

Hallo Christoph,

welche Firmware-Version ist das? Ich habe 1.62 ist das anscheinend die aktuelle?

~~Hast du ein Reading namens "R-pairCentral"? Dort steht bei den Reed-Devices die HMid meines FHEM drin. Bei den optical Devices fehlt dieses Reading.~~

Die Frage habe ich mir gerade selbst beantwortet. Nach einen unpair und erneuten pair wird wir jetzt meine HMid angezeigt. Doppelt gepaired hält besser???

Viele Grüße
Peter

Bennemannc · 19 Februar 2016, 22:10:14

Hallo Peter,

ich habe die FW 1.0 drauf. Wenn das pairing nicht stimmt, wiederholt der Sensor (Fensterkontakt) das Senden nicht - wenn das pairung stimmt, wird auf ein ack von der Zentrale gewartet und wenn das nicht kommt, wird bis zu x Mal (normalerweise 3 mal) wiederholt.

Gruß Christoph

Otto123 · 19 Februar 2016, 22:43:35

Hallo Christoph,

also wenn ich alles richtig gelernt habe, hat das nichts mit dem pairing sondern dem peering zu tun. Wenn das Gerät mit einem anderen gepeert ist und kein ack bekommt versucht er es drei mal. Ansonsten sendet er einfach einen Befehl. Das pairing mit der Zentrale spielt dabei keine Rolle.
Aber vielleicht liege ich auch falsch.

Gruß Otto

Bennemannc · 19 Februar 2016, 23:02:45

Hallo Otto,

Zitat2016.02.17 18:36:11 4: CUL_Parse: CUL_0 A 0C 62 8641 3C8C72 000000 012C00DC -92
2016.02.17 18:36:11 4: CUL_send: CUL_0As 09 02 A112 F13744 3C8C72

Ist das CUL_send kein ack ? So wirklich entschlüsseln kann ich das nicht - das erste ist 3C8C72 an Broadcast 000000 - das send ist F13744 (Zentrale ?) and 3C8C72 - daraus habe ich interpretiert das es ein ack sein könnte.

Gruß Christoph

LuckyDay · 19 Februar 2016, 23:32:41

A112 F13744 3C8C72

A112 heißt , zentrale möchte in den Aktor neue Daten schreiben , und soll nicht einschlafen, der Aktor muß mit 00 Quittieren,
dass er bereit ist, wahrscheinlich waren da noch Kommandos auf pending

plin · 20 Februar 2016, 09:27:19

Hallo Leute,

ja, bei meinen Kontakten sehe ich viele CMDs_Pending.

Mir ist aber auch das Reading trigDst_F13744 bzw. trigDst_broadcast aufgefallen. Mittlerweile senden 4 meiner 15 Kontakte an CUL_0, die anderen immer noch an broadcast. Wie kann ich das ändern?

VG Peter

Bennemannc · 20 Februar 2016, 09:57:28

Hallo Peter,

Knopf am Kontakt kurz drücken - wie beim pairen - dann fragt er bei der Zentrale an, obenes was für ihn gibt. Eventuell mus der Vorgang mehrfach wiederholt werden, weil beim ersten mal nicht umbedingt alles übertragen wird.

Gruß Christoph

plin · 20 Februar 2016, 11:30:28

Hallo Christoph,

mein aktueller Verdacht: Ich habe gestern erst die AES-Lib installiert. Heute Morgen habe ich ein Device neu gepaired und das meldet jetzt an CUL_0. Werde später die anderen auch noch mal neu pairen.

VG Peter

LuckyDay · 20 Februar 2016, 12:37:48

ZitatAES-Lib installiert

das ist grundvoraussetzung für CUL und AES
da die HM-SEC-SCo nur so pairen kannst

plin · 21 Februar 2016, 15:28:19

Hallo zusammen,

ich nähere mich dem Ziel, es gibt nur noch wenige MISSING ACKs der am weitesten entfernten Devices. Für alle die vergleichbare Probleme haben und bei diesem Thread landen sind vielleicht folgenden Informationen hilfreich:

schaut Euch den aktuellen Stand des Wiki-Artikels http://www.fhemwiki.de/wiki/HM-SEC-SCo_T%C3%BCr-Fensterkontakt,_optisch an, der beinhaltet nun auch Angaben zu AES
Wenn ihr eine ältere FHEM-Installation habt, dann denkt mal an eine http://www.fhemwiki.de/wiki/Homematic-fhem.cfg-Neuinstallation nach dem aktuellsten Stand der Dinge. Dort wird der CUL z.B. mit 38400 Baud statt 9600 angegeben.
Verfolgt das Thema VCCU (http://www.fhemwiki.de/wiki/Virtueller_Controller_VCCU). Dort wird erklärt wie man die Reichweite erweitern. Ich werden meine primäre FHEM-Instanz weiterhin mit dem CUL betreiben aber die Kontrolle über den HMLAN von der zweiten auf die primäre FHEM-Instanz umziehen. Die Devices können dann den jeweils am güntigsten platzierten Adapter nehmen.

VG Peter

plin · 22 Februar 2016, 16:45:45

Hi,

der letzte Kontakt bleibt hartnäckig. Von meinem FHEM-Server aus ist er nur über den Repeater mit brauchbarer Qualität zu erreichen

rssi_at_CUL_0 avg:-93.37 cnt:8 min:-98.5 max:-90 lst:-90.5
rssi_at_rpt_CUL_0 min:-53.5 cnt:1 avg:-53.5 lst:-53.5 max:-53.5

Aber er mag sich nicht mit meiner VCCU pairen, er sendet immer noch an broadcast. Folglich meldet er wieder MISSING ACKs.

Wie schaut das bei verschlüsselten Verbindungen in Kombination mit einem Repeater aus? Gibt es da irgend etwas zu beachten?

VG Peter

plin · 22 Februar 2016, 21:20:24

Es ist vollbracht (never give up),

RasPi ins Erdgeschoss gebracht, so aufgestellt, dass die Antenne frei in Richtung Sensor abstrahlen kann. Viele viele Versuche (unpair, HW reset, pair ...) und letztendlich ist er gegen die HMid gepaired und AES meldet ok.

RasPi wieder in die Hausmitte gebracht, gestartet. Erstes öffnen/schließen des Fenster führte noch zu rotem Blinken, zweiter Durchgang zu "grün". rssi via Repeater liegt jetzt im 50er Bereich.

VG Peter