Philips Hue related crashes

[rspaninks]

Hi,

I'm running domoticz 2025.1 on RPi 4. Having issues with Philips Hue. I'm on the old Hue Bridge.

I have been running Domoticz for several years including Hue without real problems. I have installed 2025.1 months ago and it has been run stable. Over the last few weeks I'm experiencing domoticz crashes. Examination of the crashlog indicates it is Hue related. I'm not aware of significant changes in my Hue setup, nor my Domoticz.

I've tried several things:

- Disabled all my DZVentz scripts that reference.use Hue -- Did not help
- Set the update interval of Hue from 10 (default AFAIK) to 200 -- Did not help
- Tried removing all Hue devices I don't really need in Domoticz, but they automatically come back when changes occur -- did not help
- Tried to see if I could relate the crashes to a specific hue device or action, but it seems pretty random, or at least it is not obvious

Finally I disabled the Hue hardware device. That was like 4 days ago and stable since. I'm a bit lost here.

Excerpt of a crashlog (other crashlog are very similar) :

Thread 25 (Thread 0xac1fb220 (LWP 3478)):
#0 __waitpid (options=0, stat_loc=0xac1f9860, pid=724) at ../sysdeps/unix/sysv/linux/waitpid.c:30
#1 __waitpid (pid=724, stat_loc=0xac1f9860, options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:25
#2 0x007380ba in dumpstack_gdb(bool) ()
#3 0x00738510 in signal_handler(int, siginfo_t*, void*) ()
#4 <signal handler called>
#5 raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#6 <signal handler called>
#7 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#8 0xb688f230 in __GI_abort () at abort.c:79
#9 0x00beffc0 in __gnu_cxx::__verbose_terminate_handler() ()
#10 0x00b96140 in __cxxabiv1::__terminate(void (*)()) ()
#11 0x00b96196 in std::terminate() ()
#12 0x00b960bc in __cxa_throw ()
#13 0x00abfb0c in Json::throwLogicError(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
#14 0x00ac4926 in Json::Value::operator[](unsigned int) ()
#15 0x00ac4c44 in Json::Value::operator[](int) ()
#16 0x00993792 in CPhilipsHue::GetGroups(Json::Value const&) ()
#17 0x00994abe in CPhilipsHue::GetStates() ()
#18 0x00994c7a in CPhilipsHue::Do_Work() ()
#19 0x00bebca2 in execute_native_thread_routine ()
#20 0xb6a9c494 in start_thread (arg=0xac1fb220) at pthread_create.c:486
#21 0xb694f578 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:73 from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Hope this rings a bell for someone....

Thanks, Richard

[Matmar]

Hi, I’m chiming in because I’ve encountered exactly the same issue with the stable 2025.1 release of Domoticz on Raspberry Pi OS Bullseye.

In my case, Domoticz regularly crashes after a few minutes/hours of operation when using the old Philips Hue bridge (port 80).

Here’s my experience:

I updated my Raspberry Pi to Bookworm.

I tested the latest beta, where everything seems to work without crashes, but I haven’t tested it for a long period.

I returned to stable 2025.1 because in the beta I observed a significant CPU increase caused by the Philips Hue hardware using API v2, probably due to heavy HTTPS message parsing.

Disabling the Hue hardware in the beta immediately removes the high CPU load.

On the stable release, the crash appears only when the Philips Hue hardware is active.
Disabling the Hue hardware in stable prevents the crash completely.

At the moment, I continue to use the stable 2025.1, managing the occasional crash with a script that automatically restarts Domoticz every 2 minutes.

It seems there is a bug introduced in stable 2025.1 affecting users with the old Philips Hue bridge.
If helpful for the developers, I can share the stack trace showing that the crash originates from the Hue module.

[jannl]

Not sure what you mean by the old Hue bridge. I suppose the V1 or so. To support that there has been an update, you propably should upgrade to 2025.2 or newer. The update had something to do with the support of http iso https.

I run 2025.2 (16917) on a Pi 3B with 30+ hue devices and an average cpu usage of round 10%

[Matmar]

Thanks for your feedback.
I also upgraded to the latest beta (16922) and with around 20–30 Hue devices I’m seeing an average CPU load of 15–20%.
On the stable 2025.1, instead, my system sits around 5% CPU on average, so for now I prefer staying on the stable release.
To me it looks like there is still some room for optimization in the new Hue code, because the jump in CPU usage is really significant.

