Innr GU10s with Hue flashing and random weirdness

Configuration
1

I have a mix of Innr GU10s and Philips Hue GU10s.
When I turn on individual Innr bulbs or a hue group the lights do weird things like flash full brightness then settle back down to say 70% and the same when turning them off, flash dim, full off etc. Dimming the bulbs is even weirder, they are random and slow to respond and generally very unpleasent to use.
I’ve noticed though that not all Innr bulbs are doing this, some on firmware 2.0 do and some on firmware 2.1 don’t and behave much like the Hue bulbs.

The problem is that this didn’t use to happen, they all worked smoothly until a few HA upgrades back.

It seems that HA is sending some additional commands when ttriggering the hue lights and groups, like a flash or something. I’ve tried editing the entities for the affected bulbs and disable things like effects, color, random etc. but no difference.

It’s important to mention that controlling any of these bulbs via the Hue app on my phone is perfect, no weirdness, delays, flashing or other anomalies with any of the Innr bulbs so this looks to be specific to how HA is triggering the bulbs via Hue.

Has anyone else experienced this or know of a fix?

1 Like
2

As said here I have the same problem:

What is interesting in this post is that is says this was not a problem in earliyer versions.

Any chance that somebody looks into it? It’s really annoying. If I had knewn that I would have bought Osram, they don’t show this behaviour, but now most of my bulbs are innr, would be expensive to exchange them all.

3

Same issue. No idea of a fix, odd behaviour. It’s not the hue api from what I’ve discovered. It only happens in ha

4

I’ve got the exact same Problem. I use a Hue hub (2nd generation). My Philips Hue bulbs behave fine. My Osram bulbs also behave fine. But my innr bulbs always flash to 100% brightness before dimming to the desired brightness, which is quite annoying. When I control the lights with any Android app, the innr lights work correctly, so I also think this must be an HA issue…

5

Same problem here. Home-assistant (docker stable), with Hue Bridge v2 and Innr Lights.
The Problem is, the HA send the PUT requests with the “alert”-flag with value “none”. The result, every change of the light via HA force the light to flash up. (yes be none, the light is flashing).

Here the HTTP request and response from the bridge.

PUT /api/XXX/lights/11/state HTTP/1.1
Host: 192.168.201.225
User-Agent: HomeAssistant/0.102.3 aiohttp/3.6.1 Python/3.7
Accept: */*
Accept-Encoding: gzip, deflate
Content-Length: 29
Content-Type: application/json

{"on": true, "alert": "none"}

HTTP/1.1 200 OK
Server: nginx
Date: Tue, 10 Dec 2019 17:24:11 GMT
Content-Type: application/json
Connection: close
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Expires: Mon, 1 Aug 2011 09:00:00 GMT
Access-Control-Max-Age: 3600
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: POST, GET, OPTIONS, PUT, DELETE, HEAD
Access-Control-Allow-Headers: Content-Type
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'self'
Cache-Control: no-store
Pragma: no-cache

[{"success":{"/lights/11/state/on":true}},{"success":{"/lights/11/state/alert":"none"}}]

The hue lights does nothing when alert=none, innr is flashing one time.
can we drop the flag, when the value is none?

1 Like
6

Fix send upstream: https://github.com/home-assistant/home-assistant/pull/29828

7

The most recent version of Homeassistant included a fix for this Innr flashing but unfortunately it doesn’t work and has now introduced about 2s delay in turning on the lights.

8

The version of the fix that made it into HA 0.104 really does not work completely. Earlier pull requests for the fix by InuSasha (which where unfortunately rejected) in fact did work…
I guess that the problem lies around line 261 (if is_group:) of homeassistant/components/hue/light.py. All my innr lights are part of light groups, so the ifs in lines 425 and 458 don’t have any effect…

As a temporary workaround I’ve removed the following code lines from the file:

        elif not self.is_innr:
            command["alert"] = "none"

(lines 425 and 458)

This doesn’t seem to have a negative effect on any of my lights (Philips, Osram, innr and Müller)

9

It seems to be working fine for me in .104, not seeing any issues with delays turning on. I’ve tried via the motion sensor and using ha.

10

So I’ve removed both of those lines from light.py and woohoo, no flashing Innr bulbs on state change for the first time in about 6 or 8 months :slight_smile:
The delay in switching on lights also seems to have disappeared. No observable issues with any of the other Philips GU19 bulbs since this change either.

Why would they have refused the PR with this fix if it solves the problem and doesn’t seem to cause any other issues? Just doesn’t make sense.

Is there any way we can override this alert=none from within Homeassistant by customizing the entity?

11

I have the same problem, if the bulb is toggled directly then there is no flashing and the work that InuSasha did works perfectly. But if the bulb is part of a group then the flashing bulb problem still occurs. Editing homeassistant/components/hue/light.py lines 361 and 362 to comment them out as per tiger42’s instructions (different line numbers for some reason) has worked.

@InuSasha is there anything that can be done for Innr lights when they are part of a group?

12

@tanc It is not possible to differ between different type of lights, when they are in a hue-group.
But for some lights, the alert-field has to be set, and for some (innr) it has to be unset…
My solution is: i mange my lights in lights-groups in HA and not in hue-groups

13

I got a similar problem: I have the latest version of hassio running. Recently I have enabled integration with the Philips Hue bridge v2.0, with 2 philips led lights connected. This integration results in a blinking philips led lights after a while, meaning: it could be stable for an hour or so but all of a sudden the lights start blinking. I have now removed the integration temporary and it seems to be stable. Any idea how this issue can be caused?

14

Hey folks, I have a similar issue here but with different brand lights connected to my hue hub V2.

Would anyone be able to help with a fix or some troubleshooting to confirm either way?

Thanks.

Pete

15

Good Day, I am still experiencing the same problem. Turning on an INNR light from the turn light on service with specific birghtness and color, flashes to latest brightness first

16

Has this been released into the production builds yet? I’m seeing the same issue with some Innr bulbs on 2021.5.5?

Thanks!

Gareth

17

Nah, it was never fixed. Never taken seriously as an actual “issue”. I ended up just copying the hue component to a custom component and removing the two offending bits of code. Never an issue since.

18

Ah I see, dull. Have just attempted the same, downloaded the zip of the release I’m on, edited the .py file as described. Then created a folder called hue custom under the custom_components folder. HA sees it, but when I try to load it I get an error stating “config flow could not be loaded”, nothing obvious in the logs. Anything else you needed to do to get this working other than change those two lines?

Thanks!

19

The only difference is that I copied the hue folder from the local hass install instead of extracting it from the downloaded zip file.

Have you tried it as an unmodified custom component? Just to rule out the edits as the issue.

20

Downloaded a fresh copy and tried it again, worked this time. Thanks!

However, still seeing some odd behaviour with my GU10’s. Might give zigbee2mqtt a go and see if I can ditch the hue hub. Would be great to only have 1 network, and get away from the hue hub bottleneck.