Problème détection pont Hue depuis la 4.2.1

Configuration
21

J’ai regardé ce matin si je pouvais faire quelques chose là dessus, mais c’est pas aussi simple que ça.

L’API nupnpsearch a changé dans la version 4 node-hue-api du module qu’on utilise, et ne renvoie plus le serial number, qu’on utilisait jusque-là comme identifiant unique pour identifier le bridge à travers Gladys.

Passer à un mix nupnp + upnp n’est pas un simple changement, c’est un vrai développement qui demande des tests avec du matos réel (que je n’ai pas). Je vais plus tout casser qu’autre chose si je fais ça à l’aveugle ^^

Si quelqu’un a du matos Philips Hue et veut donner un coup de main à @Tlse-vins pour son problème, je suis dispo si il y a des questions sur l’intégration actuelle :slight_smile:

Désolé @Tlse-vins, je sais c’est frustrant :confused: J’aimerais que ça marche chez tout le monde tout autant que toi, et j’aimerais tout autant qu’il y ait plus de contributeurs sur les intégrations ^^

A mon avis tous les devs du forum sont en terrasse depuis le déconfinement :smiley:

22

Hello,

Je n’ai pas tout suivi du sujet, mais je viens de tester l’integration Hue sur l’instance que je monte en prod chez moi (sans docker).
Et je constate à un soucis, lorsque je connecte mes lampes, tout marche, je les met sur le dashboard, et puis après quelques instant, elles disparaissent et je dois les reconnecter via la page d’integration.

Edit : Bon après plusieurs heures, ca ne s’est pas reproduit.

23

ça me parait bizarre, tu avais bien ajouté les lampes à Gladys? Peut-être que l’ajout n’avait pas réellement fonctionné ?

ça m’étonne des lampes qui disparaissent :smiley:

D’ailleurs @Jean-Philippe, si jamais tu veux aider @Tlse-vins, on est à la recherche de quelqu’un qui a du Philips Hue et qui pourrait aider à implémenter un scan double qui fait en même temps du N-UpnP search, et du UpnP search

C’est un truc assez bête à implémenter, mais je n’ai pas de Philips Hue et je ne peux pas tester !

24

Ah ca serait cool oui!!
Nous allons bientôt emménager dans notre nouvelle maison, il me tarde de tout rebrancher et de faire évoluer mon système.

25

@pierre-gilles J’ai regardé par curiosité, je ne comprends pas comment le discover N-UPNP pouvait fonctionner car on ne récupère pas le même objet.

Exemple chez moi

UPNP:

{
  name: 'Philips hue (192.168.1.10)',
  manufacturer: 'Signify',
  ipaddress: '192.168.1.10',
  model: {
    number: 'BSB002',
    description: 'Philips hue Personal Wireless Lighting',
    name: 'Philips hue bridge 2015',
    serial: 'XXXXXXXXXXX'
  },
  version: { major: '1', minor: '0' },
  icons: [
    {
      mimetype: 'image/png',
      height: '48',
      width: '48',
      depth: '24',
      url: 'hue_logo_0.png'
    }
  ]
}

N-UPNP:

{
  ipaddress: '192.168.1.10',
  config: {
    name: 'Philips hue',
    ipaddress: '192.168.1.10',
    modelid: 'BSB002',
    swversion: '1947054040'
  }
}

D’où cette nouvelle question, comment faire une approche hybride dans ce cas ? ( serial n’est pas dans le retour de l’api )

26

C’est justement toute la difficulté :smiley:

Je me demande si il n’y a pas moyen de récupérer le serial en faisant un N-UpNp + un GET sur le bridge pour avoir ces informations ?

C’est ce qu’il faut expérimenter, et c’est pour ça que je ne pouvais pas aider @Tlse-vins, sans le matériel c’est compliqué de faire ces expériences :slight_smile:

27

Je l’avais proposé y a un moment, mais comme pour le moment le bridge n’est pas branché, je peux l’envoyer avec une ampoule pour que quelqu’un fasse les tests ou toi @pierre-gilles .

28

De mon côté j’habite en Indonésie ça va couter plus cher en expédition qu’en matos :joy:

Dans tous les cas, je l’ai expliqué sur un autre post récemment, j’ai déjà énormément de travail sur le core, c’est pas réaliste que je m’occupe des intégrations en plus, je préfère qu’il y ait des référents sur chaque intégration :slight_smile:

29

Yes ça va le faire

GET https://192.168.1.10/api/config

me retourne

{
   "name":"Philips hue",
   "datastoreversion":"111",
   "swversion":"1947054060",
   "apiversion":"1.46.0",
   "mac":"XX:XX:XX:XX:XX",
   "bridgeid":"XXXXXXXXXXX",
   "factorynew":false,
   "replacesbridgeid":null,
   "modelid":"BSB002",
   "starterkitid":""
}

Sachant que le serial c’est mac

1 « J'aime »
30

Génial ! Merci d’avoir regardé :slight_smile:

Du coup l’idée ce serait:

  • Faire un UpNp-scan (local)
  • Faire un N-UpnP scan (le call API distant)
  • Pour chaque bridge trouvé dans N-UpNp scan et pas dans UpNp scan:
    • faire un GET sur /api/config du bridge pour récupérer l’adresse mac du bridge et la stocker dans serial
  • Retourner le tableau total
31

Je remets le sujet en avant car j’ai toujours le problème pour la détection du pont hue.
Cela m’éviterai de flasher ma clef zigbee car j’ai atteint les 40 devices à cause des ampoules.

32

En vrais je te conseille de le faire.
Non seulement tu passes a 100 devices en directe jusqua 200 sous enfants, mais en plus ils ont corriger, amélioré certaine chose.

Ca te prend 10 min grand maximum.

1 « J'aime »
33

Tu l’as fait ?
tu as sauvegarder la BD zigbee avant ?

34

Maj la clef ne ne touche pas au projet z2m ^^
Ouep :slight_smile:, brancher au pc flasher debrancher rebrancher au nas et redemarer z2m via docker