ghost / unexpected hue dimmer events #99125
Comments
|
Hey there @balloob, @marcelveldt, mind taking a look at this issue as it has been labeled with an integration ( Code owner commandsCode owners of
(message by CodeOwnersMention) hue documentation |
|
I have the same here, my gate is now opening at random times :-) so I had to remove the autmations |
|
can you show your automations? |
|
I saw the same issue twice as well, hue_events are triggered randomly and I figured out that it happened both times at rougly quarter past 2pm. 2pm is the time my hue bridge was configured to perform automatic updates. Didn't see the issue anymore since I disabled the updates. First time it happened 22nd of August 2:16pm, second time 8th of September 2:21pm. Update: The release notes page shows a new software release on the 16th that could fit my occurance on the 22nd. There is nothing shown on the 8th though (https://www.philips-hue.com/de-de/support/release-notes/bridge). |
For me, almost exactly the same first time was on August 18th. |
|
Interresting is also that the latest software version according to release notes should be 1.59.1959194030 but my bridge has already 1.59.1959194040 installed (likely there was a second update that is not in the release notes). Chances are high that the issue is triggered either by an update or restart of the bridge. |
|
Indeed, mine was around 3h15 while my bridge auto updates on 3h. Now I dare to turn on my automation again.. 🤣 |
|
Thanks for the feedbacks. I also noticed that these issues happened shortly after the bridge auto update time. So it's highly likely to be related to the bridge update. It would be great if aiohue was able to detect such condition and inhibit firing ghost dimmer events when that happens. Nevertheless there is a workaround, I'll update the bridge manually for now. |
|
What I just was thinking about, |
|
I'm having the same problem with ghost events. |
|
I too have been noticing this issue but it has taken me a while because I thought it was Homekit at first since I had just setup Homekit integrations. So I disabled all of that stuff thinking Apple was turning my lights on and off. Then I disabled Alexa. Then I disabled Google Home. Now I just have some lights on the Hue bridge, using the Hue integration, and it's STILL happening. I'm not sure if it was the update to HA or recent firmware updates to the bridge, but I have and have always had auto-update disabled. Once I power cycle the Hue hub, things seem better for a few days, but then they returned today, so I'm not sure what is going on anymore. There is nothing in the logs to point me to anything... so far. I did just turn on debugging for the Hue integration in hopes of seeing something next time. |
|
I have also seen this behaviour when the bridge gets updated. I have 2 Hue Bridge's in use in my environment and I changed the Automatic updates on one to be 5 hours after the the other. Today I received a new update for the Hue Bridge and saw ‘hue_event’ at 5am and 10am as the Bridge was updated. Today my bridge updated from 1.59.1959194030 to 1.60.1960062030 but there are no release notes on the Hue website at the moment for 1.60.1960062030 |
|
I also have the same issue as described here with "ghost" hue button presses triggering around 3am BST (hue hub is set to update 2am - GMT I guess). I have 6 Hue switches ("Hue dimmer switch (RWL022)") with one of the buttons toggling AC in each room. So we now have the AC turning on seemingly randomly overnight. When I looked at logs in the past there was not much to report. This happened again last night coinciding with the Hue hub update @rbp1987 mentioned. The triggers don't happen straight away
Similar log event as flagged in the issue by @spasche Logs around room A/B trigger Logs around room C trigger Logs around room D trigger There wasn't any logs around room E or F trigger oddly... so hard to know if theses errors in the logs are a distraction or not. |
|
I just experienced this now, with the same log lines reported by others. Hue update is set for 3am. |
|
Having exactly the same. I am using two dimmer remote to control light, tv (with a smart plug) and music in my bedroom. it drives me crazy because lights turn on in the middle of the night and the tv goes off while watching. It seems to start a little later than the auto update in hue app so I disabled the auto update. I also think about hooking the remotes to Z2M so I’m not using the hue hub anymore until there is a real fix. |
|
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
issue-triage-workflows
bot
closed this as not planned
|
I think it's still an open issue.. |
|
Yes I still have the issue as well |
|
Same |
|
Still an issue, |
|
Since this issue is driving me crazy I spend some time debugging and analysing. :) At first I thought it is the Hue bridge sending out button-press events, but it is not. Well, not exactly anyway. Notice that both the Digging through the code I found that aiohue is actually first 'merging' the event with the 'cached' state before the merged resource is processed as event: https://github.com/home-assistant-libs/aiohue/blob/main/aiohue/v2/controllers/base.py#L227 I think this is wrong. Especially for event/command based events. For whatever reason the bridge is telling subscribers that some properties inside the button resource (may) have changed value, but since it is not saying anything about It is kind of questionable why the bridge sends update-events for button resources without any changes, but imagine there would be other changeable properties in the button resource, or maybe even inside the Long story short: I think the received event should be used for event processing and the merged resource can be used to maintain a complete view on the actual state. I think it relates to this feature request: home-assistant-libs/aiohue#136 |
|
It is not wrong, the state has changed and we send a full object further down the chain. So we should just translate this into our own truth and only care for the attribute that actually changed. |
No that is unrelated, its about receiving the raw events. It wont solve anything as HA is reacting on the event as a whole (so also if some attribute updates). We should either introduce the concept of a "button pressed event" in the aiolibrary or do some more filtering in HA. The simplest solution would be to store the previous button value in HA and compare it when the event comes in. That way you explicitly know the difference between " the button object updated" and "a button was pressed" |
|
I'll have a look at this again tomorrow, I have been very busy with other stuff so this one got a bit forgotten. I'll chew a bit on it if I'm going to implement some custom logic for button events in the aiohue lib or just compare the last button state in HA. Still. its crap that the hue bridge sends an attribute changed event (while no attributes changed!) after/when its updating the firmware |
That's the thing, it didn't change. The update-event is just repeating what was already known. If you would compare the state before and after merging, they would be the same. For button-events you cannot really compare states either, because after the first I agree the bridge should not send events for things that haven't changed, but as long that this doesn't happen for the (physical) button (press) and rotary properties itself there shouldn't be a functional problem. You're correct in saying that Hue does not communicate "a button has been pressed", but indeed communicates "some attribute has been changed". But if you look at events from a stateless system point of view, you can use events to know when "a button has been pressed" and that's when an update event is send with I'm not familiar with how Home Assistant handles events upstream. Maybe you need special handling for button (and rotary) events based on the RAW event content and the existing handling for others. |
|
Exactly, I will add that soon. Requires a bit less of refactoring but that should fix it for good. So a little bit more patience please |
|
Is it fixed? :-) THX btw! |
|
I'm not convinced this fixes the ghost events seen after a bridge update. As mentioned earlier, aiohue merges the incoming event with the cached state which is then passed to the home assistant integration, so if the cached state has a |
The problem
Since 2023.8.x I'm getting unexpected hue dimmer events (i.e. events that trigger when the dimmers were not activated since several hours).
This happens very seldomly, such as 2-3 times a week.
I have automations that respond to dimmer events, that's why I notice some very strange behaviors (in addition to having lights turn on unexpectedly).
When the issue happens, I get many ghost dimmer events in a short timeframe.
What version of Home Assistant Core has the issue?
2023.8.4
What was the last working version of Home Assistant Core?
2023.7.x (not 100% sure though)
What type of installation are you running?
Home Assistant Container
Integration causing the issue
Philips Hue
Link to integration documentation on our website
No response
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
Yesterday the issue happened, and I can see the following errors in the logs: 2023-08-26 14:48:12.138 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved Traceback (most recent call last): File "/usr/local/lib/python3.11/site-packages/aiohue/v2/controllers/sensors.py", line 57, in _handle_event await super()._handle_event(evt_type, evt_data) File "/usr/local/lib/python3.11/site-packages/aiohue/v2/controllers/base.py", line 257, in _handle_event callback(evt_type, cur_item) File "/usr/src/homeassistant/homeassistant/components/hue/event.py", line 101, in _handle_event self._trigger_event(resource.button.last_event.value) ^^^^^^^^^^^^^^^^^^^^^^^^^^ AttributeError: 'NoneType' object has no attribute 'last_event' 2023-08-26 14:54:35.074 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved Traceback (most recent call last): File "/usr/local/lib/python3.11/site-packages/aiohue/v2/controllers/sensors.py", line 57, in _handle_event await super()._handle_event(evt_type, evt_data) File "/usr/local/lib/python3.11/site-packages/aiohue/v2/controllers/base.py", line 257, in _handle_event callback(evt_type, cur_item) File "/usr/src/homeassistant/homeassistant/components/hue/event.py", line 101, in _handle_event self._trigger_event(resource.button.last_event.value) ^^^^^^^^^^^^^^^^^^^^^^^^^^ AttributeError: 'NoneType' object has no attribute 'last_event' 2023-08-26 14:54:35.075 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved Traceback (most recent call last): File "/usr/local/lib/python3.11/site-packages/aiohue/v2/controllers/sensors.py", line 57, in _handle_event await super()._handle_event(evt_type, evt_data) File "/usr/local/lib/python3.11/site-packages/aiohue/v2/controllers/base.py", line 257, in _handle_event callback(evt_type, cur_item) File "/usr/src/homeassistant/homeassistant/components/hue/event.py", line 101, in _handle_event self._trigger_event(resource.button.last_event.value) ^^^^^^^^^^^^^^^^^^^^^^^^^^ AttributeError: 'NoneType' object has no attribute 'last_event' 2023-08-26 14:54:35.076 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved Traceback (most recent call last): File "/usr/local/lib/python3.11/site-packages/aiohue/v2/controllers/sensors.py", line 57, in _handle_event await super()._handle_event(evt_type, evt_data) File "/usr/local/lib/python3.11/site-packages/aiohue/v2/controllers/base.py", line 257, in _handle_event callback(evt_type, cur_item) File "/usr/src/homeassistant/homeassistant/components/hue/event.py", line 101, in _handle_event self._trigger_event(resource.button.last_event.value) ^^^^^^^^^^^^^^^^^^^^^^^^^^ AttributeError: 'NoneType' object has no attribute 'last_event'Additional information
No response
The text was updated successfully, but these errors were encountered: