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 · 20 comments
Closed

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

ebaauw opened this issue Aug 8, 2017 · 20 comments

Comments

@ebaauw
Copy link
Collaborator

@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
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
Copy link
Collaborator 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
Copy link
Member

@manup manup commented Nov 23, 2018

I think Ikea also might support this

@ebaauw
Copy link
Collaborator Author

@ebaauw ebaauw commented Nov 23, 2018

I think Ikea also might support this

Source?

@manup
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
Copy link
Collaborator 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
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
Copy link
Collaborator 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
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
Copy link
Collaborator 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
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 as completed Apr 2, 2019
@intruder7777
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
Copy link
Collaborator 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).

@7wells
Copy link

@7wells 7wells commented Mar 13, 2021

@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
Copy link

@7wells 7wells commented Mar 13, 2021

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
Copy link
Collaborator Author

@ebaauw ebaauw commented Mar 13, 2021

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
Copy link

@7wells 7wells commented Mar 24, 2021

@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
Copy link
Collaborator Author

@ebaauw ebaauw commented Mar 24, 2021

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
Copy link

@7wells 7wells commented Mar 25, 2021

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
Copy link
Collaborator Author

@ebaauw ebaauw commented Mar 25, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants