Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adds missing CameraWidget registration for SCREEN_ON #4648

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ivorsmorenburg
Copy link
Contributor

Summary

Missing CameraWidget registration on SCREEN_ON, this will avoid the camera to refresh and sometimes will end up not loading the picture

Screenshots

image

Link to pull request in Documentation repository

Documentation: home-assistant/companion.home-assistant#

Any other notes

Split from #4640

@dshokouhi
Copy link
Member

So just out of curiosity how do you expect this to work? The reason I ask is because entities in the camera domain very rarely get a state update which is exactly what the screen on filter does, it registers to get entity updates but youll never get it for this entity. Furthermore this behavior is explained in the docs with regards to how frequently it updates: https://companion.home-assistant.io/docs/integrations/android-widgets#picture

if the entity is going to get more updates with this change we need to mention it in the docs but also have you done mobile data consideration here? Other entities dont really send that much data but a camera updating every time the screen turns on can be a hundred updates in a single day as opposed to the current default of 24 updates in a day. For example I had 77 screen on events yesterday that can lead to a lot of data usage unexpectedly

@ivorsmorenburg
Copy link
Contributor Author

ivorsmorenburg commented Sep 17, 2024

That's a good point, but probably the responsibility of fetching the data should not be a SCREEN_ON intent, this should be used to trigger the necessary logic to do that, the point is that camera widget stays like this. I think docs can be updated that should not be a problem.

To fetch data every 24 hours we could use WorkManager and let OS deal with scheduling the data. That way we could avoid what is shown in the video and not reflected in the documentation:
"Select the desired action on tap ("Refresh" to update the image from the camera, "Open" to open the camera entity)"

camerawidgetnotworkingonscreenon.mp4
  • Taps aren't visible, but everytime the home assistant opens is due to tapping and trying to refresh the image

@dshokouhi
Copy link
Member

That's a good point, but probably the responsibility of fetching the data should not be a SCREEN_ON intent, this should be used to trigger the necessary logic to do that,

I agree but fixing that is not in scope of this proposed change, my comment was merely about the current architecture and how things work today.

the point is that camera widget stays like this.

i personally have not experienced that, in what cases do you see this happen? are there any errors in the logs when it happens. My camera widgets always show an image when I look at them and update appropriately when I tap on them. I can't quite tell what is going on in the video, if the image is not updating that suggests another issue as the image updates in the production app everytime I click on it. If the image is not updating the logs may help us determine whats wrong. I still dont see how the screen on intent will correct this.

To fetch data every 24 hours we could use WorkManager and let OS deal with scheduling the data.

Why change it when the current behavior works fine with the current refresh interval: https://github.com/home-assistant/android/blob/master/app/src/main/res/xml/camera_widget_info.xml#L11

I think it may be more helpful to understand the issue you are seeing so we can determine proper course of action. If the image s not updating when you tap on it the logs should show what happened there.

@ivorsmorenburg
Copy link
Contributor Author

I agree but fixing that is not in scope of this proposed change, my comment was merely about the current architecture and how things work today.

Yes that's correct, maybe we could use part of the widget refactor to do that but on a separate PR?

i personally have not experienced that, in what cases do you see this happen? are there any errors in the logs when it happens. My camera widgets always show an image when I look at them and update appropriately when I tap on them. I can't quite tell what is going on in the video, if the image is not updating that suggests another issue as the image updates in the production app everytime I click on it. If the image is not updating the logs may help us determine whats wrong. I still dont see how the screen on intent will correct this.

I have seen this issue few times on my device, I can't really think of the scenario that made this happened, so I gave up using the camera widget. I'll try to find a way to reproduce and fetch the logs somehow.

Why change it when the current behavior works fine with the current refresh interval: https://github.com/home-assistant/android/blob/master/app/src/main/res/xml/camera_widget_info.xml#L11
I think it may be more helpful to understand the issue you are seeing so we can determine proper course of action. If the image s not updating when you tap on it the logs should show what happened there.

I don't think changing the behavour is the solution, is ok as it is, but just to make sure to not fall in that edge case

@dshokouhi
Copy link
Member

I have seen this issue few times on my device, I can't really think of the scenario that made this happened, so I gave up using the camera widget. I'll try to find a way to reproduce and fetch the logs somehow.

yea lets see what the actual issue is there as I am not seeing issues with this widget but that doesn't mean theres something that needs to be fixed somewhere!

@ivorsmorenburg
Copy link
Contributor Author

I have to look more in detail to this tomorrow hopefully

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants