Autor Thema: ACK Verständnisfrage  (Gelesen 3168 mal)

Offline KarlHeinz2000

  • Full Member
  • ***
  • Beiträge: 183
ACK Verständnisfrage
« am: 30 September 2020, 15:16:27 »
Ich habe einen kleinen RS485 Aufbau mit GW und einem Node und teste das ACK, um meine Übertragung zuverlässiger zu machen.
Dabei ist mir aufgefallen, dass im Falle eines fehlenden ACK das heartbeat reading auf NACK gesetzt wird und nicht der state. Soll das so sein?
Heartbeat wird auch nur durch ein gesendetes Heartbeat wieder auf alive gesetzt. Ein erfolgreiches ACK bewirkt das nicht.
Wie wäre der angedachte Ablauf? Ich sende Daten zum Node mit ACK aktiv und warte dann, ob das entsprechende Reading innerhalb einer Zeit auf den neuen Wert geht? Wenn nicht-> nicht zugestellt. Oder wertet man das heartbeat reading bzgl NACK aus? Aber wie?

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13280
  • "Developer"?!? Meistens doch eher "User"
Antw:ACK Verständnisfrage
« Antwort #1 am: 01 Oktober 2020, 08:08:23 »
Also, die story war die, dass heartbeat ursprünglich mal in state stattgefunden hat, weil das (scheinbar) gar nicht genutzt wurde.
Irgendwie war das aber nicht der richtige Ort, daher ist es insgesamt eben in ein eigenes Reading "heartbeat" gewandert, was dann nicht ganz optimal ist, wenn man es mit "state"-settern zu tun hat (also z.B. einem Relay, das man per setCommands nach "state" geschoben hat). Sowas ist aber die ziemliche Ausnahme, was man schon daran sieht, dass du nach Jahren der erste bist, der darüber grübelt ;D ...

Im Prinzip könnte man "dead" etc. ja auch wieder zurücksetzen, wenn "irgendwas" von der Node kommt. Das war mal in der Diskussion, hätte aber eine deutliche Erhöhung der Systemlast zur Folge gehabt, daher hatte ich das damals nicht umgesetzt. Du hat jetzt aber m.E. berechtigt einen "Sonderfall" aufgezeigt, werde mal schauen, wie man Antworten auf "Ack"-Anforderungen an der Stelle anders behandeln kann.

(Btw.: eine heartbeat-Message sollte nach meinem Codeverständnis eigentlich ein NACK nicht zurücksetzen, sondern erst eine zeitgerecht bestätigte (andere) ACK-Anforderung. Wenn wir das aber in der Ack-Verarbeitung berücksichtigen, kann das m.E. auch so bleiben, alles andere wäre unnötiger overhead.
Wobei man von ACK im engeren Sinne eigentlich nur noch bei nRF24 sprechen sollte, im MyS-Node-Code nennt sich das seit einiger Zeit bei anderen Transport-Layern "echo").
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13280
  • "Developer"?!? Meistens doch eher "User"
Antw:ACK Verständnisfrage
« Antwort #2 am: 01 Oktober 2020, 10:07:51 »
Mags du mal zum testen diese Routine in 10_MYSENSORS_DEVICE.pm tauschen:

sub onSetMessage {
    my $hash = shift;
    my $msg  = shift // return;
    my $name = $hash->{NAME};
    if (defined $msg->{payload}) {
      eval {
        my ($reading,$value) = rawToMappedReading($hash,$msg->{subType},$msg->{childId},$msg->{payload});
        readingsBeginUpdate($hash);
        readingsBulkUpdate($hash, $reading, $value);
        if ( defined ($hash->{setcommands}->{$value}) && $hash->{setcommands}->{$value}->{var} eq $reading ) { #$msg->{childId}
           if ($hash->{SetExtensionsCommand} && AttrVal($name, "setExtensionsEvent", undef)) {
             readingsBulkUpdate($hash,"state",$hash->{SetExtensionsCommand}) ; 
           } else {
             readingsBulkUpdate($hash,"state","$value");
             SetExtensionsCancel($hash) if !$msg->{ack};
           }
         }
      };
      readingsBulkUpdate($hash,"heartbeat","alive") if $msg->{ack} && ReadingsVal($hash,"heartbeat","dead") eq "NACK" and @{$hash->{IODev}->{messagesForRadioId}->{$hash->{radioId}}->{messages}} == 0;
      readingsEndUpdate( $hash, 1 );
      Log3 ($hash->{NAME}, 4, "MYSENSORS_DEVICE $hash->{NAME}: ignoring C_SET-message ".GP_Catch($@)) if $@;
    } else {
      Log3 ($hash->{NAME}, 5, "MYSENSORS_DEVICE $hash->{NAME}: ignoring C_SET-message without payload");
    }
    return;
}
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline KarlHeinz2000

  • Full Member
  • ***
  • Beiträge: 183
Antw:ACK Verständnisfrage
« Antwort #3 am: 01 Oktober 2020, 10:09:16 »
Alles klar. Mache ich heute Abend.
Danke.

Offline KarlHeinz2000

  • Full Member
  • ***
  • Beiträge: 183
