HM resend

[Guest]

Originally posted by: <email address deleted>

Sollte diese code in CUL_HM dafuer sorgen dass kommands die keinen ACK
bekommen haben wieder (bis 3 mal) neu abgeschickt werden?
Ich sehe bei mir kein neuversuche wenn kein ACK zuruck bekommen wird.

sub
CUL_HM_Resend($)
{
  my $hash = shift;
  my $name = $hash->{NAME};
  return if(!$hash->{ackCmdSent});      # Double timer?
  if($hash->{ackCmdSent} == 3) {
    delete($hash->{ackCmdSent});
    delete($hash->{ackWaiting});
    delete($hash->{cmdStack});
    $hash->{STATE} = "MISSING ACK";
    DoTrigger($name, "MISSING ACK");
    return;
  }
  IOWrite($hash, "", $hash->{ackWaiting});
  $hash->{ackCmdSent}++;
  DoTrigger($name, "resend nr ".$hash->{ackCmdSent});
  InternalTimer(gettimeofday()+0.5, "CUL_HM_Resend", $hash, 0);
}

--Johan

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> Sollte diese code in CUL_HM dafuer sorgen dass kommands die keinen ACK
> bekommen haben wieder (bis 3 mal) neu abgeschickt werden?

Beim CUL ja, beim HMLAN nicht, resend macht das HMLAN selber, der sagt nur,
wenn es nicht geklappt hat.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Ich bin da nicht ganz sicher. Innerhalb eine sekunde kommt schon die
NACK, und nachher kommt auch kein ACK zuruck.
Denke dass der HMLAN ziemlich dum ist. Kann Ich irgendwo diese resend
auch fuer den HMLAN aktivieren, zum testen?

Homeputer schickt das kommand einfach noch ein paar mal, bis es
klappt, Das wird da nicht vom HMLAN gemacht.

--Johan



On Sun, Feb 19, 2012 at 8:17 PM, Rudolf Koenig wrote:
>> Sollte diese code in CUL_HM dafuer sorgen dass kommands die keinen ACK
>> bekommen haben wieder (bis 3 mal) neu abgeschickt werden?
>
> Beim CUL ja, beim HMLAN nicht, resend macht das HMLAN selber, der sagt nur,
> wenn es nicht geklappt hat.
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Also, HMLan schickt innerhalb eine Sekunde dieses Bericht noch ein
mal. Da hasst du recht Aber meistens mit dem gleichen Resultat.
(NACK)
Was uns fehlt ist eine Routine, der Kommands die nicht bestätigend
wurden, später wieder neu abschickt (rescheduled).
In diesem fall hat man eine recovery von kurzfristig schlechte RF
verbindungen, marginale RF verbindungen, RF collisions etc

Jetzt sagen wir eigentlich "oke, wir wissen das das Kommand nicht
bestätigt wurde, aber schreiben es nur im log weg".
Eigentlich wird das Vorteil von einem acknowledged Protokoll noch nicht benützt.

Ist so etwas einfach zu implementieren?


--Johan



On Sun, Feb 19, 2012 at 8:45 PM, Johan van der Kolk
wrote:
> Ich bin da nicht ganz sicher. Innerhalb eine sekunde kommt schon die
> NACK, und nachher kommt auch kein ACK zuruck.
> Denke dass der HMLAN ziemlich dum ist. Kann Ich irgendwo diese resend
> auch fuer den HMLAN aktivieren, zum testen?
>
> Homeputer schickt das kommand einfach noch ein paar mal, bis es
> klappt, Das wird da nicht vom HMLAN gemacht.
>
> --Johan
>
>
>
> On Sun, Feb 19, 2012 at 8:17 PM, Rudolf Koenig wrote:
>>> Sollte diese code in CUL_HM dafuer sorgen dass kommands die keinen ACK
>>> bekommen haben wieder (bis 3 mal) neu abgeschickt werden?
>>
>> Beim CUL ja, beim HMLAN nicht, resend macht das HMLAN selber, der sagt nur,
>> wenn es nicht geklappt hat.
>>
>> --
>> To unsubscribe from this group, send email to
>> fhem-users+unsubscribe@googlegroups.com

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> Eigentlich wird das Vorteil von einem acknowledged Protokoll noch nicht benützt.

Ich persoenlich sehe auch nicht so viele Vorteile, man weiss naemlich nicht, ob
das Geraet nicht geschaltet hat, oder man nur den ack nicht gehoert hat. Z.Zt
moechte ich ein weiteres Resend nicht im Modul aufnehmen, weil ich nicht daran
glaube, dass es was nuetzt 6-mal (oder 9-mal?) zu senden, wenn es 3-mal nicht
geklappt hat.

Wenn Du unbedingt darauf bestehst, kannst auch jetzt mit einem notify auf
MISSING ACK reagieren

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Oke,
ich sehe die Vorteile, kenne mich leider nicht so gut aus mit Perl.

Das Kommando wird nur einmal wiederholt, innerhalb 1 Sekunde.
Ich hab gemeint das Kommando wieder neu zu schedulen (also das nächste
mal das der Thermostat sich meldet erst wieder senden), und nicht 9
mal hintereinander in 3 Sekunden raus zu schicken
Ob man nicht sicher ist welche Kommunikations Richtung fehlerhaft war
ist nicht so wichtig.
Man konnte nach drei fehlgeschlagene rescheduled kommands auch
detektieren das ein gerät nicht mehr funktioniert und einem Alarm
auslosen.

Zur seite, kommands die zu dem Thermostat geschickt werden, gleich
nach dem der Thermostat mit dem Heizungsregler kommuniziert hat (also
ein type 88 bericht) geben jedes mal einen ACK fehler, Sieht so aus
als ob der Thermostat in dem Moment nicht auf dem richtigen Kanal
lauscht.

Ausschnitt vom log hier unten:
2012-02-20 11:51:39 HMLAN HM_lan RCV L:0B N:C4 CMD:A258
(TYPE=88,WAKEMEUP,BIDI,RPTEN) SRC:134718 DST:136FEB 0000
2012-02-20 11:51:39 HMLAN HM_lan SND L:0B N:3C CMD:A001
(TYPE=1,BIDI,RPTEN) SRC:0EFFDA DST:134718 010E (CONFIG_STATUS_REQUEST
CHANNEL:01)
2012-02-20 11:51:40 CUL_HM th_salon MISSING ACK


--Johan



On Mon, Feb 20, 2012 at 11:20 AM, Rudolf Koenig wrote:
>> Eigentlich wird das Vorteil von einem acknowledged Protokoll noch nicht benützt.
>
> Ich persoenlich sehe auch nicht so viele Vorteile, man weiss naemlich nicht, ob
> das Geraet nicht geschaltet hat, oder man nur den ack nicht gehoert hat. Z.Zt
> moechte ich ein weiteres Resend nicht im Modul aufnehmen, weil ich nicht daran
> glaube, dass es was nuetzt 6-mal (oder 9-mal?) zu senden, wenn es 3-mal nicht
> geklappt hat.
>
> Wenn Du unbedingt darauf bestehst, kannst auch jetzt mit einem notify auf
> MISSING ACK reagieren
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com