Regarding the old Hue bridge: I am indeed using the V1 (the round white one), which communicates over port 80. Philips never released anything older than this model.

In my tests with the latest beta, the new “HTTP vs HTTPS based on port number” mechanism does not work properly on port 80:
• With port 80, nothing works and I get a huge amount of errors.
• With port 443, the beta works, but I still see occasional errors (I will post them as soon as I run the beta again and collect more logs).

So at the moment my experience is:
• stable 2025.1 → works fine but crashes when Hue V1 hardware is enabled
• beta 16922 → doesn’t work with port 80 at all, only with 443, and CPU usage is quite high

Just sharing my findings so they might help improve the Hue implementation.
Cheers!

[Matmar]

Just to add some extra information based on further testing.

With the latest beta (16922), the CPU usage on my Pi 3B stays around 15–20% on average when the Philips Hue hardware is enabled (around 20–30 devices on a Hue V1 bridge).
This is very high for a Pi 3B and has a real impact on the system responsiveness — automations, scripts and the Domoticz web interface all feel noticeably slower. A higher CPU load on such limited hardware directly translates into a less reactive home-automation system.

I also noticed that increasing the Hue poll interval to 4–5 seconds reduces CPU usage significantly, but at the cost of longer delays when lights should turn on. Since the Hue V1 bridge is already relatively slow (typically around 1 second reaction time), adding even more delay is very noticeable.

Regarding communication with the Hue V1 bridge:
• Using port 80 (the correct/default port for the V1 bridge), the latest beta does not work properly — I get continuous errors.
• Only port 443 works, even though the V1 bridge was never meant to use HTTPS.
Even on port 443 I still see occasional errors, which I will post when I reproduce them again.

All of this means that the higher CPU usage doesn’t just show up in the graphs — it actually makes the whole system feel slower and less responsive. And since increasing the poll interval reduces CPU load but adds noticeable delays, especially with the already slow Hue V1 bridge, it becomes a compromise that doesn’t really solve the problem.

In the end, this situation pushes users toward buying new hardware:
• a new Hue Bridge (since the V1 is becoming harder to support),
• and even a Raspberry Pi 4 or 5, just to compensate for the extra CPU load introduced by the new Hue API handling.

Ideally, some optimization on the Domoticz side would avoid forcing users into unnecessary upgrades.
Cheers!

[rspaninks]

Hi,

I made a mistake in the version of my Hue bridge. I have a V2 (square one) with software version 1.74. It is on auto update, so I assume this is up to date. However, my original problem as described in the first post is still existing...

Reading the release notes of 2025.2 I thought I read they just changed support for https? Not sure if this would cover my issue?

Regards, Richard

[Matmar]

Hi Richard,

I just wanted to add that I’m in the same situation. My Hue Bridge is running the same software version as yours: 1.74.197….
It’s the white square bridge, which has always worked for years over plain HTTP without any problems.

Now Philips is selling the new “Hue Bridge Pro” (the black one), promoted as more powerful, with AI features and various enhancements. These upgrades are normal — they encourage people to buy new hardware and keep the ecosystem moving. I have nothing against that in general, but the existing hardware should still remain fully compatible, especially considering that Philips is still selling the older bridge.

So I believe we are talking about the same generation of bridge, even if it’s technically called V2. And unfortunately, it looks like Philips may no longer guarantee the same level of backward compatibility for the older model, which isn’t ideal for users like us who have been relying on it for years.

Regards,
Matmar

[Peter2]

I also experienced random crashes of domoticz every couple of hours due to the hue plugin (as shown in the domoticz_crash.log). Before domoticz has been stable for years. After disabling the hue plugin the system was stable.

It started after updating the Hue Bridge V2 to fw 1974063020. At that time domoticz was on the latest stable release 2025.2.16812. To try and fix the crashing I first upgraded domoticz to the latest beta, which did not fix the problem. I ended up removing and reinstalling the hue plugin connecting at port 443. After that domoticz has crashed twice due to the hue plugin: 1. after hiding hue scenes in domoticz by putting $ in front of the name; 2. by pressing a 'button' on a hue dimmer switch in the domoticz interface. So I removed and reinstalled the hue plugin again connecting at port 443 and avoided changing anything in the domoticz interface related to hue devices apart from adding the devices/scenes/groups. Now its running stable (with low CPU use on Pi4 - 2%). It is my impression that something in the hue plugin is not fully compatible with the latest hue bridge v2 firmware, but I am not tech-savvy enough to pinpoint the problem.

