Funkprobleme auffangen

[betamax]

Hallo,

ich habe noch immer gelegentliche "Missing ACK" Probleme mit dem HM-MOD-Re-8.

Jetzt bin ich auf folgendes gestoßen:
http://www.fhemwiki.de/wiki/HM-CC-TC_Funk-Wandthermostat#Funkprobleme_auffangen
Dort steht: Falls ein Fehler bei der Funkkommunikation auftritt, erhält man die Antwort "missing ACK" oder "NACK". Auch in diesem Fall soll das Telegramm zum Ändern der Wunschtemperatur erneut an den HM-CC-TC gesendet werden:

Code Auswählen Erweitern

define n_HM_TC_err notify HM_TC:(MISSING.ACK.*|.*NACK.*) {\
   Log 1, ">>>>>>>>> n_HM_TC desired temp - missing ack/nack.\n";\
   fhem("set HM_TC desired-temp ".Value("HM_TC_Solltemperatur"));\}

Frage, wie kann man den Code an den HM-MOD-Re-8 anpassen (ich kann es leider nicht)
so dass wenn ein "Missing ACK" passiert der Befehl nach Zeit "x" wiederholt wird?

Für meine Bewässerung verwende ich ein DOIF:

Code Auswählen Erweitern

([07:00:30] or [21:00:30])(set Kue_Bew_Rel_1 on-for-timer 45)
DOELSEIF ([11:00:30])(set Kue_Bew_Rel_1 on-for-timer 60)
DOELSEIF ([14:00:30])(set Kue_Bew_Rel_1 on-for-timer 90)
DOELSEIF ([17:00:30])(set Kue_Bew_Rel_1 on-for-timer 80)

Leider ist die Zuverlässigkeit der Steuerung nicht gegeben da sporadisch immer wieder ein "Missing ACK" passiert.
msgRepeat habe ich auf 5.

Gruß
betamax

[frank]

einfach "blind" bei jedem missing ack die pumpe ein zu schalten, halte ich nicht nur für riskant. vielleicht wollte fhem zb nur einen statusrequest machen, der misslungen ist, und schon schaltet dein notify die pumpe an.
wenn du ein "Nack" bekommst, hat der aktor den befehl sogar ausdrücklich verweigert. dann bringt es doch nichts das selbe nochmal zu senden. ruckzuck hast du eine endlos schleife.

an deiner stelle würde ich auf jeden fall erst einmal den grund (funk?) für deine probleme suchen und hier verbessern (2. io?).

bis dahin ist es für dich vielleicht am einfachsten, einfach noch ein paar DOELSEIF zweige mit leicht versetzten zeiten einzufügen. könntest du sogar in abhängigkeit des zustands machen.

[betamax]

einfach "blind" bei jedem missing ack die pumpe ein zu schalten, halte ich nicht nur für riskant.

Hallo Frank,

ich kann da nichts problematisches erkennen.
Letztendlich geht es doch nur darum dass ein Befehl ausgeführt werden soll der aus irgendeinem Grund nicht ausgeführt wurde.

an deiner stelle würde ich auf jeden fall erst einmal den grund (funk?) für deine probleme suchen und hier verbessern (2. io?).

Ja klar die Voraussetzungen für eine gute Funkverbindung sollten vorhanden sein.
Das habe ich schon gemacht, CUL an div. Plätzen ausprobiert. Meine rssi Werte sind gar nicht so schlecht.
Selbst bei dem Device "Kiz" auch ein Re-8 das Sichtverbindung zum CUL hat kommt es zum "Resnd".
Ich finde das die rssi Werte min - max stark schwanken und habe 2 mal bei Busware nachgefragt, keine Antwort.
Auch hier im Forum keine Rückmeldung ob das vielleicht normal ist.

bis dahin ist es für dich vielleicht am einfachsten, einfach noch ein paar DOELSEIF zweige mit leicht versetzten zeiten einzufügen. könntest du sogar in abhängigkeit des zustands machen.

