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 Like
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

I’m bringing this topic up again because I still have the problem detecting the Hue bridge.
That would save me from having to flash my Zigbee USB stick, because I’ve reached the 40-device limit due to the bulbs.

32

Honestly, I recommend you do it.
Not only do you go from 100 devices live to up to 200 child devices, but they’ve also fixed and improved some things.

It’ll take you at most 10 minutes.

1 Like
33

Did you do it?
Did you back up the Zigbee DB beforehand?

34

Update: the key doesn’t affect the z2m project ^^

Yep :slight_smile:,