White Ambiance (E14 / Candle) blink animation error

[caseda]

When activating the blinking animation (both short and long) on the new White Ambiance (E14 / Candle) it will report back the error that it is not available 6, parameter, effect, not available, but still activates the animations.

This might also be the case for the color ones, but am unable to test that, as I only have the white ambiance currently.

[sqmk]

Are you updating these lights through group or light commands? Can you give me example code? It's odd that the lights will still fire animations after the bridge reports the effect not being available for them.

[caseda]

They are updated through light commands, though i'm not exactly sure where to look at in the code to give you a straight example, as i'm not the writer and not knowledgeable enough with this nodeJS scripting yet: https://github.com/athombv/nl.philips.hue

Why would the bridge say it is not available though, as it clearly is. So that might make it even an hue bridge issue?

Perhaps @WeeJeWel can give an extra hand in this though.

[sqmk]

The maintainer of that module will need to chime in with a code example of how those lights are being updated, and we can then determine if this is a bridge bug or not. I’m inclined to believe that Huejay is working as expected.

[WeeJeWel]

Ah, the code sets 'effect' no 'none', and blink is not an effect, but an 'alert'.

Is there a way to figure out if effects are available beforehand?

[sqmk]

The list of available effects:

• colorloop (not sure if this is available for all bulbs, white only might just change brightness?)
• none

The list of available alerts (which should be available to all bulbs, afaik):

• none
• select
• lselect

If the effect attribute is being configured with select/lselect, that would make sense that the bridge is throwing the error. However, if the bridge is still invoking alert when effect is updated, that would be a bridge bug.

[WeeJeWel]

Thank you. What I meant was if we can determine programmatically if a device is effect-capable.

[sqmk]

I don't think we can get that information from the bridge, but COULD infer the feature set for the light by way of the light's type (light.type) or the information I abstracted out in the light models (light.model.type, light.model.colorGamut).

If we wanted to go further with this, we could modify lib/LightModel/AbstractLightModel.js with a convenience method that returns a list of available effects (.getEffects()), and would return an array consisting of colorloop and/or none, or returns undefined if the effect isn't available for that light model. The values returned would be based on the model's type and/or colorGamut values, or could be overloaded by individual models if there is a special effect or abnormal event list for each.

However, the above wouldn't work out so well with group alert/effect property updates, as a mix of lights (color and white) would yield a different set of effects.