Tester gesucht: Zigbee 3.2.x

[Asgothian]

@fabio Du müsstest im Matter adapter mal schauen ob er den 'available' state als Status der Lampe weiter gibt. Zusätzlich bitte die 'role' des 'available' state im Objektbaum anschauen - und ob der Matter Adapter diesen als 'ist Status der Lampe' weiter gibt - er sollte den eigentlich ignorieren.

Was du zu testzwecken tun kannst ist die role auf indicator.reachable ändern - und dann den Matter Adapter neu starten - schauen ob er dann die Lichter anders ansteuert.

A.

[Fabio]

@asgothian der Matter Adapter muss das ja wohl weitergeben ansonten würde ja in der App es nicht angezeigt, meinst du den role ändern im Zigbee Adapter beim Gerät?
Das komische ist das ich ja 2 (jetzt sogar 3) Instanzen laufen habe und es nicht bei allen Geräten ist.

Im Matter Adapter sieht das Gerät so aus.

  Endpoint 115 (DimmableLight / a4c3b9ac-4359-4c72-aab4-3eff6f0d9526):
    Cluster-Servers:
      Cluster-Server "identify" (0x3) 
        Global-Attributes:
          "clusterRevision" (0xfffd): value = 5
          "featureMap" (0xfffc): value = {}
          "attributeList" (0xfffb): value = [ 0, 1, 65533, 65532, 65531, 65529, 65528 ]
          "acceptedCommandList" (0xfff9): value = [ 0, 64 ]
          "generatedCommandList" (0xfff8): value = []
        Attributes:
          "identifyTime" (0x0): value = 0
          "identifyType" (0x1): value = 1
        Commands:
          "identify" (0x0)
          "triggerEffect" (0x40)
        Events:

      Cluster-Server "groups" (0x4) (Features: groupNames)
        Global-Attributes:
          "clusterRevision" (0xfffd): value = 4
          "featureMap" (0xfffc): value = { groupNames: true }
          "attributeList" (0xfffb): value = [ 0, 65533, 65532, 65531, 65529, 65528 ]
          "acceptedCommandList" (0xfff9): value = [ 0, 1, 2, 3, 4, 5 ]
          "generatedCommandList" (0xfff8): value = [ 0, 1, 2, 3 ]
        Attributes:
          "nameSupport" (0x0): value = { nameSupport: false, groupNames: true }
        Commands:
          "addGroup" (0x0/0x0)
          "viewGroup" (0x1/0x1)
          "getGroupMembership" (0x2/0x2)
          "removeGroup" (0x3/0x3)
          "removeAllGroups" (0x4)
          "addGroupIfIdentifying" (0x5)
        Events:

      Cluster-Server "onOff" (0x6) (Features: lighting)
        Global-Attributes:
          "clusterRevision" (0xfffd): value = 6
          "featureMap" (0xfffc): value = { lighting: true, deadFrontBehavior: false, offOnly: false }
          "attributeList" (0xfffb): value = [ 0, 65533, 65532, 65531, 65529, 65528, 16384, 16385, 16386, 16387 ]
          "acceptedCommandList" (0xfff9): value = [ 0, 64, 65, 66, 1, 2 ]
          "generatedCommandList" (0xfff8): value = []
        Attributes:
          "onOff" (0x0): value = true
          "globalSceneControl" (0x4000): value = true
          "onTime" (0x4001): value = 0
          "offWaitTime" (0x4002): value = 0
          "startUpOnOff" (0x4003): value = null
        Commands:
          "off" (0x0)
          "offWithEffect" (0x40)
          "onWithRecallGlobalScene" (0x41)
          "onWithTimedOff" (0x42)
          "on" (0x1)
          "toggle" (0x2)
        Events:

      Cluster-Server "levelControl" (0x8) (Features: onOff, lighting)
        Global-Attributes:
          "clusterRevision" (0xfffd): value = 6
          "featureMap" (0xfffc): value = { onOff: true, lighting: true, frequency: false }
          "attributeList" (0xfffb): value = [ 0, 15, 17, 65533, 65532, 65531, 65529, 65528, 1, 16384 ]
          "acceptedCommandList" (0xfff9): value = [ 0, 1, 2, 3, 4, 5, 6, 7 ]
          "generatedCommandList" (0xfff8): value = []
        Attributes:
          "currentLevel" (0x0): value = 203
          "options" (0xf): value = { executeIfOff: false, coupleColorTempToLevel: false }
          "onLevel" (0x11): value = null
          "remainingTime" (0x1): value = 0
          "startUpCurrentLevel" (0x4000): value = null
        Commands:
          "moveToLevel" (0x0)
          "move" (0x1)
          "step" (0x2)
          "stop" (0x3)
          "moveToLevelWithOnOff" (0x4)
          "moveWithOnOff" (0x5)
          "stepWithOnOff" (0x6)
          "stopWithOnOff" (0x7)
        Events:

      Cluster-Server "bridgedDeviceBasicInformation" (0x39) 
        Global-Attributes:
          "clusterRevision" (0xfffd): value = 4
          "featureMap" (0xfffc): value = { bridgedIcdSupport: false }
          "attributeList" (0xfffb): value = [ 3, 5, 14, 15, 17, 18, 65533, 65532, 65531, 65529, 65528 ]
          "acceptedCommandList" (0xfff9): value = []
          "generatedCommandList" (0xfff8): value = []
        Attributes:
          "productName" (0x3): value = "Kaffeebar"
          "nodeLabel" (0x5): value = "Kaffeebar"
          "productLabel" (0xe): value = "Kaffeebar"
          "serialNumber" (0xf): value = "a4c3b9ac43594c72aab43eff6f0d9526"
          "reachable" (0x11): value = true
          "uniqueId" (0x12): value = "e20f77882f6d22c1fcfd14b015f69ab3"
        Commands:

        Events:
          "reachableChanged" (0x3)
      Cluster-Server "descriptor" (0x1d) 
        Global-Attributes:
          "clusterRevision" (0xfffd): value = 2
          "featureMap" (0xfffc): value = { tagList: false }
          "attributeList" (0xfffb): value = [ 0, 1, 2, 3, 65533, 65532, 65531, 65529, 65528 ]
          "acceptedCommandList" (0xfff9): value = []
          "generatedCommandList" (0xfff8): value = []
        Attributes:
          "deviceTypeList" (0x0): value = [ { deviceType: 257, revision: 3 }, { deviceType: 19, revision: 3 } ]
          "serverList" (0x1): value = [ 3, 4, 6, 8, 57, 29 ]
          "clientList" (0x2): value = []
          "partsList" (0x3): value = []
        Commands:

        Events:

    Child-Endpoints:

