get_alerts() only returns first alert in list

[tbl-benjamin]

Not sure if this is intended or not, but it seems kind of useless to only return the first alert in the list. Although, it seems the alerts are pretty useless in general if they can only be used to send emails to a recipient; it would be nice to know if there is a way of accessing/intercepting these alerts from the stat.

[doug-hoffman]

The get_alerts() behavior was fixed in 632a6d3, which made it into 0.14 yesterday. The official local API offers no means to configure or control alerts; only receive the state of alerts (active or not).

If you plan on looking into unofficial API values to manage alerts, it seems like the best path forward may be to come up with a single method for handling unofficial API calls, along the lines of:

    def set_unofficial(self, settings):
        path = "/settings"
        data = urllib.parse.urlencode(settings)
        r = self._request(path, data)
        return self.parse_response(r, 'set_unofficial')

This way, you're free to set any values you wish, but aren't littering the class with calls that aren't guaranteed to work on at least a majority of the models. Constants could still be defined within the class, but maybe named for the specific model known to support it, such as T2100_ALERT_FOO. Then you could just set_unofficial({T2100_ALERT_FOO: T2100_ALERT_FOO_ON}), set_unofficial({T2100_ALERT_FOO: T2100_ALERT_FOO_ON, T2100_ALERT_BAR: T2100_ALERT_BAR_OFF}), or even set_unofficial({'some_alert': 1}) as required.

[hpeyerl]

I do think that's a good idea, @tbl-benjamin ...

[garbled1]

I actually really like the behavior as-is, because it's perfect for a homeassistant binary_sensor. If you do change this, could you make it a new api call instead?