Z-Wave Gerät verliert/verändert Eigenschaften / Readings

[Parador]

Hallo Zusammen,

ich zweifle hier an meinem System. Ich nutze einen Raspi3B und nutze u.a. Z-Wave. Nun habe ich vor ein paar Tagen festgestellt, dass z.B. ein Sensative Strips Türkontakt plötzlich falsche Eigenschaften/Reading und auch kein Bild mehr anzeigt.

richtig wären z.B. folgende Readings:

Code Auswählen Erweitern


   READINGS:
     2019-10-06 19:57:14   CMD             ZW_APPLICATION_UPDATE
     2020-01-19 19:00:35   UNPARSED        SENSOR_BINARY 033001ff
     2020-01-14 11:57:00   alarm           HomeSecurity: Event cleared: Previous Events cleared
     2019-10-06 19:43:59   battery         100 %
     2019-10-06 19:43:59   batteryPercent  100
     2019-10-06 19:43:59   batteryState    ok
     2019-10-06 19:43:51   model           Sensative Strips
     2019-10-06 19:43:51   modelConfig     sensative/strips.xml
     2019-10-06 19:43:51   modelId         019a-0003-0003
     2019-11-22 14:40:06   neighborUpdate  done
     2020-04-23 15:29:28   reportedState   closed
     2020-04-23 15:29:28   state           closed
     2020-04-21 19:07:08   timeToAck       0.032
     2020-04-23 14:32:19   transmit        NO_ACK
     2020-04-23 14:32:09   wakeup          notification
     2019-10-06 19:43:57   zwavePlusInfo   version:01 role:SleepingReportingSlave node:Z-Wave+Node installerIcon:0c07 userIcon:0c07


jetzt finden sich da folgende:

Code Auswählen Erweitern


   READINGS:
     2020-03-15 13:37:45   UNPARSED        CONTROLLER_REPLICATION 10212c3202214400000143010d00000143
     2019-08-25 11:35:47   battery         75 %
     2019-08-25 11:35:47   batteryPercent  75
     2019-08-25 11:35:47   batteryState    ok
     2020-01-05 21:08:01   cooling         233.89  previous: 233.6 delta_time: 301 s
     2019-12-21 21:19:09   energy          0.06 kWh previous: 0.06 delta_time: 301 s
     2019-06-09 22:42:42   power           0.04 W previous: 0 delta_time: 301 s
     2020-04-12 18:59:38   reportedState   closed
     2020-04-12 18:59:38   state           closed
     2020-04-13 03:58:53   timeToAck       0.028
     2020-04-21 11:31:10   transmit        NO_ACK
     2019-08-29 15:41:52   undef           0 undef previous: 0 delta_time: 301 s
     2019-09-28 17:28:41   voltage         230.4 V previous: 230.26 delta_time: 301 s
     2020-04-21 11:30:56   wakeup          notification


beides Mal identischer sensative Strip...
bin jetzt noch nicht tiefer auf die Suche gegangen, aber vermutlich sind es noch mehr die betroffen sind

nun mehrere Frage a) was ist passiert b) warum ist es passiert c) was kann ich ändern, damit das nicht mehr passiert

[rudolfkoenig]

Ich bin weder der Hersteller der Geraete, noch kenne ich sie persoenlich, deswegen sind das nur allgemeine Vermutungen:
- das Geraet ist kaputt
- die Firmare hat einen Schaden
- Empfang der Funksignale ist gestoert, z.Bsp. wegen schlecht aufgeloetete Antenne, schwache Batterie, Zwischenwaende, Stoersignale in der Naehe, falsche relative Ausrichtung der beiden Antennen, etc. Falls der Empfang schlecht ist, schalten die ZWave-Chipsaetze von 100 auf 40 oder 9.6kBaud zurueck, bei diesen Modi wird nur ein Byte Checksum verwendet, die Wahrscheinlichkeit, dass Datensalat weitergereicht wird, ist hoeher.

Falls man die o.g. Probleme nicht beseitigen kann, hilft evtl ein Repeater, oder die Aktivierung der CRC_16_ENCAP Klasse (falls vorhanden)  mit dem useCRC16 Attribut.

[Parador]

Hm, danke für das Brainstorming und die Ideen

• Gerät kaputt - für mich schwierig auszuschließen/zu prüfen
• Firmware kaputt - schwierig auszuschließen/zu prüfen
• Empfang gestoert - möglich

Da hätte ich aber noch eine Verständnisfrage.... Wenn der Empfang schlecht / gestört ist, warum verändert sich dann das Gerät in FHEM? bzw. warum tauchen andere Readings auf?
Kann ich den die vorgesehenen Readings / etc. wiederherstellen?
Habe jetzt spontan noch einen Mulitsensor 6 gefunden der auch nicht mehr ganz korrekt angezeigt wird.