Antw:ACK Verständnisfrage
« Antwort #4 am: 01 Oktober 2020, 17:16:05 »
Habe das kurz getestet. Keine Änderung. :(
Nach einem fehlenden ACK bleibt das heartbeat reading auf NACK. Egal ob die ACKs später wieder kommen. Auch einreboot des Node ändert nichts. Nur ein gesendeter heartbeat setzt das reading auf alive. Der Übergang von dead auf NACK funktioniert.

PS:
das requestAck Attribut lässt sich nur mit deleteattr löschen. Das Ändern über das drop down Feld geht nicht (es wird immer 1 angezeigt)

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13280
  • "Developer"?!? Meistens doch eher "User"
Antw:ACK Verständnisfrage
« Antwort #5 am: 01 Oktober 2020, 17:34:02 »
Grummel, da war ich wohl etwas verpeilt, was das Ziel der ReadingsVal-Abfrage anging...

So sollte der Teil besser sein:
sub onSetMessage {
    my $hash = shift;
    my $msg  = shift // return;
    my $name = $hash->{NAME};
    if (defined $msg->{payload}) {
      eval {
        my ($reading,$value) = rawToMappedReading($hash,$msg->{subType},$msg->{childId},$msg->{payload});
        readingsBeginUpdate($hash);
        readingsBulkUpdate($hash, $reading, $value);
        if ( defined ($hash->{setcommands}->{$value}) && $hash->{setcommands}->{$value}->{var} eq $reading ) { #$msg->{childId}
           if ($hash->{SetExtensionsCommand} && AttrVal($name, "setExtensionsEvent", undef)) {
             readingsBulkUpdate($hash,"state",$hash->{SetExtensionsCommand}) ; 
           } else {
             readingsBulkUpdate($hash,"state","$value");
             SetExtensionsCancel($hash) if !$msg->{ack};
           }
         }
      };
      readingsBulkUpdate($hash,"heartbeat","alive") if $msg->{ack} && ReadingsVal($name,"heartbeat","dead") eq "NACK" and @{$hash->{IODev}->{messagesForRadioId}->{$hash->{radioId}}->{messages}} == 0;
      readingsEndUpdate( $hash, 1 );
      Log3 ($hash, 4, "MYSENSORS_DEVICE $name: ignoring C_SET-message ".GP_Catch($@)) if $@;
    } else {
      Log3 ($hash, 5, "MYSENSORS_DEVICE $name: ignoring C_SET-message without payload");
    }
    return;
}

Dafür finde ich es jetzt ganz und gar nicht mehr einleuchtend, dass eine heartbeat-Message das auf alive setzt, obwohl ggf. noch nicht alles zugestellt ist, was mit ACK-Anforderung versendet wurde (bzw. wiederholt dann auch versendet wird)... Da ist wohl auch noch was ändern ab Zeile 947:    if ($type == I_HEARTBEAT_RESPONSE) {
        readingsSingleUpdate($hash, "heartbeat", "alive",1) if !ReadingsVal($name,"heartbeat","alive") eq "NACK";

Ad PS:
Das mit dem "Wahr/Falsch"-Attribut ist auch in vielen anderen Fällen so, dass man das nur (auf 1) Setzen oder Löschen kann.
EDIT sagt: Es gibt jedenfalls nach meinem Verständnis sogar komische Ergebnisse, wenn man das via Kommandozeile auf "0" setzt, bitte mal ein list ansehen... (Wie gesagt, mit diesem Verhalten dürfte MYSENSORS_DEVICE kein Einzelfall sein ;) .)
« Letzte Änderung: 01 Oktober 2020, 17:52:38 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline KarlHeinz2000

  • Full Member
  • ***
  • Beiträge: 183
Antw:ACK Verständnisfrage
« Antwort #6 am: 01 Oktober 2020, 17:59:06 »
Jetzt funktioniert das ACK in der Art, dass das heartbeat reading nach Ablauf der timeoutAck Zeit auf NACK geht. Sobald die Nachricht zugestellt wurde geht es wieder auf alive. Passt, denke ich.
Allerdings ist das Alive jetzt ohne Funktion. Es gibt kein dead mehr. Das heartbeat reading bleibt immer auf alive. Nur wenn timeoutAlive geändert wird wird dead aktiv.

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13280
  • "Developer"?!? Meistens doch eher "User"
Antw:ACK Verständnisfrage
« Antwort #7 am: 01 Oktober 2020, 18:10:25 »
Hmm, vielleicht sollte man die Abfrage einfacher schreiben:
     readingsSingleUpdate($hash, "heartbeat", "alive",1) if ReadingsVal($name,"heartbeat","alive") ne "NACK";
Danke für's Testen und Mitdenken!
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline KarlHeinz2000

  • Full Member
  • ***
  • Beiträge: 183
Antw:ACK Verständnisfrage
« Antwort #8 am: 01 Oktober 2020, 20:00:24 »
geht immer noch nicht. Das reading wechselt nicht von alive nach dead.

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13280
  • "Developer"?!? Meistens doch eher "User"
Antw:ACK Verständnisfrage
« Antwort #9 am: 02 Oktober 2020, 08:17:08 »
Vermutlich habe ich was noch nicht richtig verstanden. Was genau meinst du mit
Allerdings ist das Alive jetzt ohne Funktion. Es gibt kein dead mehr. Das heartbeat reading bleibt immer auf alive. Nur wenn timeoutAlive geändert wird wird dead aktiv.

Grundsätzlich ist "dead" nur erreichbar, wenn timeoutAlive gesetzt ist. Du schreibst aber, dass das timeoutAlive geändert werden müßte. Dann war das gesetzt, allerdings muss der Timer wieder aktiviert werden, daher nochmaliges setzen.
(Dann hat das aber eher was mit der Änderung in onSetMessage() zu tun und nichts mit der  I_HEARTBEAT_RESPONSE-Geschichte? Das Verhalten müsste dann (fast) gleich sein, egal, was dort passiert... Grübel, werde mir das mit den Timern nochmal ansehen müssen, aber eine Klarstellung wäre ggf. hilfreich).
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline KarlHeinz2000

  • Full Member
  • ***
  • Beiträge: 183
Antw:ACK Verständnisfrage
« Antwort #10 am: 02 Oktober 2020, 09:22:30 »
Ich versuche mal das Verhalten zu beschreiben:

1)
requestAck 0
timeoutAlive 3

dead/alive funktioniert. Nach Ablauf timeoutAlive geht reading auf dead
- gesendetes heartbeat vom node: dead -> alive (->dead)
- ändern der timeoutAlive: dead->alive(->dead)

2)
requestAck 1
timeoutAck 2
timeoutAlive 3

RS485 Verbindung händisch unterbrochen.

Senden-> Reading geht auf NACK nach Ablauf der timeoutAck.
Ist die Verbindung wieder hergestellt, kommt nach einigen Sek ein erneuter/automatischer Sendeversuch. Dieser gelingt. Das reading wird von NACK->alive gesetzt (retry von FHEM oder GW?).
Es bleibt dann alive, außer:
- Wenn ein heartbeat vom node kommt, läuft die Zeit erneut ab und dead wird gesetzt.
- Die timeoutAlive Zeit wird geändert
- Übertragung ist gestört ->NACK


Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13280
  • "Developer"?!? Meistens doch eher "User"
