Open Snuffy2 opened 3 months ago
Sorry I've been MIA for a while...
The biggest concern I have is that it locks the integration into using an external (possibly precarious) AMP integration for the announcements.
I don't have any issues with having the option of creating persistent notifications but the rest I think might be too much for the integration itself to do. My opinion is that the integration should only provide the entity and attributes and it should be up to the user to decide what they do with the data. I feel that by adding all of this into the config that it will tend to limit the functionality if the integration as users may think that's all they can do.
And I'm not even sure yet if this will cause any breaking changes with the functionality of the current sensor. if it does then I really doubt that's something I would agree with.
Is there any other examples of integrations (besides maybe Alarmo - which I don't use for the exact reason that it just feels too confining to me) in which the integration itself provides a replacement for the standard automation engine in HA?
Is it possible to create another companion integration with this proposed functionality for a user that wants to use it? and they can maybe specify the sensor created by this integration (or any other future similar integration) as an input? We could add the "event" data to the sensor as well so it could be used in the extra services created.
Thoughts?
Actually I just realized that we already have the event type in the attributes in the "title" field.
My intention was to make it easier to send alerts.
While doable via automations, it requires jinja to split the alerts and find the alert types you desire, and the use of hass-variables (an integration I love and am one of the primary maintainers for).
I based the initial supported alert methods based off of what you used in your nws_alert_package.yaml which is the HA Mobile App and Alexa Media Player. I would like to also add support for Google Home notices and others.
As you see, these are optional and users don't need to enable them if they don't want to. This does not break or change the existing NWS Alerts sensor nor any existing scripts or automations.
Removes the need for separate package, automations, scripts, variable, etc. Will send NWS Alerts directly from the integration. Selection of the alert types and where to send them is part of the Config Flow.
Future improvements will be to add support for more announce and send services.