Intégration de multiprise LIDL Silvercrest

Bonjour,

on dirait qu’ils sont parvenus à le fair marcher sur Z2mqtt
https://github.com/Koenkk/zigbee2mqtt/issues/9564#issuecomment-1061509295

Il y a u patch à éditer quelque part.
J’espère que ça trouvera son chemin vers les plugins Z2MQTT et Deconz prochainement.

c’est cool. Si on veut pa trop bidouiller, dans 1 ou 2 mois ca sera sur l’addon en version stable

J’ai lu le topic. Le chemin pour les device.js ca marche pas dans l’add on. Ca marche si Z2M est sur une autre VM mais pas en add on de HA

Salut les copains,
J’avais aussi acheté 2 prises, versions de septembre 21 et je viens de tester la version z2mqtt edge et ça fonctionne. Le pb c’est que lon installation principale tourne sous zha et je n’ai pas envie de tout switcher juste pour ça :sweat_smile:. Étant tout nouveau, mon raspberry est arrivé semaine passée, vous pouvez me dire en deux mots, quelle est la fréquence des mises à jour de la base de données des appareils pour zha ? Faut il faire quelque chose en particulier pour profiter de cette maj sur mes multiprises ? Je n’ai pas trouvé aussi facilement et aussi clairement les infos que pour z2mqtt. A bientôt

1 « J'aime »

Salut Chiboule,
les mises à jour de Z2M se font le premier de chaque mois.
Il y a une procédure à suivre en ssh.
En Français et clair :
https://iooner.io/mise-a-jour-de-zigbee-2-mqtt/
A+

Salut Nico;

Pour Z2M, en effet, j’avais vu ça mais ce qui m’intéresse c’es zha, je n’ai rien vu a ce sujet, en gros je ne sais pas combien de temps on va devoir attendre pour que la multiprise soit prise en charge et je suis à 2 doigts de passer sur z2mqtt, ce qui me retient c’est de devoir réinclure mes appareils :smiling_face_with_tear:

1 « J'aime »

Pour les mises à jour de ZHA il n’y a pas de règle fixe. On peut espérer que les mises à jour mineures trouvent leur chemain dans HA une fois par mois.

« Au pire » quand on constate que son quirk a été mis à jour, il est possible de l’installer localement sans attendre la mise à jour sous Home Assistant - ni même l’intégration « officielle » dans cette bibliothèque de « quirks ».

Pour cela j’ai ceci dans mon configuration.yaml:

zha:
  enable_quirks: true
  custom_quirks_path: /config/zha_quirks

Ce qui indique à ZHA qu’il faut d’abord chercher un « quirk » dans le répertoire /config/zha_quirks . Dans la plupart des cas il suffit de déposer le fichier du quirk trouvé en ligne dans ce répertoire là. Cela devient un peu plus complexe si plusieurs fichiers interviennent. (Et après l’ajout du quirk, il faut redémarrer home assistant).

Pour info ‹ quirk › se décrit comme ‹ une habitude comportementale particulière ›. Et c’est utilisé pour ces encapsulations qui ont pour but de rendre un comportement déviant (de la specification zigbee) « compatible » avec ZHA.

Ah merci, tout va bien avec zha et je n’ai vraiment que ces 2 prises qui me posent probleme. Je ne sais pas si ça vaut vraiment la peine de changer juste pour ça mais cette histoire de mise à jour manuelle, c’est déja un pas en avant pour moi. Un grand merci!

Petite remarque, j’ai donc testé sous z2m, et ça marchait. Je suis revenu sous ZHA et le périph que j’avais réassocié avec z2m, fonctionne correctement sous ZHA maintenant. Or, j’ai une autre multiprise que je n’avais pas associée a z2m et elle, fonctionne encore à l’ancienne. Comment expliquer cela? Les parametres sont sauvés dans le dongle usb? Dans la prise? J’ai besoin d’un éclaircissement là! Merci! (Pour etre sur que la base de données de ZHA n’ait pas été mise à jour, j’ai supprimé la multiprise défaillante, réassociée uniquement avec ZHA et elle n’a pas pris les nouveaux paramètres)

Je ne vois pas de particularité dans le code spécifique de Z2M:

Seule choses que je constate:

  • meta: {multiEndpoint: true},
  • le « fingerprint » n’exige pas que la définition des endpoints et clusters ne semblent pas faire partie de l’exigence de correspondance pour trouver le quirk correspondant.

Le premier point peut avoir un impact à travers ce (type de) code:

Il se peut que le simple fait de supposer qu’il y a les 3 EP et de les appelers débloque la situation - mystérieux, mais pourquoi pas.

Du coup un quirk qui indique en critère les EP et clusters données initialement et indiquant qu’en réalité il y a 3 EP peut le faire (ou être un début).

Il faudrait lire la configuration initiale (avant de passer par Z2M) et après passage par Z2M.

Pour la multiprise de la « première génération », j’ai ceci comme « Device signature » pris dans la page du device:

{
  "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.Router: 1>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice: 142>, manufacturer_code=4098, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=True, *is_security_capable=False)",
  "endpoints": {
    "1": {
      "profile_id": 260,
      "device_type": "0x010a",
      "in_clusters": [
        "0x0000",
        "0x0003",
        "0x0004",
        "0x0005",
        "0x0006"
      ],
      "out_clusters": [
        "0x000a",
        "0x0019"
      ]
    },
    "2": {
      "profile_id": 260,
      "device_type": "0x010a",
      "in_clusters": [
        "0x0003",
        "0x0004",
        "0x0005",
        "0x0006"
      ],
      "out_clusters": []
    },
 "3": {
      "profile_id": 260,
      "device_type": "0x010a",
      "in_clusters": [
        "0x0003",
        "0x0004",
        "0x0005",
        "0x0006"
      ],
      "out_clusters": []
    },
    "242": {
      "profile_id": 41440,
      "device_type": "0x0061",
      "in_clusters": [],
      "out_clusters": [
        "0x0021"
      ]
    }
  },
  "manufacturer": "_TZ3000_vzopcetz",
  "model": "TS011F",
  "class": "zhaquirks.tuya.ts011f_plug.Plug_3AC_4USB"
}

Sinon, est-ce que dans les 2 cas le quirk s’applique sous ZHA ?

Je t’avoue ne pas comprendre grand chose à ce que tu expliques, mais voici ce que j’obtiens dans ZHA suite a la restauration de mon backup, et qui fonctionne correctement depuis cette fameuse manip avec z2m edge

{
« node_descriptor »: « NodeDescriptor(logical_type=<LogicalType.Router: 1>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice: 142>, manufacturer_code=4098, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=True, *is_security_capable=False) »,
« endpoints »: {
« 1 »: {
« profile_id »: 260,
« device_type »: « 0x010a »,
« in_clusters »: [
« 0x0000 »,
« 0x0003 »,
« 0x0004 »,
« 0x0005 »,
« 0x0006 »
],
« out_clusters »: [
« 0x000a »,
« 0x0019 »
]
},
« 2 »: {
« profile_id »: 260,
« device_type »: « 0x010a »,
« in_clusters »: [
« 0x0003 »,
« 0x0004 »,
« 0x0005 »,
« 0x0006 »
],
« out_clusters »: []
},
« 3 »: {
« profile_id »: 260,
« device_type »: « 0x010a »,
« in_clusters »: [
« 0x0003 »,
« 0x0004 »,
« 0x0005 »,
« 0x0006 »
],
« out_clusters »: []
},
« 242 »: {
« profile_id »: 41440,
« device_type »: « 0x0061 »,
« in_clusters »: [],
« out_clusters »: [
« 0x0021 »
]
}
},
« manufacturer »: « _TZ3000_vzopcetz »,
« model »: « TS011F »,
« class »: « zhaquirks.tuya.ts011f_plug.Plug_3AC_4USB »
}

Voilà - après ce passage il y a donc bien 3 endpoints (1, 2, 3) comme pour la version de l’année dernière et on voit que le quirk est utilisé: « zhaquirks.tuya.ts011f_plug.Plug_3AC_4USB » bien qu’il y ait une classification « lidl » dans les quirk - mais cela est secondaire.

Alors que @buzz-77 plus haut n’a qu’un seul endpoint et pas de quirk utilisé.

