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
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
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.
könnte es sein, dass dein fhem manchmal "hängt"? muss der cul auch andere protokolle bedienen? schon mal mit perfmon oder apptime kontrolliert?
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
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.
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
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.
tja, das Logging läuft. Einzig auffälliger Eintrag
CUL_0: Unknown code A0902E112F1374645542B::-53.5:CUL_0, help me!
Worauf sollte ich achten?
fenster status ändern und kommunikation beobachten wegen missing ack.
Hallo Frank,
habe ich gemacht. Heute ist die Welt in Ordnung
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
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.
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
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
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
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
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
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
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
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
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
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
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
ZitatAES-Lib installiert
das ist grundvoraussetzung für CUL und AES
da die HM-SEC-SCo nur so pairen kannst
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 (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 (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
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
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