Z-Wave Netz wird geflutet

Hallo zusammen

Ich habe vorgestern IPS auf den neuesten stand gebracht und nebenbei 2 neue „Fibaro Dual Switch 2“ eingebunden.
Seitdem wird mein Netz geflutet, ein Tastendruck kommt - wenn überhaupt - erst nach mehreren Minuten erst an.

Hier ist ein Ausschnitt aus dem Debug vom Gateway:


TXT: 11.01.2019, 23:42:31 |  Package was dropped | 
HEX: 11.01.2019, 23:42:31 |  Package was dropped | 
TXT: 11.01.2019, 23:42:31 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:31 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:31 |          RESPONSE 20 | ı\õc<SOH>
HEX: 11.01.2019, 23:42:31 |          RESPONSE 20 | F5 5C 9B 63 01 
TXT: 11.01.2019, 23:42:31 |  Package was dropped | 
HEX: 11.01.2019, 23:42:31 |  Package was dropped | 
TXT: 11.01.2019, 23:42:31 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:31 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:31 |  Package was dropped | 
HEX: 11.01.2019, 23:42:31 |  Package was dropped | 
TXT: 11.01.2019, 23:42:31 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:31 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:31 |  Package was dropped | 
HEX: 11.01.2019, 23:42:31 |  Package was dropped | 
TXT: 11.01.2019, 23:42:31 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:31 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:31 |  Package was dropped | 
HEX: 11.01.2019, 23:42:31 |  Package was dropped | 
TXT: 11.01.2019, 23:42:31 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:31 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:31 |  Package was dropped | 
HEX: 11.01.2019, 23:42:31 |  Package was dropped | 
TXT: 11.01.2019, 23:42:31 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:31 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:31 |  Package was dropped | 
HEX: 11.01.2019, 23:42:31 |  Package was dropped | 
TXT: 11.01.2019, 23:42:31 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:31 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:31 |  Package was dropped | 
HEX: 11.01.2019, 23:42:31 |  Package was dropped | 
TXT: 11.01.2019, 23:42:31 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:31 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:31 |  Package was dropped | 
HEX: 11.01.2019, 23:42:31 |  Package was dropped | 
TXT: 11.01.2019, 23:42:31 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:31 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:31 |  Package was dropped | 
HEX: 11.01.2019, 23:42:31 |  Package was dropped | 
TXT: 11.01.2019, 23:42:31 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:31 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:31 |  Package was dropped | 
HEX: 11.01.2019, 23:42:31 |  Package was dropped | 
TXT: 11.01.2019, 23:42:31 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:31 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:31 |  Package was dropped | 
HEX: 11.01.2019, 23:42:31 |  Package was dropped | 
TXT: 11.01.2019, 23:42:31 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:31 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:31 |  Package was dropped | 
HEX: 11.01.2019, 23:42:31 |  Package was dropped | 
TXT: 11.01.2019, 23:42:31 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:31 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:31 |  Package was dropped | 
HEX: 11.01.2019, 23:42:31 |  Package was dropped | 
TXT: 11.01.2019, 23:42:31 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:31 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:31 |  Package was dropped | 
HEX: 11.01.2019, 23:42:31 |  Package was dropped | 
TXT: 11.01.2019, 23:42:31 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:31 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:31 |  Package was dropped | 
HEX: 11.01.2019, 23:42:31 |  Package was dropped | 
TXT: 11.01.2019, 23:42:31 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:31 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:31 |  Package was dropped | 
HEX: 11.01.2019, 23:42:31 |  Package was dropped | 
TXT: 11.01.2019, 23:42:31 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:31 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:31 |  Package was dropped | 
HEX: 11.01.2019, 23:42:31 |  Package was dropped | 
TXT: 11.01.2019, 23:42:31 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:31 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:31 |  Package was dropped | 
HEX: 11.01.2019, 23:42:31 |  Package was dropped | 
TXT: 11.01.2019, 23:42:31 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:31 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:31 |  Package was dropped | 
HEX: 11.01.2019, 23:42:31 |  Package was dropped | 
TXT: 11.01.2019, 23:42:31 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:31 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:31 |  Package was dropped | 
HEX: 11.01.2019, 23:42:31 |  Package was dropped | 
TXT: 11.01.2019, 23:42:31 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:31 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:31 |  Package was dropped | 
HEX: 11.01.2019, 23:42:31 |  Package was dropped | 
TXT: 11.01.2019, 23:42:32 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:32 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:32 |  Package was dropped | 
HEX: 11.01.2019, 23:42:32 |  Package was dropped | 
TXT: 11.01.2019, 23:42:32 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:32 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:32 |  Package was dropped | 
HEX: 11.01.2019, 23:42:32 |  Package was dropped | 
TXT: 11.01.2019, 23:42:32 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:32 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:32 |  Package was dropped | 
HEX: 11.01.2019, 23:42:32 |  Package was dropped | 
TXT: 11.01.2019, 23:42:32 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:32 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:32 |  Package was dropped | 
HEX: 11.01.2019, 23:42:32 |  Package was dropped | 
TXT: 11.01.2019, 23:42:32 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:32 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:32 |  Package was dropped | 
HEX: 11.01.2019, 23:42:32 |  Package was dropped | 
TXT: 11.01.2019, 23:42:32 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:32 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:32 |  Package was dropped | 
HEX: 11.01.2019, 23:42:32 |  Package was dropped | 
TXT: 11.01.2019, 23:42:32 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:32 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:32 |  Package was dropped | 
HEX: 11.01.2019, 23:42:32 |  Package was dropped | 
TXT: 11.01.2019, 23:42:32 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:32 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:32 |  Package was dropped | 
HEX: 11.01.2019, 23:42:32 |  Package was dropped | 
TXT: 11.01.2019, 23:42:32 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:32 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:32 |  Package was dropped | 
HEX: 11.01.2019, 23:42:32 |  Package was dropped | 
TXT: 11.01.2019, 23:42:32 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:32 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:32 |  Package was dropped | 
HEX: 11.01.2019, 23:42:32 |  Package was dropped | 
TXT: 11.01.2019, 23:42:32 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:32 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:32 |  Package was dropped | 
HEX: 11.01.2019, 23:42:32 |  Package was dropped | 
TXT: 11.01.2019, 23:42:32 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:32 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:32 |  Package was dropped | 
HEX: 11.01.2019, 23:42:32 |  Package was dropped | 
TXT: 11.01.2019, 23:42:32 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:32 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:32 |  Package was dropped | 
HEX: 11.01.2019, 23:42:32 |  Package was dropped | 
TXT: 11.01.2019, 23:42:32 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:32 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:32 |  Package was dropped | 
HEX: 11.01.2019, 23:42:32 |  Package was dropped | 
TXT: 11.01.2019, 23:42:32 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:32 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:32 |  Package was dropped | 
HEX: 11.01.2019, 23:42:32 |  Package was dropped | 
TXT: 11.01.2019, 23:42:32 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:32 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:32 |  Package was dropped | 
HEX: 11.01.2019, 23:42:32 |  Package was dropped | 
TXT: 11.01.2019, 23:42:32 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:32 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:32 |  Package was dropped | 
HEX: 11.01.2019, 23:42:32 |  Package was dropped | 
TXT: 11.01.2019, 23:42:32 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:32 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:32 |  Package was dropped | 
HEX: 11.01.2019, 23:42:32 |  Package was dropped | 
TXT: 11.01.2019, 23:42:32 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:32 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:32 |  Package was dropped | 
HEX: 11.01.2019, 23:42:32 |  Package was dropped | 
TXT: 11.01.2019, 23:42:32 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:32 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:32 |  Package was dropped | 
HEX: 11.01.2019, 23:42:32 |  Package was dropped | 
TXT: 11.01.2019, 23:42:32 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:32 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:32 |  Package was dropped | 
HEX: 11.01.2019, 23:42:32 |  Package was dropped | 
TXT: 11.01.2019, 23:42:32 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:32 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:32 |  Package was dropped | 
HEX: 11.01.2019, 23:42:32 |  Package was dropped | 
TXT: 11.01.2019, 23:42:32 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:32 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:32 |  Package was dropped | 
HEX: 11.01.2019, 23:42:32 |  Package was dropped | 
TXT: 11.01.2019, 23:42:32 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:32 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:32 |  Package was dropped | 
HEX: 11.01.2019, 23:42:32 |  Package was dropped | 
TXT: 11.01.2019, 23:42:32 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:32 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:32 |  Package was dropped | 
HEX: 11.01.2019, 23:42:32 |  Package was dropped | 
TXT: 11.01.2019, 23:42:32 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:32 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:32 |  Package was dropped | 
HEX: 11.01.2019, 23:42:32 |  Package was dropped | 
TXT: 11.01.2019, 23:42:32 | Transmitted (Resend) | <SOH><ETX><NUL> ‹
HEX: 11.01.2019, 23:42:32 | Transmitted (Resend) | 01 03 00 20 DC 
TXT: 11.01.2019, 23:42:32 |          RESPONSE 20 | ı\õc<SOH>
HEX: 11.01.2019, 23:42:32 |          RESPONSE 20 | F5 5C 9B 63 01 
TXT: 11.01.2019, 23:42:32 |          RESPONSE 20 | ı\õc<SOH>
HEX: 11.01.2019, 23:42:32 |          RESPONSE 20 | F5 5C 9B 63 01 
TXT: 11.01.2019, 23:42:32 |          RESPONSE 20 | ı\õc<SOH>
HEX: 11.01.2019, 23:42:32 |          RESPONSE 20 | F5 5C 9B 63 01 

