Homematic MISSING ACK Befehl erneut senden

[spranz]

Hallo, ich habe einen Homematic 1-fach Schaltaktor.
Mit diesem Schaltaktor steuer ich direkt das "Heizen" meiner Gastherme. Soweit funktioniert es auch. Leider bekomme ich ca. alle zwei Wochen ein MISSING ACK angezeigt.
Manchmal ist dann also morgens das Haus kalt, oder die Heizung heizt ununterbrochen weiter. Je nachdem was der letzte Befehl war.
Ich vermute es liegt an einer zu schlechten Verbindung zum Aktor. (Mein System ist ein Raspi 3 mit nanoCUL)
Meine RSSI liegt bei um die -70 (also Grenzwertig) einen Repeater wollte ich nicht unbedingt verbauen.  Ich habe vor kurzem schon auf eine +8dbi Antenne aufgerüstet. Trotzdem habe ich noch manchmal die Probleme.
Ich dachte eigentlich das Homematic Bidirektional arbeitet, kann ich nicht irgendwo einstellen, dass bei Befehlsausführung so lange der Befehl gesendet wird, bis er die richtige Rückantwort vom Emfänger erhält?

Hier noch die config vom betroffenden Gerät:

Vielleicht kann mir ja jemand von euch helfen....

Code Auswählen Erweitern

Internals:
   CUL2_MSGCNT 8
   CUL2_RAWMSG A0EEAA4103C839DF10000060100005D::-71:CUL2
   CUL2_RSSI  -71
   CUL2_TIME  2017-11-14 08:23:58
   DEF        3C839D
   IODev      CUL2
   LASTInputDev CUL2
   MSGCNT     8
   NAME       HEIZEN
   NOTIFYDEV  global
   NR         67
   NTFY_ORDER 50-HEIZEN
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:EA - t:10 s:3C839D d:F10000 060100005D
   peerList   HM_375D71_SwitchTr,
   protCmdDel 1
   protLastRcv 2017-11-14 08:23:58
   protResnd  3 last_at:2017-11-13 21:10:03
   protResndFail 1 last_at:2017-11-13 21:10:08
   protSnd    11 last_at:2017-11-14 08:23:58
   protState  CMDs_done
   rssi_CUL2  avg:-92.12 min:-93 cnt:8 lst:-93 max:-90
   rssi_at_CUL2 max:-68.5 lst:-71 min:-74 avg:-70.56 cnt:8
   READINGS:
     2017-11-14 07:36:50   CommandAccepted yes
     2017-09-08 16:10:36   D-firmware      2.8
     2017-09-08 16:10:36   D-serialNr      MEQ0709962
     2017-09-08 16:18:45   PairedTo        0xF10000
     2016-02-05 12:31:08   R-HM_375D71_SwitchTr-lgActionType jmpToTarget
     2016-02-05 12:31:08   R-HM_375D71_SwitchTr-shActionType jmpToTarget
     2017-09-08 16:18:45   R-pairCentral   0xF10000
     2016-02-05 12:21:05   R-powerUpAction off
     2016-02-05 12:21:05   R-sign          off
     2017-09-08 16:18:45   RegL_00.        02:01 0A:F1 0B:00 0C:00 15:FF 18:00 00:00
     2017-09-08 16:18:46   RegL_01.        08:00  30:06 57:24 56:00 00:00
     2017-09-08 16:18:47   RegL_03.HM_375D71_SwitchTr 02:02 03:02 04:32 05:B4 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:34 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:13 8C:33 00:00
     2017-11-14 08:23:58   deviceMsg       off (to CUL2)
     2017-11-14 08:23:58   level           0
     2017-11-14 08:23:58   pct             0
     2017-11-13 19:48:30   peerList        HM_375D71_SwitchTr,
     2017-10-31 10:29:23   powerOn         2017-10-31 10:29:22
     2017-11-14 08:23:58   recentStateType info
     2016-02-05 22:31:55   sabotageAttackId_ErrIoId_375D71 cnt:3
     2016-02-05 22:31:55   sabotageAttack_ErrIoAttack cnt 3
     2017-11-14 08:23:58   state           off
     2017-11-14 08:23:58   timedOn         off
     2017-08-26 22:15:12   trigLast        HM_375D71_SwitchTr:0
     2017-08-26 22:15:12   trig_HM_375D71_SwitchTr 0_51
   helper:
     HM_CMDNR   234
     cSnd       01F100003C839D010E,01F100003C839D010E
     dlvlCmd    ++A011F100003C839D0201000000
     mId        0004
     rxType     1
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +3C839D,00,00,00
       nextSend   1510644238.37573
       prefIO
       rxt        0
       vccu
       p:
         3C839D
         00
         00
         00
     mRssi:
       mNo        EA
       io:
         CUL2       -69
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf
       qReqStat
     role:
       chn        1
       dev        1
       prs        1
     rpt:
       IO         CUL2
       flg        A
       ts         1510644238.28006
       ack:
         HASH(0x2b3e2c8)
         EA8002F100003C839D00
     rssi:
       CUL2:
         avg        -92.125
         cnt        8
         lst        -93
         max        -90
         min        -93
       at_CUL2:
         avg        -70.5625
         cnt        8
         lst        -71
         max        -68.5
         min        -74
     tmpl:
Attributes:
   IODev      CUL2
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   2.8
   icon       icoHEIZUNG
   model      HM-LC-SW1-FM
   peerIDs    00000000,375D7107,
   room       2.1 Heizung
   serialNr   MEQ0709962
   subType    switch
   webCmd     statusRequest:toggle:on:off

[Beta-User]

Hallo spranz,

willkommen hier im Forum.

An sich dürfte CUL_HM schon eine gewisse Anzahl von neuen Sendeversuchen mit eingebaut haben, aber das bis in alle Ewigkeit weiter zu versuchen, macht m.E. auch keinen großen Sinn (1%-Regel sagt dir was?).

Du kannst also entweder weiter deine Schnittstelle optimieren (Sendeleistung SW-mäßig erhöhen, timing-optimierte firmware nehmen), oder auf solche Würgarounds verzichten und ein 2. Interface verwenden (Stichworte: VCCU (Wiki) und z.B. HM-MOD-RPI-PCB mit WLAN). Vielleicht reicht es auch, das genannte PI-Modul am heutigen Standort des CUL zu verwenden, -70 ist kein sooo schlechter RSSI-Wert.

Viel Erfolg jedenfalls,

Beta-User

[Pfriemler]

Bidirektional ist die Kommunikation schon, und HM macht selbsttätig mehrere Sendeversuche. Das kann man auf Mayimum erhöhen.
Ein rssi von -70 ist nicht schlecht. Sind beide Werte ausgewogen? Wenn der Aktor einen Störer bei sich hat, wird öfter mal was verloren gehen.
Hier würde ich aber mal eine Ebene höher ansetzen und die Ausführung extra mit notify, watchdog oder so überwachen, mit verzögerten Wiederholungen wenn der Istzustand nicht dem Sollzustand entspricht. Bei missing ack müsste der Aktor ja im State "set_...." hängenbleiben.

Gib mal ein paar mehr Infos zur räumlichen Situation ... vielleicht lässt sich die Ursache besser bekämpfen als das Symptom.

[Pfriemler]

Ja..  ich sehe gerade, die rssi sind stark unsymmetrisch, der CUL wird vom Aktor zu schlecht gehört. Der Aktor sollte evtl vesser platziert werden.

Dann ist da noch ein peering mit einem Wandthermostat. Das spuckt aber nicht in die Suppe bzw. funktioniert gut?

[spranz]

Danke erstmal für eure schnellen Antworten 
Also zur Räumlichen Situation: Grob gesagt habe ich keinerlei Stahldecken, aber von der Entfernung ist der Aktor schon ca. 30m durch eine Holzdecke und mehrere Türen vom Cul entfernt.
Ich habe den Emfänger vor zwei Wochen mit zwei Metern Kabel über der Gastherme angebracht, weil ich vermutet habe, dass die Hochspannung vom Zündfunken der Therme evtl. auch die Funkverbindung stören könnte.
Das Wandthermostat sollte eigentlich nicht mehr mit dem Schaltaktor verbunden sein, sondern arbeitet mittlerweile direkt mit dem CUL. Wie kann ich das Peering wieder vom Schaltaktor löschen?
Und wie kann ich die Sendeversuche vom CUL auf max stellen?