[rudolfkoenig]

Wenn der Empfang schlecht / gesört ist, warum verändert sich dann das Gerät in FHEM?

Weil Datensalat als ZWave-Nachricht interpretiert wird: ein 8 Bits Checksum ist bei Muell in 1 aus 256 Faellen gueltig.

Kann ich den die vorgesehenen Readings / etc. wiederherstellen?

Ja, aus einem Backup. FHEM erstellt bei save automatisch ein Backup der fhem.cfg und fhem.state (hier sind die Readings), diese kann man mit restore und anschliessenden Neustart wiederherstellen.

[Parador]

Ok, das mit dem Datensalat habe ich verstanden.
Wäre es eine Option für FHEM angelegte Geräte mt einer Art Schalter zu sichern, dass sich Reading/Config Typen nicht mehr ändern können, bzw. nur wenn man es wieder anstubst? Die Ausführungen klingen so, als könne das relativ häufig passieren.

Mit der Wiederherstellung der vorgesehenen Readings...
Das mit dem wiederherstellen aus dem Backup stelle ich mir ...schwierig... vor, oder sehe ich das falsch, damit stelle ich ja einen Status-Quo zum Save-Datum wieder her. allerdings kann sich da dazwischen ja auch einiges mehr geändert haben, als nur bei dem Datensalat-Gerät... Damit würde ich mich praktisch wieder zu einem Punkt X zurücksetzen... schwierig wenn man nicht über jede Änderung mit Datum und Uhrzeit Buch führt...

Gibt es evtl. die Möglichkeit die Parameter für ein einzelnes Gerät nochmal abzurufen, zu syncen(oder ähnliches)?

[rudolfkoenig]

Wäre es eine Option für FHEM angelegte Geräte mt einer Art Schalter zu sichern, dass sich Reading/Config Typen nicht mehr ändern können, bzw. nur wenn man es wieder anstubst?

Ich verstehe das Anwendungs-Szenario dafuer noch nicht.

allerdings kann sich da dazwischen ja auch einiges mehr geändert haben, als nur bei dem Datensalat-Gerät...

Ich wuerde in FHEMWEB die kaputten readings mit "deletereading datenSalatGeraet .* entfernen", die Backup-fhem.state Datei aus restoreDir/save/datum im Editor oeffnen, alle Zeilen mit "setstate datenSalatGeraet" kopieren, und diese im FHEMWEB, im "Text-Input" Fenster (hinter dem + Knopf oben links) einfuegen und ausfuehren.

[Parador]

Zum "Sicherheits-Schalter"-Szenario
Wenn so wie geschrieben, bei Z-Wave-Geräten mit schlechtem Empfang die Chance groß ist, dass es zu einer Veränderung der Config/Reading-Typen kommt...
Wäre es dann nicht gut, nach erfolgreicher Erstanlage, diese Config/Reading-Typen "einzufrieren" und dann falsche Config/Reading-Typen abzulehnen?
Deshalb mit meiner Idee eines "Sicherheits-Schalters" vermutlich pro Gerät, damit es nicht zu willkürlichen Änderungen kommen kann?

Normalerweise ändern sich ja die Config/Reading-Typen eines Gerätes innerhalb der Lebensdauer nicht, oder? Vielleicht nach einem Firmware-Update/Upgrade, aber ein Fensterkontakt wird ein Fensterkontakt bleiben, er wird vermutlich meist nur ein "auf/zu" liefern. Ein MultiSensor wird seine Werte liefern und nicht auf einmal eine neue Sensorart dazubekommen, oder?

Ich habe jetzt eben aktuell einen Fensterkontakt, der glaubt den Strom/verbrauch an einer Steckdose zu messen, was eher unmöglich erscheint
Vielleicht liege ich ja auch völlig falsch und es gibt viele smarte Dinge die über die Zeit Ihre Eigenschaften ändern...?!


Das mit dem Backup/Restore muss ich mir in einer ruhigen Minute mal ansehen, ...Danke für die Anleitung..!!!

[FHEM-User22]

Moin,
solche Probleme mit z-Wave habe ich auch. Da läuft nichts über einen längeren Zeitraum problemlos.

Grüße

[rudolfkoenig]

Wäre es dann nicht gut, nach erfolgreicher Erstanlage, diese Config/Reading-Typen "einzufrieren" und dann falsche Config/Reading-Typen abzulehnen?

Dazu muesste der Benutzer bestimmen, was er unter "falsche Config/Reading-Typen" versteht, und da ist vmtl. die Ausnahme/Positivliste sinnvoller. Aber wenn Readingnamen (im ZWave-Lingo Klassen-Nummer) schon falsch gesendet werden, dann werden vmtl. auch Werte falsch gesendet, insofern waere das nur eine psychologische Massnahme: "ich habe was gemacht, funktioniert trotzdem nicht"