Antw:ACK Verständnisfrage
« Antwort #11 am: 02 Oktober 2020, 09:34:13 »
OK, dann muss der Timer auch an der Stelle wieder in Gang gesetzt werden. Ergo sollte das hier helfen:

sub onSetMessage {
    my $hash = shift;
    my $msg  = shift // return;
    my $name = $hash->{NAME};
    if (defined $msg->{payload}) {
      readingsBeginUpdate($hash);
      eval {
        my ($reading,$value) = rawToMappedReading($hash,$msg->{subType},$msg->{childId},$msg->{payload});
     
        readingsBulkUpdate($hash, $reading, $value);
        if ( defined ($hash->{setcommands}->{$value}) && $hash->{setcommands}->{$value}->{var} eq $reading ) { #$msg->{childId}
           if ($hash->{SetExtensionsCommand} && AttrVal($name, "setExtensionsEvent", undef)) {
             readingsBulkUpdate($hash,"state",$hash->{SetExtensionsCommand}) ; 
           } else {
             readingsBulkUpdate($hash,"state","$value");
             SetExtensionsCancel($hash) if !$msg->{ack};
           }
         }
      };
      if ($msg->{ack} && ReadingsVal($name,"heartbeat","dead") eq "NACK" and @{$hash->{IODev}->{messagesForRadioId}->{$hash->{radioId}}->{messages}} == 0) {
         readingsBulkUpdate($hash,"heartbeat","alive") ;
         refreshInternalMySTimer($hash,"Alive") if $hash->{timeoutAlive};
      }
      readingsEndUpdate( $hash, 1 );
      Log3 ($hash, 4, "MYSENSORS_DEVICE $name: ignoring C_SET-message ".GP_Catch($@)) if $@;
    } else {
      Log3 ($hash, 5, "MYSENSORS_DEVICE $name: ignoring C_SET-message without payload");
    }
    return;
}
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline KarlHeinz2000

  • Full Member
  • ***
  • Beiträge: 183
Antw:ACK Verständnisfrage
« Antwort #12 am: 02 Oktober 2020, 12:05:44 »
Sieht gut aus!  :)
Soweit ich es testen konnte ist alles ok.

Ein eingehendes heartbeat vom Node generiert allerdings 2 alive events im monitor. Soll das so sein? War evtl auch vorher schon so...

Und jetzt geht es an die Umsetzung der eigentlichen Kommunikation mit ACK. Da habe ich auf FHEM Seite noch keine Idee.
Eine Sub schreiben, in der gesendet wird und gleichzeitig ein Timer läuft und auf das ACK wartet?
Wie kann ich sicherstellen, dass ein empfangenes ACK auch zu meiner gesendeten Nachricht gehört und nicht von einem anderen Node stammt? Fängt da Protokoll das ab?
Es gibt unterschiedliche events:
MYSENSORS_DEVICE MYSENSOR_100 var2 3
MYSENSORS_DEVICE MYSENSOR_100 var2: 3
Einmal mit und ohne ":"
"Ohne" ist das Senden mit angefordertem ACK
"Mit" ist das eingehende ACK
Bei timeout ACK kommt das NACK zwischendrin

2020-10-02 11:57:35 MYSENSORS_DEVICE MYSENSOR_100 var2 3
2020-10-02 11:57:37 MYSENSORS_DEVICE MYSENSOR_100 heartbeat: NACK
2020-10-02 11:57:49 MYSENSORS_DEVICE MYSENSOR_100 var2: 3

Wird ohne requestACK gesendet kommt nur:

MYSENSORS_DEVICE MYSENSOR_100 var2: 3

Macht ein Fifo Sinn, wenn eine Nachricht länger braucht und schon eine die nächste gesendet werden soll. Wo fängt man sowas ab?



Wenn es da Ideen gibt, bitte her damit  ;)

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13280
  • "Developer"?!? Meistens doch eher "User"
Antw:ACK Verständnisfrage
« Antwort #13 am: 02 Oktober 2020, 12:24:40 »
Wg. des 2. Events: Ist vermutlich eine "Nebenwirkung" der Timer-Erneuerung, kommentiere mal in onSetEvent den Reading-Update aus:
if ($msg->{ack} && ReadingsVal($name,"heartbeat","dead") eq "NACK" and @{$hash->{IODev}->{messagesForRadioId}->{$hash->{radioId}}->{messages}} == 0) {
         #readingsBulkUpdate($hash,"heartbeat","alive") ;
         refreshInternalMySTimer($hash,"Alive") if $hash->{timeoutAlive};
      }

Was die "Warteschlange" angeht: die wird vom Modul verwaltet und der Reihe nach abgearbeitet. MAn. no action required. Ob da irgendeine bessere Timing-Verarbeitung erforderlich wäre: keine Ahnung, ein Teil der Nachrichten wird nämlich auch (zusätzlich) vom GW gepuffert, das hat einen buffer, der afaik sowohl eingehende wie ausgehende Messages enthalten kann (dunkel: ~15). Von daher würde ich das "Freischießen der Leitung" nach Möglichkeit auf dem GW belassen. Wer da richtig viel Traffic hat, muss ggf. eine andere MCU einsetzen und den Nachrichtenpuffer dort vergrößern?

Die Events mit und ohne Doppelpunkt dürften normal sein, ist einmal das Setzen vom User/von FHEM aus und einmal die Antwort, ohne Ack wird so getan, als "wäre das so".
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline KarlHeinz2000

  • Full Member
  • ***
  • Beiträge: 183
Antw:ACK Verständnisfrage
« Antwort #14 am: 02 Oktober 2020, 13:01:53 »
Die 2 alive sind immer noch im event monitor. Aber nur wenn das heartbeat vom Node kommt. Wenn ich nur den timeoutAlive ändere, kommt nur 1x alive.

