As BB continues to add additional features that are not feeder specific, the current config entry structure will become less meaningful.
What will remain the same:
One config entry per login - as it is today
One device entry per physical feeder on the account:
This includes "owned" feeders, and "member" feeders (where the account has been explicitly invited to join that feeder)
Each physical feeder device will continue to group feeder-specific entities (state, battery, charging, wifi signal, etc)
Worth noting: when a feeder is removed from an account, the device and entity entries do not get removed automatically; however the user has the option to delete a device if the device is no longer being provided by the integration
New proposals:
Feed events (like new visitor / postcard) could be associated with a physical device; or it may be associated only with a "service"?
In particular, the Feed, postcards, and collections outlive the physical feeders on the account - if you remove a feeder, your postcards and photos remain, even if the metadata might reference a feeder id that no longer exists (which is why the metadata also includes the feeder name and location, so that the data can still be displayed even if the feeder is removed)
Also new features like "BB Explore", BB TV, and so on may be more dynamic and might not make sense to create a bunch of device entries for community feeders. So a service might make more sense for these. As an example, the app allows swapping a connected feeder easily, including some time-based (expiring) connections. Because these can change frequently, we shouldn't create long-lived device entries for something that might change every few days. These could be associated with a single "BB Explore" service, or with "Explore slot 1", "Explore slot 2", etc, services.
Consider being able to add extra sub-entries associated with a config entry, service, or device (Think ); for example:
New image entity types
Allow adding a new image to a config entry or service, giving the user the option to select what type of image it will encapsulate:
Latest visitor per feeder (associated with a feeder device)
Rotating recent visitor(s) image(s): rotate through photos in each
Rotating "Community" feeder photos
Including "BB Explore" photos - will do some testing here, as I'm not sure if these will appear as postcards in the Feed, when you connect a BB Explore feeder
This would solve the problem of deciding what type of image we should surface, because the user would be in control of it.
However, is it possible to add a "sub" entry like this? If not we might have no choice but to create the separate entities but leave them disabled; or have an options flow to configure which image type(s) to enable for each service entry
camera entity type that can play a video from collection or postcard, or from the "BB TV" section of the app
This might not be feasible, given the expected behavior of a camera entity. Last I checked, there is no good way to render a video file as a camera entity, because the stream component doesn't know how to handle that (and e.g. whether it should loop the file, for example)
As BB continues to add additional features that are not feeder specific, the current config entry structure will become less meaningful.
What will remain the same:
New proposals:
imageentity typescameraentity type that can play a video from collection or postcard, or from the "BB TV" section of the app