[gelöst] Problem mit Zwave Devices beim Anlernen

Begonnen von tux75at, 17 Oktober 2020, 13:54:32

Vorheriges Thema - Nächstes Thema

tux75at

Ich hab ein Problem mit ein paar ZWave geräten, da mir dieses kleine Problem bisher aber kein Problem für meine Funktion war, habe ich es ignoriert.

Es geht ums Anlernen und hier fehlt mir der Begriff, ansonsten würde ich eventuell etwas suchen können.
Der Steinel Bewegungsmelder (funktioniert nicht ganz so wie ich mir das Wünsche, aber genügt meinen Ansprüchen), hat eine Subdevices.
Device besteht aus dem Konfigurationsgerät welche nur die NodeID hat, dann gibt es noch NodeID mit 01, 02, 03, 04 und 05.
Soweit ich es herauslesen konnte, sind das der Aktor für den Ausgang (meldet ein/aus), Alarmmeldungen vom Bewegungsmelder, Helligkeitssensor, Schalter zum getrennten schalten ohne Bewegungsmelder und einen Sensor.

Da mir der Bewegungsmelder defekt wurde, wollte ich ihn austauschen und habe den Kreis abgedreht, einmal Version ausgelesen, isFailedDevice --> yes, und dann versucht mit replaceFailedNode inkludieren.
Das hat leider nicht geklappt und ich dachte mir, dann lerne ich den neu an. Das hat funktioniert (extra nochmals exkludiert vor dem inkludieren)
Jetzt sind nicht alle Devices aufgetaucht.

ZWave_SENSOR_NOTIFICATION_89
ZWave_SENSOR_MULTILEVEL_89.02
ZWave_SWITCH_BINARY_89.03

waren gleich da.

Später dann

ZWave_Node_89.1

Dieses  hat jetzt aber keine Funktion, es fehlt scheinbar die Verbindung zum Bewegungsmelder.
Es gibt auch nur die Möglichkeit "set ZWave_Node_89.1 attrTemplate" auszuführen, aber da kann ich nicht das richtige auswählen, bzw. für eine Eingabe in der Kommandozeile weiss ich nicht was man hier eingeben muss, damit die Verbindung wieder da ist und das Gerät verwendbar wird.

Gibt es eine Lösung dazu außer wieder zu exkludieren und inkludieren?

tux75at

Logfile:

2020-10-17_13:29:28 os_eingang_bewegungsmelder mcCreateAll
2020-10-17_13:29:28 os_eingang_bewegungsmelder modelId: 0271-0002-1a72
2020-10-17_13:29:28 os_eingang_bewegungsmelder modelConfig: steinel/is140-2.xml
2020-10-17_13:29:28 os_eingang_bewegungsmelder model: Steinel IS140-2
2020-10-17_13:29:32 os_eingang_bewegungsmelder mcaAdd 1 0 1 0
2020-10-17_13:29:32 os_eingang_bewegungsmelder transmit: NO_ACK
2020-10-17_13:29:38 os_eingang_bewegungsmelder transmit: NO_ACK
2020-10-17_13:29:46 os_eingang_bewegungsmelder transmit: NO_ACK
2020-10-17_13:29:49 os_eingang_bewegungsmelder mcEndpoints: total 3, different
2020-10-17_13:29:50 os_eingang_bewegungsmelder mcEndpoints: total 3, different
2020-10-17_13:29:51 os_eingang_bewegungsmelder mcEndpoints: total 3, different
2020-10-17_13:29:51 os_eingang_bewegungsmelder mcCapability_02: ZWAVEPLUS_INFO SENSOR_MULTILEVEL ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO
2020-10-17_13:29:51 os_eingang_bewegungsmelder mcCapability_03: ZWAVEPLUS_INFO ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO SWITCH_BINARY SWITCH_ALL APPLICATION_STATUS
2020-10-17_13:29:51 os_eingang_bewegungsmelder mcCapability_03: ZWAVEPLUS_INFO ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO SWITCH_BINARY SWITCH_ALL APPLICATION_STATUS
2020-10-17_13:34:41 os_eingang_bewegungsmelder configDurationOfLightAfterMotion1: 180
2020-10-17_13:34:41 os_eingang_bewegungsmelder configGlobalLight: Disable
2020-10-17_13:34:41 os_eingang_bewegungsmelder configLightThreshold: 2000
2020-10-17_13:34:41 os_eingang_bewegungsmelder configMotionOffBehaviour: 0
2020-10-17_13:34:41 os_eingang_bewegungsmelder configOffBehaviour: 10
2020-10-17_13:34:42 os_eingang_bewegungsmelder configOnBehaviour: 255
2020-10-17_13:34:42 os_eingang_bewegungsmelder configOnBehaviourTimeOver: 204
2020-10-17_13:34:42 os_eingang_bewegungsmelder configSensitivity: 100
2020-10-17_13:34:42 os_eingang_bewegungsmelder configSequenceOffOnBehaviour: 204
2020-10-17_13:34:43 os_eingang_bewegungsmelder configSequenceOnOffBehaviour: 204
2020-10-17_13:34:43 os_eingang_bewegungsmelder configSequenceTiming: 10
2020-10-17_13:34:43 os_eingang_bewegungsmelder configSlaveMode: NormalModeWithLifelineError2
2020-10-17_13:37:29 os_eingang_bewegungsmelder configDurationOfLightAfterMotion1: 180
2020-10-17_13:37:29 os_eingang_bewegungsmelder configGlobalLight: Disable
2020-10-17_13:37:29 os_eingang_bewegungsmelder configLightThreshold: 2000
2020-10-17_13:37:29 os_eingang_bewegungsmelder configMotionOffBehaviour: 0
2020-10-17_13:37:29 os_eingang_bewegungsmelder configOffBehaviour: 10
2020-10-17_13:37:30 os_eingang_bewegungsmelder configOnBehaviour: 255
2020-10-17_13:37:30 os_eingang_bewegungsmelder configOnBehaviourTimeOver: 204
2020-10-17_13:37:30 os_eingang_bewegungsmelder configSensitivity: 100
2020-10-17_13:37:30 os_eingang_bewegungsmelder configSequenceOffOnBehaviour: 204
2020-10-17_13:37:30 os_eingang_bewegungsmelder configSequenceOnOffBehaviour: 204
2020-10-17_13:37:31 os_eingang_bewegungsmelder configSequenceTiming: 10
2020-10-17_13:37:31 os_eingang_bewegungsmelder configSlaveMode: NormalModeWithLifelineError2
2020-10-17_13:56:12 os_eingang_bewegungsmelder version: Lib 3 Prot 4.38 App 1.0 HW 8 FWCounter 1 FW 8.9
2020-10-17_14:03:05 os_eingang_bewegungsmelder mcEndpoints: total 3, different
2020-10-17_14:03:32 os_eingang_bewegungsmelder modelId: 0271-0002-1a72
2020-10-17_14:03:32 os_eingang_bewegungsmelder modelConfig: steinel/is140-2.xml
2020-10-17_14:03:32 os_eingang_bewegungsmelder model: Steinel IS140-2

rudolfkoenig

Mir ist nicht ganz klar was fehlt.

Das FHEM-Modul legt alle subdevice an, wenn das Haupttgeraet MULTI_CHANNEL unterstuetuetzt. Genauer gesagt, falls die Klasse vorhanden ist, wird bei der Inklusion des Hauptgeraetes mcCreateAll abgesetzt, was fuer jeden subDevice ein mcCapability absetzt, und die Antwort auf diese Abfrage erzeugt das FHEM-Geraet.

Vmtl. ist mcCreateAll bei der Inklusion schiefgegangen, und man muss es wiederholen.

Siehe auch
https://wiki.fhem.de/wiki/Z-Wave#Wie_k.C3.B6nnen_bei_mehrkanaligen_Aktoren_die_zus.C3.A4tzlichen_Kan.C3.A4le_.28.3E1.29_angesprochen_werden.3F
https://wiki.fhem.de/wiki/Z-Wave#Welche_Infos_sollten_Anfragen_im_ZWave-Forum_enthalten.3F

Zitat2020-10-17_13:29:49 os_eingang_bewegungsmelder mcEndpoints: total 3, different
Laut Geraet gibt es "nur" 3 endPoints aka subDevices.


tux75at

Danke Rudolf, wie setzt man ein mcCreateAll ab?

set mcCreateAll auf das Device funktioniert leider nicht, oder meinst du die Inklusion wiederholen?

Die "notwendigen Infos" habe ich übersehen, ich liefere sie jetzt nach:

list <device>:
Internals:
   DEF        dc682b87 89
   FUUID      5f8ad582-f33f-1245-3815-0bfe0c9b476743b3
   FVERSION   10_ZWave.pm:0.229660/2020-10-13
   IODev      ZWDongle_0
   NAME       os_eingang_bewegungsmelder_aktor
   NR         484
   STATE      mcaAdd 1 0 1 0
   TYPE       ZWave
   ZWaveSubDevice no
   endpointChildren ZWave_Node_89.1,os_eingang_bewegungsmelder_sensor_02,os_eingang_bewegungsmelder_schalter_03
   homeId     dc682b87
   nodeIdHex  59
   READINGS:
     2020-10-17 13:29:32   SEND_DATA       failed:00
     2020-10-17 22:16:15   associatedWith  ZWave_Node_89.1,os_eingang_bewegungsmelder_sensor_02,os_eingang_bewegungsmelder_schalter_03
     2020-10-17 13:37:29   configDurationOfLightAfterMotion1 180
     2020-10-17 13:37:29   configGlobalLight Disable
     2020-10-17 13:37:29   configLightThreshold 2000
     2020-10-17 13:37:29   configMotionOffBehaviour 0
     2020-10-17 13:37:29   configOffBehaviour 10
     2020-10-17 13:37:30   configOnBehaviour 255
     2020-10-17 13:37:30   configOnBehaviourTimeOver 204
     2020-10-17 13:37:30   configSensitivity 100
     2020-10-17 13:37:30   configSequenceOffOnBehaviour 204
     2020-10-17 13:37:30   configSequenceOnOffBehaviour 204
     2020-10-17 13:37:31   configSequenceTiming 10
     2020-10-17 13:37:31   configSlaveMode NormalModeWithLifelineError2
     2020-10-17 22:13:53   mcCapability_01 ZWAVEPLUS_INFO ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO ALARM
     2020-10-17 22:13:53   mcCapability_02 ZWAVEPLUS_INFO SENSOR_MULTILEVEL ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO
     2020-10-17 22:13:53   mcCapability_03 ZWAVEPLUS_INFO ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO SWITCH_BINARY SWITCH_ALL APPLICATION_STATUS
     2020-10-17 22:13:53   mcEndpoints     total 3, different
     2020-10-17 14:03:32   model           Steinel IS140-2
     2020-10-17 14:03:32   modelConfig     steinel/is140-2.xml
     2020-10-17 14:03:32   modelId         0271-0002-1a72
     2020-10-17 13:29:32   state           mcaAdd 1 0 1 0
     2020-10-17 22:13:53   timeToAck       0.136
     2020-10-17 22:13:53   transmit        OK
     2020-10-17 13:56:12   version         Lib 3 Prot 4.38 App 1.0 HW 8 FWCounter 1 FW 8.9
Attributes:
   DbLogExclude .*
   IODev      ZWDongle_0
   classes    ZWAVEPLUS_INFO FIRMWARE_UPDATE_MD VERSION MANUFACTURER_SPECIFIC MULTI_CHANNEL DEVICE_RESET_LOCALLY CONFIGURATION POWERLEVEL NODE_NAMING ALARM ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO SENSOR_MULTILEVEL SWITCH_BINARY SWITCH_ALL
   room       OS->Eingang,ZWave
   vclasses   ALARM:4 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:3 MANUFACTURER_SPECIFIC:2 MULTI_CHANNEL:4 MULTI_CHANNEL_ASSOCIATION:3 NODE_NAMING:1 SENSOR_MULTILEVEL:4 SWITCH_ALL:1 SWITCH_BINARY:1 VERSION:2 ZWAVEPLUS_INFO:2


get assosiationAll:
2020-10-17_22:19:31 os_eingang_bewegungsmelder_aktor assocGroups: 4
2020-10-17_22:19:31 os_eingang_bewegungsmelder_aktor assocGroup_1: Max 1 Nodes
2020-10-17_22:19:31 os_eingang_bewegungsmelder_aktor assocGroup_2: Max 16 Nodes
2020-10-17_22:19:31 os_eingang_bewegungsmelder_aktor assocGroup_3: Max 16 Nodes
2020-10-17_22:19:32 os_eingang_bewegungsmelder_aktor assocGroup_4: Max 16 Nodes


