Regelmäßiges neighborUpdate

[krikan]

Das Wakeupintervall steht auf 15 Minuten. Die Route zum Controller läuft über eine Funksteckdose, die wiederum über eine andere Funksteckdose mit dem Controller kommuniziert. Das mit den mehrfachen wakeups passiert nur bei diesem Regler. Bei anderen kommt es sporadisch zu den NO_ACK Meldungen und falls dabei mal was auf dem sendstack hängen bleibt, dann reguliert sich das nach kurzer Zeit wieder.

Dann tippe ich auf Defekt oder nicht optimale Funkverbindung.

Macht es Sinn mit dem WNMI_Delay zu experimentieren? Wenn ja, mit welchem Wert?

Da kann ich bei dem merkwürdigen Regler keinen Zusammenhang erkennen.
Bei den anderen könnten NO_ACK minimiert werden, wenn die zu schnell schlafen gehen. 1s sollte ungefaehrlich sein.

Wie Du merkst, ist das alles leider sehr viel Raterei...

[ToKa]

So seit 1,5 h ist Ruhe im Log!!!!

Ich habe die 3 einzelnen notifys für den störrischen Regler so wie von Dir vorgeschlagen eingerichtet und seither ist kein Fehler mehr aufgetreten. Für die anderen Regler läuft weiterhin das notify, das alle 3 Werte abfrägt. Ich beobachte das Log mal weiter und falls bei den anderen auch wieder Fehler auftreten, baue ich das generelle notify auf 3 Stück um.

Vielen Dank für Deine Unterstützung und den Tipp!
(Verstehen muss ich das jetzt aber nicht... wäre aber trotzdem beruhigter, wenn das alles etwas stabiler laufen würde)

Gruß

Torsten

[krikan]

Wenn aufgrund von Netzstörungen der hier festgestellte https://forum.fhem.de/index.php/topic,65055.msg568121.html#msg568121 bzw. hier bereits befürchtete

Probiere es einmal aus. Aber komplett wird es das Problem vermutlich nicht beheben, wenn 3 WUN oder 3 Antworten auf gleiche Abfragen kommen.

Effekt durch mehrfache Antworten auf Protokollebene eintritt, faellt mir als Notbehelf bei weiterhin bestehenden Poll-Wunsch nur die Verhinderung der mehrfachen Ablage des gleichen Befehls im Sendstack ein. (Duplikatserkennung)

Also vor Ablage eines get-Befehls im Sendstack prüfen, ob der gleiche Befehl nicht schon im Sendstack liegt.
-> ja, get-Befehl nicht ablegen
-> nein, get-Befehl ablegen

Betone, dass das auch wieder nur ein dummes Hilfskonstrukt für dieses "kaputte" Geraet/Netz ist.

Oder Du gehst auf ein at mit dem alle Befehle regelmaeßig in den Sendstack gelegt werden, statt notify. Aber auch das wird vermutlich nicht die Lösung bringen, da die Kommunikation mit den Geraeten sehr fragil zu sein scheint.

Gruß, Christian

[rudolfkoenig]

Ich habe das Thema nochmal durchgelesen, und versuche den Stand (auch aus den anderen Themen) zusammenzufassen:

- In diesem Netz gibt es mehrere Heizungsregler (9+ Stueck), die alle 15 Minuten 3 Werte melden sollen. Das sind mit der aktuellen Implementation unter idealen Verbindungen+Funkverhaeltnisse 9*(WUN+3*(get+Antwort))*2 = 126 Nachrichten, grob 8 pro Minute.
- Einer der Regler macht (mehr?) Probleme, er sollte ueber 2 Steckdosen geroutet sein.
- Falls eine Nachricht ueber mehrere Router geschickt wird, dann gibt es bei jeden Hop ein Ack an den Vorherigen+1 "Overall-Ack". D.h. eine Nachricht ueber 2 Hops bedeutet  3*2+1=7 Funktelegramme. Das koennte man (nur?) mit einem ZWCUL verifizieren, ich habe das aber bei mir so schon gesehen.
- In diesem Netz gehen Acks in beide Richtungen verloren, was zu Wiederholen der Meldungen fuehrt.
- Wenn an dem WUN FHEM-Notifies haengen, die ihrerseits 3 Werte abfragen, fuehrt das bestenfalls zu: 1*WUN => 3*Get => 3*Antwort => 7*7=49 Funknachrichten, schlimmstenfalls zu 3*WUN => 9*Get => 27*Antwort => 39*7=283 Funknachrichten.
- notify jeweils an dem naechsten Antwort zu koppeln scheint das Problem zu entschaerfen, was ich nicht erklaeren kann.