Ich will nicht ausschliessen, dass das ZWave-Modul ein Problem hat, obwohl ich nicht daran glaube. Ich biete es an, ein "attr ZWDongle verbose 5" log daraufhin zu untersuchen, aber bitte nur, wenn Ihr einen begruendeten Verdacht habt, da es aufwendig ist. Falls ich das Problem haette, wuerde ich als erstes Funkprobleme beseitigen (s.o.).

[Parador]

Erstmal Danke für Deine Bereitschaft, würde aber auch gerne mit den Funkproblemen anfangen.
Kannst Du mir einen Tipp geben, wie ich denen auf die Schliche komme? Die Sensative Kontakte sind festverklebt, kann sie also nicht einfach mal näher ran bringen.
Worauf muss ich achten? was kann ich probieren?

[krikan]

Hast Du ein ZWave Plus Dongle?
Was liefert die Abfrage:

Code Auswählen Erweitern

get <ZWDongle> routeFor <dezimalNodeIDSensative>

Bei mir ergibt die Abfrage für den Sensative bspw:

ZWDongle_0 at 100kbps

Bedeutet direkte Verbindung des Dongles mit dem Strip über 100kbps. Die 100kbps haben eine bessere Checksummen-Absicherung als der alte Standard mit 40kbps, den Rudi oben anführte. Fehlerhafte Telegramme kommen afaik nicht mehr durch.

Problembehebungsansätze:
Nutzung eines ZWavePlus-Dongles, falls noch nicht genutzt
manuelle Routenupdates:

Code Auswählen Erweitern

set TYPE=ZWave:FILTER=ZWaveSubDevice=no neighborUpdate
Positionsveränderung Dongle
Einsetzen von zusätzlichen ZWavePlus-Repeatern

Gruß, Christian

[Parador]

Hey Christian,

danke für die Hilfestellungen. Ich habe es mit folgendem probiert:

Code Auswählen Erweitern

get ZWDongle_0 routeFor 1a
wobei ZWDongle_0 mein Dongle ist und 1a nicht der <dezimalNodeIDSensative> sondern der <nodeIdHex> ist, dann erhielt ich die Antwort:

ZWDongle_0 routeFor_1a => last at 40kbps

Ist somit eher schlecht...

Die Frage nach dem Dongle selbst ist schwieriger, kann es gar nicht mehr sagen was es für einer ist... Aber vielleicht kann man das hier erkennen?

Code Auswählen Erweitern


Vers:5 Rev:6 ManufID:0115 ProductType:0400 ProductID:0001 SERIAL_API_GET_INIT_DATA SERIAL_API_APPL_NODE_INFORMATION APPLICATION_COMMAND_HANDLER ZW_GET_CONTROLLER_CAPABILITIES SERIAL_API_SET_TIMEOUTS SERIAL_API_GET_CAPABILITIES SERIAL_API_SOFT_RESET UNKNOWN_09 UNKNOWN_0a ZW_SET_R_F_RECEIVE_MODE ZW_SET_SLEEP_MODE ZW_SEND_NODE_INFORMATION ZW_SEND_DATA ZW_SEND_DATA_MULTI ZW_GET_VERSION ZW_SEND_DATA_ABORT ZW_R_F_POWER_LEVEL_SET ZW_SEND_DATA_META ZW_GET_RANDOM MEMORY_GET_ID MEMORY_GET_BYTE MEMORY_PUT_BYTE MEMORY_GET_BUFFER MEMORY_PUT_BUFFER FLASH_AUTO_PROG_SET ZW_NVR_GET_VALUE NVM_GET_ID NVM_EXT_READ_LONG_BUFFER NVM_EXT_WRITE_LONG_BUFFER NVM_EXT_READ_LONG_BYTE NVM_EXT_WRITE_LONG_BYTE ZW_GET_NODE_PROTOCOL_INFO ZW_SET_DEFAULT ZW_REPLICATION_COMMAND_COMPLETE ZW_REPLICATION_SEND_DATA ZW_ASSIGN_RETURN_ROUTE ZW_DELETE_RETURN_ROUTE ZW_REQUEST_NODE_NEIGHBOR_UPDATE ZW_APPLICATION_UPDATE ZW_ADD_NODE_TO_NETWORK ZW_REMOVE_NODE_FROM_NETWORK ZW_CREATE_NEW_PRIMARY ZW_CONTROLLER_CHANGE ZW_SET_LEARN_MODE ZW_ASSIGN_SUC_RETURN_ROUTE ZW_REQUEST_NETWORK_UPDATE ZW_SET_SUC_NODE_ID ZW_DELETE_SUC_RETURN_ROUTE ZW_GET_SUC_NODE_ID ZW_SEND_SUC_ID ZW_EXPLORE_REQUEST_INCLUSION ZW_REQUEST_NODE_INFO ZW_REMOVE_FAILED_NODE_ID ZW_IS_FAILED_NODE ZW_REPLACE_FAILED_NODE UNKNOWN_66 UNKNOWN_67 ZW_FIRMWARE_UPDATE_NVM GET_ROUTING_TABLE_LINE LOCK_ROUTE_RESPONSE ZW_GET_PRIORITY_ROUTE ZW_SET_PRIORITY_ROUTE UNKNOWN_98 ZW_SET_WUT_TIMEOUT ZW_WATCHDOG_ENABLE ZW_WATCHDOG_DISABLE ZW_WATCHDOG_CHECK ZW_SET_EXT_INT_LEVEL ZW_RF_POWERLEVEL_GET ZW_TYPE_LIBRARY ZW_SEND_TEST_FRAME ZW_GET_PROTOCOL_STATUS WATCHDOG_START WATCHDOG_STOP ZW_SET_ROUTING_MAX UNKNOWN_ef ZME_FREQ_CHANGE ZME_BOOTLOADER_FLASH ZME_CAPABILITIES
Gibt es Empfehlungen welcher Dongle "besonders" gut ist? 