Ein Restart von IPS bringt ca 5 min ruhe, dann schaukelt es sich wieder hoch. Ich habe zum testen auch mal IPS gestoppt und Z-Way gestartet, da war ruhe.

Mein Setup sieht wie folgt aus:

  • IPS: 5.0 93cb63bbeb2 auf RPi
  • Gesplittetes Z-Wave Netzwerk, teils läuft auf Razberry, teils auf einem Vision stick. (Ja, ich weiss, ich sollte dies mal bereinigen)

Der Auszug oben ist vom Razberry, aber das Log vom Vision sieht genauso aus. :frowning:

Hat jemand eine Ahnung, was da los sein könnte? Liegt es an einer faulty Node? Oder hat sich ein Fehler in IPS eingeschlichen, dass diese Resends ohne Unterlass gesendet werden?

PS: In den Meldungen ist nicht viel drin, Minütlich mal ein:

12.01.2019, 00:06:05 | TimerPool | Razberry Gateway (KeepAlive): Zeitüberschreitung beim Warten auf Bestätigung
12.01.2019, 00:06:13 | TimerPool | Z-Wave Gateway - Vision (KeepAlive): Zeitüberschreitung beim Warten auf Bestätigung

Danke und Gruss
Pelota

Ok, ich habe IPS auf v.5.0-2681 zurück downgraded und das problem besteht immer noch. Also daran lags wohl nicht.

