Deconz-rest-plugin: Feature request: support power-on defaults for OSRAM lights

[ebaauw]

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.

[stale[bot]]

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.

[ebaauw]

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.

[manup]

I think Ikea also might support this

[ebaauw]

I think Ikea also might support this

Source?

[manup]

Level control cluster attributes suggest that when I recall correctly, but I haven't tested if it works.

[ebaauw]

There's two different issues (I had them confused as well):

• How the light behaves when turning on, while it has remained powered (issue #149). This is set through the _On Level_ and _OnOff Transition TIme_ attributes of the _Level Control_ cluster. The Hue lights don't support these, and behave as if they're set to 255 (previous level) and 4 (0.4 sec transition time). Most other lights (OSRAM, IKEA, ubisys, innr) support these, but with different default values, so you want to set them to the Hue values, so all your lights behave similarly. These attributes are stored in volatile memory, so the values need to be written on pairing and after receiving a device announcement.
• How the lights behaves when powered on. Currently, the Hue lights come on at full intensity and some unholy colour temperature. OSRAM allows changing these power-on defaults through a manufacturer specific cluster. I've not seen anything similar this for other lights, but Philips / Signify have announced they will support setting another power-on default for Hue lights, see https://github.com/ebaauw/homebridge-hue/issues/41#issuecomment-436936220. I'm assuming it will be through an API enhancement, probably writing some manufacturer specific attribute.

[manup]

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.

[ebaauw]

hopefully Philips will go the standard route here.

I'm confident they will, the issue is more: which standard? ;-)

[manup]

Side note: the new hue developer docs describe the startup attribute:

https://developers.meethue.com/develop/hue-api/supported-devices/

[ebaauw]

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"
}

[stale[bot]]

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.

[intruder7777]

i would like reopen this request because power-on defaults for osram lights actually already not implemented

[ebaauw]

The general.xml from the above commit adds deCONZ GUI support, see #1833.

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).