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?

[krikan]

Das ist die 26. Siehst Du im DEF nach der HomeId Deines ZWave-Netzes. Der Name des Devices sollte aber auch funktionieren.

[Parador]

Hm, ok
Habe jetzt nochmal zwei Abfragen gestartet:

Code Auswählen Erweitern

get ZWDongle_0 routeFor 26 (und auch mit Namen) ergab:

ZWDongle_0 routeFor_26 => last Steinel_Motion at 40kbps

Das verblüfft mich jetzt weil "Steinel_Motion" ein Bewegungsmelder draußen ist und laut DEF die 33 ist...

[krikan]

Das ist schon plausibel.
Bedeutet: Controller hat zuletzt (last) die NodeId 26 (Strips) über den Repeater NodeId 33 (Steinel) mit 40kbps erreicht.

100kbps sollte Ziel sein und das müsste auch über den Steinel funktionieren, da der afaik ZwavePlus ist.
Bestes Ergebnis wäre direkte Kommunikation des Controllers mit dem Strips; blöde Anmerkung: steht so auch in der Strips Anleitung.

Probiere erst mal neigborupdate und dann schauen wir weiter.

Wie groß ist die Entfernung zwischen Strips und Controller? Wie viele und welche Wände?

[rudolfkoenig]

Die Routen meiner ZWDongle haben mich auch schon verbluefft. Da wird Geraet A ueber B und C geroutet, wobei C direkt neben A ist, und B in einer ganz anderen Ecke, ungefaehr genausoweit wie A und C. Und dass das kein Maerchen ist, konnte  ich mit einem ZWCUL nachvollziehen.

Evtl. hilft bei dir das Spiel mit neighborUpdate.

In diesem Zusammenhang: falls du bei jedem Geraet "get neighborList" ausfuehrst, dann kann man in der ZWDongle Detailansicht die potentiellen Routen auch grafisch darstellen ("Show neighbor map"). Und ich bin nicht ueberzeugt, dass das vom ZWDongle tatsaechlich so verwendet wird.

[Parador]

Wieder was gelernt..
also der Controller ist ziemlich exakt mittig, der Strip ist zwei massive Wände und der Steinel drei massive Wände und ca 1m weiter vom Controller entfernt...
das NeighborUpdate habe ich gestartet.. denke das braucht noch das entsprechende Wakeup überall...(kann also noch dauern)..
Denke Morgen kann ich den nächsten Versuch starten. Da sollte auch noch ein Repeater in der Nähe sein...
Dann versuche ich die Route manuell auf den Controller zu legen...
Melde mich morgen wieder...

