Hue Bridge Integration and Tasmota issue with recent HE platform updates

🧰 Built-In Apps and Drivers Built-in Apps
1

Have Tasmota setup as a coordinator for my Zigbee bulbs (only devices on standalone zigbee network)

Was using built-in Hue Bridge Integration with Tasmota Zigbee bridge on my C4 since 2020 and now my C8Pro since Nov 2024 current HE platform OS at that time.

With current HE platform, built-in Hue Bridge is no longer working correctly. Discovers the bridge but won't add devices.

I was going to switch to a new Tasmota bridge device (Sonoff ZB Bridge Pro running Tasmota) and noticed it was not discovered. I thought there was a conflict with older bridge so I removed it and now won't discover devices on either old or new.

Here's the logs:

app:612025-04-25 12:23:19.523errorjava.lang.Exception: No response data exists for async request on line 1905 (method parseBridgeInfoResponse)
app:612025-04-25 12:23:19.480debugsendBridgeInfoRequest()
app:612025-04-25 12:23:19.478debugBridge authorized. Requesting information from Bridge and creating Hue Bridge device on Hubitat...
app:612025-04-25 12:23:19.477debug IP address = 192.168.0.12
app:612025-04-25 12:23:19.476debugBeginning bridge link process...
app:612025-04-25 12:23:14.627errorjava.lang.Exception: No response data exists for async request on line 1905 (method parseBridgeInfoResponse)
app:612025-04-25 12:23:14.481debugsendBridgeInfoRequest()
app:612025-04-25 12:23:14.480debugBridge authorized. Requesting information from Bridge and creating Hue Bridge device on Hubitat...
app:612025-04-25 12:23:14.478debug IP address = 192.168.0.12
app:612025-04-25 12:23:14.477debugBeginning bridge link process...
app:612025-04-25 12:23:09.592errorjava.lang.Exception: No response data exists for async request on line 1905 (method parseBridgeInfoResponse)
app:612025-04-25 12:23:09.476debugsendBridgeInfoRequest()
app:612025-04-25 12:23:09.475debugBridge authorized. Requesting information from Bridge and creating Hue Bridge device on Hubitat...
app:612025-04-25 12:23:09.472debug IP address = 192.168.0.12
app:612025-04-25 12:23:09.471debugBeginning bridge link process...
app:612025-04-25 12:23:04.628debugBridge authorized!
app:612025-04-25 12:23:04.627debugAttempting to request Hue Bridge API key/username; result = [[success:[username:666781]]]
app:612025-04-25 12:23:04.440debugsendUsernameRequest()... (IP = 192.168.0.12)
app:612025-04-25 12:23:04.439debugAttempting Hue Bridge authorization; attempt number 1
app:612025-04-25 12:23:04.436debug IP address = 192.168.0.12
app:612025-04-25 12:23:04.435debugBeginning bridge link process...
app:612025-04-25 12:23:00.926debugpageAddBridge()...
app:612025-04-25 12:22:55.619debugpageAddBridge()...
app:612025-04-25 12:22:36.203debugpageAddBridge()...
app:612025-04-25 12:22:33.947debugSubscribing to and sending SSDP discovery...
app:612025-04-25 12:22:33.945debugpageAddBridge()...
app:612025-04-25 12:22:33.613debugPolling disabled; not scheduling
app:612025-04-25 12:22:33.612debugscheduleRefresh()
app:612025-04-25 12:22:33.594debugDebug logging will be automatically disabled in 30 minutes
app:612025-04-25 12:22:33.568debugSubscribing to SSDP...
app:612025-04-25 12:22:33.561debuginitialize()
app:612025-04-25 12:22:33.557debuginstalled()
2

I'm a bit confused by the relationship between the two distinct kinds of devices you mentioned. Are you saying you added a Tasmota bridge using the Hue integration? If so, they must have re-implemented the API on their own device but are missing something the 2.4.0+ integration depends on that the 2.3.9 and earlier one did not. Turning logging all the way up on the app and bridge device might give more clues, though whether it can be "fixed" without breaking anything for an actual Hue Bridge, I don't know.

If you're attempting to use the new Tasmota bridge integration you mentioned, none of the log entries above appear to be from that, in case that is helpful to know (they all look like Hue).

3

I try to clarify:

I have been using Tasmota with it Zigbee bridge feature (Tasmota v11). Tasmota has Hue Emulation feature also. This was a homemade device running on a NodeMCU connected to a TI-CC2530 Zigbee Chip. I only have my Zigbee bulbs on this network.

