c’est dommage, en l’état c’est la meme chose qu’une prise connecté sur laquelle tu branches une multiprise …
Effectivement, pour l’instant, c’est juste une multiprise chère… 
Mais j’espère que coté Deconz ils vont réussir intégrer ce qu’il faut pour les reconnaitre et les controler.
La gateway LIDL arrive bien à le faire, il n’y a pas de raison qu’ils n’y arrivent pas aussi sur Deconz/ZHA/Z2mqtt…
Pour info coté forum français, c’est aussi suivi coté jeedom
https://community.jeedom.com/t/multiprise-silvercrest/79764/36
J’avais la meme chose que toi. Un endpoint correspondant au 1 pour la prise 1 et le 242 pour le green power. Force la suppression. Ré-appaire à coté du dongle zigbee et spam le bouton d’alimentation de la prise ca devrait te faire remonter les trois. Par contre ca ne régle pas le fait qu’il faille encore dissocier les trois prises.
Quand tu dis remonter les 3 prises, c’est l’état ? Mais tu ne peux toujours pas les piloter indépendamment ?
C’est cela.
Sur les deux prises achetées une me remontait les trois prises + la green power, la seconde qu’une prise et la green.
C’était sans doute dû à un problème d’interview la multiprise pourtant collée au dongle.
Et effectivement impossible à piloter individuellement en Z2M.
Là encore, la remontée d’état n’est pas la même selon la prise, mais il faut une vidéo pour l’illustrer. Mais en cela me fait penser au fonctionnement d’une carte relais 4 canaux contrôlés via ESPHome en Uart : Peristaltic Pump / Autodoser upgrade / conversion to Home Assistant Control Project - #12 by Twinsen68 - Share your Projects! - Home Assistant Community
La mise à jour de Z2M de ce mois-ci n’est pas encore dispo. Croisons les doigts qu’elle corrige ce défaut !
Merci pour tes explications.
la mise a jour est sortie est elle n’a rien fait pour la prise 
Bon … Je sens qu’il va falloir attendre au moins encore un mois …
Ils ont réussi a priori ici :
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 
. É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 
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.