Das Routenupdate werde ich jetzt gleich mal anstubsen...

[krikan]

wobei ZWDongle_0 mein Dongle ist und 1a nicht der <dezimalNodeIDSensative> sondern der <nodeIdHex> ist,

Das mit der NodeId irritiert mich. Ich muss die dezimale NodeId beim Befehl mitgeben, damit der korrekte Node abgefragt wird. Steht auch so in der commandref und meine 00_ZWDongle.pm ist aktuell. Ich bin gerade überfragt, wo das Problem liegt. Andererseits stelle ich fest, dass auch Hex-NodeIds wie bspw. 0c akzeptiert werden und zu merkwürdigen Ergebnissen führen. ( Rudi?  )

Code Auswählen Erweitern

Vers:5 Rev:6 ManufID:0115 ProductType:0400 ProductID:0001
Das ist ein ZME_UZB1 von ZWave.me. Ist ein ZwavePlus-Stick und damit vollkommen ok. Firmware könnte man mal updaten; habe aber keine Ahnung, ob das einen Einfluß hat.

Das Routenupdate werde ich jetzt gleich mal anstubsen...

Probiere mal Dein Glück. Leider habe ich noch nicht herausgefunden nach welchem Algorithmus ZWave die Route/Geschwindigkeit auswählt. Zur Not(!) kannst Du mal versuchen mit set-routeFor die Route und Geschwindigkeit vorzugeben.

Gruß, Christian

[rudolfkoenig]

Andererseits stelle ich fest, dass auch Hex-NodeIds wie bspw. 0c akzeptiert werden und zu merkwürdigen Ergebnissen führen. ( Rudi?  )

Kann ich bestaetigen, im Log duerfte auch eine Perl-Warnung auftauchen.
Habe 00_ZWDongle.pm angepasst, damit nur Dezimalzahlen akzeptiert werden.

Gibt es Empfehlungen welcher Dongle "besonders" gut ist? 

Ich habe noch kein ZWave-Dongle mit einer "richtigen" Antenne gesehen.
Die Hersteller empfehlen vmtl. bei Problemen ein ZWave-Geraet in der Naehe, was staendig am Strom haengt.
Oder sie rechnen damit, das wir die Betreuung der Benutzer uebernehmen.

[Parador]

Ok, auch hier wieder danke!
könnt Ihr mir noch einen Tipp geben, wo ich die DezimaleNodeID finde? Muss blind sein, habe hier nur "nodeIdHex" es könnte noch "Nr" sein?

Internals:
   DEF        e65a849f 26
   FUUID      5c7add62-f33f-3c2f-b77e-7117e5a95c9368fe
   IODev      ZWDongle_0
   LASTInputDev ZWDongle_0
   MSGCNT     2
   NAME       EG_Zi_1
   NR         257
   STATE      closed
   TYPE       ZWave
   ZWDongle_0_MSGCNT 2
   ZWDongle_0_RAWMSG 0004001a03300300
   ZWDongle_0_TIME 2020-05-04 19:58:12
   ZWaveSubDevice no
   homeId     e65a849f
   isWakeUp   1
   nodeIdHex  1a

und wenn wir schon dabei sind, ich vermute, dass alle ZWaveSubDevices Relay-Funktion haben? Also in der Regel die mit Dauerstrom?