Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upFeature request: support power-on defaults for OSRAM lights #102
Comments
This comment has been minimized.
This comment has been minimized.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This comment has been minimized.
This comment has been minimized.
Please keep this on the list. It will be very relevant this fall, with the expected new firmware for the Hue bulbs finally allowing a power-on setting. |
This comment has been minimized.
This comment has been minimized.
I think Ikea also might support this |
This comment has been minimized.
This comment has been minimized.
Source? |
This comment has been minimized.
This comment has been minimized.
Level control cluster attributes suggest that when I recall correctly, but I haven't tested if it works. |
This comment has been minimized.
This comment has been minimized.
There's two different issues (I had them confused as well):
|
This comment has been minimized.
This comment has been minimized.
Thanks for clarification indeed I thought the first was directly related to the second. I'm not 100% sure but I think for the power-on behavior the ZCL Ballast Control cluster provides some useful attributes but it isn't used by OSRAM, hopefully Philips will go the standard route here. |
This comment has been minimized.
This comment has been minimized.
I'm confident they will, the issue is more: which standard? ;-) |
This comment has been minimized.
This comment has been minimized.
Side note: the new hue developer docs describe the https://developers.meethue.com/develop/hue-api/supported-devices/ |
This comment has been minimized.
This comment has been minimized.
Interesting. They don't mention it on the Lights API page. It is mentioned in the changelog. Last weekend, I updated my Hue bridge to the latest firmware (API version 1.28.0), and paired a Hue LCT003 extended color spot (to see if the firmware for the light would already be available - not). It didn't show a config.startup (my sorting): {
"capabilities": {
"certified": true,
"control": {
"colorgamut": [
[
0.675,
0.322
],
[
0.409,
0.518
],
[
0.167,
0.04
]
],
"colorgamuttype": "B",
"ct": {
"max": 500,
"min": 153
},
"maxlumen": 250,
"mindimlevel": 5000
},
"streaming": {
"proxy": true,
"renderer": true
}
},
"config": {
"archetype": "spotbulb",
"direction": "downwards",
"function": "mixed"
},
"manufacturername": "Philips",
"modelid": "LCT003",
"name": "Hue color spot 1",
"productname": "Hue color spot",
"state": {
"alert": "none",
"bri": 254,
"colormode": "ct",
"ct": 366,
"effect": "none",
"hue": 14988,
"mode": "homeautomation",
"on": true,
"reachable": true,
"sat": 141,
"xy": [
0.4575,
0.4101
]
},
"swupdate": {
"lastinstall": null,
"state": "noupdates"
},
"swversion": "5.105.0.21536",
"type": "Extended color light",
"uniqueid": "00:17:88:01:10:3c:9d:0a-0b"
} |
This comment has been minimized.
This comment has been minimized.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This comment has been minimized.
This comment has been minimized.
i would like reopen this request because power-on defaults for osram lights actually already not implemented |
This comment has been minimized.
This comment has been minimized.
The Luckily, the bulb seems happy with a standard (non-manufacturer-specific) 0x01 command to the manufacturer-specific 0xfc0f cluster. Note the mismatch between the manufacturer code in the node descriptor (0xbbaa) vs that in the sniffed command (0x110c). |
Could we support setting the power-on defaults of an OSRAM light from the deCONZ REST API? I'd imagine a syntax like PUT /lights/xx/config/poweron with a body of
{"bri":xxx, "ct":xxx}
.Sniffing around the OSRAM gateway, it looks like it issues a 0x01 command to the 0xFC0F cluster to store the power-on defaults (packet 691). Before that, it issues an On command to the 0x0006 cluster (packet 683), and a 0x0A command to 0x0300, with the current colour temperature as data (packet 687). The same sequence in 311, 315, 317.
Attached the BitCatcher log file:
osram.dcf.gz
You probably need the network key as well: CB:2D:00:A0:72:EA:FF:63:03:5E:D5:95:41:36:83:24.
Note that BitCatcher starts counting packets at 0, but WireShark at 1, so add 1 when viewing with WireShark.