Home Assistant Light Wizard triggers the philips hue wizard

[AlexandreJubert]

Steps to reproduce

1. In the web interface, select the LED Hardware menu
2. In the Controller type dropdown, select home_assistant
3. Press on the purple Home Assistant lights wizard button
4. (optional) enter your local home assistant instance address
5. Enter your long term authentication token

What is expected?

The wizard find the local home assistant instance and display the light entities exposed in home assistant

What is actually happening?

I'm getting prompt and error messages regarding the philips hue wizard and other issues, I've tried entering the home assistant address manually to no avail. See image below.

System

HyperHDR Server:

• Build: (HEAD detached at v21.0.0.0) (Awawa-24e1675/803162c-1741515688)
• Build time: Mar 9 2025 10:36:34
• Git Remote: https://github.com/awawa-dev/HyperHDR
• Version: 21.0.0.0
• UI Lang: auto (BrowserLang: en-CA)
• Avail Capt: Windows (Microsoft Media Foundation)
• Database: read/write

HyperHDR Server OS:

• Distribution: Windows 11 Version 24H2
• Architecture: x86_64
• CPU Model: AMD Ryzen 7 5800X 8-Core Processor
• Kernel: winnt (10.0.26100 (WS: 64))
• Qt Version: 6.5.3
• OpenSSL: OpenSSL 3.2.4 11 Feb 2025
• Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:143.0) Gecko/20100101 Firefox/143.0

Logs

https://pastebin.com/jQAZxLwE

[awawa-dev]

Hi
Please test this latest build just to be sure: https://github.com/awawa-dev/HyperHDR/actions/runs/17744152852
Logs from the browser would be more helpful (Web Developer console. on Firefox Ctrl + Shift + K) when that happens.
Could you please describe all the steps to reproduce the error: starting from selecting the LED driver from the combobox (even if the particular step works)?

[awawa-dev]

Just to be clear: HyperHDR should not display this Philips wizard but there is no communication with your HA instance and no fix on HyperHDR side will help you: it's your network issue.