Hat jemand eine Ahnung wie ich rausfinde, warum dies passiert? und was dieses Paket überhaupt ist?

Danke
Pelota

Hast du den Razberry evtl. durchgestartet, und im Hintergrund läuft z-Way noch mit?
Bei mir hat sich Z-way obwohl dauerhaft deaktiviert, nach irgendeinem Update (Z-Way?IPS?RASPBIAN) wieder aktiviert.
Mal hat ein Schaltbefehl funktioniert, mal nicht - da sich IPS + Z-way gemeinsam nicht vertragen…

Ansonsten die üblichen verdächtigen:

  • neue Zwave Aktoren verbaut?
  • Evtl mit den Alarmklassen gespielt?
  • evtl. an den Assoziationen etwas verändert? (D.h. an einem Zwave Aktor in allen drei Reportklassen das ZWave Gateway hinterlegt? Über die Assoziationsgruppen, schicken die Zwave Aktoren/Sensoren gerne unterschiedlich viel und oft…

Ich hatte mal einen Steinel Zwave Bewegungsmelder samt Leuchte ins Netz integriert.
In den Standardeinstellungen, legt das Teil einem das Zwave Netz lahm…
Mit angepasster Einstellung läuft das Teil friedlich mit den anderen Zwave Kollegen.

P.S. ohne die Fehlermeldung zu kennen, liest sich diese für mich aber so, als ob zu sendende Datenpakete nicht weitergeleitet werden können. Zwave schickt seine Datenpakete ja über die gelernten ROuten um die Reichweite zu erhöhen.
Schon mal eine OPTIMIERUNG laufen lassen? Ist evtl. einer der ZWave Geräte kaputt gegangen, so dass über diese TEil nicht mehr gesendet/empfangen werden kann? Das müsste man dem ZWAVE Netz mittels Optimierung beibringen.

Nun, ich habe wie oben beschrieben 2 Fibaro Aktoren hinzugefügt, und diese mit dem Razberry assoziiert (Passiert neuerdings ja automatisch). Aber zum Testen habe ich diese 2 vom Strom genommen, also an denen lags wohl nicht.
An den Alarmklassen hab ich nichts gemacht.

Das mit z-way noch am laufen hab ich als erstes kontrolliert, ist mir nämlich auch schon mal passiert. Ich habe zwar Z-Way upgedated, aber danach sofort dessen Autostart abgestellt.

Eine Optimierung habe ich nur für die 2 neuen Aktoren angestossen, aber optimiert nicht IPS jede nacht?

Error Meldung - wie gerne würd ich eine sehen… Nein, das Message Log ist leer und das Debug Log von den Gateways werden so schnell geflutet, dass ich der Zeitraum ziemlich begrenzt ist. Gibts da eine Möglichkeit, dies in ein File zu debuggen?

Was mir noch aufgefallen ist:
Beim Razberry ist der Resend stets:

Transmitted (Resend) | 01 03 00 20 DC

Und hin und wieder erscheint ein

RESPONSE 20 | F5 5C 9B 63 01

Beim Vision ist es :

Transmitted (Resend) | 01 03 00 16 EA

als auch

Transmitted (Resend) | 01 03 00 20 DC

die erscheinende response hingegen ist die gleiche:

RESPONSE 20 | F5 5C 9B 63 01

Vielleicht bin ich ja auf dem Holzweg. Wäre toll, wenn ich die Z-Wave Packets verstehen würde.
Apropos: Wenn auf beiden Gateways (unterschiedliche netze) der Debug läuft, sieht man eigentlich packets des anderen Netz (auch wenn diese verworfen werden)?

Danke
Pelota

RaZberry nur mit Ser2Net oder auch Z-Way?

Dort hat jemand dasselbe Kommando gepostet.

„Transmitted (Resend) | 01 03 00 20 DC“

und auch irgendwas mit Z-way / Ser2Net zum Schluss gepostet… vielleicht trifft das ja auch auf dich zu…

Den Beitrag hatte ich gar nicht gefunden, danke sehr. Leider bringts nichts.

Aber in der Zwischenzeit habe ich IPS neugestartet, nach dem abklemmen des einen des Fibaros.
Und jetzt, nach mehr als einem halben Tag, sind die Debug Fenster recht leer.

Hoffentlich bleibt dabei…

Danke
Pelota

Leider war mein letzter Post zu früh gepostet.
Es passiert immer und immer wieder.

Ich habe inzwischen mehrere nodes mit neuen Qubinos ersetzt, alle sind jetzt Z-Wave Plus Geräte.
Den Vision Stick habe ich entfernt, so ist nur der Razberry am laufen, mit 14 Geräten, Davon 1 Batteriebetrieben und 4 ohne Strom.

Ich kann den Fehler auslösen, indem ich 1-2x mein „Alles aus“ Skript starte (welches zZ. nur 6 Instanzen triggert).
Hier ist das debug log:
debug.txt (47.6 KB)
Leider krieg ich das nicht besser hin, bei der Menge an Daten macht der Download-Button im Debug Fenster nicht mit.

Ich hab auch wieder mit Z-Way rumgespielt, dort sehe ich sowas wie „Aborting, too many retries“. Müsste Symcon das nicht auch tun?

Gruss
Pelota

Achtung Halbwissen, aber evtl ein Ansatz:

Das IPS log paßt mehr oder weniger mit dem Bild hier überein:
https://m.eet.com/media/1076364/1006esdGaleev02.gif
Demnach steht der der Ziel-Node im fünften Byte. Hab das bei mir überprüft, das kommt hin. Fünftes Byte ist der Ziel-Node.

In deinem letzten log hättest du demnach mit Node 8 und Node 9 ein Problem.
Allerdings war es in einem der letzten Posts Node 220 :eek: hast du so viele ?

Ich weiß nicht wie die logs deiner Interfaces genau zu interpretieren sind. Kann gut sein das noch das ein oder andere Byte mehr angezeigt wird.

Bei mir fangen jedenfalls alle Packets welche von IPS versendet werden mit 0x01 an. In deinem log sieht das gleich aus, also dürfte es so wohl so falsch nicht sein.

schöne Grüße
bernhard

Ach ja nochwas: evtl. ist es ja gar kein zWave Problem, sondern der Funkkanal wird durch irgendein anders Gerät gestört ?
Hast irgendwas neues funkiges in Betrieb genommen ?
Ich hatte vor langer zeit mal ein ähnliches Problem. Da störte eine Funktastur das komplette 868Mhz Band. Kaum war der Dongle angesteckt und mit der Tastatur gepaired ging es mit sehr schlechtem Empfang der FS20 und HM Geräte los.
Irgendwann ging das Teil in Standby und alles war gut, bis man es wieder berührt hat.
Hab ewig gebraucht bis ich den Verursacher identifiziert hatte.

gruß
bb

hallo bernard, danke für die Antwort.

Nein, ich habe keine 220 Nodes :), sind lediglich 14, das letzte hat id 21.

Ja, in dem Log ist node 9 auffällig, hast recht, aber ich weiss nicht warum. Zuvor wars die 3, die hab ich excludiert.
Diesmal startets irgendwann bei 20:22:07, da seh ich das erste resend, danach seh ichs bei 0x0a und 0x15 (vielleicht noch mehr).
Und dann halt auch das 5bytige 01 03 … welches sich dann auch nicht erholt, sondern xfach pro Sekunde resendet wird und das System verstopft :frowning:

Ich werde die nächsten Tage einen neuen Razberry und weitere Qubinos bekommen. Mal schauen…

Bez. Fremdfunker, nein ich habe nichts zusätzlich hinzugefügt und auch nichts extra gestartet.

Wie oben erwähnt kann ich den Zustand auslösen durch Schalten mehrerer Nodes zur selben Zeit. Auch seh ich den Zustand jetzt jeden Morgen. Könnte durch das nächtliche Optimieren ausgelöst werden?!

Ich werd das Gefühl nicht los, dass IPS da schuldig ist, dass es bei einem drop das system zu schnell wieder bombardiert und somit einfach einen DoS startet…

Gruss
Pelota

Hmm, eher nicht.
paresy hat ja vor kurzem in einem anderen Thread geschrieben das IPS von sich aus kein „Resend“ macht.
Du müßtets es selbst per Script auslösen. Es wird nur einmal gesendet und dann ist von Seiten IPS Schluß.
Allerdings probierten es der Controller selbst noch mehrere Male, bzw. auch über andere Routen.