-> Ich wundere mich nicht, dass diese Kommunikation (Geraet ueber 2 Hops regelmaessig abzufragen) problematisch ist.

Loesungsansaetze:
- Organisatorisch: Geraet nicht abfragen
- Hardware:
  - ein RPi+ZWDongle per LAN in der Naehe des Reglers platzieren, und es via socat an FHEM anbinden.
  - bessere (nicht mehr!) Repeater verwenden.
- Software:
  - WUN ignorieren, falls das Geraet intern als "wach" gekennzeichnet ist
  - Antworten auf nicht ausstehende gets ignorieren. Eine Antwort kann man von einer spontenen Nachricht anhand der CallbackId unterscheiden.
  - mehrere gets auf dem Sendstack zu einem MULTI_CMD zusammenfassen.

@Christian: siehst du ein Problem mit den Software-Ansaetzen?

[krikan]

siehst du ein Problem mit den Software-Ansaetzen?

Nein. Wenn sich jemand findet, der das in ZWave/ZWDongle einbaut, wäre das wohl die optimale Lösung für solche Störungen. 
Insbesondere 2. und 3. sind mMn gefahrlos.
Bei 1. habe ich noch ein unbestimmtes Störgefühl.
Bei 2. aber bitte mit Angabe in Reading(?), dass Duplikate aussortiert wurden, um Analyse zu erleichtern und nicht "Kaputtes" durch FHEM zu verschleiern.

[krikan]

Bei 1. habe ich noch ein unbestimmtes Störgefühl.

Wenn eine erneute WUN bei einem als "wach" markiertem Gerät zur Verlängerung des Wachzeitraums führt, aber nicht zu einem Event, halte ich es für OK. Wobei die "Duplikatserkennung" mMn zeitlich begrenzt sein sollte.

[rudolfkoenig]

Ich versteh noch nicht dein Bauchgefuehl bei 1. Hast du sowas schon beobachtet oder darueber gelesen?

Will alle 3 Optionen erstmal per Attribut aktivierbar machen, faellt mir nur kein Name ein.

[krikan]

Ich versteh noch nicht dein Bauchgefuehl bei 1. Hast du sowas schon beobachtet oder darueber gelesen?

Kann mich nicht erinnern, darum unbestimmt. Mache es einfach; unbestimmte Gefühle gehören hier eigentlich nicht hin.

Will alle 3 Optionen erstmal per Attribut aktivierbar machen, faellt mir nur kein Name ein.

Aber hoffentlich 3 Stück oder zumindest für 3. ein separates!? Eines fände ich nicht ideal.

[ToKa]

Hallo Ihr Beiden,

vielen Dank, dass Ihr Euch so sehr den Kopf wegen meines Problems zerbrecht und nach Lösungen sucht.

Zu den Lösungsansätzen, die ich selbst angehen kann:
- Gerät nicht abfragen, würde halt Blindflug bedeuten...
- Zweiter PI mit RazBerry steht hier rum. Hatte ja auf PI3 und RazBerry2 umgestellt mit der Hoffnung, der RazBerry2 hätte mehr Reichweite (kann ich aktuell nicht bestätigen). Bin aber am Überlegen, ob ich den zweiten PI nicht mit Homematic ausstatten soll, um damit mal Erfahrung bzgl. Reichweite zu sammeln.
- welche Repeater sind denn am besten?

Wäre es noch eine Idee, nach dem letzten notify/get den sendstack des entsprechenden Geräts über das letzte notify zu löschen? set Befehle sind ja von der Reihenfolge zuerst da, bevor die gets kommen (Ausnahme genau zwischen den gets kommt ein set, das nicht gleich verarbeitet wird und auf dem stack liegen bleibt/gelöscht wird).

Kann ich im notify selbst prüfen, ob ein get auf dem sendstack liegt? Eine list Funktion, die nur den sendstack anzeigt gibt es nicht oder?

Beste Grüße
Torsten

[rudolfkoenig]

Wenn eine erneute WUN bei einem als "wach" markiertem Gerät zur Verlängerung des Wachzeitraums führt, aber nicht zu einem Event, halte ich es für OK.