Many thanks to the developers for this great software! And also happy to see the hue contact added to the beta version.

[jannl]

Not sure if that is related to the Hue hardware (presuming you use the integrated hardware option and some plugin).

I see sometimes something like :

Code: Select all

2025-11-20 00:00:02.448 Error: PhilipsHueV2: FetchDevicePower HTTP GET failed (https://192.168.1.167:443/clip/v2/resource/device_power)

in the logging.

But no Domoticz crashes at all I am running on one of the latest beta's, the have been some fixes in the Hue hardware the last 3 weeks I see in github.

[mikedavies1953]

Version: 2025.2 (build 16922)
Platform: Windows 10

Like Janni & Peter2, Domoticz having previously been stable for years, I am also now experiencing random crashes every few hours due to Hue hardware.

It seems to have started after updating the Hue Bridge V2 to 1974063020. At that time Domoticz was on stable release 2025.1.To try and fix the crashing I first upgraded it to the latest stable (2025.2) and then the latest beta (16922), neither of which has fixed the problem.

Disabling Hue hardware from the Domoticz UI seems to have stopped the problem temporarily but that leaves me without Domoticz having any control over Hue, which obviously isn’t a permanent solution.

There is a further twist in that I have three Bridges V2 linked to the system, one local and two remote. The local system seems unaffected by this problem and continues to work normally. However, the two remote systems (each connected by an open port at the remote location) when enabled produce a stream of errors of the form:

Error: PhilipsHueV2: FetchDevicePower HTTP GET failed (http://83.146.XX.XXX:XXXX/clip/v2/resource/device_power)

This seems to eventually cause a stack overflow (??) that crashes Domoticz.

Any advice would be appreciated.

Thanks

[jannl]

As said, my Domoticz does not crash, I doubt wheter it is solely related to Hue.

Are all of you Hue devices on the correct firmware? Do you have battery operated devices which may have a low battery?

Besides an incidental error message regarding Hue (2sec after midnight), everything runs fine.

I run on a pi with bullseye (Bookworm in the docker).

Not sure if Windows 10 is the problem (not really supported by Microsoft since 14 oct 2025).

[mikedavies1953]

Hi, Janni

All my Hue devices are on automatic firmware update. In fact, the problems only became evident after the most recent automatic update at about 04:00 on 11 November. It seems too much of a coincidence!

I understand that your Domoticz isn’t crashing but we do seem to be suffering very similar error messages, which was why I mentioned you.

The Windows 10 platform is certainly an old machine but I have enrolled for Microsoft Extended Security Updates which should see it OK for another year or so. All it does is run Domoticz and a Plex server.

Thanks, anyway.

[jannl]

Very strange. The last 3 days exactly at 2seconds after midnight I get 1 Hue related error line.

You sure it is not related to Windows (10). May be you could try docker. Or some Debian vm?

[Matmar]

Hi all,

Even though I’m using the latest beta, with my older (white) Philips Hue bridge I keep getting these errors in the log:

2025-11-22 19:01:24.349 Error: PhilipsHueV2: FetchDevices HTTP GET failed (https://192.168.1.2:443/clip/v2/resource/device)
2025-11-22 19:01:24.575 Error: PhilipsHueV2: FetchContacts HTTP GET failed (https://192.168.1.2:443/clip/v2/resource/contact)
2025-11-22 19:01:24.800 Error: PhilipsHueV2: FetchTamper HTTP GET failed (https://192.168.1.2:443/clip/v2/resource/tamper)


It seems that Domoticz is unable to properly communicate with the Hue bridge using the v2 API, likely because the bridge does not fully support the new HTTPS calls required by the HueV2 plugin.

Has anyone else experienced the same issue with an older Hue bridge?

Thanks in advance for any suggestions!
Matmar

[Matmar]

and this error:
2025-11-22 19:16:26.539 Error: PhilipsHueV2: FetchDevicePower HTTP GET failed (https://192.168.1.2:443/clip/v2/resource/device_power)

[Jolle]

Version: 2025.2 (build 16936)
Platform: Raspberry Pi OS (Bookworm, 64-bit), running on Raspberry Pi via systemd
Plugin/Hardware: Built-in Philips Hue hardware (old Hue integration, not “Philips Hue V2”) + Hue Bridge V2 (square white bridge, firmware on automatic update)
Other hardware: P1 Smartmeter, Enphase Metered, RFXCOM, InfluxPush, MQTTPush, etc.

Hi all,

I seem to be hitting the same crash others are reporting with Philips Hue, so I’ll add my details.

Domoticz has been running stable for years here, including Hue. After upgrading to 2025.1 it was still fine for a while, but in the last days Domoticz now crashes regularly (multiple times per day) only when the Hue hardware is enabled.

When the crash happens, the log always shows a fatal signal in the Hue thread:

Error: Domoticz(pid:2677792, tid:2677859('Philips Hue Bri')) received fatal signal 6 (Aborted)
...
#12 0x00005555ac521cac in Json::throwLogicError(...)
#13 0x00005555acbdfe8c in Json::Value::operator[](unsigned int)
#14 0x00005555ac9f5688 in CPhilipsHue::GetGroups(Json::Value const&)
#15 0x00005555ac9f748c in CPhilipsHue::GetStates()
#16 0x00005555ac9f7690 in CPhilipsHue::Do_Work()
#17 0x00005555acda78dc in execute_native_thread_routine ()
#18 0x00007fffb173ee58 in start_thread (...)
#19 0x00007fffb17a7f9c in thread_start ()

I also see a lot of P1 Smartmeter messages like:
P1 Smartmeter: Dismiss incoming - CRC failed
P1 Smartmeter: P1Meter: Line parsing error (stof)

but according to the backtrace the actual crash is clearly in the Philips Hue Bri thread inside CPhilipsHue::GetGroups(), not in the P1 thread.

What I already tried
• Replaced the P1 USB cable → P1 errors changed a bit, but Domoticz still crashes.
• Disabled the CRC check for the P1 Smartmeter → data appears, crash still occurs.
• Changed Hue options like Add Groups and Add Scenes → no effect, still crashes.
• Upgraded from stable 2025.1 to 2025.2 (build 16936, beta) → exact same crash and backtrace in CPhilipsHue::GetGroups(Json::Value const&).
• If I disable the Hue hardware in Setup → Hardware, Domoticz runs stable for many hours without crashing.

So at the moment the only way to keep Domoticz stable is to disable Hue completely, which obviously is not a real solution.

Current Hue setup
• Hue Bridge V2 (square white one), firmware auto-update enabled (latest as of November 2025).
• Using the Philips Hue hardware type (legacy integration), default settings (HTTP, default port).
• Several Hue bulbs and some older Hue lamps that were previously on a V1 bridge (that bridge has now been removed from Domoticz).

Questions
• Is this a known bug in the old Philips Hue hardware code when used with recent Hue Bridge V2 firmware?
• Would you recommend:
• or is there a fix/workaround expected for the existing Philips Hue hardware (GetGroups / JSON handling)?
• If helpful, I can provide the full domoticz_crash.log and more logging with higher debug level.

Thanks a lot for any hints or patches you can provide, and of course for Domoticz in general – it’s been running here for years and I’d love to get Hue stable again.

Best regards,
Jolle

[Matmar]

Hi Jolle,
just to let you know: I have already opened a new issue on the official Domoticz GitHub regarding this exact crash in the Philips Hue integration.
Gizmocuz and the team are now aware of it.

My symptoms are identical to yours:
• Domoticz runs for years without issues
• After updating to 2025.1/2025.2 it crashes only when the old Philips Hue hardware is enabled
• The crash log always points to the same place:
CPhilipsHue::GetGroups(Json::Value const&)
• Disabling Hue makes Domoticz 100% stable
• I also suspected the Hue Bridge firmware, because the bridge updates automatically

Here is the GitHub issue I opened (the developers are following it):

https://github.com/domoticz/domoticz/is ... 3573050790

So you’re definitely not alone — it looks like something has changed (either in the Hue Bridge firmware or in how the JSON is returned) that causes a crash in the legacy Hue code of Domoticz.

The more users provide logs and backtraces, the easier it will be for the devs to fix it.

[jannl]

Strange, not really issues with Hue here. Never had the old bridge (V1).

Have you tried disabling groups/scenes in the hardware? I Have only groups enabled. Nor sure why, most likely because scenes gave too much devices. I switch groups via a bash script.

[Matmar]

It’s probably the V2, the white square one, not the new black Pro version. The previous model!

[jannl]

Same hardware here, no real problems so far.