search

NEEOInc / neeo-sdk

NEEO Brain SDK
https://neeoinc.github.io/neeo-sdk/
MIT License
49 stars 17 forks source link

[feature request] Generic device type #116

Closed tmrobert8 closed 6 years ago

tmrobert8 commented 6 years ago

ACCESSORY is a great type because it can be anything - but it's real downside is that there are no recipes associated with it (so you can't start/stop an accessory).

I've always wanted and people have asked me about is a version of accessory that does provide recipes for those SDK devices that don't fit the mold of any of the types we have. The constant example I get on how to model something is shades (close second is security devices) - none of the existing types really work with those and you can't use ACCESSORY since you want to create recipes. (I know the workaround is to create an accessory type and then use the dummy device as a shortcut holder - but that's a pain).

What I'd like is for either

  1. ACCESSORY to be allowed to have recipes/power management (although this would likely create backward compatible issues)
  2. A new GENERIC (or something else) type defined that will be similar to ACCESSORY but can have startup/stop recipes assigned. We can already use specificname and icon to properly setup the names/icons of the new type - so that's not an issue.
bdauria commented 6 years ago

This makes sense to me, I also had this issue while creating a device that didn't fit any existing type. An alternative would be to add a capability to allow accessories to run in standalone scenarios.

neophob commented 6 years ago

i think the proper approach is to extend the recipes functions on the brain, rather to implement this feature

tmrobert8 commented 6 years ago

Sounds good with me - I'd think handle it like the AUDIO device (where the recipes are hidden by default) - should accomplish the same thing.

neophob commented 6 years ago

I'll close this issue, we track this in our internal backlog.

Thanks @tmrobert8 for your input