get configAll: (Standard, nach Inklusion nichts verändert)
2020-10-17_22:20:23 os_eingang_bewegungsmelder_aktor configDurationOfLightAfterMotion1: 180
2020-10-17_22:20:23 os_eingang_bewegungsmelder_aktor configGlobalLight: Disable
2020-10-17_22:20:23 os_eingang_bewegungsmelder_aktor configLightThreshold: 63
2020-10-17_22:20:23 os_eingang_bewegungsmelder_aktor configMotionOffBehaviour: 0
2020-10-17_22:20:24 os_eingang_bewegungsmelder_aktor configOffBehaviour: 10
2020-10-17_22:20:24 os_eingang_bewegungsmelder_aktor configOnBehaviour: 255
2020-10-17_22:20:24 os_eingang_bewegungsmelder_aktor configOnBehaviourTimeOver: 204
2020-10-17_22:20:24 os_eingang_bewegungsmelder_aktor configSensitivity: 100
2020-10-17_22:20:24 os_eingang_bewegungsmelder_aktor configSequenceOffOnBehaviour: 204
2020-10-17_22:20:25 os_eingang_bewegungsmelder_aktor configSequenceOnOffBehaviour: 204
2020-10-17_22:20:25 os_eingang_bewegungsmelder_aktor configSequenceTiming: 10
2020-10-17_22:20:25 os_eingang_bewegungsmelder_aktor configSlaveMode: NormalModeWithLifelineError2


get <device> versionClassAll, hier stehe ich an, ist das vclasses Attributes?
ALARM:4 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:3 MANUFACTURER_SPECIFIC:2 MULTI_CHANNEL:4 MULTI_CHANNEL_ASSOCIATION:3 NODE_NAMING:1 POWERLEVEL:1 SENSOR_MULTILEVEL:4 SWITCH_ALL:1 SWITCH_BINARY:1 VERSION:2 ZWAVEPLUS_INFO:2

get mcaAll:
2020-10-17_22:23:35 os_eingang_bewegungsmelder_aktor mcaGroups: 4
2020-10-17_22:23:36 os_eingang_bewegungsmelder_aktor mca_1: Max 1 Nodes ZWave_STATIC_CONTROLLER_1:0
2020-10-17_22:23:37 os_eingang_bewegungsmelder_aktor mca_2: Max 16
2020-10-17_22:23:38 os_eingang_bewegungsmelder_aktor mca_3: Max 16
2020-10-17_22:23:39 os_eingang_bewegungsmelder_aktor mca_4: Max 16


verbose 5 und mseclog 1 waren beim Inkludieren nicht gesetzt, nachstellen kann ich das nicht, da ich das Gerät nochmals ex- und inkludieren müsste.
Ein replaceFailedNode hat nicht funktioniert, ist das Gerätespezifisch?

Das Problem mit den zwei Weiteren Subdevices dürfte ein Kommunikationsproblem gewesen sein. Subnode 4 und Subnode 5 haben nur zu einem bestimmten Zeitraum Meldungen geliefert. und diese waren, als das Gerät öfter mal gesponnen hat. Ich habe es auf eine Fehlkonfiguration geschoben, als ich versucht habe ein Z-Wave Gerät zu schalten und tagsüber hat der Bewegungsmelder dann hunderte Ausschaltmeldungen geliefert und mein Z-Wave Netz lahmgelegt. Der Support von Steinel hat hier auch nicht geholfen, da ich nicht deren SmartFriendsBox, oder wie sie heißt, verwende. 3 Subdevices sollten passen.

Kann man den Zustand reparieren? oder muss man das Gerät exkludieren und neu inkludieren?
Im Device Overview sehe ich nur ein mögliches set <Device> attrTemplate und ich kann nur Fibaro, Aeotec und Eurotronic sowie ein paar scheinbar Generische auswählen.
Fehlt hier die Unterstützung des Steinel Gerätes? oder ist das Aufgrund der fehlerhaften Inclusion sowieso der falsche Weg?

curt

OT:
Hallo @tux75at

Wie Du gelesen oder nicht gelesen hast, "ärgere" ich mich an anderen Stellen mit anderen ZWave-Geräten auch rum.

Kannst Du mal bitte zeigen, um welches Gerät es eigentlich geht? (Da Amazon im Grunde alles mit ZWave vertickert, wäre ein Amazon-Link schön.)
RPI 4 - Jeelink HomeMatic Z-Wave

rudolfkoenig

