Change event state back to 'Unknown'
Closed this issue · 4 comments
Hi,
I was just wondering if there was a way to set the event state from eg. "1_hold_up" back to "Unknown" or something similar. Something happened(not sure what but maybe the Hue Bridge reset itself during the night) and the automation that runs when "1_hold_up" is pressed on my dimmer switch activated, turning on all my lights and TV on at 3am as per my automation.
I think the Hue Bridge or Home Assistant thought after it booted back up that I repressed those buttons?
Also is there a way of grouping all these to make the integrations page look cleaner:
Thanks for a great int!
Hi @oneseventhree, could you share the yaml for that automation that triggered at midnight? (btw, 😱)
It would help a lot to diagnose what happened there...
Also, do you have a "Fetching error" for the hue integration in your logs for the time that happened? (or an "unavailable" point around that time in any of the battery sensors for the remotes)
I see you're using the "Fast-Hue" CC, what update interval where you using when the error happened? a very short one?
if there was a way to set the event state from eg. "1_hold_up" back to "Unknown" or something similar
Well, to retain an event as a persistent state is the basic objective of the CC, so reseting it had not much sense when implementing it...
Anyway, that should not be related at all with your issue: the event sensor only updates the state when a new event is received, there are no more 'state_changed' events emitted for this sensor, so if your automation trigger is looking at the event sensor state, and it changed, that's because the hue integration fired the event, so we should investigate why that happened in the first place.
I don't suffer from hub resets of that kind, so I'm kind of blind here :(, any extra info would be appreciated.
About the automation trigger, I personally suggest to use device triggers for that, better than state changes, and this CC is not needed for that.
If not, the state trigger must avoid the "to" field (to trigger with repeated presses), and filter the button press in conditions, so in the end more complex than the device trigger.
About the GUI mess:
Also is there a way of grouping all these to make the integrations page look cleaner
See the discussion going on #5
Hi @oneseventhree, could you share the yaml for that automation that triggered at midnight? (btw, 😱)
It would help a lot to diagnose what happened there...
Also, do you have a "Fetching error" for the hue integration in your logs for the time that happened? (or an "unavailable" point around that time in any of the battery sensors for the remotes)
I see you're using the "Fast-Hue" CC, what update interval where you using when the error happened? a very short one?
if there was a way to set the event state from eg. "1_hold_up" back to "Unknown" or something similar
Well, to retain an event as a persistent state is the basic objective of the CC, so reseting it had not much sense when implementing it...
Anyway, that should not be related at all with your issue: the event sensor only updates the state when a new event is received, there are no more 'state_changed' events emitted for this sensor, so if your automation trigger is looking at the event sensor state, and it changed, that's because the hue integration fired the event, so we should investigate why that happened in the first place.I don't suffer from hub resets of that kind, so I'm kind of blind here :(, any extra info would be appreciated.
About the automation trigger, I personally suggest to use device triggers for that, better than state changes, and this CC is not needed for that.
If not, the state trigger must avoid the "to" field (to trigger with repeated presses), and filter the button press in conditions, so in the end more complex than the device trigger.About the GUI mess:
Also is there a way of grouping all these to make the integrations page look cleaner
See the discussion going on #5
Hi @azogue, firstly thanks for a great CC. It has really helped when migrating from Hue Remotes.
I tested my problem by turning of my Hue Bridge and rebooting it as well as resetting Home Assistant and the problem did not occur again - I even turned my RBpi off. So I am not sure what caused all the remotes to trigger when something was rebooted.
I wasn't using Fast-Hue when the problem occured as I only found out about it the day after.
The automation that was trigged was for all my remotes.
eg. The last press on one of my dimmer remotes was "3_click" which turns on all my lights and my TV. So this was triggered after the remote.
My OTHER remote last press was "1_click" and this turns on the lights to blue in my home office so when I woke up those lights were blue.
So whatever the last button press was on all of 5 remotes were triggered after the unknown reboot occurred.
Let's put a pin it it for now and I'll see if it happens again - I am hoping it was just a one off glitch that doesn't involve your CC.
Now for the triggers, are you saying instead of this:
I should have this instead?
Also, in relation to the GUI mess, these are some of the integrations that bundle all the entities together in 0.108:
It would just be great if Hue added in the entities themselves instead of it showing as events only
I tested my problem by turning of my Hue Bridge and rebooting it as well as resetting Home Assistant and the problem did not occur again - I even turned my RBpi off
That is the expected behavior, as for all those scenarios no new hue_event should be triggered, that's why I was asking for details, as what happened to you is kind of weird :)
BTW, if you are using the recorder, or any other database (like influx) you could retrieve the details of what happened at that moment by querying the event sensor states in that time window.
It sounds like all event sensors received some data (which made the state change to something else) and then they received the original data, generating 2 "state changed" events for each, being the 2nd the one which triggered your automations. That situation was happening for hass-hue-remotes CC when the hub went unavailable, but shouldn't happen here, as we listen to events.
Let's put a pin it it for now and I'll see if it happens again - I am hoping it was just a one off glitch that doesn't involve your CC.
Ok then. As the code goes, if something strange happened, it was in the hue integration for sure, when reading the info in the hue hub (the code in this CC is very simple, just an event listener).
Now for the triggers, are you saying instead of this:
I should have this instead?
Yes, exactly that. The "device triggers" are internally specific event listeners, but much easier to configure :). That one would trigger n times in a row (if pressing repeatedly the same button), and won't fail with battery oscillations or other anomalies.
Also, in relation to the GUI mess, these are some of the integrations that bundle all the entities together in 0.108:
I know there are a lot :), it's not a problem of examples, but how they work internally with the config and options flows, and more details. See the discussion in #5 (and comment there about this, so we don't go off-topic here)
Anyway, the integrations UI is changing fast right now. If you read the description of HA 0.109 you'll see there are plans to group these in the near future, so no need to make code changes on the CC side for now.
closing this one, as it relates to:
- Fixing the UI for many sensors (#5), already solved on HA Core
- Implementing a way to revert/expire the sensor state, which doesn't have much sense for an event listener, IMO, as it would generate extra
state_changedevents (not paired with fired events), and anyway it's a thing that can be accomplished generically for any HA entity with a REST POST (set any state value with an API call or HA service call)