Closed ThioJoe closed 5 months ago
@ThioJoe oops... that is strange... the A19 is a regular sultanbulb
and I just re-verified here (and I have quite some of these) and they all show their proper name - so it would be pretty interesting what's the difference to your bulbs.
If you don't mind, I'd like look into this asap.
Do you know how to use the 'CLIP API Debugger' as shown here Clip API Debugger
If not, don't worry I can give you a few steps how to get your lights information right on your desktop computer.
The only thing you need is a username
(you can copy this from the Property Inspector of the plugin - just select Remove Bridge
there... it shows some information about your bridge(s).
http://<ipaddressofyourbridge>/debug/clip.html
on your computer.
In the URL:
field at the top of the window type:
/api/<yourusername>/lights
And click GET
.
This should bring up some JSON-information in the Command Response
field.
Just delete the uniqueid
and send me the JSON (either here or via Twitter @tiptronic or Reddit u/tiptronictalk
)
If you're not comfortable with that, I'll add a window to the plugin where you can also get that information.
Just let me know...
Yea I've done some experimenting with API requests to the hue bridge via Postman in the past so getting that info is easy enough.
I tried using both the V1 and V2 of the API requests and discovered the problem, just not the cause. It doesn't seem to be a problem with the Stream Deck plugin but rather something with the bridge I think.
Here's an example of one of the problematic bulbs via the V1 request. Notice the name
and productname
properties.
"33": {
"state": {
"on": false,
"bri": 254,
"hue": 41432,
"sat": 75,
"effect": "none",
"xy": [
0.3143,
0.3301
],
"ct": 156,
"alert": "select",
"colormode": "ct",
"mode": "homeautomation",
"reachable": true
},
"swupdate": {
"state": "noupdates",
"lastinstall": "2024-05-30T00:06:54"
},
"type": "Extended color light",
"name": "Bedroom 6 C",
"modelid": "LCA003",
"manufacturername": "Signify Netherlands B.V.",
"productname": "Hue color lamp",
"capabilities": {
"certified": true,
"control": {
"mindimlevel": 200,
"maxlumen": 800,
"colorgamuttype": "C",
"colorgamut": [
[
0.6915,
0.3083
],
[
0.1700,
0.7000
],
[
0.1532,
0.0475
]
],
"ct": {
"min": 153,
"max": 500
}
},
"streaming": {
"renderer": true,
"proxy": true
}
},
"config": {
"archetype": "sultanbulb",
"function": "mixed",
"direction": "omnidirectional",
"startup": {
"mode": "powerfail",
"configured": true
}
},
"uniqueid": <redacted>,
"swversion": "1.116.3",
"swconfigid": "A7A92A2E",
"productid": "Philips-LCA003-1-A19ECLv6"
},
Then here is from the V2 request. Notice how the metadata section 'property' name just says "Hue color lamp 5" for some reason. All the problematic bulbs are like this - they show a generic name in the V2 response. All the other bulbs show their actual name in the 'name' property. I
{
"id": <redacted>,
"id_v1": "/lights/33",
"owner": {
"rid": <redacted>,
"rtype": "device"
},
"metadata": {
"name": "Hue color lamp 5",
"archetype": "sultan_bulb",
"function": "mixed"
},
"product_data": {
"function": "mixed"
},
"identify": {},
"service_id": 0,
"on": {
"on": false
},
"dimming": {
"brightness": 100.0,
"min_dim_level": 0.20000000298023225
},
"dimming_delta": {},
"color_temperature": {
"mirek": 156,
"mirek_valid": true,
"mirek_schema": {
"mirek_minimum": 153,
"mirek_maximum": 500
}
},
"color_temperature_delta": {},
"color": {
"xy": {
"x": 0.3143,
"y": 0.3301
},
"gamut": {
"red": {
"x": 0.6915,
"y": 0.3083
},
"green": {
"x": 0.17,
"y": 0.7
},
"blue": {
"x": 0.1532,
"y": 0.0475
}
},
"gamut_type": "C"
},
"dynamics": {
"status": "none",
"status_values": [
"none",
"dynamic_palette"
],
"speed": 0.0,
"speed_valid": false
},
"alert": {
"action_values": [
"breathe"
]
},
"signaling": {
"signal_values": [
"no_signal",
"on_off",
"on_off_color",
"alternating"
]
},
"mode": "normal",
"effects": {
"status_values": [
"no_effect",
"candle",
"fire",
"prism",
"sparkle",
"opal",
"glisten"
],
"status": "no_effect",
"effect_values": [
"no_effect",
"candle",
"fire",
"prism",
"sparkle",
"opal",
"glisten"
]
},
"timed_effects": {
"status_values": [
"no_effect",
"sunrise",
"sunset"
],
"status": "no_effect",
"effect_values": [
"no_effect",
"sunrise",
"sunset"
]
},
"powerup": {
"preset": "powerfail",
"configured": true,
"on": {
"mode": "previous"
},
"dimming": {
"mode": "previous"
},
"color": {
"mode": "previous"
}
},
"type": "light"
},
I compared those entries with other unproblematic bulbs and they seem to be exactly the same except for the unique IDs - both for the V1 and V2 API.
I think it might have something to do with the fact that I replaced many of those bulbs or swapped them around. I've used an app iConnectHue which has a bulb replacement feature, perhaps that process went wrong somehow. I can't remember if those are ALL the ones I've used that replacement feature with though.
I'll try and do some reading in the dev docs to see why it's getting different names, I suspect this is not a common issue.
Ok actually I figured out the cause. It seems that the Hue bridge stores two separate databases/tables for the names of bulbs (and other metadata I guess). The problem appears to be that the bulbs had their names updated from the generic names with the V1 API but not with the V2 API. I suspect an app I used in the past to rename/update bulbs updated the bulbs names with V1 but not V2 also (likely iConnectHue which I used to replace bulbs and copy over all the previous properties). This left the generic names to show when a V2 request was made.
I found this out when I did API requests to rename a bulb differently using V1 and then V2, and each name only showed up when using the respective version for the GET request.
For example I tested on one of my bulbs "Uplight 1", which is one of the problematic ones.
With a V1 Put request I renamed it to "Uplight 1 Renamed Via V1":
PUT https://192.168.1.21/api/<apikey>/lights/16
{
"name":"Uplight 1 Renamed Via V1"
}
And then did the same with V2:
PUT https://192.168.1.21/clip/v2/resource/light/<bulb-id>
{
"metadata":
{
"name": "Uplight 1 Renamed Via V2"
}
}
Now when doing the light GET request it shows this for that bulb when using V1:
"16": {
...
"name": "Uplight 1 Renamed Via V1",
...
}
And this with V2:
}
...
"metadata": {
"name": "Uplight 1 Renamed Via V2",
...
}
...
}
And sure enough the names show up as expected in each plugin:
So I'll go ahead and close this since it's not actually a problem with the plugin. But at least now we know in case someone comes across the issue again.
Hey @ThioJoe thanks for the info - this was quite an interesting read 👍 I've never stumbled accross this issue before, but it's good to keep that in mind. Anyway - a big thanks for tracking this down! I really appreciate it! Other than that - did you find something else not working as expected?
btw - for the next beta I added a window where you can peek into your lights in 2 ways:
btw - for the next beta I added a window where you can peek into your lights in 2 ways:
- what the bridge sends (unmodified by the plugin)
- what the plugin stores This might help to figure out issues like this quicker @ThioJoe
Ah cool should come in handy 👍
Other than that - did you find something else not working as expected?
Nope haven't had any other issues at the moment
I noticed that several of my lights aren't showing the correct names in the new v2.0.0.38 - seemingly having been given generic names.
Here is what they show up as in the new one (wrong names marked):
Though there is another wrong one not shown that comes up as "New lamp 1"
Here's at least some of them with the correct names in the old v1.6.8 version:
The other ones in the wrong screenshot are elsewhere because of alphabetic order.
All the ones with the names "Hue color lamp" and "New lamp 1" are all A19 RGB bulbs. The "hue color downlight" ones are BR30 type bulbs 1200 lumens.
I keep a spreadsheet with all my bulbs to keep track of them and this is the info about the ones with the wrong names. There's not really a definitive pattern other than I had added them relatively recently. But there are others I added just as recently that don't have the same issue.