The Unifi Express 7 update version 5.1.31 breaks the integrated Hue Bridge Integration. Reverting to the previous 5.1.19 version fixes it. If anyone is aware of any other fix for this please let me know.
I've been running 5.1.31 for a while since it was pushed through the Release Candidate channel, without issues. What are the symptoms you're seeing? Any errors?
Mine only auto updated to 5.1.31 during the early hours of yesterday. Hue integration could no longer discover or interact with my hue bridge after that. I tried to rediscover but it was never found. I deleted and started from scratch but still could not discover. Reverted to hubitat previous firmware and restored a backup prior to the problem but still nothing. I recalled seeing a unifi update and so checked upon dates of hue problems starting and it was just after the unifi update. So I reverted the unifi to the previous version, 5.1.19, and all worked straight away.
These messages in logs:
Error communicating with Hue Bridge: HTTP 408
2026-08-26 11:46:21.677infohueBridge C67426 (Hue Bridge Pro) eventStreamStatus is disconnected
2026-08-26 11:46:10.163infohueBridge C67426 (Hue Bridge Pro) eventStreamStatus is connected
Obviously I tried cycling the power on everything and pressing the hue button, many times.
You must have some different settings on the Unifi side, than I have, because I am not seeing any issues with my Hue Bridge Pro. Check the logs on the Unifi side for any clues.
You may also need to stay on 5.1.31 as it resolves some high CVE vulnerability.
Vulnerability is for the unifi protect app, I don't have that so not applicable to me. I'm ok to sit on 5.1.19 for now, see what happens with the next release.
Running 5.1.31 on my UDM SE. No issues with my C8 Pro connecting to my Hue Bridge Pro using the built-in integration.
There are 22 different vulnerabilities addressed in https://community.ui.com/releases/Security-Advisory-Bulletin-067/fc4a3488-7c43-4628-8bab-f715e96dbfc9
Some of them are in Unifi Network app as well as the Unifi OS on various devices are impacted as well.
Same, but on a UDM Pro.
So it seems that certain hardware isn't affected but are any of you running the Express 7 without any issues?
I am running a UCG Max which is probably closer to thr UX7 but not that device. No issues for me with anything I have running
Thinking about what a 408 error is and looking at the documented change log I wouldn't think they would be connected. It seems the most likely culprit would be the router/firewall closing the connection early. Is there a keep alive setting in the Hue Bridge Integration? Maybe adjust that value down a little so keep alive are sent more frequently. Is the Hue bridge and the Hubitat on the same network/vlan?
I did some further investigations using packet captures. The hubitat is on one switch and the hue hub on a different switch. It seems that running 5.1.31 on the Express 7 introduces an arp problem of some kind. I could see arp requests but not replies. Having both devices on the same switch resolves the problem so for now that is what I will do.
I preface this response by stating that the information provided came from Google Gemini.
The reason this HTTP 408 timeout and stream disconnect is happening specifically on the Express 7 after the 5.1.31 update comes down to its new, high-performance software features.
1. The Suricata 8.0.6 Engine Overhaul (High-Speed IPS/IDS)
The 5.1.31 firmware update bundles an upgrade to the network threat detection system, shifting to Suricata version 8.0.6.
The Problem: The Express 7 is built to process massive throughput (up to 2.3 Gbps with full IDS/IPS enabled). To achieve this, the 5.1.31 kernel heavily relies on hardware-accelerated packet inspection queues.
The Conflict: Persistent local TCP stream connections—like Hubitat's SSE connection to the Hue Bridge—keep sockets open indefinitely. The newly updated Suricata engine on the UX7 is falsely classifying this continuous, non-stop local HTTP chatter as a potential tracking loop or buffer vulnerability. It silently throttles or delays the packets, which instantly triggers Hubitat's HTTP 408 timeout.
Why other Cloud Gateways escape this: Standard gateways like the Cloud Gateway Ultra max out at 1 Gbps IDS/IPS and use completely different Suricata processing threads. The specific hardware optimization code for the UX7's 10GbE network stack makes its inspection engine behave much more aggressively toward persistent internal LAN traffic.
2. The 10G/2.5G Inter-VLAN Bridging Glitch
If you are separating your Hubitat and Hue Bridge onto an IoT VLAN, the UX7 has to route that traffic internally between its 10G combo interface and 2.5G LAN interface.
- The Bug: A known routing-table efficiency bug in the 5.1.31 build causes the internal bridge on the UX7 to occasionally choke or drop packets when a device on a slower connection (like a 100Mbps Hue Bridge or a Hubitat) maintains a massive state-table footprint with a local stream.
Actionable Troubleshooting for the Express 7
Since you have a much more capable device, you don't necessarily have to downgrade right away. Try these two targeted fixes first:
-
Disable Traffic Identification & Suspicious Activity (To test):
- Go to Settings > Security > Advanced.
- Temporarily turn off Suspicious Activity (IDS/IPS) or Traffic Identification.
- If your Hubitat logs stop throwing errors immediately, you have confirmed that the Suricata 8.0.6 package is aggressively dropping your Hue streaming packets. You can create a local firewall/threat allowance rule for the Hubitat and Hue Bridge IPs to bypass inspection.
-
Move Hubitat and Hue to the Same Layer 2 Subnet:
- If they are across different VLANs, try putting them on the exact same untagged local network/VLAN. This keeps the traffic purely switching at the local Layer 2 layer, preventing the UX7's core routing engine from messing with the keep-alive packets.
Yep the second option of putting them both on the same switch worked. Could have saved myself a whole lot of effort if I'd used AI. Still proves the old skills still exist to some degree