Autor Thema: z-wave Stabilitaet  (Gelesen 681 mal)

Offline Wolfgang Hochweller

  • Sr. Member
  • ****
  • Beiträge: 659
z-wave Stabilitaet
« am: 10 Mai 2022, 10:53:15 »
Altes, aber immer wieder aktuelles Thema.

Obwohl (meistens)  alles gut funktioniert, treten immer wieder Ausreisser auf :

- Es erscheinen Readings bei Devices, die damit mit Sicherheit nichts zu tun haben, etwa Wassermengen bei Fenstersensoren, etc.
- Der Messagestack laeuft ab und zu ueber.

Ersteres kann durchaus unangenehm werden, wenn dadurch 'aus Versehen' Events ausgeloest werden.
Ich will dabei auch nicht ausschliessen, dass die z-wave Implementation bei einigen Devices nicht immer korrekt ist, insbesondere Heat-IT Geraete fallen immer wieder
negativ auf.
Trotzdem draengt sich das Gefuehl auf, dass Messages ab und an irgendwie unterwegs modifiziert werden; manchmal gibt es dann Unsinn, manchmal aber auch leider nicht.

Kann ich irgendetwas checken, um das zu verhindern ?

'Mission Critical'  Funktionen moechte ich so nicht gerne implementieren.




Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 25487
Antw:z-wave Stabilitaet
« Antwort #1 am: 10 Mai 2022, 12:33:28 »
Zitat
- Es erscheinen Readings bei Devices, die damit mit Sicherheit nichts zu tun haben, etwa Wassermengen bei Fenstersensoren, etc.
Das ist ein bekanntes Problem, falls im Netz Geraete vorhanden sind die kein 100k Datenrate koennen, oder die Datenrate wegen schlechter Verbindung auf 40k oder 9.6k zurueckgestuft wurde.  Bei etwas moderneren Controller (aka ZWave Dongle) meldet FHEM automatisch die Verbidungsdaten im routeInfo Reading.
Bei 9.6k und 40k wird ein Byte Checksum verwendet (== zu wenig), bei 100k zwei (auch nicht so viel).
Eine weitere Checksum-Ebene kann man mit  dem useCRC16 Attribut hinzufuegen, wenn dass Geraet das unterstuetzt. (Class CRC_16_ENCAP ist vorhanden).

Ich koennte das Modul noch erweitern, damit nur bei der Inklusion gemeldete Nachrichtenklassen zugelassen werden.
Eine Ausnahme muesste moeglich sein, da bei manchen Geraeten das nicht konsistent ist.

Zitat
- Der Messagestack laeuft ab und zu ueber.
Das ist auch bekannt. Das Firmware reagiert mit Fehler, wenn FHEM Nachrichten senden will, waehrend Andere noch nicht bestaetigt wurden, oder die Antwort auf einem get aussteht. FHEM versucht das zu vermeiden, es gibt aber keine Synchronization fuer gets von unterschiedlichen ZWave-Instanzen: in diesem Fall sollte man ein delay einbauen, z.Bsp. ueber structure.