Hier ist mein code, der die Therme steuert:

Code Auswählen Erweitern

([Badezimmer:measured-temp] <  [Badezimmer:desired-temp] or [Wandthermostat:measured-temp] <  [Wandthermostat:desired-temp])
   (set HEIZEN on)
DOELSEIF ([Badezimmer:measured-temp] >=  [Badezimmer:desired-temp] and [Wandthermostat:measured-temp] >= [Wandthermostat:desired-temp])
   (set HEIZEN off)

Als letzte Möglichkeit werde ich den Code einfach erweitern, falls MISSING ACK ausgegeben wird, und die Thermostate entsprechende Zustände haben, wird "Heizen"  ON oder OFF gesendet....müsste doch eigentlich gehen,oder?

[Pfriemler]

Hm ... mich wunderte die Asymmetrie. So wie beschrieben ist die eigentlich seltsam. Die Distanz ist aber auch ... kritisch.
Handelt es sich um einen echten 868-Mhz-CUL? ist die Antenne richtig? Wäre es denkbar, den CUL testweise etwas abseits des RPi (?) mit einer USB-Verlängerung abzusetzen?

Ich würde zudem Beta-Users Vorschlag in Erwägung ziehen und ein zusätzliches Interface installieren, das RPi-Modul zusammen mit einem WLAN-Modul wie dem Wemis D1, eventuell gibt es noch fertige Platine im Markt hier.

Das Peering mit dem Wandthermostat stört nicht, wenn der Wandthermostat nicht sendet, wobei ein Zurücksetzen allein reichen müsste. Sonst aber würde ich es entfernen. Wobei prinzipiell eine Direktkopplung einer Steuerung über FHEM vorzuziehen ist, wenn damit gleiche Funktionalität möglich ist.

Entpeeren mit Bordmitteln wie üblich: vom Wandthermostat-Schaltkanal aus mit "peerChan 0 <Aktorname> single unset".

[spranz]

Ich habe einen Selbstabau CUL auf Arduino nano Basis. Das Ganze läuft bei mir seit 3 Jahren problemlos. Ich denke auch, das es eher die Entfernung zum Aktor ist.
Die große 868 Mhz Antenne am CUL ist übrigens direkt von Busware, sollte also auch korrekt sein.
Ich habe gestern mal Testweise eine +2db 868Mhz Antenne an den Schaltaktor angebaut. (Die hatte ich noch übrig)
Jetzt habe ich eine deutliche verbesserung der RSSI: auf -59.
Ich denke ich werde das ganze jetzt erstmal so testen.
Achso, die transmitTryMax habe ich von 6 auf 10 genommen. (das müssten ja die Sendewiederholungen sein...?

[Pfriemler]

Super, am CUL liegt es dann wohl nicht.
Das Problem waren nicht die -70, sondern das hier:

Code Auswählen Erweitern

rssi_CUL2  avg:-92.12 min:-93 cnt:8 lst:-93 max:-90

Ein avarage von weniger als -85 ist da kritisch, -92 ist fast ein Wunder dass da was ging. ... wie ist der jetzt? -59 wäre traumhaft.

transmitTryMax bezieht sich vom Aktor auf den CUL. Wie man den CUL zu (mehr) repeats anregt weiß ich nicht.

Beachte bei den Antennen auch die Ausrichtung. Gerade die mit Gewinn bündeln stärker.

[spranz]

achso... dann ist es nur etwas besser geworden:

Code Auswählen Erweitern

max:-82 cnt:65 avg:-87 min:-96 lst:-85

Ja, mit der Ausrichtung der Antennen könnte ich noch etwas rumspielen. -vielleicht könnte ich da noch was rausholen

[spranz]

worin besteht denn eigentlich der Unterschied zwischen rssi_CUL2 und rssi_at_CUL2?

[Beta-User]

Steht doch eigentlich hier:

Ja..  ich sehe gerade, die rssi sind stark unsymmetrisch, der CUL wird vom Aktor zu schlecht gehört. Der Aktor sollte evtl vesser platziert werden.

Es handelt sich um die RSSI-Werte der im Aktor bzw. im CUL verbauten Transceiver...