Add support for Pushover custom sounds

[svobs]

Implements issue #25: Simple change which allows custom sounds to be specified for Pushover messages.

This patch:

1. Removes the check which prevented custom sounds from being specified in the JSON config; instead, uses supplied value, unless supplied value is empty, where it defaults to "pushover".
2. Changes the Sound element in the UI from a dropdown to a "typeahead" text field which suggests values for the default sounds as the user types.

Nothing fancy. It won't provide a list of the user's custom sounds, but it shouldn't be too hard for a user to test out the switch to guard against typos.

[elvirusDE]

@potrudeau Can you please merge this?

[elvirusDE]

Nice work!
@svobs Could you include it in your fork and publish it? Better so than waiting for ever...

[svobs]

Nice work!
@svobs Could you include it in your fork and publish it? Better so than waiting for ever...

@elvirusDE Sorry I didn't get to this sooner. I created a fork from this PR and published it.

Search for the plugin @svobs/homebridge-messenger in Homebridge.

[permaMonk]

@svobs
Hi.
Just to be sure. Your fork "https://www.npmjs.com/package/@svobs/homebridge-messenger" can handle Pushover customs sounds now, yes? How? It´s a extra field in config? Copy the original config to your fork, set in custom sound names and it will work?

And a following question - only a question. Is there anything you can do for "Ready for Homebridge v2.0".?

Thx for all.

[svobs]

@svobs
Hi.
Just to be sure. Your fork "https://www.npmjs.com/package/@svobs/homebridge-messenger" can handle Pushover customs sounds now, yes?

Yup.

How? It´s a extra field in config? Copy the original config to your fork, set in custom sound names and it will work?

No new field, actually. The original version was already storing the sound option as a string. But it had extra logic which prevented any values from being sent which were not one of the built-in Pushover sounds. I changed this so that the built-in sounds are suggested in the autocomplete but any value can be used.

However, the v1.03 release added @HolgerAusB's support for the ttl field, which added a new field to the config.

You can also see the changes in the Homebridge UI. For example, from the copy I'm using at home:

You can also compare changes to the source code via my project's GitHub page.

And a following question - only a question. Is there anything you can do for "Ready for Homebridge v2.0".?

I did do quite a bit of work last year (incomplete work here) to rearchitect the project adhering to the latest Homebridge plugin specs. It ended up being hundreds of lines of code, and I realized that I'd need to commit to extensive testing, which would include IFTTT & email features, which I've never used. So far I've only made changes which affect Pushover. So I ended up shelving it for the time being.

There's still some possibility I might pick it up at some future date. But I don't estimate a large number of people are using my fork. TBH it's not clear when Homebridge 2.0 will finally be released...I wonder if by that time, Home Assistant will be so good that everyone will have migrated away from of HomeKit and onto that.

[permaMonk]

Thank you very much for your really comprehensive feedback. I'll take the plunge and install your fork.

I just like the option of having a second channel, i.e. additional (unique) audio to accompany the visual notification.

It was to be expected that the switch to HomeBridge v2.0 wouldn't be easy. Nevertheless, thank you for your efforts.

Home Assistant as an alternative is also increasingly on my mind.