Hue Integration Errors on 2.4.0.144

[Automatican]

The Hue Bridge Device from the New Hue Bridge Integration App is throwing an error in the logs quite often (every 5 to 40 minutes):

The error looks like this:

Error:

groovy.lang.MissingMethodException: No signature of method: hueBridge$_parse_closure2$_closure44$_closure45$_closure47.call() is applicable for argument types: (java.util.TreeMap$Entry) values: [data=[{configuration_schema={$ref=...
.........................
...type=zigbee_device_discovery}]] Possible solutions: any(), any(), doCall(java.util.Map), any(groovy.lang.Closure), each(groovy.lang.Closure), any(groovy.lang.Closure) on line 283 (method parse)

However there are literally 220 thousand+ characters of data that I replaced with all the ........ in the message above.

It's also interesting that the error has a reported time in the logs that is out of sequence from the rest of the logs, by ~4 minutes late:

2025-12-30 05:23:13.959 PM ->> Log event just after
2025-12-30 05:19:06.805 PM ->> ERROR Being Thrown
2025-12-30 05:22:53.689 PM ->> Log entry just prior

The Hue Bridge Device is also reporting ~40% of the hub busy time over the last 3 hours since the last reboot. The total Hub busy time is only ~2% though.

Additionally:
At least 3 of the new Hue Devices are also throwing this type of error periodically:

java.lang.ArithmeticException: Division by zero on line 787 (method createEventsFromMapV1)

Perhaps a bug in the Hue Integration App in 2.4.0?

Any suggestions?

How I got here:

I updated to platform version 2.4.0.144 from 2.3.9.200 this morning.

Somehow in the process, the existing Hue Bridge Integration App refused to load from the Apps screen. Each time I clicked the App, it just showed constant spinning dots, then threw an error on the Apps screen after clocking for a very long time, that error flashed off the screen quickly. I didn't think to catch the error in the logs.

As I was try to just get the set-up to work, I was able to get around the issue by creating a new Hue Bridge Integration from the built-in Hue Bridge Integration app.

The new Hue Bridge integration app loaded just fine, linked to the hue hub fine, and detected and loaded all the Hue devices just fine (35+ devices from Hue). This resulted in 2 sets of all the Hue Devices and duplicate Hue Bridge devices.

Within the Hue Bridge Integration App:

The "Prefer V2 Hue API (EventStream/Server-Sent Events) if available" setting is enabled.

Also selected:

Use V1 API for polling (if polling enabled above) (recommended)

And the Polling interval is set to 1 Hour.

I then disabled the old Hue Bridge Integration App, but left all the old hue devices, and remapped all the dashboards to the new hue devices, and cloned all the rules referencing the old hue devices and mapped those new rules to use the new hue devices, and then disabled all the rules using the old hue devices. So nothing should be referencing the old hue devices even though they still exist in Hubitat.

Things seem to generally be working, but the errors above are appearing, and the hub seems a little sluggish when making selections.

[bertabcd1234]

There are fixes for what sound like all of the above coming in the next build.

[672southmain]

I hope so. I’m seeing much of the same, just about ready to throw it all out and go back to 2.3.9, which worked perfectly. Nothing involved with built-in Hue Integration works now. Home automation has become home abomination.

I have never seen such a bad release in my several years with Hubitat. I don’t use dashboards, don’t care what they look like, but I do expect automation to work.

[bertabcd1234]

Rolling back is very easy if you are experiencing problems.

[672southmain]

2.4.0.145 is a blessing, and has exorcised the demons from my hub. Our home is no longer possessed. The Hue Integration works again. Rules using Hue lightstrips work once more. Logs have stopped blowing up. Automations work. Stress level is low again.

Life is good.

[Automatican]

Updated to 2.4.0.145 from 2.4.0.144, and immediately upon boot-up received these log errors:

Reporting	Time	Type	Message
422	2025-01-01 10:30:45.715 AM	error	java.lang.ArithmeticException: Division by zero on line 792 (method createEventsFromMapV1)
420	2025-01-01 10:30:43.872 AM	error	java.lang.ArithmeticException: Division by zero on line 792 (method createEventsFromMapV1)
419	2025-01-01 10:30:42.745 AM	error	java.lang.ArithmeticException: Division by zero on line 792 (method createEventsFromMapV1)

Device 422 is a Hue Color Lamp and 420 & 419 are Hue Color Downlights paired to the Hue Hub. This is odd as there are many other devices of the same type that aren't reporting this error. This seems to be a line change to 792 from 787 for these devices as seen in the errors for the same devices prior to the update:

Reporting	Time	Type	Message
422	2025-12-31 09:30:42.457 PM	error	java.lang.ArithmeticException: Division by zero on line 787 (method createEventsFromMapV1)
420	2025-12-31 09:30:40.788 PM	error	java.lang.ArithmeticException: Division by zero on line 787 (method createEventsFromMapV1)
419	2025-12-31 09:30:39.815 PM	error	java.lang.ArithmeticException: Division by zero on line 787 (method createEventsFromMapV1)

Perhaps line 792 has something to do with the state that these devices happen to be in since other devices of the exact same type aren't throwing this error?

[bertabcd1234]

@Automatican

Device 422 is a Hue Color Lamp and 420 & 419 are Hue Color Downlights

What driver are these using, and what real-world capabilities do they support? If they are color-only (as opposed to "white and color," as Hue calls them), they should be using the hueBridgeBulbRGB driver, not the hueBridgeBulbRGBW driver, which is where this error appears to be coming from (a guess without really knowing this information, but one that makes sense based on the line number).

Enabling debug logging on the device would show more of the data coming in, but what must be happening is that the CT value is being reported by 0. This can be worked around in the driver, I suppose by ignoring the data in this case (it's not a valid value according to their API docs, so it really shouldn't be reported in the first place). But if the device doesn't actually support CT, this could be why, and the other driver would be more appropriate (and also should have been selected when adding, so if that didn't happen, I can look into that, too).