Ja hatte ich auch schon drüber nachgedacht auch anstelle von on-for-timer 80 zwei mal 40 sec zu schalten.
Fällt einer aus so hat man wenigsten ein bisschen gewässert, besser als nichts.
Aber ganz ehrlich professionell ist das nicht.

Mitunter läuft alles über eine Woche wunderbar, dann sporadisch und nicht nachvollziehbar ein Missing ACK.
Mit Missing ACK damit stehe ich ja nicht alleine da.
Ich gehe mal davon aus, das noch mehr User ein Interesse an einer prof. Lösung haben.
Für den HM-CC-TC gibt es die ja, das müsste sich doch auch auf andere Device anpassen lassen.
Ich würde es ja machen wenn ich es könnte.

[frank]

hi betamax.

rssi
grundsätzlich sollten die rssi passen, aber trotzdem gibt es probleme.
ein grosses manko der rssi betrachtung, wie ich finde, ist, dass zb nur die rssi existieren, die auch "durchgekommen" sind.
wenn wirklich keine aktivitäten in deinem haus sind, sollte es eigentlich auch zu keinen nennenswerten schwankungen kommen. anscheinend gibt es bei dir gelegentlich schlechtere werte, da der average deutlich dichter bei guten werten liegt. könnte passieren, wenn sich jemand in der funkstrecke befindet, fenster und türen geöffnet/geschlossen werden, jalousien geändert werden, ....
das device mit besseren rssi hat auch weniger resend. das andere hat ja auch nur einen fail mit 12 resend. dreh doch msgrepeat bei diesem device noch höher.

ich würde die rssi loggen (attr rssiLog) und sniffen, um das besser beurteilen zu können. was sagt fhem.log zu den resend zeiten. eventuell global verbose mit einem at zu den schaltterminen hochdrehen.

nutzt du den cul ausschliesslich für homematic? hat die fritzbox damit zu tun? hat fhem hänger (apptime/perfmon)?

Ja hatte ich auch schon drüber nachgedacht auch anstelle von on-for-timer 80 zwei mal 40 sec zu schalten.
Fällt einer aus so hat man wenigsten ein bisschen gewässert, besser als nichts.
Aber ganz ehrlich professionell ist das nicht.

ich meine eher folgendes: vielleicht 2 min nach dem ersten on-for-timer nur dann ein 2. senden, wenn der status des aktors nicht on ist.

[betamax]

Hallo Frank,

msgrepeat habe ich jetzt von 5 auf 10 gesetzt.

ich würde die rssi loggen (attr rssiLog) und sniffen

attr rssiLog hatte ich schon gesetzt, ist angehängt.

was sagt fhem.log zu den resend zeiten.

nicht viel, sagt mir nichts, ist angehängt.

global verbose habe ich jetzt von 1 auf 4 gesetzt.

nutzt du den cul ausschliesslich für homematic? hat die fritzbox damit zu tun? hat fhem hänger (apptime/perfmon)?

Ja und ja, der Cul ist an der Fritzbox über eine USB-Verlangerung angeschlossen so das man zum platzieren etwas Spiel hat.
Hänger hat fhem glaube ich nicht denn die beiden RE-8 schalten nacheinander. Die Schaltzeiten habe ich schon getauscht
das Problem ist unverändert.

ich meine eher folgendes: vielleicht 2 min nach dem ersten on-for-timer nur dann ein 2. senden, wenn der status des aktors nicht on ist.

Ja so in der Art aber ich habe keine Ahnung wie man das macht
(wobei 2 min für mich zu lang sind. Es sind große Blumenkästen die mehrmals kurz bewässert werden müssen ansonsten läuft es unten durch).

[frank]

attr rssiLog hatte ich schon gesetzt, ist angehängt.

mit den wenigen werten sieht man natürlich nicht viel.
ich würde zb mal ein zyklisches statusrequest einbauen, um mehr werte zu erzeugen. dann kann man sich einen schönen plot erstellen, und erkennt eventuell einen zusammenhang mit "räumlichen" veränderungen.

Code Auswählen Erweitern

define a1 at +*00:09:47 set mein_device statusRequest