[Asgothian]

@fabio sagte in Tester gesucht: Zigbee 3.2.x:

role ändern im Zigbee Adapter beim Gerät?

• im Objektbaum des Zigbee Adapters, bei einem der Geräte den DP available (im Expertenmodus) anschauen: Welche role hat der
• im Matter Adapter vom gleichen Gerät die Geräteerkennung anschauen - welche DP nutzt er für die Steuerung des Gerätes (geht aus den Daten oben nicht hervor)

Sollte da der available State mit dabei sein, dann muss der da weg. Da ich Matter aktuell nicht nutze, kann ich nicht sagen was da der beste Weg ist.

Daher der Versuch die role des oben angeschauten states auf indicator.reachable anzupassen und dann den Matter Adapter neu zu starten - in der Hoffnung das er das Gerät neu versucht zu erkennen.

A.

nachtrag: Nutzt du Alias Datenpunkte ? Wenn ja, wie erzeugst du die ? Über den 'devices' Adapter - dann ist auch da nochmal eine Mögliche Fehlerquelle.

[Fabio]

@asgothian nein kein Alias und im Matter Adapter gibt es keine Datenpunkte wie beim ZigBee Adapter und du kannst da nachträglich nichts ändern da bleibt nur das Gerät löschen und wieder neu übergeben.

.... so sieht das aus:

{
  "type": "state",
  "common": {
    "name": "Available",
    "color": null,
    "type": "boolean",
    "read": true,
    "write": false,
    "role": "state"
  },
  "native": {},
  "from": "system.adapter.zigbee.1",
  "user": "system.user.admin",
  "ts": 1750057449953,
  "_id": "zigbee.1.04cf8cdf3c7c2a0e.available",
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  }
}

[Asgothian]

@fabio dann mal mit dem Experten Modus aus dem das machen:

{
  "type": "state",
  "common": {
    "name": "Available",
    "color": null,
    "type": "boolean",
    "read": true,
    "write": false,
    "role": "indicator.reachable"
  },
  "native": {},
  "from": "system.adapter.zigbee.1",
  "user": "system.user.admin",
  "ts": 1750057449953,
  "_id": "zigbee.1.04cf8cdf3c7c2a0e.available",
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  }
}

und dann im Matter Adapter rauswerfen und neu hinzufügen.

Wobei mir dann nicht klar wird warum der Matter adapter sich anders verhält wenn du den Zigbee Adapter anpasst. Der Available State wurde auch sonst immer mal wieder aktualisiert.

A.

[Fabio]

@asgothian ich hoffe ich hab es richtig gemacht die role geändert.

Dann das Gerät im Matter Adapter gelöscht. Gewartet bis es bei Apple raus war und dann wieder neu hinzugefügt. Jetzt heißt es warten und schauen was passiert.

[Fabio]

@Asgothian so Test beendet. Ich bestätige das dieser Fehler durch deinen Workaround behoben ist. Hab jetzt alle Geräte wo das war umgestellt, blöd nur das ich sie dann auch erst löschen musste im Matter Adapter.
Sollte man apollon77 das evtl. mitteilen? Ist das überhaupt ein Bug? Erst mal herzlichen Dank melde dich wenn du Zeit hast.
Grüße Fabio

