[Deconz / ConBee II] Etat toujours détecté en "on" sur ampoule Tradfri

Bonjour,

J’ai un problème avec une de mes ampoules Ikea Tradfri. L’état n’est pas bon.

Dans l’onglet « Commandes », il y a l’info « Etat 01 » crée par défaut, qui prend comme valeur « 01.state::on » quand je teste cette valeur, elle est toujours à 1, quoi que je fasse, alors que côté « Configuration » j’ai les informations suivantes :

{
    "6": {
        "etag": "8937a5084fcfa83d8df8f8f538bb6b60",
        "hascolor": false,
        "lastseen": "2020-06-14T09:25:14.131",
        "manufacturername": "IKEA of Sweden",
        "modelid": "TRADFRI bulb GU10 W 400lm",
        "name": "Dimmable light 6",
        "state": {
            "alert": "none",
            "bri": 80,
            "on": false,
            "reachable": true
        },
        "swversion": "1.2.214",
        "type": "Dimmable light",
        "uniqueid": "d0:cf:5e:ff:fe:71:fd:9a-01"
    }
}

J’aimerais me baser sur cette valeur pour une action « Si/Sinon » dans un scenario, pour faire une action différente si la lumière est éteinte.
J’ai rebooté JeeDom plusieurs fois, me suis connecté à la gateway Phoscon de la clef et ai pu voir l’ampoule dedans, j’ai régénéré la clef API de la clef ConBee… Je ne sais plus trop quoi tenter.

Bonjour.
Peux tu mettre un screen shot de ta page de définition des commandes de ton ampoule ?

Par ailleurs, quel est le schéma de commande de cette ampoule en d’autres termes est elle commandée uniquement par une télécommande (Jeedom ou autre) ou bien y a il aussi dans son circuit un autre interrupteur ?

Voici :

L’ampoule est sur un circuit fermé en permanence (interrupteur remplacé par un domino), j’avais prévu de ne la faire commander que par un détecteur de mouvements, via Jeedom.

Tout semble OK dans la configuration . J’ajoute généralement pour le state bri le min et le max histoire de pouvoir ensuite mieux gérer les affichages dans les designs en harmonisant les widgets.
Donc il doit y avoir un pb de communication avec le websocket Jeedom.
As tu essayé de relancer le démon deconz après voir nettoyé le cache (menu configuration/cache), sans redémarrer Jeedom bien sur?

2 « J'aime »

Ça semble marcher ! Je vais faire quelques tests avant de confirmer que tout fonctionne.
J’ignorais l’existence du menu pour vider le cache, je découvre un peu Jeedom !

Merci beaucoup.

J’ai eu le même problème hier. Elle avait même disparu de phoscon… je l’ai éteinte et rallumée avec l’interrupteur et elle est revenue.

@RFX
salut,
ayant le même type d’ampoule que toi, j’utilise également la variable reachable (c’est le cas de tous mes ampoules ou autres materiels zigbee)
En associant l’état de cette variable reachable de la lampe avec la variable état de la lampe → cela me donne l’état exact de la lampe.

NB IMPORTANT : je n’ai pas d’interrupteurs Zigbee qui commandent mes ampoules, j’utilise des interrupteurs de base.

Pour moi, c’est une solution qui a reçu le WAF approuved

Lorsque les données ne sont pas rafraîchies (websocket planté, équipement en mode veille profonde, …) le cache n’est pas mis à jour et Jeedom continue de puiser dedans des valeurs de plus en plus datées. Tu peux mettre une alerte sur cette date et ainsi être alerté d’un pb.

Pour ceux qui utilisent des inters physiques qui coupent l’alimentation de leurs ampoules Zigbee, il faut garder en tête que dans ce cas c’est le dernier état connu qui sera gardé en mémoire et il y de fortes chance que ce soit l’état allumé « On » (puisque l’on a coupé le courant lorsque l’ampoule était « On » elle ne peut plus communiquer sont état « Off ») . De plus les électroniques dans les embases de ces ampoules se défiabilisent de manière logarithmique au nombre de fois qu’elle sont commutées physiquement. Donc conseil d’ami ne pas trop jouer de l’inter physique avec ces ampoules. Préférer le binding ou les groupes avec une télécommande directe

1 « J'aime »