Die Ausgabe der Route zum Steinel ist noch fürchterlicher ;-(

Code Auswählen Erweitern

ZWDongle_0 routeFor_Steinel_Motion => last ZW_Zwischenschalter_01 at 9.6kbps
Werde morgen mal versuchen das gezielt zu routen ..

[krikan]

Nach einem erfolgreichem neigborUpdate im gesamten Netz, könntest Du vielleicht vor routeFor noch per set-returnRouteAdd allen Geräten Routen für den Rückweg zum Controller zuweisen und dann noch mal testen. set-routeFor ist sehr low-level, darum würde ich das -wie oben geschrieben- nur zur Not nutzen.

Wenn Du (hoffentlich) erfolgreich warst, solltest Du mal das Log kontrollieren, ob es bei ZWave viele Telegrammkollisionen/Funkstörungen gibt (NO_ACK, resend). Die könnten zum automatischen Herabstufen auf 40 bzw. 9.6 führen und Du solltest mal die Ursachen erforschen und versuchen diese zu verhindern. Wann die Geräte wieder automatisch auf 100 hochgehen, ist mir vollkommen unklar.

[Parador]

ok, so werd ich heute Nachmittag vorgehen. Vielleicht auch die Position der Repeater / Relays nochmal überdenken.
heute Morgen hat FHEM mal unerwartet neugestartet und ich fand beim Neustart folgendes im Protokoll:

ZWDongle_ProcessSendStack: no ACK, resending message 0107000301020100f9
ZWDongle_0: SOF missing (got 2c instead of 01)
ZWDongle_0 transmit NO_ACK for CB 01, target EG_Flur

das letzte NO_ACK ist von einem Fibaro MultiSensor der ca 120cm und eine Mauer vom Dongle entfernt ist....

[krikan]

Wenn das nur einmalige bzw. seltene Probleme sind, ist das mMn egal. Nur bei gehäuften Auftreten würde ich Grübeln.

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

Nein, hat damit nichts zu tuen.
"ZWaveSubDevice=no" ist das FHEM-Device für root eines ZWave-Gerätes
"ZWaveSubDevice=yes" sind die FHEM-Devices für die Endpoints eines ZWave-Gerätes
Ein ZWave-Gerät mit mehreren Funktionen und Unterstützung der Command Class MULTI_CHANNEL steuert jede Funktion mit einem separaten Endpoint an. root eines ZWave-Gerätes ist die "übergeordnete" Einheit mit der zentrale Aufgaben angesteuert werden und u.a. Rückwärtskompatibilität mit anderen Kommunikationspartener, die MULTI_CHANNEL nicht beherrschen, sichergestellt wird.
Am Beispiel einer Mehrfach-Steckdosenleiste mit Unterstützung Command Class MULTI_CHANNEL: Jede einzelne Steckdose hat einen zugeordneten Endpoint, der genau diese Steckdose abbildet (An-/Ausschalten, Stromverbrauch,..). Die Steckdosenleiste wird durch root abgebildet, der übergreifende Funktionen wie neigborUpdate bietet und bspw. alle Dosen an- und ausschaltet. Letzteres ist leider nicht generell so, sondern im ZWave-Standard relativ frei definiert.
Details: https://www.silabs.com/documents/login/application-notes/APL12955-Z-Wave-Multi-Channel-Basics.pdf

[krikan]

Testerfahrung im Zusammenhang mit Änderung der Datenübertragungsrate:

Hatte ein ZWave-Netz mit ausschließlich ZWavePlus-Geräten und einem ZWavePlus-Controller (5 Nodes). 2 netzbetriebene Geräte von Qubino und Aeotec hatten eine Datenübertragungsrate von 9,6; jedoch bisher keine durchgekommenen defekten Telegramme.

Habe diese Geräte mit Telegrammen überhäuft in der Hoffnung, dass diese automatisch wieder auf 100 hochschalten. Taten sie aber nicht, sondern blieben bei 9.6. Als genutztes Routenschema wurde im Callback-Telegramm immer "LastWorkingRoute" angezeigt.

Dann habe ich nur bei den beiden Nodes ein neigborUpdate durchgeführt. Bei der nächsten Kommunikation mit den Aktoren war die Übertragungsrate bei beiden Geräten dann plötzlich auf den gewünschten 100 und das angewandte Routenschema war "NextToLastWorkingRoute" laut Callback-Telegramm.

Für die Routenanalyse habe ich meinen (immer noch) unvollendeten Patch-Entwurf aus https://forum.fhem.de/index.php/topic,79893.msg829426.html#msg829426 genutzt. Damit lässt sich das besser nachvollziehen und analysieren als mit manuellen routeFor Abfragen.

Mein vorsichtiges Fazit: neighborUpdate ist wichtiger als von mir vermutet. Die Explorer Frames und andere Selbstheilungsmechanismen scheinen nicht automatisch zum Hochschalten der Übertragungsraten zu führen. Eventuell muss man regelmäßig ein neigborUpdate durchführen, um optimale Übertragungen sicherzustellen und damit auch weniger fehlerhafte Telegramme zu bekommen.

Gruß, Christian

[Parador]

Hallo Christian,
werde mich morgen tiefer in den Patch-Entwurf einlesen. Aktuell habe ich versucht die Routen nachzuvollziehen, scheitere gerade daran, dass zu dem einen Gerät keine Route angezeigt wird, obwohl ein open/close ankommt...
Vielleicht setze ich nochmal die Repeater "perfekt" in die Mitte und mache noch ein neigborUpdate.
Habe ich eigentlich mit "get model" auch eine Chance auf Bereinigung der Readings? oder wird da nur das "Typenschild" neu eingelesen?

[krikan]

werde mich morgen tiefer in den Patch-Entwurf einlesen.

Musst Du nicht. Sollte auch ohne funktionieren. Ist nur Hintergrund-Info woher Routingschema kommt und ein wenig selbstaufgebauter Druck für mich mal endlich weiterzumachen. Bei Interesse darfst Du natürlich...

Aktuell habe ich versucht die Routen nachzuvollziehen, scheitere gerade daran, dass zu dem einen Gerät keine Route angezeigt wird, obwohl ein open/close ankommt...

Wenn nur die Übertragungsrate bei routeFor angezeigt wird, ist das eine Direktverbindung zwischen Controller und Gerät.
Eigentlich sollte Dein Ziel nur sein bei ZwavePlus-Geräten die 100 als Übertragungsrate angezeigt zu bekommen. Die Route an sich ist (relativ) uninteressant; außer beim Strips (-> laut Anleitung Batterieschonung durch Direktverbindung zum Controller)

Habe ich eigentlich mit "get model" auch eine Chance auf Bereinigung der Readings? oder wird da nur das "Typenschild" neu eingelesen?

Keine Chance. Nimm einfach https://fhem.de/commandref.html#deletereading zum Aufräumen.

[krikan]

Vielleicht setze ich nochmal die Repeater "perfekt" in die Mitte und mache noch ein neigborUpdate.

Anmerkung: Damit die Datenübertragungsrate von 100 genutzt wird müssen alle Geräte auf der Route ZWavePlus sein und die 100 unterstützen. Ein ohne Plus-Gerät als Repeater zwingt zu höchstens 40. Andererseits könnte dennoch eine Stabilisierung eintreten. Jaja, hätte, könnte, wäre. 

[Parador]

Hallo Krikan,
ich kämpfe immer noch an meiner ZWave-Aufstellung. Noch sind nicht alle Repeater und andere Switches die als Repeater dienen könnten da...
Ich versuche immer noch meinen Sensative Strips die richtige Route mitzugeben, scheitere aber noch an der "Erreichbarkeit" bis sie aufwachen.
Du hast ja geschrieben: "außer bei dem Strips (-> laut Anleitung Batterieschonung durch Direktverbindung zum Controller)."
Mache ich das konkret? Ich versuche die Rückroute mit

Code Auswählen Erweitern

set <Sensative_Name> returnRouteAdd  <ZwaveControllerName>
zu manipulieren.
Oder muss ich hier noch was dazwischenpacken? Was ist, wenn die "Route zu lang" wird und der Sensative die Telegramme nicht bis zum Controller bringt? (Krieg ich das mit, außer dass keine Veränderungen kommen?
Danke für Deine Unterstützung schon jetzt

[krikan]

Nach dem neigborUpdate für das Netz, kannst Du die Rückroute mit returnRouteAdd so wie von Dir gezeigt manipulieren. Welche Rückrouten der Controller an das Gerät schickt, kannst Du nicht beeinflußen. Mir ist auch kein Weg bekannt, wie man diese auslesen kann.

Was ist, wenn die "Route zu lang" wird und der Sensative die Telegramme nicht bis zum Controller bringt?  (Krieg ich das mit, außer dass keine Veränderungen kommen?

returnRouteAdd erzeugt die Events laut commandref mit Infos zu Erfolg/Mißerfolg.
Schlimmstenfalls tritt Deine Befürchtung für spontane Nachrichten des Sensative ein. Wenn der Controller/Du einen Befehl an den Sensative schickt und NO_ACK auftaucht, siehst Du auch direkt, dass etwas im Argen liegt.

Mit dem Controllerbefehl get-routeFor kannst Du nachträglich herausfinden, welche Route der Controller zum Versand wählt.

[Parador]

Und schon wieder hat sich eine Frage aufgetan:

Code Auswählen Erweitern

set <Sensative_Name> returnRouteAdd  <ZwaveControllerName> stimmt ja nicht ganz, eigentilich muss es wieder

Code Auswählen Erweitern

set <Sensative_Name> returnRouteAdd  <ZwaveControllerDezimaleNodeID> sein.

und die ist diesmal nicht in der DEF ... kannst Du mir da auch nochmal helfen? 

Code Auswählen Erweitern

Internals:
   CallbackNr 0
   Clients    :ZWave:
   DEF        /dev/ttyACM0@115200
   DeviceName /dev/ttyACM0@115200
   FD         20
   FUUID      5c7add52-f33f-3c2f-24e7-3f62334ad9a8224f
   MaxSendRetries 3
   NAME       ZWDongle_0
   NR         59
   PARTIAL   
   RAWMSG     000400120a3202a14a0000012d0000
   ReadTime   1591548487.11977
   STATE      Initialized
   SendRetries 0
   SendTime   1591546173.18217
   TYPE       ZWDongle
   WaitForAck 0
   ZWDongle_0_MSGCNT 1229
   ZWDongle_0_TIME 2020-06-07 18:48:07
   homeId     e65a849f
   nodeIdHex  01
   nrNAck     0

[krikan]

Code Auswählen Erweitern

nodeIdHex  01
entspricht 1 dezimal.

Ja, Namen funktionieren bei returnRouteAdd wirklich nicht, sondern nur NodeIds.

[rudolfkoenig]

Ja, Namen funktionieren bei returnRouteAdd wirklich nicht, sondern nur NodeIds.

Habe das Modul geaendert, sollte damit funktionieren.

[Parador]

Spitze, Danke!