Mir fehlt immer noch die klare Formulierung des Problems.

Da du ueber Subdevice 4 und 5 redest: Laut Geraet gibt es nur 3:
Zitat2020-10-17 22:13:53   mcEndpoints     total 3, different
Aus diesem Grund kommt FHEM auch nicht auf die Idee, nach weiteren Subdevices zu suchen.

Zitatset mcCreateAll auf das Device funktioniert leider nicht, oder meinst du die Inklusion wiederholen?
Bei der Inklusion wird auch nur "set device mcCreateAll" abgesetzt.
Was genau heisst "funktioniert leider nicht"?

tux75at

#6
Gerät: model: Steinel IS140-2
Ist im Logfile bzw nochmal wo drinne.

Produktlink:
https://www.steinel.de/de/lights-sensors/produkte/sensoren/bewegungsmelder/is-140-2-z-wave-029814.html

Das Problem mit der Anzahl der Endpoints ist garkein Problem, es gibt nur 3. Ich vermute durch Kommunikationsprobleme gab es plötzlich zwei weitere, wobei diese nur kurz mal etwas gesendet haben. Vielleicht auch ein Schluckauf des Gerätes? ich weiss es nicht.
Anzahl der Endpoints ist geklärt und kann man vergessen. Das Gerät habe ich auch ausgetauscht, da es sowieso defekt ist.

Jetzt habe ich nach Anlernen zwei Endpoints 02 und 03 welche richtig funktionieren, der Enpoint 01 ist jedoch beim inkludieren fehlerhaft angelegt worden.
Dieser zeigt jetzt nur mehr die Möglichkeit eines Befehlels "set attrTemplate". Ich kann auch nicht das richtige auswählen.
Dieser Endpoint liefert die Bewegungsinformation"alarm: HomeSecurity: Motion Detection".
Irgendwie hängt er in der Luft und ist nicht richtig dem Bewegungsmelder zugeordnet.
Ausser bei diesem Endpoint gibt es nichts anderes und das ist normal, für mich schaut es nicht richtig aus.
Bei allen anderen Endpoints kann man set und get ausführen und zumindest "get zwavePlusInfo", "get" fehlt jedoch vollständig in der Weboberläche.
Wenn ich get ZWave_Node_89.1 zwavePlusInfo eingebe erhalte folgende Antwort:
Unknown argument zwavePlusInfo, choose one of
Die Meldung hört mit "of" auf, es gibt laut FHEM keine argumente für "set".

Wenn es normal für dieses Gerät ist, dann passt es, aber für mich sieht es nicht richtig aus.

edit: Amazonlink auf Produktlink von Steinel geändert

rudolfkoenig

Welche Befehle (set und get) zur Verfuegung stehen, bestimmt (groesstenteils) das classes Attribut.

Die Liste der unterstutzten Klassen wird beim Inkludieren/Anlegen vom Geraet selbst geliefert, damit beschreibt das Geraet, was es kann.

Das gilt genauso fuer die Kanaele (aka subdevices), wenn das Hauptgeraet MULTI_CHANNEL unterstuetzt. mcaCreateAll fragt bei der Inklusion der Reihe nach die Klassen (und damit indirekt die verfuegbaren Befehle) fuer jeden einzelnen Kanal ab. Mit "get Hauptgeraet mcCapability 1" kann man diese Abfrage fuer Kanal 1 manuell wiederholen, das Ergebnis (Liste der Klassen) landet in mcCapability_1 Reading des Hauptgeraetes.

Wenn diese nicht mit dem classes Attribut der Subdevice uebereinstimmt, dann ist in der Tat was schiefgelaufen.

tux75at

#8
Danke Rudolf für deine Erklärungen, leider hatte ich die letzten Tage nicht genug Zeit zu antworten.

Ich versuche dieses Gerät zu verstehen, ich hab ein paar Screenshots gemacht, damit du siehst wie es bei mir aussieht.
Wenn das so in Ordnung ist, kann ich es akzeptieren, aber es sieht halt nicht nicht richtig aus.
Falls mehr notwendig ist, gib bescheid. Die Readings habe ich weggelassen, ich glaub nicht dass sie notwendig sind.

Maindevice, sowie die drei Subdevices und die mcCapabilities für die drei subdevices (get mcCapability 1 bis 3).

