Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: support power-on defaults for OSRAM lights #102

Closed
ebaauw opened this issue Aug 8, 2017 · 13 comments

Comments

@ebaauw
Copy link
Contributor

@ebaauw ebaauw commented Aug 8, 2017

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 comment has been minimized.

Copy link

@stale stale bot commented Nov 23, 2018

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.

@stale stale bot added the wontfix label Nov 23, 2018
@ebaauw

This comment has been minimized.

Copy link
Contributor Author

@ebaauw ebaauw commented Nov 23, 2018

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 manup added enhancement and removed wontfix labels Nov 23, 2018
@manup

This comment has been minimized.

Copy link
Member

@manup manup commented Nov 23, 2018

I think Ikea also might support this

@ebaauw

This comment has been minimized.

Copy link
Contributor Author

@ebaauw ebaauw commented Nov 23, 2018

I think Ikea also might support this

Source?

@manup

This comment has been minimized.

Copy link
Member

@manup manup commented Nov 23, 2018

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

@ebaauw

This comment has been minimized.

Copy link
Contributor Author

@ebaauw ebaauw commented Nov 23, 2018

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

This comment has been minimized.

Copy link
Member

@manup manup commented Nov 24, 2018

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

This comment has been minimized.

Copy link
Contributor Author

@ebaauw ebaauw commented Nov 24, 2018

hopefully Philips will go the standard route here.

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

@manup

This comment has been minimized.

Copy link
Member

@manup manup commented Nov 26, 2018

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

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

@ebaauw

This comment has been minimized.

Copy link
Contributor Author

@ebaauw ebaauw commented Nov 26, 2018

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 comment has been minimized.

Copy link

@stale stale bot commented Mar 26, 2019

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.

@stale stale bot added the stale label Mar 26, 2019
@stale stale bot closed this Apr 2, 2019
@intruder7777

This comment has been minimized.

Copy link

@intruder7777 intruder7777 commented Jul 3, 2019

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

@ebaauw

This comment has been minimized.

Copy link
Contributor Author

@ebaauw ebaauw commented Sep 8, 2019

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

manup added a commit that referenced this issue Sep 9, 2019
OSRAM power-on defaults, see #102, #1833.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.