IPS sagt dem Controller nur „schicke-Dies-und-das-dorthin“. Alles weitere machen die Controller (auch die Sticks) selbst. evtl. ist ja an der Razberry Config irgendwas schräg ?
Ich verwende hier nur einen ZME UZB1 Stick und bin soweit recht zufrieden damit.

Und ja, vermutlich kann auch das optimieren irgeinen Blödsinn auslösen. Ich hoffe wenn die zWave anbindung überarbeitet da ser eine Option vorsieht mit der man das global abschalten kann. Wenn sich an der Hardware nichts ändert macht es auch wenig Sinn rumzuoptimieren.
Hab hier bspw. zwei Ein-Button Scenecontroler. Wenn die Optimierung aktiviert ist, so ist der Akku in wenigen Tagen leer. Wenn AUS, dan hält er einige Wochen.

Hoffe hab in Summe jetzt keinen Blödsinn geschrieben, mein zWave Weltbild ist noch etwas löchrig.
Bernhard

Hi Bernhard,

wenn (wie in diesem Falle) ein Paket aktiv vom Gateway abgelehnt wird dann versucht IP-Symcon das Paket erneut zu senden. Dies ist auch so in der API vorgegeben. Dieses ablehnen passiert sehr selten und somit wundert es mich, dass das Gateway die Anfragen nicht früher oder später abarbeiten kann. Ich kann gerne die Zeit zum „Retry“ erhöhen. Ich bin mir aber nicht sicher, ob das helfen wird.

