Issue detecting Hue bridge since 4.2.1

Configuration
21

I checked this morning to see if I could do something about it, but it’s not as simple as that.

The nupnpsearch API has changed in version 4 of the node-hue-api module we use, and no longer returns the serial number, which we used until now as a unique identifier to identify the bridge through Gladys.

Switching to a mix of nupnp + upnp is not a simple change, it’s a real development that requires testing with real equipment (which I don’t have). I’ll probably break more than I fix if I do this blindly ^^

If anyone has Philips Hue equipment and wants to help @Tlse-vins with his problem, I’m available if there are any questions about the current integration :slight_smile:

Sorry @Tlse-vins, I know it’s frustrating :confused: I’d like it to work for everyone as much as you do, and I’d like there to be more contributors on the integrations just as much ^^

In my opinion, all the devs on the forum have been on the terrace since the deconfinement :smiley:

22

Hello,

I didn’t follow the whole topic, but I just tested the Hue integration on the instance I’m setting up in production at home (without Docker).
And I notice an issue, when I connect my lights, everything works, I put them on the dashboard, and then after a few moments, they disappear and I have to reconnect them via the integration page.

Edit: Well, after several hours, it hasn’t happened again.

23

It seems strange to me, did you really add the lamps to Gladys? Maybe the addition didn’t actually work?

I’m surprised that lamps are disappearing :smiley:

By the way @Jean-Philippe, if you ever want to help @Tlse-vins, we are looking for someone who has Philips Hue and could help implement a double scan that does both N-UpnP search and UpnP search at the same time

It’s quite a simple thing to implement, but I don’t have Philips Hue and I can’t test it!

24

Oh that would be cool yes!!

We are going to move into our new house soon, I can’t wait to reconnect everything and evolve my system.

25

@pierre-gilles I looked out of curiosity, I don’t understand how the discover N-UPNP could work as we don’t retrieve the same object.

Example at my place

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'
  }
}

Hence this new question, how to make a hybrid approach in this case? (serial is not in the API return)

26

That’s exactly the difficulty :smiley:

I wonder if there isn’t a way to retrieve the serial by doing an N-UpNp + a GET on the bridge to get this information?

That’s what needs to be experimented with, and that’s why I couldn’t help @Tlse-vins, without the equipment it’s complicated to do these experiments :slight_smile:

27

I suggested this a while ago, but since the bridge isn’t connected right now, I can send it with a bulb so someone can test it or you @pierre-gilles.

28

On my side, I live in Indonesia, it will cost more in shipping than in materials :joy:

In any case, as I explained in another post recently, I already have a lot of work on the core, it’s not realistic for me to handle integrations in addition, I prefer that there are referents on each integration :slight_smile:

29

Yes it will work

GET https://192.168.1.10/api/config

returns

{
   "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":""
}

Given that the serial is the mac

30

Great! Thanks for watching :slight_smile:

So the idea would be:

  • Perform a local UpNp-scan
  • Perform a remote N-UpNp scan (call the API)
  • For each bridge found in the N-UpNp scan but not in the UpNp scan:
    • Make a GET request to /api/config of the bridge to retrieve the bridge’s MAC address and store it in serial
  • Return the total array
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.

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:,