fix: Growatt solar, prevent invalid readouts during boot cycle

[rfpronk]

What does this implement/fix?

Early morning when first light hits the solar panels the inverter boots up and powers the USB port on which the ESPhome device is powered.
The first readouts can be invalid, giving either invalid values or values from the previous day, which is annoying when counting energy production per day. (this ruins home assistant energy dashboard graphs).
This PR gives the inverter a bit time (30s) to complete it's boot cycle before ESPHome will pay attention to the data values it will be sending.

I wrote this fix in the evening, but I can't this in the evening. Compilation works and tomorrow when the sun shines again I will flash this branch and let it run for a couple of days to see if the spikes are gone.

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Other

Related issue or feature (if applicable): fixes esphome/issues/issues/3965

Pull request in esphome-docs with documentation (if applicable): esphome/esphome-docs/pull/3832

Test Environment

• ESP32
• ESP32 IDF
• ESP8266
• RP2040
• BK72xx
• RTL87xx

Example entry for config.yaml:

Example will do the trick, https://esphome.io/components/sensor/growatt_solar.html

Checklist:

• The code change is tested and works locally.
• Tests have been added to verify that the new code works (under tests/ folder).

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated in esphome-docs.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 54.18%. Comparing base (4d8b5ed) to head (2c3a4fd).
Report is 586 commits behind head on dev.

Additional details and impacted files

@@            Coverage Diff             @@
##              dev    #6724      +/-   ##
==========================================
+ Coverage   53.70%   54.18%   +0.47%     
==========================================
  Files          50       50              
  Lines        9408     9587     +179     
  Branches     1654     1689      +35     
==========================================
+ Hits         5053     5195     +142     
- Misses       4056     4067      +11     
- Partials      299      325      +26     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jesserockz]

This should be a user configurable config of duration that defaults to 0s (to no break existing configs).

This user provided time should then just be checked inside update and just do a return if its less than the time, preventing it from ever sending any data requests.

[rfpronk]

Thanks for your review.

This should be a user configurable config of duration that defaults to 0s (to no break existing configs).

This only happens after startup (when the inverter comes online) and when flashing a new esphome (and thus restart). It will only take a bit longer for the first reading to be available. imho it doesn't break existing config and a user configurable value might work confusing. Would you still prefer a user configurable setting? I'm just curious to your thoughts here. Never mind, I implemented it 👍

This user provided time should then just be checked inside update and just do a return if its less than the time, preventing it from ever sending any data requests.

Good point, I will change this soon

This morning it worked fine on my unit, the invalid spike in readout was gone so the idea does the trick on the initial issue 👍

[probot-esphome]

Hey there @leeuwte, mind taking a look at this pull request as it has been labeled with an integration (growatt_solar) you are listed as a code owner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[jesserockz]

Looks better =)
Just a few minor things below

[jesserockz]

Suggested change

	cv.Optional(CONF_WARM_UP_TIME, default=0): cv.uint8_t,
	cv.Optional(CONF_WARM_UP_TIME, default="0s"): cv.All(cv.positive_time_period_seconds, cv.uint8_t),

[rfpronk]

Sorry for asking, but setting a string as default for an int would cause an issue right? Or does the Optional function convert/cast that? The int() cast on line 169 will error on "0s" but can handle "0"

[esphome]

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍

Learn more about our pull request process.