Fix binary_sensor initial publish

[dudanov]

What does this implement/fix?

Fixes an error in the initial publication of the state of the binary sensor during the use of filters.

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

https://community.home-assistant.io/t/esphome-fails-to-update-sensor-state-in-ha-when-using-4-second-delay-filters-workaround/347541

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

Test Environment

• ESP32
• ESP32 IDF
• ESP8266
• RP2040

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.

[probot-esphome]

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

[jesserockz]

Im gonna close this as I think the filters should not alter the data unexpectedly like this. #5091 should fix the problem you were having by publishing false as initial. Let me know if something else is still required though.

[dudanov]

Im gonna close this as I think the filters should not alter the data unexpectedly like this. #5091 should fix the problem you were having by publishing false as initial. Let me know if something else is still required though.

Jesse, I wouldn't create a PR or make corrections if it wasn't required. #5091 does not fix the whole problem. Since the method publish_initial_state still runs through all the filters that delay the publication of the signal. If you are familiar with automation, then there are no and should not be indeterminate states, exceptions in electrical engineering are the so-called Z-states. The standard automation library has functional blocks TON, TOF, etc., they all have certain states at the output. This PR is necessary as it solves this problem.

[jesserockz]

The main issue I see here is that if you specifically have a filter that delays any state being reported until you need a true or false from startup, this code will break that by forcing a false return.

A BinarySensor has .has_state() to tell you if this sensor has a state published yet or not.

I'll reopen, but not satisfied with the solution (yet)

[dudanov]

A BinarySensor has .has_state() to tell you if this sensor has a state published yet or not.

In lambda, yes, I can. But this is not an option, especially since the user interface cannot be configured out of the box to display false instead of undefined.

[github-actions]

There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. Thank you for your contributions.