[Automatican]

The devices are:

Device ID	Device Name	Hue Product Name	Hue Model #	Description	Hue Integration Chosen Driver
419 & 420	Hue Color Downlight	Hue Spot BR30	LCT002	Hue White and Color BR30	hueBridgeBulbRGBW
422	Hue Color Lamp	Hue White and Color Ambience A19	LCT014	Hue White and Color Ambience A19	hueBridgeBulbRGBW

I think what's happening with these 3 specific devices is that their power is off at the source making them unreachable to the Hue hub, even though they are associated with the Hue hub.

Then according to each of these devices' "Current States" in the Hubitat Devices page, it doesn't seem that these 3 devices have reported a Color Temperature.

As you indicate the Hubitat driver is probably expecting at least some Color Temperature value so isn't able to handle division by null...

What's interesting is that another exact same bulb as 422 (device 423 for example) is also hard powered off and unreachable, but is, and/or, has reported a Color Temperature, and so isn't throwing this error.

Other bulbs, the same as 419 & 420, are also on the hub, and they have a Color Temperature value reported even though they are currently displaying a specific color.

So I'd guess this is some type of a problem with how the Driver or Hue Integration handles initial bulb on-boarding when no Color Temperature is reported as all these bulbs were just added to the Hubitat hub in the last day.

[bertabcd1234]

@Automatican

As you indicate the Hubitat driver is probably expecting at least some Color Temperature value so isn't able to handle division by null...

Not exactly what I meant; the value under "Current States" on the device detail page doesn't matter but rather whatever data is coming in from the API. That is what debug logging will show you. The value under "Current States" will be reflected after this data is parsed, but in your case, this error probably prevents this. But the error should only appear when the CT is reported by 0, which itself is pretty odd.