Meine Aussage zu „wir versuchen es nicht erneut“ betrifft die Kommunikation mit den Geräten, welche dann in ein Timeout laufen.

paresy

Danke für die Erklärungen.
Das das Gateway Packete auch unmittelbar ablehnen kann war mir so nicht bewußt. Macht aber logischerweise Sinn.
Wie gesagt zzt. nur halbwissen, die API hab ich nicht ganz durchgearbeitet, bin ja zum Glück nur Anwender. :stuck_out_tongue:

Für pelota fragt sich aber natürlich warum das Gateway das Packtet überhaupt abweist.
Von 20:19:43 - 20:20-07 ist wenig Kommunikation und alles gut.
ab 20:20:07 gehts dann los mit sekündlichen dropped Packets.

Pelota was passiert eigentlich wenn du währendeiner Problemphase einfach nur das Gateway neu startest ?
Läufts dann wieder füre einen gewisse Zeit, oder ist sofort wieder Schluß ?
Das könnte doch auch noch einen Rückschluß auf einen möglichen exteren Störer geben.

gruß
bb

Soweit ich weiß werden Pakete abgelehnt, wenn das Gateway aktuell Daten empfängt und somit nichts raussenden kann.

paresy

Ich kann alles wieder normalisieren, indem ich Symcon neu starte. Dann ist ruhe. Bis wieder …

ich weiss nicht, ob es irgendwas zu tun hat, aber Node 8 und 9 (Fibaro) sitzen zusammen in der selben Schalter-Kombination und taten stets etwas bockig (keine Antwort).
Nun hab ich von 8 versucht die Assoziationen zu laden, was zu einem „Timeout“ führte. Das Debug zeigt aber was anderes:
(Debug Download will einfach nicht, nutze Safari)


Könnte dieser Security Error was zu tun haben?

paresy
Soweit ich weiß werden Pakete abgelehnt, wenn das Gateway aktuell Daten empfängt und somit nichts raussenden kann.

Ich sehe leider nur die Symcon Seite, und da zeitweise nur das drop/resend, keine andere Aktivität.
Ich habe einen neuen Razberry bestellt, den würde ich mal in einen anderen RPi klemmen. Meint Ihr, ich könnte so die „andere Seite“ sehen?

Ich kann gerne die Zeit zum „Retry“ erhöhen. Ich bin mir aber nicht sicher, ob das helfen wird.

Würde es da Sinn machen, eine back pressure einzubauen? Ich mein sowas wie:

[ul]
[li]10x schneller resend[/li][li]100x resend mit 100ms delay[/li][li]danach weiter versuchen mit 1s delay [/li][li]vielleicht nach 5min abzubrechen[/li][/ul]

Off Topic - Ich habe eine Fehler in der neuen Konsole entdeckt:
Wenn ich auf einer Instanz auf „Assoziation laden“ klicke und nicht den Timeout abwarte, sondern direkt auf den Debug Tab wechsle, dann ist der modale Dialog nicht sichtbar, aber das Fenster mir dem Shadow überzogen. Dann geht nix mehr, man muss die Konsole komplett neu laden.

Edit: Ein Schliessen/Öffnen der seriellen Schnittstelle reicht, um das Netz zu beruhigen.

Gruss
Pelota

Hallo zusammen

Nachdem ich fast jede Komponente im Haus ausgetauscht, neu angelernt hatte und sogar den Razberry durch einen neueren gewechselt habe, fand ich per Zufall den Fehler.

Es ist tatsächlich IPS - mein Fehler, sorry :o

Ich hatte währen meiner ersten Zügel-Übung (vom Vision auf den Razberry) den falschen Tab offen und aus versehen vom Vision Gateway die IO Instanz auf die vom Razberry gewechselt. Nun hörten stets 2 gateways auf dieselben Packages. seit dem zurück stellen ist Ruhe im Debug-Fenster.

Dumm, dass das passiert ist, aber könnte anderen vielleicht helfen, sollten sie auch so’n problem haben.

Danke für die Mühe und Gruss
Pelota