Charging schedule gets updated hourly when EV is physically not conne…

[quartien]

Adding an extra condition to "not_charging". When the EV is not connected, the charging schedule gets updated hourly so you can see in advance when charging can happen in the future.

[codecov[bot]]

Codecov Report

Patch and project coverage have no change.

Comparison is base (7599e84) 99.87% compared to head (4742b83) 99.87%.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #181 +/- ## ======================================= Coverage 99.87% 99.87% ======================================= Files 14 14 Lines 1581 1581 ======================================= Hits 1579 1579 Misses 2 2 ``` | [Files Changed](https://app.codecov.io/gh/jonasbkarlsson/ev_smart_charging/pull/181?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=Jonas+Karlsson) | Coverage Δ | | |---|---|---| | [custom\_components/ev\_smart\_charging/coordinator.py](https://app.codecov.io/gh/jonasbkarlsson/ev_smart_charging/pull/181?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=Jonas+Karlsson#diff-Y3VzdG9tX2NvbXBvbmVudHMvZXZfc21hcnRfY2hhcmdpbmcvY29vcmRpbmF0b3IucHk=) | `99.43% <ø> (ø)` | |

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[jonasbkarlsson]

Thanks for providing the PR. I have some related changes on-going that I need to check if it works well with your suggestion or not.

Ignore the codecov failures.

Can you provide some short description of the startup problems that you fixed with the updates yesterday?

[mnordseth]

I see the same startup issue, may be a race condition where ev smart charging integration is loaded before norpool. This is form my log:

2023-08-29 10:53:16.532 ERROR (MainThread) [homeassistant.components.switch] Error while setting up ev_smart_charging platform for switch Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 370, in _async_setup_platform await asyncio.gather(pending) File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 510, in async_add_entities await asyncio.gather(tasks) File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 750, in _async_add_entity await entity.add_to_platform_finish() File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1003, in add_to_platform_finish await self.async_added_to_hass() File "/config/custom_components/ev_smart_charging/switch.py", line 66, in async_added_to_hass await self.async_turn_on() File "/config/custom_components/ev_smart_charging/switch.py", line 87, in async_turn_on await self.coordinator.switch_active_update(True) File "/config/custom_components/ev_smart_charging/coordinator.py", line 388, in switch_active_update await self.update_configuration() File "/config/custom_components/ev_smart_charging/coordinator.py", line 513, in update_configuration await self.update_sensors(configuration_updated=True) File "/config/custom_components/ev_smart_charging/coordinator.py", line 534, in update_sensors price_state = self.hass.states.get(self.price_entity_id) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/core.py", line 1505, in get return self._states.get(entity_id.lower()) AttributeError: 'NoneType' object has no attribute 'lower'

[jonasbkarlsson]

@mnordseth and @quartien what version of HA are you using (that causes such race condition problems)?

The integration handled such race conditions without problems before. At least, I haven't heard about this kind of problems until now.

[mnordseth]

I am running Home Assistant 2023.8.4

[quartien]

Same here, I'm also running Home Assistant 2023.8.4 Still investigating. Not sure yet, if related with nordpool. I'm using EV SOC and EV Target SOC from the Volkswagen We Connect ID integration, that takes some of time to start up.

[jonasbkarlsson]

Have tested a little with HA 2023.8.4, but have so far not been able to recreate the error.

However, as far as I can see, this error should only be able to occur during startup of the integration. After the integration has completed it's startup, everything should work correctly.

Could you please confirm that this is what happens? Or do you see anything strange, except the Error message in the logfile?

[mnordseth]

From what I have seen, it only happens on startup. I don't see any other issues, and it can be resolved by reloading the integration after home assistant has started.

[quartien]

Tested with 2 installations:

• HA 2023.8.4 OS on raspberry pi: it happens at startup, some switches are disabled, you have to reload the integration, then everything is fine.
• HA 2023.8.4 Docker on intel NUC: I cannot reproduce. The order of starting the integrations is different though, most probably based on which integration was installed first ? Points to some kind a race condition.

[jonasbkarlsson]

Tested with 2 installations:

• HA 2023.8.4 OS on raspberry pi: it happens at startup, some switches are disabled, you have to reload the integration, then everything is fine.
• HA 2023.8.4 Docker on intel NUC: I cannot reproduce. The order of starting the integrations is different though, most probably based on which integration was installed first ? Points to some kind a race condition.

Can you enable debug logging, and share the log file for the case when you get the error at startup?

[jonasbkarlsson]

I have made a pre-release v1.9.0-dev1 that I believe should fix the startup problem.

Since I have not been able to recreate the problem myself, I can't verify that the startup problem actually is fixed. Could someone try and report back?

The problem I have identified is that if the SWITCH platform is started before the SENSOR platform, the errors reported above could happen. So I have simply changed the order of initialization, now starting with the SENSOR platform first. To my understanding, the startup problem should not be related to other integrations such as Nordpool.

[quartien]

I verified the pre-release v1.9.0-dev1 and it seems to work fine. Problem did not occur after 5 restarts.

Thx,

[mnordseth]

Looks good for me also. Thank you for the quick resolution and a great integration!

[jonasbkarlsson]

Ok, thanks! So @quartien, will you remove the commits related to the startup problem? And maybe rebase on the latest main commit?