Feature request from euf0ria on the Home Assistant forum thread. Raised there rather than here, so recording it properly with credit.
The request
This is now my favorite integration, huge fan of Douglas Adams work.
Some feedback for improvement:
Add config field for conditions
Why: Adds an alternative adaptation of Gregs quiet hours to match your regular automation blockers (and irregular life).
Example of conditions that must be met:
-switch.home_occupancy = on
-boolean.quite_hours = false
-input_select.home_mode = day
I use a few core conditions spread through all my automations to adapt the home to all situations (day, night, focus, guests over, not_home etc.). It would be great if Greg also took the same core conditions into account.
What it is asking for
Greg currently has exactly one way to be told to keep quiet: quiet_hours_enabled with a start and an end time, checked by _is_quiet_time() before he reacts or speaks.
A clock is a poor model of an evening. Guests arrive, somebody works late, the house is empty. euf0ria already keeps a small set of core conditions that every other automation in the house consults, and the ask is that Greg consults them too rather than keeping his own private idea of when it is night.
Why it is worth doing
It replaces a Greg-specific concept with the one the rest of the user's setup already runs on. Anyone who has built that pattern gets Greg respecting it for free, and anyone who has not keeps the existing time window and notices nothing.
It also covers a case quiet hours cannot express at all. "Not when the house is empty" is not a time range.
Where it would go
_is_quiet_time() in custom_components/greg/__init__.py is the single gate. Both _react and the existential timer already call it, so one check covers everything he does.- Config would sit alongside the quiet hours fields in the options flow.
- Home Assistant already has a condition validator and evaluator,
homeassistant.helpers.condition, which is what automations themselves use. Reusing it means accepting exactly the condition syntax people already know, including and, or and templates, rather than inventing a smaller language that will disappoint someone by the second week.
Open questions
- Alongside or instead of quiet hours? Alongside seems right. Anyone who has not written conditions keeps what they have, and both blocking would be the least surprising.
- How is it entered? A YAML condition block in the options flow is the honest answer for something this shaped, but it is a poor fit for the panel, which is where the rest of the settings now live. A simple entity/state row builder covers the three examples above and most real setups, at the cost of not covering everything.
- Does a blocked Greg still count disturbances? Quiet hours today stops him reacting at all. Worth deciding whether a condition block should behave the same way or let the tally keep running silently.
Credit
Requested by euf0ria. If this ships they should be named in the release notes.
Feature request from euf0ria on the Home Assistant forum thread. Raised there rather than here, so recording it properly with credit.
The request
What it is asking for
Greg currently has exactly one way to be told to keep quiet:
quiet_hours_enabledwith a start and an end time, checked by_is_quiet_time()before he reacts or speaks.A clock is a poor model of an evening. Guests arrive, somebody works late, the house is empty. euf0ria already keeps a small set of core conditions that every other automation in the house consults, and the ask is that Greg consults them too rather than keeping his own private idea of when it is night.
Why it is worth doing
It replaces a Greg-specific concept with the one the rest of the user's setup already runs on. Anyone who has built that pattern gets Greg respecting it for free, and anyone who has not keeps the existing time window and notices nothing.
It also covers a case quiet hours cannot express at all. "Not when the house is empty" is not a time range.
Where it would go
_is_quiet_time()incustom_components/greg/__init__.pyis the single gate. Both_reactand the existential timer already call it, so one check covers everything he does.homeassistant.helpers.condition, which is what automations themselves use. Reusing it means accepting exactly the condition syntax people already know, includingand,orand templates, rather than inventing a smaller language that will disappoint someone by the second week.Open questions
Credit
Requested by euf0ria. If this ships they should be named in the release notes.