2025-09-24T19:53:38.728Z [LEDDEVICE] (ProviderRestApi.cpp:174) GET begin: [http://homeassistant.local/api/states] []
2025-09-24T19:53:39.227Z [LEDDEVICE] (ProviderRestApi.cpp:198) GET end (499 ms): [http://homeassistant.local/api/states] []
2025-09-24T19:53:39.227Z [LEDDEVICE] Reply error. Reason: [408 Timeout] - Check the status of your network and whether the destination IP address is correct

and that particular empty address is interesting:
2025-09-24T19:57:31.407Z [WEBSOCKET] Could not resolve '' as IP local address at your HyperHDR host device.

[AlexandreJubert]

@awawa-dev thank you for the quick answer, the web log only has those messages

Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user’s experience. For more help https://xhr.spec.whatwg.org/#sync-warning jquery.min.js:2:81868
window.controllers/Controllers is deprecated. Do not use it for UA detection. localhost:8090:36:31061
[window.websocket::onmessage]  The Philips Hue wizard supports only valid IP addresses in the LOCAL network.
It may be preferable to use the IP4 address instead of the host name if you are having problems with DNS resolution. hyperhdr.js:218:16

I've updated the repro steps on the issue.

I've tried the latest build you linked, same issue. I'm going to dig around the
2025-09-24T19:57:31.407Z [WEBSOCKET] Could not resolve '' as IP local address at your HyperHDR host device.

Might be a Windows Firewall issue or something else, it's my first time using HyperHDR so it's a fresh install, I haven't really modified anything in the configuration yet.

[AlexandreJubert]

Ok I managed to make it work, here's the solution I found:

Entering homeassistant.local:8123 worked.

Those addresses did not work:

• homeassistant.local
• 192.168.1.XXX (local IP of my instance)

[AlexandreJubert]

Hitting another issue, but I'm going to figure this one out, definitely a weird firewall/network problem, the funny thing is, from my computer I can easily access the address and I'm running the hyperHDR instance on the same computer right now for testing.

2025-09-24T21:21:56.603Z [LEDDEVICE0_HOME_ASSISTANT] The LED device is not ready... trying to reconnect (try 2/60).
2025-09-24T21:21:56.603Z [LEDDEVICE0_HOME_ASSISTANT] (LedDevice.cpp:64) Switch on
2025-09-24T21:21:56.603Z [LEDDEVICE] (ProviderRestApi.cpp:182) POST begin: [http://homeassistant.local:8123/api/services/light/turn_on] [{"entity_id":["light.lightstrip_bureau","light.lampe_bureau"]}]
2025-09-24T21:21:57.104Z [LEDDEVICE] (ProviderRestApi.cpp:206) POST end (500 ms): [http://homeassistant.local:8123/api/services/light/turn_on] [{"entity_id":["light.lightstrip_bureau","light.lampe_bureau"]}]
2025-09-24T21:21:57.104Z [LEDDEVICE] Reply error. Reason: [408 Timeout] - Check the status of your network and whether the destination IP address is correct
2025-09-24T21:21:57.104Z [LEDDEVICE0_HOME_ASSISTANT] Device 'home_assistant' is disabled due to an error: '[408 Timeout] - Check the status of your network and whether the destination IP address is correct'
2025-09-24T21:21:57.104Z [LEDDEVICE0_HOME_ASSISTANT] (LedDevice.cpp:373) Device is not ready to start a timer

[awawa-dev]

Ok I managed to make it work, here's the solution I found:

Entering homeassistant.local:8123 worked.

Those addresses did not work:

* `homeassistant.local`

* `192.168.1.XXX` (local IP of my instance)

Since the beginning of HyperHDR's HA support, port 8123 has always been used in the code. Latest builds also support https. I've had user reports that it works, so that's probably not the issue. There's no need to explicitly specify the port. Perhaps the network was temporarily unavailable?

[AlexandreJubert]

No network was fine, I moved the instance on the same computer as my home assistant instance, and I'm havign the same issue, it sometimes work but the lights more often timeout, even through localhost.

2025-09-24T22:42:12.897Z [LEDDEVICE0_HOME_ASSISTANT] The LED device is not ready... trying to reconnect (try 1/60).
2025-09-24T22:42:12.897Z [LEDDEVICE0_HOME_ASSISTANT] The LED device is not ready... trying to reconnect (try 1/60).
2025-09-24T22:42:12.901Z [LEDDEVICE0_HOME_ASSISTANT] Saving state of light.lampe_bureau: state: ON, brightness: 255, rgb: [255,255,255]
2025-09-24T22:42:12.901Z [LEDDEVICE0_HOME_ASSISTANT] Saving state of light.lampe_bureau: state: ON, brightness: 255, rgb: [255,255,255]
2025-09-24T22:42:12.903Z [LEDDEVICE0_HOME_ASSISTANT] Saving state of light.lightstrip_bureau: state: ON, brightness: 255, rgb: [255,255,255]
2025-09-24T22:42:12.903Z [LEDDEVICE0_HOME_ASSISTANT] Saving state of light.lightstrip_bureau: state: ON, brightness: 255, rgb: [255,255,255]
2025-09-24T22:42:13.021Z [COMPONENTCTRL0] LED device: enabled
2025-09-24T22:42:13.021Z [COMPONENTCTRL0] LED device: enabled
2025-09-24T22:42:14.440Z [LEDDEVICE] Reply error. Reason: [408 Timeout] - Check the status of your network and whether the destination IP address is correct
2025-09-24T22:42:14.440Z [LEDDEVICE] Reply error. Reason: [408 Timeout] - Check the status of your network and whether the destination IP address is correct
2025-09-24T22:42:14.441Z [LEDDEVICE0_HOME_ASSISTANT] Device 'home_assistant' is disabled due to an error: '[408 Timeout] - Check the status of your network and whether the destination IP address is correct'
2025-09-24T22:42:14.441Z [LEDDEVICE0_HOME_ASSISTANT] Device 'home_assistant' is disabled due to an error: '[408 Timeout] - Check the status of your network and whether the destination IP address is correct'
2025-09-24T22:42:14.441Z [COMPONENTCTRL0] LED device: disabled
2025-09-24T22:42:14.441Z [COMPONENTCTRL0] LED device: disabled

This is on a linux build this time

HyperHDR Server: 
- Build:           (HEAD detached at v21.0.0.0) (Awawa-24e1675/803162c-1741515688)
- Build time:      Mar  9 2025 10:34:01
- Git Remote:      https://github.com/awawa-dev/HyperHDR
- Version:         21.0.0.0
- UI Lang:         auto (BrowserLang: en-CA)
- Avail Capt:      Linux (V4L2)
- Database:        read/write

HyperHDR Server OS: 
- Distribution:   Debian GNU/Linux 11 (bullseye)
- Architecture:   x86_64
- CPU Model:      Intel(R) N150
- CPU Type:       190
- Kernel:         linux (6.12.43-haos (WS: 64))
- Qt Version:     5.15.2
- OpenSSL:        OpenSSL 1.1.1w  11 Sep 2023
- Browser:        Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:143.0) Gecko/20100101 Firefox/143.0 

And for reference the ping from my computer to my home assistant instance is around 3ms

[AlexandreJubert]

Another quick update, I'm seeing this getting spammed in the haos hyperhdr log (seems that debug flag is also enabled there)

23:13:20.216 COMPONENTCTRL0         : <INFO> LED device: disabled
23:13:20.216 PERFORMANCE            : <INFO> [INSTANCE0: FPS = 0.11, processed = 7]
23:13:24.971 LEDDEVICE0_HOME_ASSIST : <WARNING> The LED device is not ready... trying to reconnect (try 1/60).
23:13:24.973 LEDDEVICE0_HOME_ASSIST : <INFO> Saving state of light.lampe_bureau: state: ON, brightness: 0, rgb: [255,255,255]
23:13:24.974 LEDDEVICE0_HOME_ASSIST : <INFO> Saving state of light.lightstrip_bureau: state: OFF, brightness: -1, rgb: []
content-type missing in HTTP POST, defaulting to application/x-www-form-urlencoded. Use QNetworkRequest::setHeader() to fix this problem.
23:13:25.083 COMPONENTCTRL0         : <INFO> LED device: enabled
content-type missing in HTTP POST, defaulting to application/x-www-form-urlencoded. Use QNetworkRequest::setHeader() to fix this problem.
content-type missing in HTTP POST, defaulting to application/x-www-form-urlencoded. Use QNetworkRequest::setHeader() to fix this problem.
content-type missing in HTTP POST, defaulting to application/x-www-form-urlencoded. Use QNetworkRequest::setHeader() to fix this problem.
content-type missing in HTTP POST, defaulting to application/x-www-form-urlencoded. Use QNetworkRequest::setHeader() to fix this problem.
content-type missing in HTTP POST, defaulting to application/x-www-form-urlencoded. Use QNetworkRequest::setHeader() to fix this problem.
content-type missing in HTTP POST, defaulting to application/x-www-form-urlencoded. Use QNetworkRequest::setHeader() to fix this problem.
content-type missing in HTTP POST, defaulting to application/x-www-form-urlencoded. Use QNetworkRequest::setHeader() to fix this problem.
content-type missing in HTTP POST, defaulting to application/x-www-form-urlencoded. Use QNetworkRequest::setHeader() to fix this problem.
content-type missing in HTTP POST, defaulting to application/x-www-form-urlencoded. Use QNetworkRequest::setHeader() to fix this problem.
content-type missing in HTTP POST, defaulting to application/x-www-form-urlencoded. Use QNetworkRequest::setHeader() to fix this problem.
content-type missing in HTTP POST, defaulting to application/x-www-form-urlencoded. Use QNetworkRequest::setHeader() to fix this problem.
content-type missing in HTTP POST, defaulting to application/x-www-form-urlencoded. Use QNetworkRequest::setHeader() to fix this problem.
content-type missing in HTTP POST, defaulting to application/x-www-form-urlencoded. Use QNetworkRequest::setHeader() to fix this problem.
23:13:27.474 LEDDEVICE              : <ERROR> Reply error. Reason: [408 Timeout] - Check the status of your network and whether the destination IP address is correct
23:13:27.474 LEDDEVICE0_HOME_ASSIST : <ERROR> Device 'home_assistant' is disabled due to an error: '[408 Timeout] - Check the status of your network and whether the destination IP address is correct'
23:13:27.474 COMPONENTCTRL0         : <INFO> LED device: disabled

Sadly I'm not well versed in this kind of API but that might be an indication of something?

[awawa-dev]

The network is definitely not working, and the constant timeouts when attempting to read communication are throwing HyperHDR into limbo, as it's receiving junk data (or rather, it's not receiving any at all). Timeouts don't just happen out of nowhere. I'm sorry, but I don't think I can help here, as everything points to a network issue. The best I can do is make HyperHDR more secure so it's more cautious in such situations and doesn't display the Philips Hue wizard. That's if I can replicate this, which should be easy, as I don't even need a running HA instance.

[awawa-dev]

Other possibility is your HA instance suffers from some kind of problem like for ex. lack of resources. Unfortunately I cant help here either.

[AlexandreJubert]

Could you point me to where the packets are formed?

I spent the evening troubleshooting the network and my haos instance, it responds in less than 3ms to any requests I sent it via curl, the computer it runs on is at a stable 10% of cpu usage and around 10% of memory consumption. Network wise it's wired via gigabit Ethernet to my router directly, and both HyperHDR and HomeAssistant are on the same computer, just HyperHDR running in a docker container managed by home assistant. If you look at the timestamps the timeouts are instant, it's not like they're delayed by X seconds, I'm wondering if we're receiving an unexpected packet format from the API endpoint and default to 408 as an answer. I'm running the latest home assistant version, maybe some breaking changes in the Rest API occurred?

[AlexandreJubert]

Alright, probably last update, I identified the problem with any POST request to my HA instance. Still unsure why, any GET requests goes through properly, but any POST just hangs. Issue is on HA side for sure, I'll keep the issue opened here until I found a fix, either on the format of the POST request or on HA side. Will update later this week. Thanks @awawa-dev for your help with this issue!

[AlexandreJubert]

Alright, update. Found the problem, might need a fix on HyperHDR side of things.

The reason of the timeout is that there's a timeout hardcoded in the _restApi instance inside HyperHDR.

The POST call to /api/services/light/turn_on is synchronous, i.e. as long as the device didn't execute the action on home assistant side, it'll hold the request until it can answer.

I need to dig why this specific light takes a while to answer through the API, but I do think that due to the nature of home assistant, HyperHDR shouldn't disable the light controller if it takes a while to answer. It should just gracefully timeout, at the cost of losing some transitions/lights, instead of shutting off completely and redoing the connection handshake.

I'm going to continue investigating the POST delay on my end, once again will update here if I found another reason other than the light bulb takes a while to answer.

[awawa-dev]

Let me give my opinion that this is not a HyperHDR problem and the timeout will remain in place as it is. We need to set a reasonable timeout limit when we're no longer waiting for a response and assume that communication with the device doesn't meet any minimum standards for our purposes. As is the case here. Serious systems that aim to support ambient lighting, not just display a fancy color every few seconds, use UDP, where the timeout issue is essentially nonexistent. In the case of Home Assistant... well, we only have TCP.

BTW it's not just this light that's causing the problem, but even communication with the HA itself is causing the problem, as seen in your logs:

2025-09-24T19:53:39.227Z [LEDDEVICE] (ProviderRestApi.cpp:198) GET end (499 ms): [http://homeassistant.local/api/states] []

It's possible that the HA itself is having a problem with this unit, which shouldn't render its API useless. However, this isn't a HyperHDR issue.

EDIT:
And since HyperHDR cannot detect HA instance then m-dns also fails in your network/HA!

[awawa-dev]

The POST call to /api/services/light/turn_on is synchronous, i.e. as long as the device didn't execute the action on home assistant side, it'll hold the request until it can answer.

I remember I tested that approach without waiting for the answer: the communication with HA crashed after few minutes as it was too much for HA.