Mehrfache WUNs haben auch bisher nicht zu eine Verlaengerung gefuehrt. Das neue Attribut heisst ignoreDupMsg, ist per default aus, und implementiert #1und #2. Es wird auf loglevel 3 eine Meldung ausgegeben (Log3 $name, 3, "$name: ignore duplicate answer $event[0]" falls was "verworfen" wird, bei WUN aehnlich. Eigentlich gehoert es per default aktiviert, aber erst nach ausgiebigen Tests. #3. ist aufwendiger, kommt spaeter.

@ToKa: Gedulde dich etwas. Bitte mit der neuen Version (morgen ab 8 per update, usw) das Attribut ignoreDupMsg fuer alle problematischen ZWave Geraete setzen (siehe auch devspec), und berichten. Sollte de-facto das Gleiche bewirken wie event-min-interval (was nicht mehr notwendig ist), mit dem Unterschied das readingsChange jetzt funktioniert

[krikan]

Mehrfache WUNs haben auch bisher nicht zu eine Verlaengerung gefuehrt.

Das stelle ich nicht in Abrede und ist für den Normalfall vollkommen ok.
Mein Gedankengang: bei WUN-Wiederholungen, die -wie oben im Log- noch 2 Sekunden spaeter (=Ende Wachphase) den Aktor beschaeftigen, haben die eigentlichen Abfragen keine Chance durchzukommen, wenn die Wachphase sich nicht verlaengert. Schauen wir, was die Praxis zeigt. 

[A.Harrenberg]

Hi Rudi,

den Teil des neuen Codes verstehe ich nicht...

Code Auswählen Erweitern


   if($hash->{ignoreDupMsg} && $callbackid ne "00") {
      my $hp = hex($callbackid);
      if($zwave_cbid2dev{$hp}) {
        delete $zwave_cbid2dev{$hp};
      } else {
        Log3 $name, 3, "$name: ignore duplicate answer $event[0]";
        return "";
      }
    }
Das soll ja wohl diesen Teil hier implementieren:

- Antworten auf nicht ausstehende gets ignorieren. Eine Antwort kann man von einer spontenen Nachricht anhand der CallbackId unterscheiden.

1.) was versteckt sich eigentlich hinter "$zwave_cbid2dev{$hp}" und was macht dann das delete?
2.) der obere Teil wird ausgeführt wenn ignoreDupMsg gesetzt ist UND die CB nicht "00" ist, d.h. im Umkehrschluss wird der untere Teil mit dem "ignore" ausgeführt wenn
  a.) ignoreDupMsg NICHT gesetzt ist ODER
  b.) CB = "00" ist

Bei 2.) hätte ich die Logik genau anders herum erwartet...

Gruß,
Andreas.

[rudolfkoenig]

Ich meine immer noch, dass es so richtig ist, und kurz getestet habe ich es auch.
1. in zwave_cbid2dev wird abgelegt, zu welchem Hash die letzte Callbackid gehoert. Wird geloescht, um zu zeigen, dass dafuer ein event generiert wurde.  Ich gehe davon aus, dass auf eine Frage nicht mehrere Antwort-Telegramme mit gesetzten CB kommen koennen.
2. ich weiss nicht, was du mit "unteren" Teil meinst, ich sehe kein else fuer das aussere if.

[A.Harrenberg]

Hi Rudi,

ok, mein Fehler, ich hatte das else tatsächlich dem äußeren if zugeordnet...

Gruß,
Andreas.

[ToKa]

Hallo zusammen,

ich habe nach dem Update heute Abend für 3 meiner COMET Problemkinder das Attribut ignoreDupMsg gesetzt. Dies führt einerseits zu der entsprechenden Meldung "ignore duplicate answer", andererseits auch immer noch zu mehrfachen Einträgen in den Gerätelogs z.B. für temperature. Bei einem Gerät (E2.ez.HR.Heizung) sieht man um 20:33 Uhr ein mehrfaches WUN und dann keine weiteren Einträge im log, die get-Befehle sind wieder auf dem sendstack stehen geblieben (siehe list).

Für mich sieht das immer noch nach Chaos aus, aber ich hoffe, Euch sagt es mehr. Wenn Ihr verbose 5 logs benötigt, sagt Bescheid.

Beste Grüße
Torsten