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

plin · 15 Februar 2016, 21:39:13

Hallo zusammen,

habe mittlerweile an die 10 HM-SEC-SCo im Einsatz die ich über einen CUL angebunden habe. Hin und wieder kriege ich MISSING ACK oder einen falschen Status gemeldet (z.B. open obwohl die Tür zu ist).

Wie kann ich den HM-SEC-SCo dazu bringen den Zustand noch mal zu prüfen und zu senden?

VG Peter

Bennemannc · 15 Februar 2016, 23:11:38

Hallo,

das sollte der eigentlich selber machen - bis zu dreinmal senden wenn kein ack (Daten erhalten) kommt. Was sagen denn die rssi Werte von den Sensoren die Probleme machen ? Bis 80 ist ok - alles darüber ist Lotterie. Welche Firmware ist auf dem CUL - es gibt da eine angepasste, die ein besseres Timing hat - vielleicht kommt das ack zu spät.

Gruß Christoph

plin · 16 Februar 2016, 18:00:56

Hallo Christoph,

mein CUL hat die Version V 1.62 CUL868 und weist selbst ein RSSI von -58.5 aus.

Die Tür-/Fensterkontakte sind im Haus verteilt. Das Logging der rssi-Werte habe ich gerade erst wieder eingeschaltet. Der schlechteste Wert liegt bei -86.5.

Mittlerweile habe ich einen Repeater angeschafft den ich u.U. zuhilfe nehmen kann. Gestern ist es mir aber das erste Mal passiert, dass 5 Kontakte gleichzeitig ein MISSING ACK melden

VG Peter

P.S. Mein CUL hat eine aufgewickelte Lambda/4-Antenne.

frank · 16 Februar 2016, 19:21:27

könnte es sein, dass dein fhem manchmal "hängt"? muss der cul auch andere protokolle bedienen? schon mal mit perfmon oder apptime kontrolliert?

plin · 16 Februar 2016, 19:54:58

Zitat von: frank am 16 Februar 2016, 19:21:27
könnte es sein, dass dein fhem manchmal "hängt"? muss der cul auch andere protokolle bedienen? schon mal mit perfmon oder apptime kontrolliert?

Ich habe mein FHEM bereits von einem RasPi auf einen BananaPi umgezogen weil der performanter ist.

Ein zweite Instanz auf meinem Server übernimmt die IP-basierten Module, die hält dem BananaPi den Rücken frei damit der sich auf das CUL-Geschäft konzentrieren kann.

Mit perfmon oder apptime habe ich noch nicht rumgespielt (da ich hier bisher kein Problem gesehen habe). htop zeigt mir eine CPU-Auslastung der beiden Cores von <5%, selten drüber.

VG Peter

frank · 16 Februar 2016, 20:45:32

es geht nicht um leistung. sondern eher wie ein perl-sleep, sodass fhem hängt und auf irgendeine funktion warten muss. 1w-module können das wohl auch sehr gut.

die rssi kannst du auch gut mit get hminfo rssi überblicken. -60 ist aber eigentlich zu gut für häufige missing ack bei wechselnden devices. daher die vermutung, dass manche ack (diese werden zudem wiederholt) "verloren" gehen.

sniffen wäre sicherlich aufschlussreich.

plin · 16 Februar 2016, 20:54:30

Zitat von: frank am 16 Februar 2016, 20:45:32
die rssi kannst du auch gut mit get hminfo rssi überblicken. -60 ist aber eigentlich zu gut für häufige missing ack bei wechselnden devices.

sniffen wäre sicherlich aufschlussreich.

Na ja, meine FHEM-Instanz sitzt mitten im Haus im ersten OG, die kritischen Sensoren im Erdgeschoss. Da liegen die rssi-Werte bei bis zu -86.5 .

Sollte ich die über den Repeater laufen lassen?

Wie kann ich den CUL sniffen?

VG Peter

frank · 16 Februar 2016, 21:06:42

ZitatWie kann ich den CUL sniffen?

cul verbose=4

wenn du ein repeater hast, natürlich testen. du kannst auch die wiederholungen erhöhen, im register des fk und in fhem attr msgrepeat. ich habe den antennendraht bei einigen fk nach aussen gelegt. wirk wahre wunder.

plin · 16 Februar 2016, 21:29:00

tja, das Logging läuft. Einzig auffälliger Eintrag

Code Auswählen

CUL_0: Unknown code A0902E112F1374645542B::-53.5:CUL_0, help me!

Worauf sollte ich achten?

frank · 16 Februar 2016, 21:52:06

fenster status ändern und kommunikation beobachten wegen missing ack.

plin · 17 Februar 2016, 18:44:59

Hallo Frank,

habe ich gemacht. Heute ist die Welt in Ordnung

Code Auswählen


2016.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

Obwohl der rssi bei -92 liegt wurde der Status korrekt übertragen.

Also doch eher nach Störquellen suchen? Kann es sein, dass meine zweite FHEM-Instanz im Keller den Funkverkehr stört? Dort sind die Tür-/Fesnterkontakte aber nicht gepaired.

VG Peter

plin · 18 Februar 2016, 21:58:25

Ich habe in den Logfiles mal übergreifend nach "MISSING ACK" gesucht. Die treten in Schüben auf und scheinen dann jedes Devices nur einmal pro Tag in einem Zeitfenster v on 1-2 Stunden zu treffen (aber nicht alle). Kommt auch nicht jeden Tag vor. Die Tür-/Fensterkontakte scheinen aber anfälliger zu sein als die Aktoren.

Bennemannc · 18 Februar 2016, 22:03:51

Hallo,

wenn ich das richtig lese, sendent der Kontakt an Broadcast 000000

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

sind die Kontakte gepairt ? Macht es eventuell Sinn diese mit einem Virtuellen Actor einer VCCU zu peeren ?

Gruß Christoph

plin · 19 Februar 2016, 15:56:36

Hallo Christoph,

die neuen optischen Kontakte wurden alle gegen meine Haupt-FHEM-Instanz gepaired bevor ich sie installiert habe. Ich habe 2 alte mit Reed-Kontakt, die Melden sich mit "closed (to CUL_0)", alle optischen mit "closed (to broadcast)".

Da sich die MISSING ACKs irgendwie zeitlich auf 1-2 Stunden konzentrieren stelle ich mir schon die Frage, ob irgend ein Gerät (wie z.B. die Waschmaschine) ins Funknetz reinspuckt.

VG Peter

Bennemannc · 19 Februar 2016, 16:43:26

Hallo Peter,

das ist interessant - ich habe nur alte und einen neuen optischen, aber auch der meldet closed to VCCU. Warum Deine anders reagieren, verstehe ich nicht. Hast Du auf dem CUL schon die Firmware bei der das Timing für Homematic optimiert wurde ? Nicht dass das Probleme macht.

Gruß Christoph