Enviromental Alarm trigger events - Separate event triggers for different enviromental device type sensors to allow other actions as well as Fire or Water Leak Alarm notifications when a smoke/heat/gas/CO2/moisture/safety sensor trigger?

[Hedda]

Can you please consider adding Enviromental Alarm trigger events - Separate event triggers for different enviromental device type sensors to allow other actions as well as Fire or Water Leak Alarm notifications when a smoke/heat/gas/CO2/moisture/safety sensor trigger even though those sensors are placed in the same area?

This feature has partially been requested before in little less than a year ago but was automatically closed as stale (which probably should not have?), and there kind of a non-self explanatory workaround by placing easy different type of sensors in different areas, but that is not really user-firendly or explained anywhere in the integration interface or the documentation .

Please see the previous feature request here:

• Enviromental Alarm trigger #896

I think that would be more user-friendly to add some feature to enable differencing between different device type events if possible.

Checklist

• I checked for similar existing requests (both open and closed) before posting.
• My request is generic, other users may benefit from it too.

Proposal

Suggest add new separate event types for the Environmental device types and enable to use those new event types as confitions.

I believe that should allow users to place different Environmental device types in the same area but have then them perform different notification tasks and actions.

Additional info

Alarmo already defines these Environmental device types as binary sensors (with predefined configuration as a Always on), but I think what is missing is for those binary sensors to trigger different type of events and for the users to set conditions for those events:

• carbon_monoxide
• gas
• heat
• moisture
• smoke
• safety

[nielsfaber]

There has been extensive discussion about this topic in the past, the summary is as follows:

1. Alarmo is intended for setting up a burglar alarm. All functionality and corresponding code is written with this in mind. We should not 'contaminate' alarmo with additional responsibility.
2. The state machine for a burglar alarm includes arming/disarming, leaving/entering the house, pin codes etc. All of these are not really applicable for a fire alarm. A fire alarm is either triggered or not triggered.
3. Users may want to set up completely different actions/notifications and delay times for a fire alarm than for their burglar alarm, which would require duplicate administration (similar to setting up a dedicated area in alarmo). Additionally (like you pointed out), the response to a fire event may be different than a water leak event, so there is a need to distinguish between the various device classes currently mapped as 'environmental' sensors.
4. Alarmo is not intended as an alternative 'automation engine', HA already includes its own (better) UI for setting up automations. Given arguments 2 and 3, users can already fulfill their needs by setting up (simple) automations in HA that performs the desired action in case an environmental sensor triggers.
5. Based on all the above and the fact that alarmo already allows setting up multiple areas and it implements the 'always on' sensors, the decision was made to leave alarmo as is.

I'm open to rediscuss the topic here.
However, I see many other (more essential) parts that can benefit from improvement and I have very few time on my hands to work on them, I don't consider this a priority.