Wie reagiere ich, wenn beim Senden etwas nicht ankommt. z.B: 3 Nachrichten sollen gesendet werden. Bei der 2. gibt es kein ACK. Wie bekomme ich das mit? Wird dann abgebrochen oder noch x-Mal probiert? Geht die 3. Nachricht noch raus?

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13280
  • "Developer"?!? Meistens doch eher "User"
Antw:ACK Verständnisfrage
« Antwort #15 am: 02 Oktober 2020, 13:55:52 »
Puh, dickes Brett, aber m.E. war das mit den Timern der entscheidende Hinweis. Kann zwar sein, dass das jetzt erst mal noch eine Regression gibt, aber im Prinzip sollte es zielführend sein, alles in den Timer-Erneuerungen abzuklären und (im Prinzip) auch nur da die Events zu erzeugen. Da das ganze jetzt auf ein paar Stellen verteilt ist, das ganze Packet anbei.

Was die Queue angeht: Das Modul versucht - in immer größeren Abständen - zuzustellen, solange, bis es eine Bestätigung gibt (oder einen neuen Content, der an das Noce/Child-Paar gehen soll). Erst mit der Bestätigung fliegt das aus der Queue (oder mit einem FHEM-Restart).
Konkret auf dein Beispiel bedeutet es, dass die 2. und 3. Nachricht "ewig" wiederholt wird. Die Größe der Warteschlange insgesamt steht auch irgendwo (aus dem Gedächtnis: beim GW, bitte ggf. in die Internals und lists schauen).

(EDIT: gleich noch eine etwas erweiterte Meta-Unterstützung eingebaut).
« Letzte Änderung: 03 Oktober 2020, 08:56:38 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline KarlHeinz2000

  • Full Member
  • ***
  • Beiträge: 183
Antw:ACK Verständnisfrage
« Antwort #16 am: 05 Oktober 2020, 09:06:04 »
Moin,
habe das heute noch mal getestet und es funktioniert.

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13280
  • "Developer"?!? Meistens doch eher "User"
Antw:ACK Verständnisfrage
« Antwort #17 am: 05 Oktober 2020, 09:50:04 »
Danke für die Rückmeldung, dann checke ich das bei Gelegenheit ein :) .
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline KarlHeinz2000

  • Full Member
  • ***
  • Beiträge: 183
Antw:ACK Verständnisfrage
« Antwort #18 am: 10 November 2020, 21:47:06 »
Mir ist noch was aufgefallen. Wenn ich von FHEM aus ohne payload sende, dann wird das vom node kommende ECHO nicht erkannt und zyklisch wiederholt gesendet.
Ich habe eine "0" dann "" dann "0" gesendet
Das ECHO bei "" wurde nicht erkannt und deswegen 3 Mal wiederholt.

2020.11.10 21:36:47 4: MYSENSORS/RAW: /0;255
2020.11.10 21:36:47 4: MYSENSORS/RAW: 0;255/;3;0;9;53010
2020.11.10 21:36:47 4: MYSENSORS/RAW: 0;255;3;0;9;53010/0657
2020.11.10 21:36:47 4: MYSENSORS/RAW: 0;255;3;0;9;530100657 /TSF:SAN:OK

2020.11.10 21:36:47 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '530100657 TSF:SAN:OK'

2020.11.10 21:36:47 5: MYSENSORS gateway gateway: 530100657 TSF:SAN:OK
2020.11.10 21:36:49 5: MYSENSORS send: Rx: fr=070 ci=000 c=001(C_SET         ) st=047(V_TEXT          ) ack=1 '0'

2020.11.10 21:36:49 5: SW: 37303b303b313b313b34373b300a
2020.11.10 21:36:49 5: MYSENSOR_70: refreshInternalMySTimer called (Ack)
2020.11.10 21:36:49 5: MYSENSOR_70: Ack timeout timer set at 1605040609.34201
2020.11.10 21:36:49 5: MYSENSOR_70 is not sleeping, sending message!
2020.11.10 21:36:49 5: gateway: getFirmwareTypes - list contains:
2020.11.10 21:36:49 5: MYSENSOR_70: timeoutAck called
2020.11.10 21:36:49 4: MYSENSOR_70: timeoutAck called, outstanding: 1
2020.11.10 21:36:49 5: gateway: getFirmwareTypes - list contains:
2020.11.10 21:36:49 4: MYSENSORS/RAW: /0;255;3;0;9;530102025 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=0,l=1,sg=0,ft=0,st=OK:0
0;255;3;0;9;530102046 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=0,l=1,sg=0:0
0;255;3;0;9;530102066 TSF:MSG:ECHO
70;0;1;1;47;0

2020.11.10 21:36:49 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '530102025 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=0,l=1,sg=0,ft=0,st=OK:0'

2020.11.10 21:36:49 5: MYSENSORS gateway gateway: 530102025 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=0,l=1,sg=0,ft=0,st=OK:0
2020.11.10 21:36:49 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '530102046 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=0,l=1,sg=0:0'

2020.11.10 21:36:49 5: MYSENSORS gateway gateway: 530102046 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=0,l=1,sg=0:0
2020.11.10 21:36:49 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '530102066 TSF:MSG:ECHO'

2020.11.10 21:36:49 5: MYSENSORS gateway gateway: 530102066 TSF:MSG:ECHO
2020.11.10 21:36:49 4: MYSENSORS Read: Rx: fr=070 ci=000 c=001(C_SET         ) st=047(V_TEXT          ) ack=1 '0'

2020.11.10 21:36:49 5: MYSENSOR_70: refreshInternalMySTimer called (Alive)
2020.11.10 21:36:49 5: gateway: getFirmwareTypes - list contains:
2020.11.10 21:36:49 5: MYSENSOR_70: refreshInternalMySTimer called (Ack)
2020.11.10 21:36:49 5: MYSENSOR_70: Ack timeout timer set at 1605040609.55885
2020.11.10 21:36:49 5: MYSENSOR_70: timeoutAck called
2020.11.10 21:36:49 4: MYSENSOR_70: timeoutAck called, no outstanding Acks at all
2020.11.10 21:36:53 5: MYSENSORS send: Rx: fr=070 ci=000 c=001(C_SET         ) st=047(V_TEXT          ) ack=1 ''