This has been working with the built-in Hue Bridge app on a C4 since 2020 and a C8Pro since Nov 2024. I retired my C4 and replaced with C8Pro in Oct 2024.

This homemade bridge has been working on all various HE OS's up to releases during the Dec 2024 timeframe. Unfortunately I don't remember what version I was running on HE at that time

I am currently on ver 2.4.0.151

I received my Sonoff ZB Bridge Pro End of Jan 2025 and flashed it with current version of Tasmota32 (specific build for Sonoff BridgePro) at that time I tried to add it to HE and noticed that it never completed the device discovery process.

I have been having occasional issues with the homemade bridge loosing connectivity to the bulbs, again today. ( the reason for the ZB Bridge Pro, it is based on ESP32 and CC2652 chip).

I decided to dig into this and by mistake removed the working bridge. Upon attempting to add previous working Tasmota bridge back, I get the above error in the Hue Bridge app.

4

As I alluded to above, there were significant changes to the Hue integration in platform version 2.4.0, which you can also see in the release notes. Those are undoubtedly responsible for the differences, and it coincides with your timeline, as 2.4.0 was released in December of 2024. I'm not sure what specific difference would have caused this, but clearly, they're doing something at least a bit different from the Hue Bridge.

Is all logging enabled for the app and Bridge device (if it is even created yet, which it looks like it is)? It's possible there will be more clues there.

What do you see if you look at the output of http://<tasmotaBridgeIP>/api/0/config in a web browser (or really anything that can fetch the JSON this endpoint should return with an HTTP GET)?

5

Sorry, I misunderstood your response.

There are no logging options in the native Hue Bridge.

Going back to 2.3.x is not an option obviously.

This is on my bridge pro with latest Tasmota version 14.6.0

Here's the log from Tasmota:

14:46:34.496 CMD: weblog 4
14:46:34.497 SRC: WebConsole from 192.168.0.5
14:46:34.498 CMD: Grp 0, Cmd 'WEBLOG', Idx 1, Len 1, Pld 4, Data '4'
14:46:34.502 MQT: stat/zig2tas/RESULT = {"WebLog":4}
14:46:41.994 HTP: Hue API (/6a3964/lights/536923121) from 192.168.0.145
14:46:41.996 /lights path=/lights/536923121
14:46:41.998 HTP: Hue Result ({"state":{"on":true,"bri":254,"colormode":"ct","ct":370,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"TestLamp","modelid":"Ecosmart-ZBT-A19-CCT-Bulb","manufacturername":"The Home Depot","uniqueid":"20:43:a8:6a:39:64:cb:E1-01"})
14:46:43.943 UDP: Packet (119/333)
14:46:43.944 UDP: Packet (119/333)
14:46:49.344 WIF: Checking connection...
14:46:51.496 HTP: Hue API () from 192.168.0.19
14:46:51.496 HTP: Hue POST args ({"devicetype":"Hubitat Hue#HubitatC8"})
14:46:51.500 HTP: Hue Authentication Result ([{"success":{"username":"6a3964"}}])
14:47:02.100 BRY: GC from 4336 to 3724 bytes, objects freed 1/38 (in 1 ms) - slots from 51/91 to 41/91
14:47:02.108 MQT: tele/zig2tas/STATE = {"Time":"2025-04-25T14:47:02","Uptime":"8T03:14:52","UptimeSec":702892,"Heap":178,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":40,"Berry":{"HeapUsed":3,"Objects":38},"Wifi":{"AP":1,"SSId":"NutHouse","BSSId":"A8:9A:93:98:61:46","Channel":6,"Mode":"HT40","RSSI":100,"Signal":-47,"LinkCount":17,"Downtime":"0T00:05:57"}}
14:47:09.348 WIF: Checking connection...
14:47:13.948 UDP: Packet (119/333)
14:47:13.949 UDP: Packet (119/333)
14:47:29.350 WIF: Checking connection...
14:47:44.049 UDP: Packet (119/333)
14:47:44.050 UDP: Packet (119/333)
14:47:49.350 WIF: Checking connection...
14:48:09.351 WIF: Checking connection...

Here's the output from the endpoint you referenced:

{
  "name": "Philips hue",
  "mac": "20:43:A8:6A:39:64",
  "dhcp": true,
  "ipaddress": "192.168.0.13",
  "netmask": "255.255.255.0",
  "gateway": "192.168.0.1",
  "proxyaddress": "none",
  "proxyport": 0,
  "bridgeid": "2043A8FFFE6A3964",
  "UTC": "2025-04-25T18:49:04Z",
  "whitelist": {
    "6a3964": {
      "last use date": "2025-04-25T18:49:04Z",
      "create date": "2025-04-25T18:49:04Z",
      "name": "Remote"
    }
  },
  "swversion": "01041302",
  "apiversion": "1.17.0",
  "swupdate": {
    "updatestate": 0,
    "url": "",
    "text": "",
    "notify": false
  },
  "linkbutton": false,
  "portalservices": false
}

And the logs from HE:

app:652025-04-25 14:47:52.091errorjava.lang.Exception: No response data exists for async request on line 1905 (method parseBridgeInfoResponse)
app:652025-04-25 14:47:51.891debugsendBridgeInfoRequest()
app:652025-04-25 14:47:51.890debugBridge authorized. Requesting information from Bridge and creating Hue Bridge device on Hubitat...
app:652025-04-25 14:47:51.888debug IP address = 192.168.0.13
app:652025-04-25 14:47:51.887debugBeginning bridge link process...

Note: I tried your COCOHue app/driver and got the same error (method parseBridgeInfoResponse) .

6

I'm having a hard time figuring out why this wouldn't work. Maybe the content type isn't set to application/json for the data returned from the api/0 endpoint I had you try? But even then, I think there should be something...

Commenting out the offending line in CoCoHue should work if it's just a log.debug line as I suspect, though you're likely to run into the problem later in the code. For sure disable the options to use the V2 API and likely SSE (server-sent events) unless you know Tasmota supports them, which are options you'll see in the app before you add the Bridge. That might help, too.

7

I tried disabling V2 to no effect. I don't see an option for disabling SSE.

I tried device discovery in Alexa and it found the bridge and added the bulbs without issue. Selected hue bridge version 1.

Here's what get with CoCoHue.

HE logs:

app:672025-04-25 15:47:26.309errorjava.lang.Exception: No response data exists for async request on line 1585 (method parseBridgeInfoResponse)
app:672025-04-25 15:47:26.280debugsendBridgeInfoRequest()
app:672025-04-25 15:47:26.279debugBridge authorized. Requesting information from Bridge and creating Hue Bridge device on Hubitat...
app:672025-04-25 15:47:26.277debug IP address = 192.168.0.12
app:672025-04-25 15:47:26.275debugBeginning bridge link process...
app:672025-04-25 15:47:21.333errorjava.lang.Exception: No response data exists for async request on line 1585 (method parseBridgeInfoResponse)
app:672025-04-25 15:47:21.284debugsendBridgeInfoRequest()
app:672025-04-25 15:47:21.282debugBridge authorized. Requesting information from Bridge and creating Hue Bridge device on Hubitat...
app:672025-04-25 15:47:21.280debug IP address = 192.168.0.12
app:672025-04-25 15:47:21.278debugBeginning bridge link process...
app:672025-04-25 15:47:16.364errorjava.lang.Exception: No response data exists for async request on line 1585 (method parseBridgeInfoResponse)
app:672025-04-25 15:47:16.288debugsendBridgeInfoRequest()
app:672025-04-25 15:47:16.286debugBridge authorized. Requesting information from Bridge and creating Hue Bridge device on Hubitat...
app:672025-04-25 15:47:16.282debug IP address = 192.168.0.12
app:672025-04-25 15:47:16.281debugBeginning bridge link process...
app:672025-04-25 15:47:11.200debugBridge authorized!
app:672025-04-25 15:47:11.198debugAttempting to request Hue Bridge API key/username; result = [[success:[username:666781]]]
app:672025-04-25 15:47:11.123debugsendUsernameRequest()... (IP = 192.168.0.12)
app:672025-04-25 15:47:11.121debugAttempting Hue Bridge authorization; attempt number 1
app:672025-04-25 15:47:11.114debug IP address = 192.168.0.12
app:672025-04-25 15:47:11.112debugBeginning bridge link process...

Tasmota logs:

15:47:11.654 HTP: Hue API () from 192.168.0.19
15:47:11.655 HTP: Hue POST args ({"devicetype":"Hubitat CCH#HubitatC8"})
15:47:11.659 HTP: Hue Authentication Result ([{"success":{"username":"666781"}}])
15:47:18.184 WIF: Checking connection...
15:47:24.175 WIF: Sending Gratuitous ARP
15:47:30.716 UDP: Packet (119)
15:47:38.172 WIF: Checking connection...
15:47:48.191 MQT: tele/zig2tas/STATE = {"Time":"2025-04-25T15:47:48","Uptime":"0T03:55:02","UptimeSec":14102,"Heap":22,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":2,"Wifi":{"AP":1,"SSId":"NutHouse","BSSId":"1C:8B:76:76:27:C3","Channel":1,"Mode":"11n","RSSI":74,"Signal":-63,"LinkCount":2,"Downtime":"0T00:00:04"}}
15:47:58.166 WIF: Checking connection...
15:48:00.799 UDP: Packet (119)
15:48:00.800 UDP: Packet (119)
15:48:18.166 WIF: Checking connection...
15:48:24.192 WIF: Sending Gratuitous ARP
15:48:30.805 UDP: Packet (119)
15:48:30.858 HTP: Hue API (/666781/lights/536935523) from 192.168.0.197
15:48:30.860 /lights path=/lights/536935523
15:48:30.863 HTP: Hue Result ({"state":{"on":false,"bri":64,"colormode":"ct","ct":370,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Micks Lamp","modelid":"Ecosmart-ZBT-A19-CCT-Bulb","manufacturername":"The Home Depot","uniqueid":"2c:f4:32:66:67:81:fc:11-63"})
15:48:38.152 WIF: Checking connection...
15:48:56.578 HTP: Hue API (/666781/lights/536878490) from 192.168.0.197
15:48:56.580 /lights path=/lights/536878490
15:48:56.584 HTP: Hue Result ({"state":{"on":false,"bri":102,"colormode":"ct","xy":[0.32999,0.32999],"hue":65535,"sat":254,"ct":370,"alert":"none","effect":"none","reachable":true},"type":"Extended color light","name":"Deannas Lamp","modelid":"Ecosmart-ZBT-A19-CCT-Bulb","manufacturername":"The Home Depot","uniqueid":"2c:f4:32:66:67:81:1d:11-9a"})
15:48:58.190 WIF: Checking connection...
8

If I query this endpoint tasmota-ip/api/0/lights

I get this: (just 2 of 6 bulbs)

{
  "536879769": {
    "state": {
      "on": false,
      "bri": 254,
      "colormode": "ct",
      "ct": 370,
      "alert": "none",
      "effect": "none",
      "reachable": true
    },
    "type": "Extended color light",
    "name": "Blue Herron Lamp",
    "modelid": "Ecosmart-ZBT-A19-CCT-Bulb",
    "manufacturername": "The Home Depot",
    "uniqueid": "2c:f4:32:66:67:81:22:11-99"
  },
  "536885659": {
    "state": {
      "on": false,
      "bri": 102,
      "colormode": "ct",
      "ct": 370,
      "alert": "none",
      "effect": "none",
      "reachable": true
    },
    "type": "Extended color light",
    "name": "Chicken Lamp",
    "modelid": "Ecosmart-ZBT-A19-CCT-Bulb",
    "manufacturername": "The Home Depot",
    "uniqueid": "2c:f4:32:66:67:81:39:11-9b"
  },
9

What is line 1585 in this app for you?

Commenting it out may work if it's what I suspect above, though, again you may just run into the same problem later in the code.

Maybe replace it with `log.debug "${resp.status}" and see what that logs -- hopefully "200", but I suspect not, or I can't imagine why this would be happening.

10

That line is from CoCohue. I mentioned it in my previous post.

I tried your app just to see if it would work.

11

Respectfully, it seems you are only reading a portion of my responses before replying. This makes further assistance difficult. The question was not what app you are using, as it seems you assume but I already understand, but rather:

As I mentioned, it's probably a log line and one of the ideas above could help you get past this (though likely stop somewhere else) or provide more information.

1 Like
12

A couple other ideas that might help:

  • temporarily downgrading to 2.3.9 to work around the issue, which seems to to only involve the time immediately after discovery/addition, then re-upgrading to see if it still works after that; or
  • trying an older version of CoCoHue (4.x is still easily available, but the entire history is open source and an old enough version may have some change that helps)
13

Yes i did miss the part where you mentioned your app. I assumed that the line number would be the same in all instances between installs. If I understand your question correctly.

However you mentioned that I most likely would run into problems later so I didn't proceed further along that front, however.

Line 1585 is:

if (logEnable == true) log.debug "parseBridgeInfoResponse(resp?.data = ${resp?.data}, data = $data)"

This is the relevant section of code on my end.

/** Parses response from GET of /api/0/config endpoint on the Bridge;
 *  verifies that device is a Hue Bridge (modelName contains "Philips Hue Bridge")
 * and obtains MAC address for use in creating device name
 */
void parseBridgeInfoResponse(resp, Map data) {
   //resp?.properties.each { log.trace it }
   if (logEnable == true) log.debug "parseBridgeInfoResponse(resp?.data = ${resp?.data}, data = $data)"
   String ipAddress = (data?.ip == null) ? state.ipAddress : data.ip
   Map body
   try {
      body = resp.json
   }
   catch (Exception ex) {
      if (logEnable == true) log.debug "  Responding device likely not a Hue Bridge: $ex"
      return
      // if (!(data.haveAttemptedV1)) {
      //    // try again with V1 API in case is V1 Bridge or old firmware on V2:
      //    if (logEnable == true) log.debug "  Retrying with V1 API"
      //    data.haveAttemptedV1 = true
      //    sendBridgeInfoRequest(data)
      // }
   }

So this is what I changed in your code (first line) in response to changing the debug type as you suggested. I commented out the original line and the changed version is on the second line.

   // if (logEnable == true) log.debug "parseBridgeInfoResponse(resp?.data = ${resp?.data}, data = $data)"
   if (logEnable == true) log.debug "${resp.status}"

Is it possible that the name returned by Tasmota is not an exact match? Case sensitive, etc.

I noticed in your comments at the beginning of the above section code that the name is (modelName contains "Philips Hue Bridge"), where Tasmota returns "name":"Philips hue",

This is what Node-Red returned:

Header

{"content-type":"application/json","content-length":"497","connection":"close","x-node-red-request-node":"138a8bd4"}

Payload

{"name":"Philips hue","mac":"2C:F4:32:66:67:81","dhcp":true,"ipaddress":"192.168.0.12","netmask":"255.255.255.0","gateway":"192.168.0.1","proxyaddress":"none","proxyport":0,"bridgeid":"2CF432FFFE666781","UTC":"2025-04-25T22:31:12","whitelist":{"666781":{"last use date":"2025-04-25T22:31:12","create date":"2025-04-25T22:31:12","name":"Remote"}},"swversion":"01041302","apiversion":"1.17.0","swupdate":{"updatestate":0,"url":"","text":"","notify": false},"linkbutton":false,"portalservices":false}
14

So this is what I get in the HE logs after changing the code as suggested, if I did it correctly.

app:682025-04-25 18:56:45.304debug Responding device likely not a Hue Bridge: java.lang.IllegalArgumentException: No json exists for response
app:682025-04-25 18:56:45.303debug408
app:682025-04-25 18:56:45.287debugsendBridgeInfoRequest()
app:682025-04-25 18:56:45.285debugBridge authorized. Requesting information from Bridge and creating Hue Bridge device on Hubitat...
app:682025-04-25 18:56:45.284debug IP address = 192.168.0.12
app:682025-04-25 18:56:45.282debugBeginning bridge link proces
15

Downgrading to 2.3.9 is not an option as I don't have any db backups from that time and I thought i read that was a requirement to downgrading to prior 2.4.0.

I can try prior version of CoCoHue.

16

That is interesting, though I guess not surprising if there is no data, either.

Looking at this more, do you see something like this around line 1538?


contentType: "text/xml",

If so, changing that to this might change things:

contentType: "application/json",

The error you're sharing above makes sense that it would go along with the other one you share; the HTTP response it's sending to the hub doesn't contain JSON (like it clearly does from your browser response), or any data at all apparently (which the resp.status property I suggested would give more clues about), and this might be what's wrong -- the older way of doing this (via a different endpoint) was looking for XML, and Tasmota might be pickier.

17

I was just looking at that line (then saw your post) and wondered if changing to what you suggested would work.

I did try changing that line in the code it and I still get the same error. I assume that removing the app with the remove button and then adding it back in will use the new code.

Are there other endpoints I can try querying Tasmota?

I never get beyond this screen

image
image802×278 10.6 KB

18

I would start by seeing what this value is:

19

I don't follow you, I changed that line earlier, as you suggested (lIne 1585) to that bit of code and haven't changed it back.

20

Ok something new, I uncommented line 1584

resp?.properties.each { log.trace it }

And got this:

app:712025-04-25 19:57:52.322debug Responding device likely not a Hue Bridge: java.lang.IllegalArgumentException: No json exists for response
app:712025-04-25 19:57:52.321debug408
app:712025-04-25 19:57:52.320traceerrorData=null
app:712025-04-25 19:57:52.319traceerrorMessage=Connect to 192.168.0.12:443 [/192.168.0.12] failed: Connection refused (Connection refused)
app:712025-04-25 19:57:52.317tracestatus=408
app:712025-04-25 19:57:52.316traceclass=class hubitat.scheduling.AsyncResponse
app:712025-04-25 19:57:52.315tracewarningMessages=[]
app:712025-04-25 19:57:52.313traceheaders=null

It looks like your trying to use https when Tasmota doesn't support https. Is there a simple way to not use https?