search

sca075 / mqtt_vacuum_camera

Camera Integration for Home Assistant to export and render all Vacuums connected via MQTT( including Valetudo Hypfer and RE(rand256)) Maps.
Apache License 2.0
92 stars 5 forks source link

At HA Startup / Warning camera took longer than the scheduled update interval 0:00:03 #200

Closed sca075 closed 2 months ago

sca075 commented 2 months ago

Checklist

The problem

This warning occurs wile HA is staring up, the first image is taking longer than the expected 3 second for the frame. The issue was already reported, but actually not visible in the test environments used.

What version of an integration has described problem?

2024.07.0

What was the last working version of an integration?

not specified

What vacuum model do you have problems with?

Roborock.S5

Please firmware installed on your Vacuum.

No response

What type of platform you use?

ARM (Raspberry Pi, Odroid, etc.) > 4GB

What version of Home Assistant do you use?

2024.7.2

What type of installation are you running?

Home Assistant OS

Logs or Errors shown in the HA snapshots (please enable the Debug Mode) text will be auto formatted to code.

Updating mqtt_vacuum_camera camera took longer than the scheduled update interval 0:00:03
Logger: homeassistant.helpers.entity
Source: helpers/entity.py:1266
First occurred: 7:11:26 PM (2 occurrences)
Last logged: 7:11:26 PM

Update of camera.valetudo_v1_silenttepidstinkbug_camera is taking over 10 seconds
Update of camera.valetudo_s5_glossyhardtofindnarwhal_camera is taking over 10 seconds

Function, that in your opinion is creating the issue.

Image Aspect Ratio

Additional information

It is possible to improve the startup of the integration. The idea is to store the trims and image hash so that we will be possible to avoid the re-calculation of the trims as it was already done. Those values need to be updated at every home assistant restart.

sca075 commented 2 months ago

The issue seams related to the first image creation, I'm currently evaluating a possible solution as per it looks that image trimming (as expected) is taking longer at the first image as per the trims need to be defined. One possible option is to store the trims and reload them at start up (as it was done in several versions earlier). This imply a modification on the config_flow to allow the storage of this parameters once the image is fully completed (after the vacuum has all data).