@RFX
Dans le cas de l’utilisation de la variable reachable avec la variable d’état de l’ampoule,
je tiens à t’apporter une précision importante :

Pour mon cas, quand je coupe l’alimentation de l’ampoule via l’interrupteur (non zigbee), le statut de la variable reachable ne change pas immédiatement.
C’est deconz qui, après des essais multiples de communications avec l’ampoule, fait le changement d’état de la variable (plus ou moins rapidement).

@Yves19

salut @Yves19 je ne connaissait pas cette problématique de fiabilisation lié à la commutation. Peux tu m’en dire un peu plus.
merci d’avance.

L’électronique comme la mécanique (ce ne sont que des choses physiques in fine) s’ « use » à sa manière. Ainsi le phénomène de changement d’état est un de ceux qui prédominent dans les calculs de fiabilité.
Une mise sous tension (ou hors tension) peut être assimilée à un changement brutal d’état et créé un front raide assimilable macroscopiquement à un Dirac de tension ou de courant à chaque commutation.

Ces surtensions ou surcourants vont accélérer les migrations électroniques à l’intérieur des composants soit à cause d’un effet thermique soit à cause de polarisations inverses soit à cause de polarisations trop élevées soit les trois à la fois. Et ce jusqu’à ce que le composant ne remplisse plus son œuvre. Et je ne parle pas des jonctions entre la puce et ses petites pattes qui vont sans cesse se micro dilater et rétracter jusqu’à casser.
Pour les composants électromécaniques (relais, bilame, microself, par exemples) les mini déformations mécaniques entrainées par des changements brusque de champ électromagnétique ou par des micros échauffements thermiques répétés vont conduire à la casse mécanique (fil qui fond , soudure qui craque, composant qui se dessoude, entraxe qui s’agrandit …).

Dans une embase d’ampoule on a les deux types de composants : électroniques et électromécaniques et en plus très miniaturisés. Donc les commutations vont faire en sorte que les composants électroniques vont vieillir (beaucoup) plus vite et les composant micro électromécaniques aussi.

Comme on le dit souvent dans le métier le seul état qui ne fasse pas vieillir prématurément c’est l’état stable (allumé ou éteint) et le changement d’état est instable par définition. Un peu comme dans la vraie vie : marcher c’est se mettre en déséquilibre permanent avec le risque plus important de tomber que lorsque l’on est assis ou lorsque l’on est debout en statique.

Bien sur je vulgarise à outrance. Ces sujets on donnée lieu à de multiples thèses très utilisées par les grands fondeurs de composants comme par les designers de systèmes embarqués (une ampoule pouvant être assimilée à ces derniers)

3 « J'aime »

@Yves19
Merci pour tes infos +++. Initialement, je cherchais une solution dans lequel je n’etais pas tributaire de switches zigbee. Je prendrais en compte dans mes prochaines acquisitions de ce que tu m’as explique.
Merci encore👍

Cherche sur ce forum.
J’y ai expliqué comment faire un « bind » direct entre une télécommande (commande à pile) et un équipement alimenté sur secteur.
Ainsi tu n’es pas tributaire d’une box ou d’une clef lorsque ces dernières sont HS ou pas utilisées pour utiliser ton installation électrique. A la pile près qu’il faut changer on va dire tous les 3 à 5 ans selon l’usage, c’est de la même disponibilité qu’un interrupteur physique, la fiabilité en plus (puisque l’on ne commute plus physiquement).

@Yves19
Merci, j’ai trouve ton post.
Juste pour savoir, l’information du bind est ecrite dans les puces zigbee des 2 associes ? Il y a t-il perte d’information si, en reprenant l’exemple de l’ampoule et le télécommande, tu mets de cote cette ampoule (ampoule de secours) qui etait associee avec la telecommande?
Merci de tes reponses.

Si tu mets de coté = tu la démontes et la ranges au fond d’un tiroir : l’ampoule conserve en mémoire son bind. Dès qu’elle sera rebranchée sur le même réseau bien sur elle reprendra son rôle.

Si tu mets de coté = tu jettes l’ampoule ou la détruit ou la réinitialise : oui la fonction sera perdue. Il restera dans la mémoire de la télécommande (tant que cette dernière n’est pas réinitialisée bien sur) une adresse « orpheline ».

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.