When will the Philips Hue bug be uploaded?
I still can’t do anything.
What bug?
If you are referring to the increase in the local discovery timeout (UpNp-search), this was released in 4.3.1 25 days ago (see CHANGELOG: Release v4.3.1 · GladysAssistant/Gladys · GitHub).
Yes, I’m talking about that.
It still doesn’t work on my end.
Oh shoot! It worked for some people, so since I didn’t get any more feedback, I thought the issue was resolved 
For your information, we doubled the timeout from 5s to 10 seconds, but maybe that’s not enough in your case.
Do you have a development setup or not? I can’t remember.
If yes, you could try making the change locally (add another 5-10 seconds to the timeout) and see if it works? (Example commit to modify this: Increase Philips hue bridge scan timeout to 10s (#1185) · GladysAssistant/Gladys@757d95b · GitHub )
Otherwise, I can build a development version with the timeout doubled.
I found it strange that it took so long to fix that.
Yes, I have a development environment, but I’m far from being up to par.
I’ll check it out.
@VonOx you had the same problem, does it work for you now?
You told me it was possible to do an UpNp-search and also an N-uPnP-search, why not do that?
If you can do the most, you can do the least!!
Yes, it had resolved the problem, or so I thought, because it no longer works, so the source of the problem is probably elsewhere.
Because when searching with @VonOx, increasing the timeout solved the problem for him, so we stopped there
Yes, but the more takes more time to develop, time which is far from being infinite
Oh dear. Okay, we’ll continue to investigate then. @VonOx can you do some tests to see where it comes from? Increase the timeout for example? See if it’s a problem related to the Docker configuration?
@lmilcent Your bug fix in the scenes is live in Gladys v4.4:
Hello,
Wouldn’t adding the possibility to specify the bridge’s IP as a last resort be a relevant solution?
This will allow the user to still connect the bridge to Gladys in really particular cases.
Why not, it could be a good idea!
Yes, if it’s possible that would be great. Because at the moment I still have nothing.
Is this issue present with other people who have Philips Hue?
I haven’t been able to reproduce it on my side recently, it’s a bit random because I had the issue.
@Tlse-vins you didn’t answer me about Philips Hue, I wanted to know if it was just a timeout issue or not, could you test changing the timeout?
Hello @pierre-gilles, I didn’t have time to look at it before.
I just tested it in my dev environment with a 30-second timeout and it’s the same.
I did check that the bridge is on the same network.
@JeuFore mentions the use of the IP address, Eedomus does it this way. There is even a network scan to find the IP and Mac addresses of the devices.
Is this a viable solution?
Manual addition is indeed a feasible solution. However, in your case, if it worked with the N-Upnp search, I thought we could do a hybrid scan UpNp + N-UpNp, that’s another solution.
A network scan is exactly what we’re doing right now, except it doesn’t seem to work for you.
Initially, I think that in your case, a mix of N-Upnp + Upnp would be the simplest solution.
Would you have time to take a look at it?
I did a test by replacing UpNp with N-UpNp in 2 files.
In the logs, a bridge was found but it is not under Gladys.
Additionally, there are several error messages in several files.
I could give you feedback tonight.
For your information, I am not a developer. If you make the changes, I can test them by integrating them on my side.
Here is the result of the modification above.
2021-07-04T22:22:21+0200 <info> light.getBridges.js:12 (PhilipsHueLightHandler.getBridges) PhilipsHueService: Found 1 bridges
2021-07-04T22:22:21+0200 <trace> errorMiddleware.js:49 (errorMiddleware) TypeError: Cannot read property 'serial' of undefined
at /home/linux-vins/gladys/server/services/philips-hue/lib/light/light.getBridges.js:14:49
at Array.forEach (<anonymous>)
at PhilipsHueLightHandler.getBridges (/home/linux-vins/gladys/server/services/philips-hue/lib/light/light.getBridges.js:13:16)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
at async getBridges (/home/linux-vins/gladys/server/services/philips-hue/api/hue.controller.js:10:21)
From previous event:
at /home/linux-vins/gladys/server/api/middlewares/asyncMiddleware.js:4:11
at Layer.handle [as handle_request] (/home/linux-vins/gladys/server/node_modules/express/lib/router/layer.js:95:5)
at next (/home/linux-vins/gladys/server/node_modules/express/lib/router/route.js:137:13)
at /home/linux-vins/gladys/server/api/middlewares/authMiddleware.js:28:7
@Tlse-vins The N-uPnP search and UpNp search API are not the same, hence the error.
The library documentation:
I read the documentation thoroughly.
I tried removing the Hue application bridge and putting it back, I performed bridge searches in both cases and nothing in Gladys, no detection.
The change from N-UPnP to UPnP follows a request from @Herve who had detection issues with the first method. Was he the only one in this situation?
Since this change, no detection on my side, and @VonOx intermittently (if I’m not mistaken).
Is anyone else affected by this issue?
Does it work with Gladys Plus?
@pierre-gilles opened an issue
to implement both methods.
I’m ready to test.