2020.11.10 21:36:53 5: SW: 37303b303b313b313b34373b0a
2020.11.10 21:36:53 5: MYSENSOR_70: refreshInternalMySTimer called (Ack)
2020.11.10 21:36:53 5: MYSENSOR_70: Ack timeout timer set at 1605040613.70833
2020.11.10 21:36:53 5: MYSENSOR_70 is not sleeping, sending message!
2020.11.10 21:36:53 5: gateway: getFirmwareTypes - list contains:
2020.11.10 21:36:53 4: MYSENSORS/RAW: /0;255;3;0;9;530106392 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=1,l=1,sg=0,ft=0,st=OK:0
0;255;3;0;9;530106415 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=1,l=1,sg=0:
2020.11.10 21:36:53 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '530106392 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=1,l=1,sg=0,ft=0,st=OK:0'

2020.11.10 21:36:53 5: MYSENSORS gateway gateway: 530106392 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=1,l=1,sg=0,ft=0,st=OK:0
2020.11.10 21:36:53 4: MYSENSORS/RAW: 0;255;3;0;9;530106415 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=1,l=1,sg=0:/0
0;255;3;0;9;53
2020.11.10 21:36:53 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '530106415 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=1,l=1,sg=0:0'

2020.11.10 21:36:53 5: MYSENSORS gateway gateway: 530106415 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=1,l=1,sg=0:0
2020.11.10 21:36:53 4: MYSENSORS/RAW: 0;255;3;0;9;53/0106434 TSF:MSG:ECHO

2020.11.10 21:36:53 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '530106434 TSF:MSG:ECHO'

2020.11.10 21:36:53 5: MYSENSORS gateway gateway: 530106434 TSF:MSG:ECHO
2020.11.10 21:36:53 4: MYSENSORS/RAW: /70;0;1;1;47;0

2020.11.10 21:36:53 4: MYSENSORS Read: Rx: fr=070 ci=000 c=001(C_SET         ) st=047(V_TEXT          ) ack=1 '0'

2020.11.10 21:36:53 4: MYSENSORS Read: unexpected ack Rx: fr=070 ci=000 c=001(C_SET         ) st=047(V_TEXT          ) ack=1 '0'

2020.11.10 21:36:53 5: MYSENSOR_70: refreshInternalMySTimer called (Alive)
2020.11.10 21:36:53 5: gateway: getFirmwareTypes - list contains:
2020.11.10 21:36:53 5: MYSENSOR_70: refreshInternalMySTimer called (Ack)
2020.11.10 21:36:53 5: MYSENSOR_70: Ack timeout timer set at 1605040613.81766
2020.11.10 21:36:53 5: MYSENSOR_70: timeoutAck called
2020.11.10 21:36:53 4: MYSENSOR_70: timeoutAck called, outstanding: 1
2020.11.10 21:36:53 5: gateway: getFirmwareTypes - list contains:
2020.11.10 21:36:55 5: MYSENSORS outstanding ack, re-send: Rx: fr=070 ci=000 c=001(C_SET         ) st=047(V_TEXT          ) ack=1 ''

2020.11.10 21:36:55 5: SW: 37303b303b313b313b34373b0a
2020.11.10 21:36:55 4: MYSENSORS/RAW: /0;25
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;25/5;3;0;
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3;0;/9;530
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3;0;9;530/107787
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3;0;9;530107787/ TSF:
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3;0;9;530107787 TSF:/MSG:SE
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3;0;9;530107787 TSF:MSG:SE/ND,0-
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3;0;9;530107787 TSF:MSG:SEND,0-/0-70-7
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3;0;9;530107787 TSF:MSG:SEND,0-0-70-7/0,s=0
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3;0;9;530107787 TSF:MSG:SEND,0-0-70-70,s=0/,c=1,t
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3;0;9;530107787 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t/=47,pt
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3;0;9;530107787 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt/=1,l=
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3;0;9;530107787 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=1,l=/1,sg=0
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3;0;9;530107787 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=1,l=1,sg=0/,ft=0
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3;0;9;530107787 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=1,l=1,sg=0,ft=0/,st=OK
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3;0;9;530107787 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=1,l=1,sg=0,ft=0,st=OK/:0
0
2020.11.10 21:36:55 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '530107787 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=1,l=1,sg=0,ft=0,st=OK:0'

2020.11.10 21:36:55 5: MYSENSORS gateway gateway: 530107787 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=1,l=1,sg=0,ft=0,st=OK:0
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0/;255;3
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3/;0;9;5
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3;0;9;5/30107
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3;0;9;530107/809 TS
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3;0;9;530107809 TS/F:MSG
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3;0;9;530107809 TSF:MSG/:READ,
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3;0;9;530107809 TSF:MSG:READ,/70-70
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3;0;9;530107809 TSF:MSG:READ,70-70/-0,s=0
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3;0;9;530107809 TSF:MSG:READ,70-70-0,s=0/,c=1,
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3;0;9;530107809 TSF:MSG:READ,70-70-0,s=0,c=1,/t=47,p
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3;0;9;530107809 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,p/t=1,l=
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3;0;9;530107809 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=1,l=/1,sg=
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3;0;9;530107809 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=1,l=1,sg=/0:0
0
2020.11.10 21:36:55 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '530107809 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=1,l=1,sg=0:0'

2020.11.10 21:36:55 5: MYSENSORS gateway gateway: 530107809 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=1,l=1,sg=0:0
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0/;255;3
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3/;0;9;5
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3;0;9;5/30107
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3;0;9;530107/828 TS
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3;0;9;530107828 TS/F:MSG
2020.11.10 21:36:55 4: MYSENSORS/RAW: 0;255;3;0;9;530107828 TSF:MSG/:ECHO

2020.11.10 21:36:55 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '530107828 TSF:MSG:ECHO'

2020.11.10 21:36:55 5: MYSENSORS gateway gateway: 530107828 TSF:MSG:ECHO
2020.11.10 21:36:55 4: MYSENSORS/RAW: /70;0
2020.11.10 21:36:55 4: MYSENSORS/RAW: 70;0/;1;1;4
2020.11.10 21:36:55 4: MYSENSORS/RAW: 70;0;1;1;4/7;0

2020.11.10 21:36:55 4: MYSENSORS Read: Rx: fr=070 ci=000 c=001(C_SET         ) st=047(V_TEXT          ) ack=1 '0'

2020.11.10 21:36:55 4: MYSENSORS Read: unexpected ack Rx: fr=070 ci=000 c=001(C_SET         ) st=047(V_TEXT          ) ack=1 '0'

2020.11.10 21:36:55 5: MYSENSOR_70: refreshInternalMySTimer called (Alive)
2020.11.10 21:36:55 5: gateway: getFirmwareTypes - list contains:
2020.11.10 21:36:55 5: MYSENSOR_70: refreshInternalMySTimer called (Ack)
2020.11.10 21:36:55 5: MYSENSOR_70: Ack timeout timer set at 1605040615.18579
2020.11.10 21:36:55 5: MYSENSOR_70: timeoutAck called
2020.11.10 21:36:55 4: MYSENSOR_70: timeoutAck called, outstanding: 1
2020.11.10 21:36:55 5: gateway: getFirmwareTypes - list contains:
2020.11.10 21:36:58 5: MYSENSORS outstanding ack, re-send: Rx: fr=070 ci=000 c=001(C_SET         ) st=047(V_TEXT          ) ack=1 ''

2020.11.10 21:36:58 5: SW: 37303b303b313b313b34373b0a
2020.11.10 21:36:58 4: MYSENSORS/RAW: /0;25
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;25/5;3;0
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3;0/;9;530
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3;0;9;530/110787
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3;0;9;530110787/ TSF:
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3;0;9;530110787 TSF:/MSG:SE
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3;0;9;530110787 TSF:MSG:SE/ND,0-
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3;0;9;530110787 TSF:MSG:SEND,0-/0-70-7
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3;0;9;530110787 TSF:MSG:SEND,0-0-70-7/0,s=0
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3;0;9;530110787 TSF:MSG:SEND,0-0-70-70,s=0/,c=1,t
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3;0;9;530110787 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t/=47,p
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3;0;9;530110787 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,p/t=1,l=
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3;0;9;530110787 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=1,l=/1,sg=
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3;0;9;530110787 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=1,l=1,sg=/0,ft=0
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3;0;9;530110787 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=1,l=1,sg=0,ft=0/,st=OK
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3;0;9;530110787 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=1,l=1,sg=0,ft=0,st=OK/:0
0
2020.11.10 21:36:58 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '530110787 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=1,l=1,sg=0,ft=0,st=OK:0'

2020.11.10 21:36:58 5: MYSENSORS gateway gateway: 530110787 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=1,l=1,sg=0,ft=0,st=OK:0
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0/;255;3
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3/;0;9;
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3;0;9;/530110
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3;0;9;530110/810 T
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3;0;9;530110810 T/SF:MSG
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3;0;9;530110810 TSF:MSG/:READ,
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3;0;9;530110810 TSF:MSG:READ,/70-70
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3;0;9;530110810 TSF:MSG:READ,70-70/-0,s=0
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3;0;9;530110810 TSF:MSG:READ,70-70-0,s=0/,c=1,
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3;0;9;530110810 TSF:MSG:READ,70-70-0,s=0,c=1,/t=47,p
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3;0;9;530110810 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,p/t=1,l
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3;0;9;530110810 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=1,l/=1,sg=
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3;0;9;530110810 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=1,l=1,sg=/0:0
0
2020.11.10 21:36:58 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '530110810 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=1,l=1,sg=0:0'

2020.11.10 21:36:58 5: MYSENSORS gateway gateway: 530110810 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=1,l=1,sg=0:0
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0/;255;3
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3/;0;9;
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3;0;9;/530110
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3;0;9;530110/828 TS
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3;0;9;530110828 TS/F:MSG
2020.11.10 21:36:58 4: MYSENSORS/RAW: 0;255;3;0;9;530110828 TSF:MSG/:ECHO

2020.11.10 21:36:58 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '530110828 TSF:MSG:ECHO'

2020.11.10 21:36:58 5: MYSENSORS gateway gateway: 530110828 TSF:MSG:ECHO
2020.11.10 21:36:58 4: MYSENSORS/RAW: /70;0
2020.11.10 21:36:58 4: MYSENSORS/RAW: 70;0/;1;1;4
2020.11.10 21:36:58 4: MYSENSORS/RAW: 70;0;1;1;4/7;0

2020.11.10 21:36:58 4: MYSENSORS Read: Rx: fr=070 ci=000 c=001(C_SET         ) st=047(V_TEXT          ) ack=1 '0'

2020.11.10 21:36:58 4: MYSENSORS Read: unexpected ack Rx: fr=070 ci=000 c=001(C_SET         ) st=047(V_TEXT          ) ack=1 '0'

2020.11.10 21:36:58 5: MYSENSOR_70: refreshInternalMySTimer called (Alive)
2020.11.10 21:36:58 5: gateway: getFirmwareTypes - list contains:
2020.11.10 21:36:58 5: MYSENSOR_70: refreshInternalMySTimer called (Ack)
2020.11.10 21:36:58 5: MYSENSOR_70: Ack timeout timer set at 1605040618.18538
2020.11.10 21:36:58 5: MYSENSOR_70: timeoutAck called
2020.11.10 21:36:58 4: MYSENSOR_70: timeoutAck called, outstanding: 1
2020.11.10 21:36:58 5: gateway: getFirmwareTypes - list contains:
2020.11.10 21:37:01 5: MYSENSORS outstanding ack, re-send: Rx: fr=070 ci=000 c=001(C_SET         ) st=047(V_TEXT          ) ack=1 ''

2020.11.10 21:37:01 5: SW: 37303b303b313b313b34373b0a
2020.11.10 21:37:01 4: MYSENSORS/RAW: /0;2
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;2/55;3;
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;/0;9;53
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;53/01137
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;5301137/87 TSF
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;530113787 TSF/:MSG:S
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;530113787 TSF:MSG:S/END,0
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;530113787 TSF:MSG:SEND,0/-0-70-
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;530113787 TSF:MSG:SEND,0-0-70-/70,s=
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;530113787 TSF:MSG:SEND,0-0-70-70,s=/0,c=1,
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;530113787 TSF:MSG:SEND,0-0-70-70,s=0,c=1,/t=47,
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;530113787 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,/pt=1,l
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;530113787 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=1,l/=1,sg
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;530113787 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=1,l=1,sg/=0,ft=
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;530113787 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=1,l=1,sg=0,ft=/0,st=O
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;530113787 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=1,l=1,sg=0,ft=0,st=O/K:0

2020.11.10 21:37:01 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '530113787 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=1,l=1,sg=0,ft=0,st=OK:0'

2020.11.10 21:37:01 5: MYSENSORS gateway gateway: 530113787 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=1,l=1,sg=0,ft=0,st=OK:0
2020.11.10 21:37:01 4: MYSENSORS/RAW: /0;255
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255/;3;0;
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;/9;5301
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;5301/13810
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;530113810/ TSF:M
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;530113810 TSF:M/SG:REA
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;530113810 TSF:MSG:REA/D,70-
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;530113810 TSF:MSG:READ,70-/70-0,s
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;530113810 TSF:MSG:READ,70-70-0,s/=0,c=
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;530113810 TSF:MSG:READ,70-70-0,s=0,c=/1,t=47
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;530113810 TSF:MSG:READ,70-70-0,s=0,c=1,t=47/,pt=1
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;530113810 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=1/,l=1,s
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;530113810 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=1,l=1,s/g=0:0
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;530113810 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=1,l=1,sg=0:0/
0;25
2020.11.10 21:37:01 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '530113810 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=1,l=1,sg=0:0'

2020.11.10 21:37:01 5: MYSENSORS gateway gateway: 530113810 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=1,l=1,sg=0:0
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;25/5;3;0
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0/;9;530
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;530/113828
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;530113828/ TSF:
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;530113828 TSF:/MSG:EC
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;530113828 TSF:MSG:EC/HO
7
2020.11.10 21:37:01 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '530113828 TSF:MSG:ECHO'

2020.11.10 21:37:01 5: MYSENSORS gateway gateway: 530113828 TSF:MSG:ECHO
2020.11.10 21:37:01 4: MYSENSORS/RAW: 7/0;0;1;
2020.11.10 21:37:01 4: MYSENSORS/RAW: 70;0;1;/1;47;
2020.11.10 21:37:01 4: MYSENSORS/RAW: 70;0;1;1;47;/0

2020.11.10 21:37:01 4: MYSENSORS Read: Rx: fr=070 ci=000 c=001(C_SET         ) st=047(V_TEXT          ) ack=1 '0'

2020.11.10 21:37:01 4: MYSENSORS Read: unexpected ack Rx: fr=070 ci=000 c=001(C_SET         ) st=047(V_TEXT          ) ack=1 '0'

2020.11.10 21:37:01 5: MYSENSOR_70: refreshInternalMySTimer called (Alive)
2020.11.10 21:37:01 5: gateway: getFirmwareTypes - list contains:
2020.11.10 21:37:01 5: MYSENSOR_70: refreshInternalMySTimer called (Ack)
2020.11.10 21:37:01 5: MYSENSOR_70: Ack timeout timer set at 1605040621.18625
2020.11.10 21:37:01 5: MYSENSOR_70: timeoutAck called
2020.11.10 21:37:01 4: MYSENSOR_70: timeoutAck called, outstanding: 1
2020.11.10 21:37:01 5: gateway: getFirmwareTypes - list contains:
2020.11.10 21:37:01 5: MYSENSORS send: Rx: fr=070 ci=000 c=001(C_SET         ) st=047(V_TEXT          ) ack=1 '0'

2020.11.10 21:37:01 5: SW: 37303b303b313b313b34373b300a
2020.11.10 21:37:01 5: MYSENSOR_70: refreshInternalMySTimer called (Ack)
2020.11.10 21:37:01 5: MYSENSOR_70: Ack timeout timer set at 1605040621.95284
2020.11.10 21:37:01 5: MYSENSOR_70 is not sleeping, sending message!
2020.11.10 21:37:01 5: gateway: getFirmwareTypes - list contains:
2020.11.10 21:37:01 4: MYSENSORS/RAW: /0;255;3;0;9;530114635 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=0,l=1,sg=0,ft=0,st=OK:0
0;255;3;0;9;530114658 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=0,l=1,sg=
2020.11.10 21:37:01 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '530114635 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=0,l=1,sg=0,ft=0,st=OK:0'

2020.11.10 21:37:01 5: MYSENSORS gateway gateway: 530114635 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=0,l=1,sg=0,ft=0,st=OK:0
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;530114658 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=0,l=1,sg=/0:0
0;255;3;0;9;
2020.11.10 21:37:01 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '530114658 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=0,l=1,sg=0:0'

2020.11.10 21:37:01 5: MYSENSORS gateway gateway: 530114658 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=0,l=1,sg=0:0
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;/530114677 TSF:MSG:ECHO
2020.11.10 21:37:01 4: MYSENSORS/RAW: 0;255;3;0;9;530114677 TSF:MSG:ECHO/
70;0
2020.11.10 21:37:01 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '530114677 TSF:MSG:ECHO'

2020.11.10 21:37:01 5: MYSENSORS gateway gateway: 530114677 TSF:MSG:ECHO
2020.11.10 21:37:01 4: MYSENSORS/RAW: 70;0/;1;1;47;0

2020.11.10 21:37:01 4: MYSENSORS Read: Rx: fr=070 ci=000 c=001(C_SET         ) st=047(V_TEXT          ) ack=1 '0'

2020.11.10 21:37:01 5: MYSENSOR_70: refreshInternalMySTimer called (Alive)
2020.11.10 21:37:01 5: gateway: getFirmwareTypes - list contains:
2020.11.10 21:37:01 5: MYSENSOR_70: refreshInternalMySTimer called (Ack)
2020.11.10 21:37:01 5: MYSENSOR_70: Ack timeout timer set at 1605040622.06195
2020.11.10 21:37:02 5: MYSENSOR_70: timeoutAck called
2020.11.10 21:37:02 4: MYSENSOR_70: timeoutAck called, no outstanding Acks at all

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13280
  • "Developer"?!? Meistens doch eher "User"
Antw:ACK Verständnisfrage
« Antwort #19 am: 11 November 2020, 10:51:27 »
Boa, nicht so einfach, nichts von nichts zu unterscheiden; kann ggf. unerwünschte Nebenwirkungen haben...

Kannst du mal testweise in 00_MYSENSORS folgende Zeile zum Ergänzen der fehlenden payload was reinbasteln:
sub onAcknowledge {
  my ($hash,$msg) = @_;
  my $ack;
  $msg->{payload} = '' if !defined $msg->{payload};
  if (defined (my $outstanding = $hash->{messagesForRadioId}->{$msg->{radioId}}->{messages})) {

Irgendwann muß ich auch das mit den firmware-update-Nachfragen fixen, das ist irgendwie unschön...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline KarlHeinz2000

  • Full Member
  • ***
  • Beiträge: 183
Antw:ACK Verständnisfrage
« Antwort #20 am: 11 November 2020, 23:11:20 »
Funktioniert leider nicht. Wobei ich mir immer noch nicht im klaren bin, was FHEM bei "" wirklich sendet. Ist das wirklich nichts/leer/... oder doch irgendein Zeichen? NULL? Wie bekommt man da ran? Auf dem RX vom GW mitmessen?

Wenn ich mit FHEM "" sende steht im log vom node

22:45:26.259 -> 816348 TSF:MSG:SEND,70-70-0-0,s=0,c=1,t=47,pt=1,l=1,sg=0,ft=0,st=OK:0
22:45:26.259 -> ID: 0, Data:
22:45:26.259 -> ret is <null>

Parallel mit einem anderen GW am MYSController
11.11.2020 22:45:26 RX 0;255;3;0;9;2103425 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=1,l=1,sg=0:0
11.11.2020 22:45:26 RX 0;255;3;0;9;2103443 TSF:MSG:ACK
11.11.2020 22:45:26 RX 70;0;1;1;47;0

Beides mal wird "0" angezeigt, wobei der Node das als NULL /0 erkennt. Das scheint keine normale 0 zu sein.

Sende ich vom Node "" zu FHEM sieht das so aus
11.11.2020 22:50:00 RX 0;255;3;0;9;2377205 TSF:MSG:READ,70-70-0,s=0,c=1,t=47,pt=0,l=0,sg=0:
11.11.2020 22:50:00 RX 70;0;1;0;47;
Und "" von MYSController zum node
11.11.2020 22:57:07 TX 70;0;1;0;47;
11.11.2020 22:57:07 RX 0;255;3;0;9;2803834 TSF:MSG:SEND,0-0-70-70,s=0,c=1,t=47,pt=0,l=0,sg=0,ft=0,st=OK:

Beides mal richtig leer/kein Zeichen. Auch das ECHO funktioniert zwischen MYSController und Node.
Siehe auch https://forum.mysensors.org/post/108080
Das habe ich mittlerweile auch so selbst testen können.


Offline KarlHeinz2000

  • Full Member
  • ***
  • Beiträge: 183
Antw:ACK Verständnisfrage
« Antwort #21 am: 11 November 2020, 23:39:16 »
Nachgemessen. FHEM und MYSController versenden die gleiche Nachricht zum GW. Payload fehlt. Warum der Node das unterschiedlich darstellt???

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13280
  • "Developer"?!? Meistens doch eher "User"
Antw:ACK Verständnisfrage
« Antwort #22 am: 12 November 2020, 10:41:04 »
Bin grade auch noch am gedanklichen Puzzeln.

Habe mir auch nochmal die Vorgeschichte angesehen...
Es ist jedenfalls ein Problem, wenn was anderes zurückkommt, als versendet wurde, zumindest liegt es dann schon mal nicht an der onAcknowledge().

Aber warum versendet MYSController da auch (zusätzlich...?!?) was mit I_NONCE...?!? (Log Parser Auswertung von dem, was frits gepostet hatte)

Es gibt in jedem Fall auch ein Problem in onSetMessage() in DEVICE: Da wird vorausgesetzt, dass es eine Payload gibt, sonst wird auch das ack nicht richtig verarbeitet. Das muss ich mir wohl in jedem Fall mal anschauen, aber das hat mit deinem Problem erst mal nichts zu tun. Das mit dem I_NONCE muss ich mir wohl auch mal ansehen, bisher hatte ich nicht die leiseste Idee, für was das da sein könnte; aber evtl. geht es da tatsächlich um die Option, Inhalte mit NULL zu belegen? (Falls du eine Quelle dazu findest: her damit...)

Ansonsten bastelt FHEM bei jeder ausgehenden Message eine "Zwangspayload" mit "". Vielleicht wäre hier ein () besser (Zeile 937) (Merker für mich: abgekupfert von https://www.tutorialspoint.com/using-null-values-in-perl-database-operation).
Was anderes fällt mir grade nicht ein...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline KarlHeinz2000

  • Full Member
  • ***
  • Beiträge: 183
Antw:ACK Verständnisfrage
« Antwort #23 am: 12 November 2020, 23:07:50 »
Entwarnung in gewisser Weise.
Nach einer Menge Testen sieht es für mich so aus, dass der Fehler in der aktuellen MySensor lib liegt.
Wenn das GW mit 2.2.0 läuft ist alles gut. ECHO wird sofort erkannt.
Mit der 2.3.2 auf dem GW gibt es die Probleme, da das GW beim ECHO anstelle "" eine 0 an FHEM sendet.

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13280
  • "Developer"?!? Meistens doch eher "User"
Antw:ACK Verständnisfrage
« Antwort #24 am: 13 November 2020, 08:00:28 »
Hm, ok, dann lege ich das Thema mal auf die Seite.

Ich nehme an, du hast/wirst das als PR bei MySensors einkippen, oder?
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13280
  • "Developer"?!? Meistens doch eher "User"
Antw:ACK Verständnisfrage
« Antwort #25 am: 21 November 2020, 08:13:32 »
Danke für die Rückmeldung, dann checke ich das bei Gelegenheit ein :) .
Done!
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

 

decade-submarginal