Im Bild "os_eingang_bewegungsmelder_alarm_01.png" ist dieses merkwürdige SET zu sehen, auf mich wirkt es, als ob FHEM es, aus logischer Sicht" mit keinem Gerät verbunden hat. Durch die Node ID ist klarer weise mit dem Bewegungsmelder verbunden (Subdevice).

edit: Home ID aus Screenshots entfernt

rudolfkoenig

ZitatDie Readings habe ich weggelassen, ich glaub nicht dass sie notwendig sind.
Die Internals sind fuer das diskutierte Problem ("Wo sind die gets/sets beim Subdevice #1") noch weniger relevant.
Wie zuletzt geschrieben, es kommt auf das classes Attribut an, und das ist in keinem der Screenshots zu sehen.

Wenn mcCapability_1 nicht mit dem classes Attribut im dazugehoerigen Subdevice uebereinstimmt, dann sollte das Subdevice entfernt, und mit mcCreateAll wieder angelegt werden.

attrTemplate wird bei ZWave automatisch hinzugefuegt, die Liste der attrTemplate Parameter je nach Geraete-Eigenschaften gefiltert.

tux75at

Hallo Rudolf,

Hier hab ich zuvor etwas nicht richtig verstanden, liegt vielleicht auch noch daran, dass dieses Classes Attribute beim Subdevice garnicht vorkommt.
D.h. es stimmt damit nicht mit dem mcCapability überein. (Annahme: kein Classes Attribute ist identisch zu Attribute Classes = "")

Um das zu korrigieren sollte man das Subdevice entfernen und mit mcCreateAll wieder anlegen.
Wenn ich das richtig verstanden habe ein "delete SubDevice1" und danach ein "set MainDevice mcCreateAll" ?
Damit sollte das gelöschte SubDevice1 mit einem generischen Namen neu erstellt werden?

rudolfkoenig

ZitatWenn ich das richtig verstanden habe ein "delete SubDevice1" und danach ein "set MainDevice mcCreateAll" ?
Ja.

tux75at

Danke Rudolf, wieder was dazugelernt.

Das Attribute Classes sieht viel besser aus, es existiert und zeigt den richtigen Inhalt.
Jetzt sind auch die "set" und "get" korrekt und nicht mehr nur dieses attrTemplate zum auswählen.

Ich vermute mal, dass es beim Inkludieren zu Problemen gekommen ist.
Jetzt weiss ich wie man dies Reparieren kann :)

curt

Zitat von: tux75at am 24 Oktober 2020, 22:41:50
Ich vermute mal, dass es beim Inkludieren zu Problemen gekommen ist.

@tux75at
Die Lösung habe ich auch verstanden - nur das Problem noch nicht. Respektive wie man es erkennt.

Das ist in diesem Forum leider oft so: Fachleute unterhalten sich über Geheimwissenschaften und man liest ratlos mit und denkt: Wäre doch schön, das auch zu verstehen.

Also mal ganz konkret:
Woran ganz genau hast Du gesehen, dass da etwas nicht richtig ist?
RPI 4 - Jeelink HomeMatic Z-Wave

tux75at

Hallo Curt,

Oben in den Bildern ist bei einem Subdevice nur ein set möglich und auch nur eingeschränkt auf "attrTemplate".
Das hat mich Stutzig gemacht, aber auch einige .... eigentlich sogar einige viele Subdevices die irgendwie nicht gepasst haben.
Z.B. ZWave_17.33 oder ZWave_54.13, also die Subdevicenummer höher als 5 ist ein Anzeichen dass etwas nicht passt, es gibt vielleicht einige wenige Geräte mit mehr Subdevices, aber sicher nicht viele.
Bei mir war es bei einem .01, das nicht richtig Initialisiert worden ist. Normalerweise kann man zumindest die Version mit einem get abfragen (Ausnahmen wird es vielleicht geben). Aber wenn das nicht möglich ist, dann stimmt höchst wahrscheinlich etwas nicht.

Nachdem ich viele fehlerhafte Subdevices gelöscht habe, habe ich auch ein
set TYPE=ZWave:FILTER=ZWaveSubDevice=no mcCreateAll
ausgeführt. Ich denke mal ich hab das richtig verstanden: Alle Geräte vom Typ ZWave mit einem Filter auf keine Subdevices ein set mcCreateAll ausführen.
Damit werden, wenn es ein Subdevice nicht gibt (sic!) die Subdevices neu angelegt.