There is a fix for that last thing in for the next build, the fix being to ignore the data in this case (it's not valid per the API spec -- or real life, so I'm not sure why it's happening).

Again, debug logging will show you the data coming in from the Hue Bridge for either a refresh (usng any API version) or realtime data (on the V2 API); debug logging on the device itself should be sufficient unless you think data from the bridge isn't being matched up to the device, in which case bridge logging will show you everything. I suspect this will be pretty boring and you'll just see 0 CT values from your bulbs, something neither the integration app nor driver can help with (maybe re-pairing them to your Hue network would help?) -- my best guess being that the Hue Bridge never got valid values for these before they went offline or maybe eventually got rid of its cached values.

In any case, this will at least stop the errors -- the rest is up to the bridge to report properly unless debug logs show good data being ignored.

[Automatican]

I set the debug logging on 422.

The errors are showing up exactly once per hour, which is what the Hue Integration V1 polling is set to. So I suspect we'll see what, if anything, is being sent at the next v1 polling minute, which is at xx:54.

Edit: As expected, the log entry was created at xx:54. They indicate:

Device ID	Time	Type	Message
dev:422	2025-01-01 05:54:08.302 PM	error	java.lang.ArithmeticException: Division by zero on line 792 (method createEventsFromMapV1)
dev:422	2025-01-01 05:54:08.289 PM	debug	createEventsFromMapV1(): reate events from map from Bridge: [alert:select, bri:0, colormode:hs, ct:0, effect:none, hue:0, mode:homeautomation, on:false, reachable:false, sat:0, xy:[0.0000, 0.0000]]

There's no other info.

[bertabcd1234]

That is what I suspected. Your bulbs are reporting 0 as the color temperature. This shouldn't happen, but the next build will ignore these value and prevent the error. Thanks!

[672southmain]

Not quite the same errors as above, but infrequent pair of errors with built-in Hue Integration on Hue Color Lightstrips (3 lightstrips) using hueBridgeBulbRGBW driver on C-8 with 2.4.0.145. Not using V2 API.

Errors:

The first pair of errors occurred immediately after systemStart following update to 2.4.0.145, when my systemStart triggered rule initialized the lightstrips. The second pair occurred this morning when we got up.

Not often enough to cause issues, and everything appears to be working.

[bertabcd1234]

That method is no longer present or scheduled as handler in the current integration, so it looks like something got stuck (perhaps because of your previous errors). A "Done" in the integration app should fix that, or if not, the usual tricks to delete this specific scheduled job should work, which I can help with if you're not sure -- but I'd still be curious if the above didn't do it for some reason.

[672southmain]

Ok. I went to the Hue Integration app and saved a screenshot of subscriptions:

I then went and hit Done. Subscriptions look the same now, but times changed slightly for scheduled jobs. Will see if the occasional errors repeat in the future. Thanks.

[bertabcd1234]

D'oh, this one is a subscription, not a scheduled job. This is probably because it didn't clean that up from the older version of the built-in integration. You can probably trick it into doing so by going to the edit Bridge page like you're trying to change the IP address or SSDP/discovery preference (but don't), but I will add something to prevent this for new upgrades in the future.

[672southmain]

I don’t believe that cleans things up. Went to the edit bridge page, refreshed bridges, selected the same (only) bridge, clicked next, looked at subscriptions, etc., unchanged.

[bertabcd1234]

A closer look at the code makes it look like you'd need to turn off discovery (SSDP) for this to work (you can re-enable it right after if you had it on before). But a "Done" will fix this in the next build if you just wanted to wait. It is a harmless error in the meantime--the Bridge must be sending an SSDP advertisement on your network, and the old handler for that is still around, even though it's handled differently (and still would be despite this) with the updated version.

[672southmain]

I assume that “turn off discovery” means to turn off “remain subscribed to Bridge discovery requests”. Turned that off, clicked Done, went back, turned it on, all that changed was that the subscriptions became re-ordered, but nothing else changed.

My Hue hub has DHCP reserved IP, so, in a sense (as I understand this setting), it doesn’t matter for me.

Anyway, this doesn’t seem to remove the subscription. Regardless, it doesn’t matter, error is harmless.

I will just wait for the next update, and I will report if the update doesn’t fix things.

Thanks for your help.

[672southmain]

@bertabcd1234

A closer look at the code makes it look like you'd need to turn off discovery (SSDP) for this to work (you can re-enable it right after if you had it on before). But a "Done" will fix this in the next build if you just wanted to wait. It is a harmless error in the meantime--the Bridge must be sending an SSDP advertisement on your network, and the old handler for that is still around, even though it's handled differently (and still would be despite this) with the updated version.

Robert, simply an FYI, the same issue still seems to exist in 2.4.0.146, update applies moments ago, the pair of errors occurred on the systemStart reboot after update. No big deal, it seems harmless.

[CAZ]

I'm seeing these 2 errors as well. The last 3 days they have come in at 6:33am. Very consistent, 2 of the 3 at 6:33:10 and 1 at 6:33:09. Everything seems to be humming along nicely though. Reading through this I just turned off Remain subscribed. I did not see that setting when I set it up.