[Feature Request] Better Flow and Zone Support for Custom alarm_* Capabilities

Ideas & Suggestions
, ,
1

Summary

Custom boolean capabilities with the prefix alarm_ currently behave like alarms in the UI, but they do not offer the same practical Flow and zone-level behavior as system alarm capabilities.

This forces app developers to choose between:

  • correct semantics with a custom alarm capability
  • practical Homey integration with a misleading system capability

Real-world Example

For a soil moisture sensor, the correct capability for a threshold alarm would be something like alarm_soil_dry.

Using alarm_water is semantically wrong, because it normally means water detected or leak alarm, not soil moisture below a configured threshold.

However, today alarm_water is the pragmatic choice because it integrates better with standard Flow usage.

Problem

Custom alarm_* capabilities:

  • show up as alarms in the device UI
  • can be updated as boolean alarm states
  • can trigger custom capability Flow triggers

But they do not provide the same out-of-the-box experience as standard alarm capabilities for:

  • generic Flow cards
  • easier zone-based automation
  • consistent alarm behavior across apps without custom card duplication

Requested Improvement

Option 1: Full parity for custom alarm_*

Allow custom boolean capabilities prefixed with alarm_ to participate in the same generic Flow and zone behavior as system alarm capabilities where feasible.

Option 2: Opt-in manifest behavior

Allow apps to opt a custom alarm_* capability into standard alarm Flow behavior through a manifest flag.

For example, something conceptually like:

{
  "type": "boolean",
  "title": { "en": "Soil Dry Alarm" },
  "getable": true,
  "setable": false,
  "insights": true,
  "alarmBehavior": "generic"
}

The exact property name is not important. The main request is an official way to make custom alarm capabilities participate in Homey’s native alarm Flow model.

Option 3: New system capability patterns

If Homey does not want to generalize custom alarm behavior, another option would be to introduce more threshold-oriented standard alarm capabilities, such as a generic low/high threshold alarm model for sensors.

Why This Matters

  • Many sensor alarms are domain-specific and threshold-based.
  • Existing system capabilities do not always match the actual meaning.
  • Developers should not have to misuse alarm_water for dry soil just to get practical Flow behavior.
  • Users get a cleaner and more predictable setup when the capability meaning matches the actual device state.

Practical Outcome

With better support for custom alarm_* capabilities, apps could expose:

  • alarm_soil_dry
  • alarm_humidity_low
  • alarm_humidity_high
  • alarm_co2_high

without losing the usability benefits of Homey’s standard alarm automation model.

Closing

This would make Homey’s custom capability model much stronger for real-world sensor apps, especially where domain-specific alarms do not map cleanly onto the current built-in capabilities.

2

I’m not sure I fully understand what you mean. Are you looking to have something like alarm_water trigger zone activity?

You could also create a custom capability using the alarm_* pattern, as you mentioned. That wouldn’t behave any differently from a system capability.

The only thing you’d need to do is wire up the Flow card logic. Fortunately, Homey automatically generates Flow triggers for alarm capabilities if you name them alarm_**_true and alarm_**_false. You can find that here.

For the soil moisture you could create a custom alarm_moisture capability with two Flow cards: alarm_moisture_true and alarm_moisture_false.

Or are you referring to some Flow behavior that’s currently missing?

3

Thanks for your kind reply.

I think the main point of my request is specifically the zone-level behavior.

I understand that custom alarm_* capabilities can be created, and that custom Flow triggers such as alarm_moisture_true / alarm_moisture_false can be added.

What I am asking about is whether a custom alarm capability like alarm_soil_dry participates in Homey’s native zone alarm behavior in the same way as a built-in alarm capability like alarm_water.

That is the part I find most interesting, because for this kind of domain-specific sensor alarm, the ideal outcome would be:

  • the capability name matches the actual meaning
  • it still fits naturally into Homey’s zone-level alarm model

So my core question is:

Are custom alarm_* capabilities fully equivalent to built-in alarm capabilities when it comes to zone-level alarm behavior?

If they already are, then that answers my question.

If they are not, then my feature request is essentially about making it possible for custom alarm capabilities to participate in that same native zone alarm model.

4

Alarms that activate a Zone are those that indicate activity within that Zone, such as motion, presence, contact, or vibration.

Alarms like alarm_water (typically used for leak detection) do not trigger Zone Activity.

The following system capabilities will activate Zone Activity:

  • alarm_motion
  • alarm_contact
  • alarm_vibration
  • alarm_occupancy
  • alarm_presence

The reason custom capabilities can’t interact with Zone Activity is that many users rely on this feature to trigger Flows, like turning on lights. If custom capabilities were included, something like a plant needing water could unintentionally trigger those Flows.

5

Thanks, that distinction makes sense.

To be very specific, I am not referring to Zone Activity cards such as a zone becoming active/inactive.

I am also not referring to device-level custom Flow triggers such as alarm_moisture_true / alarm_moisture_false.

What I am referring to is the built-in zone-level Flow cards in Homey that represent alarms generically at zone scope rather than at device scope.

In other words, I am asking about cards already generated on zone-level conceptually in the form of:

  • Any device’s <alarm> turned on
  • Any device’s <alarm> turned off

I have a danish version, so I did google-translate - I have attached screenshot from my homey

image
image344×187 3.55 KB

I did an experiment adding a custom alarm to a device - and that alarm did not show up on the the shown zonecards

So the question is:

Are the built-in zone-level alarm Flow cards only driven by “system” alarm capabilities, or is it possible that custom alarm_* capabilities can participate in those cards (NOT affecting Zone Activity)?

The behavior I am asking about is, that custom alarms can participate.