So I sat and thought about this. Then I put it on the back burner for a while, and then thought about it some more. Then I asked Claude to analyze the problem for me to find whatever I’d missed, which turned out to be quite a bit, depending on how, ah, klugy we want to go. But that’s why it’s taken me a while.
Current Design
So you’ve seen my current minimalist approach, which implements only current state and ack/unack, and does it by squeezing them both into one switch - basically replicating the Alert 1 behavior. I give the switch in that the friendly name of the Alert2, because I think making the common cases easy is beneficial.
Separating Firing from Acking
It’s doable, but not at zero cost.
To represent whether or not the alert is firing, as I see it, we have two ways to go. One of them is to use a switch that can’t actually be turned on or off (but Alexa won’t know that, so that’s something users would have to remember) to represent the state of the alert, which is a misuse of the switch but which allows us to use the natural language “Is such-and-such alert on?” utterance.
The other option is to use a binary sensor. The trouble is that Alexa only understands binary sensors as contact or motion sensors (intended for use with alarm systems and the like), so you we have to rephrase questions as something like “Is such-and-such alert open?”
I really don’t like the second one. I can’t say I like the first one much, either, but…
For acking, we could use a separate switch. The annoying thing here is that Alexa enforces a strict “only one entity of a given name” constraint, so instead of being able to say “turn [on|off] workshop door left open”, you would have to say “turn [on|off] workshop door left open acknowledgement”, which is one of the issues I had that lead me to the Alert 1 emulation design in the first place.
Claude, however, had a better idea. If you use button entities in Home Assistant, they can be exposed to Alexa and come through as scenes, which can be triggered by just saying their friendly name. So we could have “acknowledge workshop door left open” and “unacknowledge workshop door left open” as valid utterances.
This one, I like. The drawback, of course: two additional voice-support entities per alert.
Other features
Notifications enable/disable: we can do that per-alert at the cost of an additional switch; it’s already a boolean, so that’s fine. That gives us “turn off workshop door left open notifications”, which is natural enough.
Snoozing: Snoozing is kind of a nightmare. There are three possibilities, really, all of which use the notifications enable switch to turn it back on and assume that it’s okay to have snoozed notifications and disabled notifications look identical from a voice perspective:
- Preset a snooze time in the config; generate one button/scene/utterance to snooze the alert. We can put the preset time in the button name, so that gives us “snooze workshop door left open for an hour”, or we can leave it at just “snooze workshop door left open”.
- Present multiple snooze times in the config, and generate one button each. Works just like the above, only with multiple entities and so multiple utterances. Drawback: multiplies the heck out of our secondary entities.
- We could, in theory, use a number entity to set the snooze time and a button to trigger the snooze. Drawbacks: two entities, Alexa’s units don’t include time units so you have to use a bare number in the utterance, and unless you remember what the snooze time is and it’s what you want, you have to use two utterances to snooze. “Alexa, set workshop door left open snooze time to 3600; Alexa, snooze workshop door left open.” Not loving it.
Also potentially worth implementing
- An ack all button, for “Acknowledge all alerts”.
- Anything firing switches/binary sensors, possibly by priority - “Are any alerts on?” or “Are any alerts open?”/“Are any high priority alerts [on|open]?”, etc.
Can’t dos
Sophisticated queries, since Alexa Smart Home skills don’t support list responses or dynamic speech. The best we can probably do are things like the anything-firing-by-priority options just above, or things like them as a substitute for “Which alerts are firing?”.
As for “How long has foo been firing?”, the only way we can get numeric sensors out are as temperature sensors, so we’d be publishing elapsed minutes as a fake temperature. That’s horrible and we should absolutely not do it.
Proposals
What would I do, if I didn’t do what I’ve already done?
- Use a non-changeable switch for the state of the alert, and give it the same friendly name as the alert. (This does mean users could try to turn it on and off, which would be a silent no-op, but we’d have to live with that; at least it allows for reasonable natural language checking of the alert state.)
- Implement acking and unacking using two buttons/scenes, for the most natural language there. (This doesn’t provide for a way of checking whether an alert is currently acked, but since acking or unacking twice is a no-op, that’s probably okay.)
For an initial release, I’d stop right there, because that covers what I see as the most important functions. I’d also probably make the ack/unack functionality - and other similar things added in later releases - an option, since as this path ends up with multiple proxy entities, I want to avoid accidentally polluting entity-space with them unless the user actually wants them.
Other things, in rough priority order, at least as I’d guess it:
- Ack all/unack all buttons/scenes, which slightly contrary to their name would affect all firing alerts.
- Are-alerts-of-this-priority-firing? switches/sensors, which might be refinable with some more thought into some more sophisticated group sensors. Use HA labels maybe? Needs some rumination.
- I’d be tempted to declare both notification enable/disable and snoozing out of scope, given the multiplying number of entities involved and that we’d have already covered the most common use cases. But if we do want them, the former at least is easy; the latter is design hell.
That’s what I have thus far.
