Pour les lampes qui ne fonctionnaient plus je pencherais pour une coupure/rétablissement de leur alimentation (cause ?) qui les a rendues injoignables lors de la coupure de leur alimentation puis à leur état par défaut (à priori ON) lors du rétablissement.
Quelques pistes d’investigation :
les défauts des lampes interviennent ils tjrs sur les mêmes lampes ? => si oui la qualité de la ligne d’alimentation et/ou des lampes peuvent être mises en cause voire peut être aussi un pb de routage vers ces lampes.
quel est l’état par défaut à la mise sous tension de chaque lampe (à voir depuis deconz dans les attributs POWERON ou équivalent généralement du cluster 0x0006) ? => si ON alors a chaque coupure électrique la lampe s’allumera à la prochaine mise sous tension (OFF elle restera éteinte, PREVIOUS elle prendra la valeur qu’elle avait avant la coupure). reste à voir pourquoi elles ne reviennent pas dans le réseau Zigbee
avant de redémarrer Jeedom , tracer sous Phoscon les commandes issues des inters ou des capteurs qui pilotent les lampes juste pour s’assurer que ces commandes sont bien émises.
j’ai compris que ce sont des lampes Philips. Tu peux tjrs essayer sur au moins une, si tu as le pont HUE, de mettre à jour son firmware et son mode par défaut et de la tester en dehors de Jeedom sur l’applie HUE.
les défauts des lampes interviennent ils tjrs sur les mêmes lampes ? => si oui la qualité de la ligne d’alimentation et/ou des lampes peuvent être mises en cause voire peut être aussi un pb de routage vers ces lampes.
=> Pas systématiquement les mêmes ampoules
quel est l’état par défaut à la mise sous tension de chaque lampe (à voir depuis deconz dans les attributs POWERON ou équivalent généralement du cluster 0x0006) ? => si ON alors a chaque coupure électrique la lampe s’allumera à la prochaine mise sous tension (OFF elle restera éteinte, PREVIOUS elle prendra la valeur qu’elle avait avant la coupure). reste à voir pourquoi elles ne reviennent pas dans le réseau Zigbee
=> Je n’arrive pas à trouver l’option PowerOn ; peux tu m’indiquer ou la trouver?
=> Je note également que sous deconz, j’ai uniquement 4 ampoules qui sont affectée à un groupe (je ne sais pas si c’est important)
avant de redémarrer Jeedom , tracer sous Phoscon les commandes issues des inters ou des capteurs qui pilotent les lampes juste pour s’assurer que ces commandes sont bien émises.
=> Actuellement, aprés le redemarrage de 11h, cela fonctionne
(excuses moi, c’est une copie d’écran, car je fais une prise de controle d’une browser déporté pour avoir accés à Deconz)
j’ai compris que ce sont des lampes Philips. Tu peux tjrs essayer sur au moins une, si tu as le pont HUE, de mettre à jour son firmware et son mode par défaut et de la tester en dehors de Jeedom sur l’applie HUE.
J’avais un pont Hue version 1. Je ne l’ai pas utilisé depuis trés longtemps et je ne sais plus trop ou il est.
Oui il y a définitivement quelque chose de louche.
En plus philips c’est du tres bon matos, les ampoules c’est les appareils avec les meilleures connexions. Bon après un re-demarrage ça ne revient pas de suite, mais c’est rapide pour des routeurs.
Tu n’aurais pas une lampe branché sur un interrupteur ?
Pour démarrer l’application deconz afin de modifier les attributs de clusters non accessibles depuis une interface de plus hait niveau j’avais commis ceci il y a quelque temps :
Ensuite tout (ou presque) est proche de ce tuto qui explique comment modifier un attribut PowerOn sur une prise commandée Legrand. Les modifications sur les lampes Philips se font de manière similaire (je ne pourrai te guider en détail qu’à mon retour à la maison dans 3 jours).
Tu veux dire plutôt que tes équipements ne sont plus dans Phoscon.
Un petit coup de découverte de la gateway dans ton navigateur sur un PC branché sur le même réseau que ta box domotique https://phoscon.de/discover
Vérifie que l’information retournée correspond à l’ip de ta box domotique.
Si oui Vérifie que la clef Conbee2 est bien accessible sudo GCFFlasher_internal -l
GCFFlasher V3_17 (c) dresden elektronik ingenieurtechnik gmbh
Path | Vendor | Product | Serial | Type
-----------------±-------±--------±-----------±------
/dev/ttyACM0 | 0x1CF1 | 0x0030 | DE2216551 | ConBee II
/dev/ttyAMA0 | 0x0000 | 0x0000 | | RaspBee
Note : j’ai branché le dongle ZigBee sur le port usb3 , car le pi ne démarrait pas sur le port usb2 .j’ai lu que cela pouvait provoquer des perturbations
Note : j’ai une sauvegarde du dongle, tenté une restauration, mais pas grand chose de plus.
En effet en restaurant la sauvegarde, je vois bien les ampoules.
Il reste quand même une problème de communication, car tout ce petit monde ne se parle pas
Tu es bien repassé sur l’USB 2.0 ? Tu as essayé avec la rallonge USB ?
Si oui ça vaudrait le coup de réinstaller deconz sur un PC (avec le même backup), tu aurais accès a Deconz, donc visualisation du réseau et les logs plus facilement.
C’est pas normal qu’il te manque autant de lampes. Elle ne fonctionnent pas du coup ?
Soirée bien chargée.
1/J’ai retrouvé une sauvegarde du mois de février de phoscon que j’ai restaurée.
2/Réinstallé jeedom du 27 mars
3/ Mis le dongle ZigBee ainsi que BT Blea sur le port usb2
Il y a eu de nombreux ralentissement, j’ai laissé le temps de dîner pour que jeedom se stabilise
Cela a re-fonctionné sur 4 ampoules.
Je mets sous surveillance
Moralité : sauvegarde de phoscon a mettre sous scellés pour la prochaine fois
Bilan, ce matin, presque tout est redevenu stable.
Hormi l’ampoule de la cuisine qui reste allumée.
J’ai fait ON /OFF depuis le plusgin jeedom
Les logs du plugin jeedom me donne
2023-03-29 07:44:33] deconz.DEBUG: Execute commande : lights/2/state whith parameters : {"on":false} [] []
[2023-03-29 07:44:33] deconz.DEBUG: 127.0.0.1:8484/api/B62B11D007/lights/2/state type : PUT [] []
[2023-03-29 07:44:33] deconz.ERROR: Erreur exécution de la commande [Cuisine][Lumiere deconz][Off 0b] : Erreur lors de la requete : 127.0.0.1:8484/api/B62B11D007/lights/2/state(PUT), data : {"on":false} erreur : 202 => resource, /lights/2/state, is not modifiable. Device is not reachable. [] []