[Asgothian]

@fabio sagte in Tester gesucht: Zigbee 3.2.x:

@Asgothian so Test beendet. Ich bestätige das dieser Fehler durch deinen Workaround behoben ist. Hab jetzt alle Geräte wo das war umgestellt, blöd nur das ich sie dann auch erst löschen musste im Matter Adapter.
Sollte man apollon77 das evtl. mitteilen? Ist das überhaupt ein Bug? Erst mal herzlichen Dank melde dich wenn du Zeit hast.
Grüße Fabio

• das der Type detektor den available state als 'SET_ACTUAL` deklariert ist unglücklich. Das der Matter Adapter den einfach so übernimmt auch.
• Das der Matter Adapter nicht von sich aus auf geänderte Rollen reagiert ist meiner Meinung nach ein Bug - allerdings kann es sein das @apollon77 das absichtlich so umgesetzt hat.

Nen Issue ist das auf aber jeden Fall wert - dann kann geschaut werden ob das absicht, versehen oder bug ist.

Zum Thema Type Detektor (das ist denk ich nicht apollons direkte Baustelle) - das was da gemacht wird ist denkbar unschön:

Lt. der Rollen definition soll ein Datenpunkt dessen Role nicht zu den vordefinierten passt die Role state bekommen:

• state - very common purpose. If you don't know which role the state has, use this one.

Die Doku zum Type-Detector für lights sagt in der Tabelle das der Wert für ON_ACTUAL ein Boolean mit der Role sensor.light sein soll. Leider sagt das Match-Muster das daneben auch Boolean states mit der Role state oder switch als ON_ACTUAL genommen werden.

In der Kombination muss das eigentlich schief gehen. Ob das ein Fehler im Matter Adapter, im Type Detektor oder in der Role Definition ist weiss ich nicht.
Ich kenne verschiedene Zigbee Devices die als Light erkannt werden sollen, die aber weitere boolean States beinhalten - nicht nur available. Bei einigen davon gibt es sogar mehrere read only boolean states.

In der 3.2.6 wird jedenfalls zumindest der state available eine andere Role bekommen: indicator.reachable

Trotzdem ist die Kombination von Role definition, Device-Detektor und Matter Adapter in der Form mindestens mal unglücklich.

A.

[Fabio]

@asgothian
Type detektor available wird als state als 'SET_ACTUAL` deklariert
https://github.com/ioBroker/ioBroker.matter/issues/618

sansonifabio created this issue in ioBroker/ioBroker.matter

closed Type detektor available wird als state als 'SET_ACTUAL` deklariert #618

[apollon77]

Hey. Ja das an einigen stellen im type detector auch generische „state“ rollen genutzt werden sind der vergangenheit geschuldet. Kann ich leider so einfach nicht ändern. Alternative sind aliase oder Rollen korrigieren. Aber ja man kann gern type detector issue mit Beispiel Objekt Export anlegen dann kann man das diskutieren.

Das der matter Adapter (oder auch iot) nicht auf sich ändernde Rollen reagiert ohne restart bzw neustarten der Bridge liegt einfach daran das sich Rollen im Normalfall nicht einfach so ändern. Also für so einen Sonderfall Logik zu bauen empfinde ich daher als eher unnötig um ehrlich zu sein.

[Fabio]

@apollon77 ich bin nur ein einfacher Nutzer und kein Developer und verstehe auch nicht immer die Zusammenhänge.
Aber, ich persöhnlich finde das sehr merkwürdig, das An sich ändert wenn der State dafür aber nicht geschaltet wurde, sondern nur weil value generated 'true' from device a4c1389893367f90 for 'Available' geändert sprich abgefragt wurde, so weiß man letztendlich nicht wie in der Apple Home App, ist das Gerät nun wirklich An oder Aus. Und das finde ich ist ne Dikussion oder Änderung alle mal wert.

Herzliche Grüße
Fabio

[Asgothian]

@apollon77

Das der matter Adapter (oder auch iot) nicht auf sich ändernde Rollen reagiert ohne restart bzw >neustarten der Bridge liegt einfach daran das sich Rollen im Normalfall nicht einfach so ändern. Also für so einen Sonderfall Logik zu bauen empfinde ich daher als eher unnötig um ehrlich zu sein

Nur als Klarstellung - beim Neustart des matter Adapters werden die Änderungen der Role erkannt ?

A.

[apollon77]

@asgothian Sogar beim "Nur neustarten (einmal aus und an) der Bridge" weil dann wird alles eingelesen und gemappt. Ja

[apollon77]

Ich hab mal https://github.com/ioBroker/ioBroker.type-detector/issues/155 angelegt. Gern dort Meinungen rein hauen

Apollon77 created this issue in ioBroker/ioBroker.type-detector

open Check/Adjust ON_ACTUAL #155