[betamax]

Hallo Frank,

den statusrequest habe ich gestern gesetzt, jetzt kommen jede Menge Daten.
Allerdings läuft z. Z. alles bestens, nicht einmal ein Resend.
Mal sehen wie lange das anhält.

Gruß
betamax

[betamax]

Hallo Frank,

so jetzt läuft er nicht mehr so gut.
Dank dem statusrequest habe ich jetzt mehr Daten, allerdings kann ich daraus nicht viel ableiten.
Ich sehe nur das der HM-MOD-Re-8 manchmal anscheint keine Lust hat, außer "Missing ACK" gibt es keine Fehlermeldung.
Warum der manchmal einfach nicht will erschließt sich mir nicht.

Gruß
betamax

[frank]

wie gesagt würde ich die rssi werte mal in einem plot darstellen, um zu sehen, in welchen situationen die rssi schwächer werden. in diesem kleinen ausschnit sieht man ja, dass gegen 17 uhr, die rssi bis -79.5 runtergehen und anschliessend gibt es missing ack.

ist das device irgendwo eingebaut? richte die antenne mal anders aus, sodass die werte vieleicht besser werden. hat zu dieser zeit jemand vor dem device oder dem io gestanden? ich kenne deine örtlichkeiten nicht. das müsstest du jetzt selber herausfinden, was diese schwankungen verursachen könnte.

was sagt denn get hminfo rssi jetzt?

[betamax]

wie gesagt würde ich die rssi werte mal in einem plot darstellen, um zu sehen, in welchen situationen die rssi schwächer werden. in diesem kleinen ausschnit sieht man ja, dass gegen 17 uhr, die rssi bis -79.5 runtergehen und anschliessend gibt es missing ack.

Hallo Frank,

habe mal einen Plot gemacht und angehängt.
Ja gegen 17 Uhr werden die Werte schlechter.
Aber um 16:43:15 & 17:22:25 Uhr sind die Werte gut trotzdem ein Missing ACK.
Um 17:00:30 fand eine Bewässerung statt, rssi -77.

Das Device ist in einem BOPLA Kunststoffgehäuse, die Antenne ist sogar herausgeführt.
Ich habe sogar versucht den Empfang zu stören indem ich einen kleinen Edelstahlbecher über die Antenne vom Re-8
gestülpt habe, ohne Erfolg, hat sofort geschaltet und ohne Resend.

Ich glaube nicht das es an der Signalstärke liegt.

Gruß
betamax

[frank]

Aber um 16:43:15 & 17:22:25 Uhr sind die Werte gut trotzdem ein Missing ACK.
Um 17:00:30 fand eine Bewässerung statt, rssi -77.

für 16:43 kann man leider keine aussage über den rssi machen. man kann höchstens behaupten, 10 min vorher und 10 min danach war es in ordnung. da keine kommunikation möglich war, ist es wahrscheinlicher, dass es zu dieser zeit eher zu schlecht war. trozdem spekulation.

Ich habe sogar versucht den Empfang zu stören indem ich einen kleinen Edelstahlbecher über die Antenne vom Re-8
gestülpt habe, ohne Erfolg, hat sofort geschaltet und ohne Resend.

das ist ja schon mal ein gutes zeichen.

bis 16:00 sieht dein plot ziehmlich gut und gleichmässig aus, keine besonderen schwankungen. hm...
vielleicht das netzteil? oder die spannungsversorgung vom cul?

[betamax]

So die Netzteile der beiden Re-8 untereinander getauscht, keine Änderung.
Den CUL schließe ich mittlerweile auch aus wie auf dem Bild zu sehen ist verhalten sich die beiden Re-8 unterschiedlich obwohl beide fast Zeitgleich geschaltet werden.

Eine zuverlässige Befehlsausführung ist einfach nicht gegeben warum auch immer.
Mir fällt zur Fehlersuche nichts mehr ein.
Wie man sieht um 17:00:33 ein Missing ACK und 23 Sekunden später schaltet er wieder.
Ohne zuverlässige Befehlswiederholung wird das nichts.

