How to delete a single bird budy?
RuudvanMunster opened this issue · 13 comments
I had some issues with the last update of my Bird Buddy due to wifi problems and decided to remove the Bird Buddy and add it again to the network. At that moment a new Bird Buddy was created (maybe I should have used exactly the same name? :) )
Now I have two Bird Buddy's in Home Assistant. I am not able to remove the old one. Using the delete option seems to delete both?
With other integrations using the triple dots option I get a submenu for each device within the integration. Could that be an option here too?
I've run into this as well, after asking a user for access to their feeder in order to test multi-feeder support. A few things come from this issue:
- The integration should ideally notice when a feeder that used to be on your account is no longer on the account, and offer to delete it.
- The integration should probably use the Serial No of the device, rather than the Feeder ID (UUID), which gets regenerated if you remove and re-pair, while a serial number won't. This would also allow the integration to keep all the older data and just associate new data with the same entities, because the serial number is the same. This could create the same disconnect however if you replace a feeder with a new one.
- Similar to (1), I've noticed that it also doesn't refresh the integration name: we used to name the integration connection by the login email, and now we use your BB user account's "name" instead - but my integration still shows my email instead. A "Reconfigure" or "Reauthenticate" config flow would probably help resolve this.
In the meantime, if you simply delete all the entities associated with the old one, the device should just "fall off" once there are no more entities. But I understand that's not a solution.
Let me start by thanking you for this nice integration. What we are talking about now are of course mainly refinements, which will be very welcome in the long run. Maybe something for the wish list?
I've already removed the entities associated with the old one and disabled the old BB in the integration's configuration. So there is no obstacle.
The old data is still available. Do I understand correctly that the old data is still there due to the presence of the old BB?
What we are talking about now are of course mainly refinements
Yeah, I think so. Unless you end up in a state where the old feeder is there with no way to remove it (other than deleting and re-adding the integration). Then that's a little more severe than just refinement.
Do I understand correctly that the old data is still there due to the presence of the old BB?
Depends on what you mean by the old data:
- If you mean old photos in BB app; those are saved on your account and are not associated with the feeder itself.
- If you mean when you open a graph (such as for battery), you see older data in the graph, from before the switch; that means that the Recorder is associating the new entity with the old data automatically, which usually means that there shouldn't be any extra entities.
- If you mean you can see the old device, and the old device has old entities, and the old data can be found in the old entities, then yes, that's only still viewable because the old entities and device are still present.
It would be possible to merge the old data into the new entity states, by running some manual SQL queries in the database, effectively moving the old data so it's associated with the new device.
I meant the old photo's. I understand that the photo's available in "Media" are still there, also because they are saved on my account. I was a short moment worrying about that. :)
They old graphs are indeed removed with the entities, I suppose. That is no problem. I have indeed been playing with TablePlus to explore the database. So that indeed is a nice solution to merge the old and new data.
I've just pushed a new PR #58 that will delete orphaned BB devices once they are no longer associated with your account.
On one hand, this would likely be the simplest way to handle it, because the orphaned device should probably be deleted anyway. On the other hand, it doesn't give the user any warning or the ability to opt out of performing this, and it will happen as soon as the integration loads (or reloads). But I don't know of any alternative here: we either delete the orphaned device, or we leave it. If we leave it, I don't know of any other way for the user to remove it.
In most cases, if the user is simply swapping one unit with another (i.e., warranty replacement), then the feeder name will likely (?) be the same, and the new device will have entities that generally match the entity names of the old device, which means the new device entities should in theory replace the old entities (and hopefully inherit the old entity's state history 🤞). However that's not simple to test or verify. If I have a chance I'll try to add a unit test for that, to verify the behavior.
@RuudvanMunster do you have any opinions on the notes above?
@RuudvanMunster do you have any opinions on the notes above?
I'm not sure if I'm fully overseeing this. I'm still on a steep learning curve with Home Assistant. I tend to be hesitant to automatically remove devices. At the moment I have turned off the old BB. I don't know if I shouldn't. Is there a possibility to give the BB the status "orphaned"?
Looking back, I should have given the same name to the device after reinstallation. I did that with my electricity meter and kept my history. Luckily that wasn't a problem here.
May be I see another solution. An example could be the Fibaro integration, but I have seen it with more integrations.
The toplevel for Fibaro does not have the three dots ("more") option, but has direct links to the (multiple) devices. If you click on these links, you get the three dots per device, including a delete option. Is that an option for this issue?
I'm not familiar with the Fibaro device handler. But I'm assuming it looks similar to what ESPHome does.
I'm thinking this would be done in a way that the integration creates a "service" device, which acts as a hub consisting of your service login info. From there, each device would be separate entries under that service, with entities associated with those devices.
I'll have to play with the service idea to see if that would accomplish what we're looking for.
If I try to understand some "common sense" how different devices are organised I see two way of organising:
- The current implementation for Bird Buddy: I see this method especially for different devices that share a common interface, like Z-wave and Zigbee devices.
- The implementation I propose for Bird Buddy, as shown above, which seems to be used for all camera's, media devices, mobile devices.
The exception to this "rule" I found is for Google devices. Which make maintenacne in my network somewhat more difficult. I can not delete Google devices from HA as well.
I hope this helps you.
Still I find that we are discussing ways towards perfection. I am very happy with your BB integration as it is. You really did a nice job for others and me. I am especially very happy with the automatic processing of the visitors!
If you are looking for further perfection: I would be very happy to have more options to process the pictures and delete them. I am not so happy with the current version of the Bird Buddy app.
I think that it is possible to write a stand-alone program, using your software for processing of the images. May be it is a good starting point for me to develop my programming skills. :)
The current app does make it difficult to process postcards, but a new feature is coming soon, called "Inbox" that aims to make processing postcards easier and more streamlined (fewer clicks). However, it won't fix the AI (either which photos to snap or how to identify the species), and if you use the automation to process them, then the "Inbox" feature won't really help either.
I don't intend to add any management of media (like deleting photos) from the media browser at this time. But feel free to make a feature request issue here in github if you have specific ideas.
Back to the device discussion, while reading up on devices vs services, it looks like it would be pretty simple to create the UI like this. However, I also found that giving HA the ability to Delete the device (like your screenshot shows for the sub-device), is much easier than expected. I couldn't figure out why I wasn't being given the option to delete devices, but turns out it's because I wasn't adding the correct component callbacks: https://developers.home-assistant.io/docs/device_registry_index#removing-devices. Adding this callback works perfectly. And if you happen to delete a device that still exists on your account, you can simply reload the integration and it'll come back (so this delete is really only intended for deleting orphaned devices). I'll have an update for this soon.