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]

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 ebaauw/homebridge-hue#41 (comment). 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]

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

[7wells]

@ebaauw
Erm, sorry to ask, but it remains unclear to me after reading all this:
How would I set values (light temperature and brightness) for an OSRAM Lightify/Smart+ E27 bulb to be used when electricity went off and comes back on again? I assume I have to do this in deconz (not in phoscon) but am still not clear where exactly in deconz this is set. Of course I do not expect a full guidance, but a hint which tab to visit and which code to use would be great. Thank you! 👍

PS: I came here after your kind hint over at discord:

OSRAM has a proprietary command on the 0xFC0F cluster to store the current state as power-on state

[7wells]

In deconz, I see for one of my "OSRAM Extended color lights" in the "Node Info" tab a section "Power Descriptor":
Power Mode: On When Idle
Power Source: Mains
Power Level: 100%

I can overwrite e.g. the 100% with 90% but the value gets reverted to 100% shortly after, so this did not work. And how about the light temperature? I do not see anything there (despite the light is a "tunable white" bulb).

And I have not understood what is meant by "proprietary command on the 0xFC0F cluster to store the current state as power-on state". Once more, thanks for your help! :)

[ebaauw]

Set the current state however you want: in Phoscons, in deCONZ, through your favourite API client. Then in the GUI open the Cluster Info panel and select the FC0F cluster on the OSRAM bulb, and press the button to execute the Store Power-On Defaults command. Wait a minute or so before testing it; it takes the light some time to write the non-volatile memory.

[7wells]

@ebaauw
Very good - thanks for your helpful advice. 😄 First I did not know that I first have to click on the right one of the two radio buttons of the device in order to see something on the Cluster Info panel. 😊 The execution of e.g. the Osram mini garden pole was successful, same as for a night light. There is no (future) possibility to get this done directly in phoscon? Because it is manufacturer-specific?

[ebaauw]

Because it isn't exposed by the REST API. Neither is the (more or less?) standard setting.

Typically you do these settings only once, after pairing the light, so very low priority for API support. I have no compassion for the fools folks who still think it's a good idea to run deCONZ without the GUI.

[7wells]

Thanks for the explanation. I use deconz with its GUI, and I agree with you that these settings are rather not done multiple times.

[ebaauw]

though it sticks
And I do use deconz with its GUI

Sorry, I wasn’t referring to you, as, obviously, you are indeed running the GUI. It’s intended as a pre-emptive strike at the next request to enable this through the API and/or Phoscon, because they don’t run the GUI.