For example Discord webhooks returns a 204 success code as response, which gets logged as an error in the log, even though it is successful.
Update the allowed statuses to accept all 2xx responses as successful.
The REST notification component only allows 200 + 201 as a successful
response code to the submission. notify.me returns a 202 (Accepted)
response, which works fine but gets logged as a warning in the log.
Update the allowed statuses to treat the 202 as ok.
* Add mysensors notify platform
* Make add_devices optional in platform callback function.
* Use new argument structure for all existing mysensors platforms.
* Add notify platform.
* Update mysensors gateway.
* Refactor notify setup
* Enable discovery of notify platforms.
* Update and add tests for notify component and some platforms.
* Continue setup of notify platforms if a platform fails setup.
* Remove notify tests that check platform config. These tests are not
needed when config validation is used.
* Add config validation to APNS notify platform.
* Use discovery to set up mysensors notify platform.
* Add discovery_info to get_service and update tests
* Add discovery_info as keyword argument to the get_service function
signature and update all notify platforms.
* Update existing notify tests to check config validation using test
helper.
* Add removed tests back in that checked config in apns, command_line
and file platforms, but use config validation test helper to verify
config.
* Add a test for notify file to increase coverage.
* Fix some PEP issues.
* Fix comments and use more constants
* Move apns notify service under notify domain
* Update notify to expect a list of string targets instead of a single string
* Actually do the thing I set out to do
* Fix notify.group test to expect an array of targets
* REST platform will only use the first target in the list
* Update notify platforms to expect a list of targets
* Update notify services.yaml