Hat keiner eine Idee wie man den Code "Funkprobleme auffangen" vom HM-CC-TC
http://www.fhemwiki.de/wiki/HM-CC-TC_Funk-Wandthermostat#Funkprobleme_auffangen
an den HM-MOD-Re-8 anpassen kann?

Gruß
betamax

[Motivierte linke Hände]

Hast Du das Problem lösen können?

[betamax]

Leider nicht!

Ich habe versucht den Code "Funkprobleme auffangen" vom HM-CC-TC auf den HM-MOD-Re-8 anpassen.
Bin da aber gescheitert, da reichen meine Programmierfähigkeiten scheinbar nicht aus.

Leider lässt sich auch der Autor des Artikels
http://www.fhemwiki.de/wiki/HM-CC-TC_Funk-Wandthermostat#Funkprobleme_auffangen
nicht ermitteln.

[Motivierte linke Hände]

Vielleicht hilft Dir ein wenig weiter, was ich mir mal gebastelt habe, um Homematic-Schalter am Rande des Funkbereichs schalten zu können (für die 99_myUtils.pm):

Code Auswählen Erweitern

sub set_switch ($$$) {
  my ($Switch, $Kommando, $ExpectedStatus) = @_;

  my $retry = ReadingsVal($Switch, 'SwitchAttempt', 'Error');
  if ($retry ne 'Error') {
    Log 1, ("set_switch: ($Switch, $Kommando) Es läuft noch ein Versuch, den Schalter zu schalten. Abbruch, kein neuer Schaltbefehl.");
  } else {
    fhem('set '.$Switch.' '.$Kommando);
    fhem("setreading $Switch SwitchAttempt 0");
    my $new_at = 'define at_'.$Switch.'chk0 at +00:01 { check_switch_status("'.$Switch.'", "'.$Kommando.'", "'.$ExpectedStatus.'") }';
    # Log 1, ("set_switch: ($Switch, $Kommando) Geschaltet, definiere zum Prüfen in 1 Minute neues at: ".$new_at);
    fhem($new_at);
  }
}

sub check_switch_status ($$$) {
  my ($Switch, $Kommando, $ExpectedStatus) = @_;
  my $status = '';
  my $new_at = '';

  $status = Value($Switch);
  my $retry = ReadingsVal($Switch, 'SwitchAttempt', 'Error');
  if ($retry eq 'Error') {
    $retry = 0;
  }
  $retry++;
  fhem("setreading $Switch SwitchAttempt $retry");
  if (index($status, 'set_') != -1) {
    Log 1, ("check_switch_status: ($Switch, $Kommando, Check $retry) Status von $Switch ist >$status< (erwartet >$ExpectedStatus<), prüfe erneut in 1 Minute.");
    fhem('set '.$Switch.' statusRequest');
    $new_at = 'define at_'.$Switch.'chk'.$retry.' at +00:01 { check_switch_status("'.$Switch.'", "'.$Kommando.'", "'.$ExpectedStatus.'") }';
    Log 1, ("check_switch_status: ($Switch, $Kommando, Check $retry) Definiere neues at:".$new_at);
    fhem($new_at);
  } else {
    if (index($status, $ExpectedStatus) != -1) {
      Log 1, ("check_switch_status: ($Switch, $Kommando, Check $retry) Status von $Switch is >$status<, alles ok.");
      fhem("deletereading $Switch SwitchAttempt", 1);
      if (index($Kommando, 'on-for-timer') != -1) {
        my $Stunden = 0;
        my $Minuten = 0;
        my ($dummy,$Sekunden) = split(/ /,$Kommando);
        if ($Sekunden > 0) {
          $Minuten = int($Sekunden / 60);
          $Sekunden = $Sekunden - $Minuten * 60;
          $Sekunden = sprintf("%02d", $Sekunden);
          if ($Minuten > 59) {
            $Stunden = int($Minuten / 60);
            $Minuten = $Minuten - $Stunden * 60;
          }
          $Minuten = sprintf("%02d", $Minuten);
          $Stunden = sprintf("%02d", $Stunden);
          if ($Stunden < 24) {
            Log 1, ("check_switch_status: ($Switch, $Kommando) on-for-timer gesetzt; prüfe, ob Schalter wieder aus ist in $Stunden Stunden, $Minuten Minuten, $Sekunden Sekunden.");
            my $at_Name = 'at_'.$Switch.'chk_off';
            if (exists($defs{$at_Name})) {
              fhem("delete $at_Name");
            }
            $new_at = "define $at_Name at +$Stunden:$Minuten:$Sekunden ".'{ check_switch_status("'.$Switch.'", "off", "off") }';
            Log 1, ("check_switch_status: ($Switch, $Kommando) Definiere neues at: $new_at");
            fhem($new_at);
          } else {
            Log 1, ("check_switch_status: ($Switch, $Kommando) Kann on-for-timer nicht prüfen, Dauer länger als ein Tag ($Stunden Stunden, $Minuten Minuten, $Sekunden Sekunden).");
          }
        }       
      }
    } else {
      if ($retry < 100) {
        if ($retry / 5 == int($retry/5)) {
          Log 1, ("check_switch_status: ($Switch, $Kommando, Check $retry) Status von $Switch is >$status< (erwartet >$ExpectedStatus<), sende Schaltbefehl erneut.");
          fhem('set '.$Switch.' '.$Kommando);
        } else {
          Log 1, ("check_switch_status: ($Switch, $Kommando, Check $retry) Status von $Switch is >$status< (erwartet >$ExpectedStatus<), prüfe erneut in 1 Minute.");
        }
        $new_at = 'define at_'.$Switch.'chk'.$retry.' at +00:01 { check_switch_status("'.$Switch.'", "'.$Kommando.'", "'.$ExpectedStatus.'") }';
        Log 1, ("check_switch_status: ($Switch, $Kommando, Check $retry) Definiere neues at:".$new_at);
        fhem($new_at);
      } else {
        Log 1, ("check_switch_status: ($Switch, $Kommando, Check $retry) Gebe nach 100 Versuchen auf. Nächster Versuch in 6 Stunden.");
        $new_at = 'define at_'.$Switch.'_deletereadings_switchattempt at +06:00 deletereading '.$Switch.' SwitchAttempt';
        fhem($new_at);
      }
    }
  }
}


Man sieht dem Code sicherlich an, dass ich von Haus aus etwas anderes gelernt habe  , aber es funktioniert hier zum Schalten von ein paar Switches im Garten.

Das Ganze funktioniert so, dass Du statt des Schaltens in fhem ("set <switch> on") das perl sub "set_switch" von oben aufrufst, und zwar:

Code Auswählen Erweitern

{ set_switch ("<switch>", "<Befehl>", "<erwarteter_Status>") }

Also z.B. zum Anschalten:

Code Auswählen Erweitern

{ set_switch ("<switch>", "on", "on") }

Oder für on-for-timer:

Code Auswählen Erweitern

{ set_switch ("<switch>", "on-for-timer 3600", "on") }

set_switch setzt den Befehl ab und prüft dann regelmäßig den Status des Switches, ob entsprechend geschaltet wurde. Bei "on-for-timer" wird auch geprüft, ob nach Ablauf der Zeit der Status wieder "off" ist. Im Bedarfsfall wird dann auch "off" geschaltet.

Ich setze das u.a. für die Gartenbewässerung ein. Hin und wieder gab es Funkprobleme, da die Gartengröße und die Beschaffenheit der Mauern gemeinsam mit kompatibel mit dem Funkprotokoll sind...  Die obigen subs laufen hier jetzt länger als ein Jahr, und die Wasserrechnung hat bisher nicht gelitten. Vielleicht hilft das auch Dir.

Ein Hinweis noch: Die Log-Befehle fluten Dein Log unabhängig von verbose, so dass Du sehen kannst, was passiert. Wenn es läuft, kannst Du die entsprechenden Log-Zeilen einfach durch vorangestelltes # auskommentieren.

Grüße, Christian