jhansche/ha-birdbuddy

Battery life during deep sleep and HA integration.

cbrollin opened this issue · 6 comments

My bird buddy has now been going into deep sleep during the night, as it is designed to do.

Thanks to this integration, I can see the battery life during that time, and I am basically seeing no change in behavior compared to normal operation. Status timeline shows purple as ready, and light blue as sleeping. Time periods for the two graphs are the same.

06A1DD22-6D50-48C2-9648-1337B7179933
1572FB1A-611E-41C8-88DE-EE41AC47040B

I am wondering if this integration is excessively polling (even if it is every 5 min) during the night, and reducing the battery life. Or do we think the Bird Buddy app polls at the same rate regardless? I am trying to figure out how to test this.

Maybe we can restrict polling based on sunrise/sunset of the feeder location (like how the feeder works), or restrict polling for a certain time period following the first deep sleep status message.

Really? I definitely see a difference in my battery usage, since they turned on deep sleep overnight. In my graphs you can see a very clear change of trend starting Jan 5-6, when they enabled sleeping:

Screenshot_20230111-223021

Screenshot_20230111-222840

I am very nearly certain that us polling the GraphQL API does not do anything to wake the feeder. I say that because the API responses are pretty fast, and if it had to wait for a response from the feeder, it would be much slower and more erratic. Also if it were keeping it from sleeping, then it would not remain in deep sleep state overnight, but it does.

I believe the only thing that would cause it to wake up and prevent it from sleeping, would be if we instructed it to enter streaming mode, which even when you do that from the app, it can take up to 2 minutes before the streaming actually starts. It has that potential delay, because it just sets a flag on the server side, and waits for the feeder to check in and see the flag is set, before the feeder actually starts streaming the camera feed. If hitting the API alone would wake the feeder, then it wouldn't have that long of a delay before starting the stream.

Huh. Ok. Well your device and data seem to act how I would expect. Maybe I need to reset, or reboot my bird buddy. I will try that out.

From the earlier parts of the 30+ day maroon graph, you can see that I used to have to charge it every 2-4 days. But this week it lasted from Jan 4-11, just about doubling the battery life.

Also see these shots from Jan 3-6. I had started experimenting with putting it off-grid, which actually did nothing for preserving battery. A few days later I started seeing deep sleep state, and that actually did have a noticeable impact:
Screenshot_20230111-224652
Screenshot_20230111-224600

Another thing to consider might be the placement of your feeder -- for example, the support site mentions things like a waving flag near the FOV of the camera, or if your feeder is hanging, it might be moving if it's windy. Now, that article might be outdated since the change to enable sleep mode, since there's no reason it should wake up from a flag in the frame. But just something to consider.

I think your idea of trying to power cycle it could be a good first step, and also make sure you're on the latest firmware (1.1.0).

If you do suspect the integration still, you can try disabling the integration in HA for a day, or even a few hours, and then see if the battery trend looks any different. Of course you wouldn't see the graph during that time, but you'll be able to see the trend from before and after. Judging from the trend of your graph, it would be pretty easy to determine. I expect if it looks something like this, then it likely isn't the integration:

211966279-75b9096f-bcdc-4437-854a-ba0c1d845a89~2

If the graph looks like it would connect on the same trend, then we can rule out the integration causing it.

@cbrollin any update here? Were you able to try a test with the integration disabled? Or did you try a soft reset?

I tried a power cycle, and that seemed to fix the problem. I am seeing the appropriate behavior now.
49B4CB77-F20E-481A-B26C-820C9EF90DE6