Pour les courageux entre vous, vous pouvez tenter de coller ce qui suit dans un fichier avec extension .py (exemple: lidl_tfs011f_plug.py) et le mettre dans un répertoire destinés aux quirks locaux.

Si tout va bien, dans un premier temps ce quirk sera indiqué dans le détail de l’appareil et si la magie opère, plus tard (après un redémarrage) le quirk « officiel ». Mais tant que cela fonctionne, pas besoin de redémarrer.

"""TS011F plug."""

from zigpy.profiles import zha
from zigpy.zcl.clusters.general import (
    Basic,
    GreenPowerProxy,
    Groups,
    Identify,
    OnOff,
    Ota,
    Scenes,
    Time,
)

from zhaquirks.const import (
    DEVICE_TYPE,
    ENDPOINTS,
    INPUT_CLUSTERS,
    MODEL,
    OUTPUT_CLUSTERS,
    PROFILE_ID,
)
from zhaquirks.tuya import Plug_3AC_4USB


class Lidl_Plug_3AC_4USB(Plug_3AC_4USB):
    """LIDL 3 outlet + 4 USB with restore power state support."""

    signature = {
        MODEL: "TS011F",
        ENDPOINTS: {
            # <SimpleDescriptor endpoint=1 profile=260 device_type=266
            # device_version=1
            # input_clusters=[0, 3, 4, 5, 6]
            # output_clusters=[10, 25]>
            1: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.ON_OFF_PLUG_IN_UNIT,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    Identify.cluster_id,
                    Groups.cluster_id,
                    Scenes.cluster_id,
                    OnOff.cluster_id,
                ],
                OUTPUT_CLUSTERS: [Time.cluster_id, Ota.cluster_id],
            },
            # <SimpleDescriptor endpoint=242 profile=41440 device_type=97
            # device_version=1
            # input_clusters=[]
            # output_clusters=[33]>
            242: {
                PROFILE_ID: 41440,
                DEVICE_TYPE: 97,
                INPUT_CLUSTERS: [],
                OUTPUT_CLUSTERS: [GreenPowerProxy.cluster_id],
            },
        },
    }

Qu’est-ce que cela fait: cela réutilise le quirk d’origine mais modifie l’exigence de correspondance: un seul endpoint.
Et comme cela hérite du quirk principal, ZHA va « voir » 3 endpoints.

Bonjour,
J’ai essayé ta proposition, mais ça me met en croix tout ZHA. Du coup j’ai supprimé le fichier créé et tout est rentré dans l’ordre.

EDIT :

Ok, j’ai fait un petit test en local qui valide le chargement, il fallait ajuster le chemin de l’import.

"""TS011F plug."""

from zigpy.profiles import zha
from zigpy.zcl.clusters.general import (
    Basic,
    GreenPowerProxy,
    Groups,
    Identify,
    OnOff,
    Ota,
    Scenes,
    Time,
)

from zhaquirks.const import (
    DEVICE_TYPE,
    ENDPOINTS,
    INPUT_CLUSTERS,
    MODEL,
    OUTPUT_CLUSTERS,
    PROFILE_ID,
)
from zhaquirks.tuya.ts011f_plug import Plug_3AC_4USB


class Lidl_Plug_3AC_4USB(Plug_3AC_4USB):
    """LIDL 3 outlet + 4 USB with restore power state support."""

    signature = {
        MODEL: "TS011F",
        ENDPOINTS: {
            # <SimpleDescriptor endpoint=1 profile=260 device_type=266
            # device_version=1
            # input_clusters=[0, 3, 4, 5, 6]
            # output_clusters=[10, 25]>
            1: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.ON_OFF_PLUG_IN_UNIT,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    Identify.cluster_id,
                    Groups.cluster_id,
                    Scenes.cluster_id,
                    OnOff.cluster_id,
                ],
                OUTPUT_CLUSTERS: [Time.cluster_id, Ota.cluster_id],
            },
            # <SimpleDescriptor endpoint=242 profile=41440 device_type=97
            # device_version=1
            # input_clusters=[]
            # output_clusters=[33]>
            242: {
                PROFILE_ID: 41440,
                DEVICE_TYPE: 97,
                INPUT_CLUSTERS: [],
                OUTPUT_CLUSTERS: [GreenPowerProxy.cluster_id],
            },
        },
    }
1 « J'aime »

@le_top Merci de ton implication.

Testé :

  • Suppression de la prise de ZHA,
  • Ajout de ton code,
  • Redémarrage de HA,
  • Appairage de la multiprise.

Résultat :

Trois boutons s’affichent mais ils ne sont pas indépendants. Quand on appuie sur 1 boutons, les autres font la même action.

Voici ce qu’affiche la signature de l’appareil Zigbee

{
  "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.Router: 1>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice: 142>, manufacturer_code=4098, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=True, *is_security_capable=False)",
  "endpoints": {
    "1": {
      "profile_id": 260,
      "device_type": "0x010a",
      "in_clusters": [
        "0x0000",
        "0x0003",
        "0x0004",
        "0x0005",
        "0x0006"
      ],
      "out_clusters": [
        "0x000a",
        "0x0019"
      ]
    },
    "2": {
      "profile_id": 260,
      "device_type": "0x010a",
      "in_clusters": [
        "0x0003",
        "0x0004",
        "0x0005",
        "0x0006"
      ],
      "out_clusters": []
    },
    "3": {
      "profile_id": 260,
      "device_type": "0x010a",
      "in_clusters": [
        "0x0003",
        "0x0004",
        "0x0005",
        "0x0006"
      ],
      "out_clusters": []
    },
    "242": {
      "profile_id": 41440,
      "device_type": "0x0061",
      "in_clusters": [],
      "out_clusters": [
        "0x0021"
      ]
    }
  },
  "manufacturer": "_TZ3000_vzopcetz",
  "model": "TS011F",
  "class": "lidl_tfs011f_plug.Lidl_Plug_3AC_4USB"

C’est un début ;-). On voit bien que le nouveau qurik est utilisé, non seulement par les endpoitns, mais qussi par la classe « lidl_tfs011f_plug.Lidl_Plug_3AC_4USB » .

La multiprise réagit aux trois clusters - soit parce que le « Endpoint » n’est pas vérifié soit parce qu’il y a vraiment 3 endpoints.

La question est maintenant, quelle magie s’opère avec Z2M.

A priori cela fonctionnait tout de suite sous Z2M. Soit. J’aurais gardé l’appairage, redémarré, actionné la multiprise, désappairé et réappairé supposant qu’éventuellement l’actionnement initial débloque les 3 endpoints correctement au prochain démarrage.

Sinon, il y a un attribut qui est défini sous Z2M qui rend les 3 endpoints indépendants, un truc dans un « registre spécifique de Tuya ».

En partant de ce quirk, il est possible d’ajouter les commandes « magiques » (une fois connu) pour aboutir au fonctionnement normal attendu.

Bonjour,
pour ceux qui sont sous deconz, est-ce qu’il y a une manip equivalente à un « Quirk » ZHA?
ou bien faut-il attendre une mise à jour du plug-in?

Merci

Bonjour, par curiosité,
pour faire ça, tu as deux clés gateway zigbee, et tu fais tourner ça sur la même instance Home-assistant, avec les 2 plug-in Z2M et ZHA?

Sous zigpy-deconz c’est du ZHA, sinon, je ne savais pas qu’il y avait un autre choix que Z2M ou ZHA.

Bonsoir,
La manip que tu donnes permet d’avoir cette fois ci un fonctionnement autonome de chaque bouton. Par contre, charque bouton éteint physiquement les 3 autres.
On l’aura un jour… On l’aura !!! :yum:

Le quirk c’est toujours lidl_tfs011f_plug.Lidl_Plug_3AC_4USB ou c’est passé sur zhaquirks.tuya.ts011f_plug.Plug_3AC_4USB ?

Puisque cela a fonctionné une fois, peut-être qu’un appairage/désappairage supplémentaire fixe l’extinction…

Dernier truc que je propose c’est de faire un scan_device.
Idéalement ce serait à faire sur une qui ne fonctionne pas, une qui fonctionne partiellement (comme le tiens), et un qui a été « rattrapé » pour comparer les valeurs des attributs de Tuya. J’ai collé mes valeurs plus haut, mais c’est la version précédente.

Après, on peut écrire des valeurs dans les attributs pour voir leur effet - toujours possible avec zha-toolkit en utilisant le service attr_write.