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

Sending {"alert":"select"} changes color bulb to white #183

Closed
wvuyk opened this issue Sep 9, 2017 · 8 comments
Closed

Sending {"alert":"select"} changes color bulb to white #183

wvuyk opened this issue Sep 9, 2017 · 8 comments

Comments

@wvuyk
Copy link

wvuyk commented Sep 9, 2017

When I send an alert command to a color bulb I would expect it to flash shortly in the last set color, but through deCONZ the color always changes to white. If I do the same on the Philips bridge, the light stays at the last used color.
Can the alert command be changed, so a bulb stays at the last set color? Or could it honour the color settings if I send these with the same commmand. The combined command would be even better?

@ebaauw
Copy link
Collaborator

ebaauw commented Sep 9, 2017

See #100. The Hue bridge sends a Breathe command, followed by a Breathe Stop, 2 seconds later. deCONZ sends an Identify command, with the identify time as parameter. You can replay this in the deCONZ GUI using the Identify cluster. I already changed deCONZ to use a 2s identify time, as the Hue lights don't react to an identify time of only 1s.

@manup is reluctant to change the default behaviour, as not all lights might handle Breathe correctly. Rightfully so, as my innr UC110 and PL110 lights hang when receiving the Breathe Stop too soon after the Breathe, requiring a power cycle before they can be operated again.

I've been thinking about using different values for alert, e.g. "breathe" and "lbreathe" to mimic the Hue bridge behaviour, but I haven't found out yet in deCONZ how to handle the timing of issuing the Breathe Stop command.

@wvuyk
Copy link
Author

wvuyk commented Sep 9, 2017

Ok, I understand that then. But I am a bit reluctant on creating a "breathe" command for it. It would be there only for a bulb of brand Philips and would break the generic character for deCONZ maybe. I think I could work around this issue of Philips inside my plugin itself if needed.
If you all decide it should be there, I will also use it, but if you decide otherwise I can live with that as well.

@ebaauw
Copy link
Collaborator

ebaauw commented Sep 9, 2017

Breathe is not Philips specific, it's defined in the ZCL standard (as an Effect to the Trigger Effect command):

The Trigger Effect command allows the support of feedback to the user, such as a certain light effect. It is used to allow an implementation to provide visual feedback to the user under certain circumstances such as a color light turning green when it has successfully connected to a network. The use of this command and the effects themselves are entirely up to the implementer to use whenever a visual feedback is useful but it is not the same as and does not replace the identify mechanism used during commissioning.

The last part is the catch: different manufacturers implement this differently. And some light firmware contains bugs, which only surface when pairing the light with a bridge/gateway from another manufacturer that uses a different command to achieve more or less the same (remember the OSRAM lights not turning off unless you'd explicitly specify a transitiontime of 0).

and would break the generic character for deCONZ maybe.

By that argument deCONZ shouldn't be supporting the Hue dimmer switch either. That's using manufacturer-specific extensions for the button events (albeit within the boundaries set by the standard).

@wvuyk
Copy link
Author

wvuyk commented Sep 9, 2017

Ok, if is part of the ZCL standard then I am not protesting, but I did get the feeling this might have been a Phiips trick outside the standard. Then we have to work around the different intepretations, like osram... same woraround is in the plugin here...

@ebaauw
Copy link
Collaborator

ebaauw commented Sep 9, 2017

OK, with PR #186, you should be able to get the same effect as {"alert": "select"} from the Hue bridge by issuing {"alert":"breathe"} followed by {"alert":"finish"}. For {"alert": "lselect"}, just leave out the finish.

@wvuyk
Copy link
Author

wvuyk commented Sep 9, 2017

Thanks! Will try this soon. But as I understand, use only on tested brands, untested stays on the old standard "select", right?

@ebaauw
Copy link
Collaborator

ebaauw commented Sep 9, 2017

My Philips, OSRAM, IKEA lights, and even my regular innr bulbs all respond normally to Breathe (though not all in the same way). It's only the control box for the innr xx110 that hangs when it receives a Finish (or was is Stop?) too early after a Breathe. From the innr service pages (under Miscellaneous):

Philips Hue 'Identify' function:
If you click on a lamp from the overview in the Hue app under Settings and Light Management it 'winks' at you (identify). This is useful to understand which light from the list corresponds to the light in your home.

Problem:
Some Innr lights* get confused of giving the wink. The light gets stuck on a low dim setting and can no longer be controlled via the Hue App. In practice, this happens only during installation.

  • applies to the following model numbers: FL 110 Flex, PL 110 Puck, ST 110 Strip, UC 110 Cabinet, SL 110 Spot and DL 110 Spot.

Solution:
Disrupt the power for a short period from the Innr lamp and reconnecting it will allow the innr light to function properly.

@manup
Copy link
Member

manup commented Sep 17, 2018

Closing the oldest issues for know to tidy up the tracker and duplicates in newer issues.

@manup manup closed this as completed Sep 17, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants