Make rest sensor and binary sensor more efficient

[exxamalte]

Description:

I am proposing the following small changes to the rest sensor and rest binary sensor:

• Currently, if the initial rest call fails when setting up a rest binary sensor that binary sensor will not be created. I propose to create the binary sensor anyway and keep trying fetching the rest resource to update the status. The component is already capable of handling the case where the rest resource is unavailable.
• Currently, both - rest sensor and rest binary sensor - fetch the rest resource twice during the setup. Once manually, and then again through the add_devices call. I propose to initially only make one call to fetch the rest resource. For the binary sensor I propose to initially only make one call to fetch the rest resource - the sensor state can be determined based on that.
• I also fixed up several test assertions that aren't currently working as expected. The tests pass but the assertions aren't working as intended.

Related issue (if applicable): n/a

Pull request in home-assistant.github.io with documentation (if applicable): n/a

Example entry for configuration.yaml (if applicable):

n/a

Checklist:

• The code change is tested and works locally.
• Local tests pass with tox. Your PR cannot be merged unless tests pass

[fabaff]

We should raise PlatformNotReady. Keep in mind that the platform can't recover if the credentials or header entries are wrong. Then the users will end-up with non-functional platforms in their setup.

[exxamalte]

Thanks for the review - I see what you mean.
I am hoping to find a way to distinguish between recoverable and unrecoverable errors. Once the sensor is correctly set up (correct URL, correct username/password, etc.), it would be nice if the code could handle intermittent errors. At present, if a third-party service used in a rest binary sensor is unavailable just at the time when HA is restarted, that binary sensor is not created.
BTW: A rest sensor is still created in the same situation. And a rest switch is only not created if the HTTP response code is >= 400 or if specific exceptions occur; this may be a role model for sensor and binary sensor?
I'll look into PlatformNotReady.

[exxamalte]

Alright, I wasn't aware that when raising a PlatformNotReady HA automatically retries after 30 seconds (with backoff). That definitely helps with intermittent errors during the setup of the sensors.

[exxamalte]

@fabaff: As suggested I changed the setup of the sensors to raise PlatformNotReady if the rest call does not return data. However this approach requires to fetch the rest resource within the setup method. To keep avoiding fetching that same resource again immediately after the setup I introduced throttling access to the RestData#update method to 10 seconds.

[syssi]

You could set this parameter to false:

https://github.com/exxamalte/home-assistant/blob/bf5edd37d08dbfa0dbe68d3ae1d975d46a47f672/homeassistant/components/binary_sensor/rest.py#L74

To avoid the first update call.

[exxamalte]

@syssi: That approach would work for the rest binary sensor. However, if the rest sensor isn't updated immediately it remains in an unknown state(i.e. self._state remains STATE_UNKNOWN).
Furthermore, the reason that the above would work for the rest binary sensor is because it doesn't cache its state but calculates it every time is_on is called. Most sensors I have seen update their state in their update method and then store that value.

[exxamalte]

Are there any more suggestions on how to improve this PR or can it be merged please?

[syssi]

The problem of throttling the update method is you cannot use a SCAN_INTERVAL < 10 seconds anymore. :-(

[exxamalte]

Yes, that is correct.
So, if update intervals <10 seconds are important, then how about the following compromise: I remove the throttling of the update and remove the immediate update of the rest binary sensor. This means that the rest sensor will still update twice during the initial setup.
In a next step (future PR) I will look at how to refactor the two sensors (and I found a few others that make use of the RestData class) in a way that makes their behaviour more consistent and avoids the two updates during setup.

[exxamalte]

@syssi: Is this now ready to be merged?

[exxamalte]

Is there anything left to do for this PR, or can this be merged now?