Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Publish birth and will messages by default #37371

Merged
merged 2 commits into from Jul 4, 2020

Conversation

emontnemery
Copy link
Contributor

@emontnemery emontnemery commented Jul 2, 2020

Breaking change

MQTT birth message defaults to: {"topic": "homeassistant/status", "payload": "online"}
MQTT will message defaults to: {"topic": "homeassistant/status", "payload": "offline"}
MQTT will published also on clean connect from broker

Proposed change

MQTT birth message defaults to: {"topic": "homeassistant/status", "payload": "online"}
MQTT will message defaults to: {"topic": "homeassistant/status", "payload": "offline"}
MQTT will published also on clean connect from broker

Type of change

  • Dependency upgrade
  • Bugfix (non-breaking change which fixes an issue)
  • New integration (thank you!)
  • New feature (which adds functionality to an existing integration)
  • Breaking change (fix/feature causing existing functionality to break)
  • Code quality improvements to existing code or addition of tests

Example entry for configuration.yaml:

# Example configuration.yaml

Additional information

  • Link to documentation pull request: TODO

Checklist

  • The code change is tested and works locally.
  • Local tests pass. Your PR cannot be merged unless tests pass
  • There is no commented out code in this PR.
  • I have followed the development checklist
  • The code has been formatted using Black (black --fast homeassistant tests)
  • Tests have been added to verify that the new code works.

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

If the code communicates with devices, web services, or third-party tools:

  • The manifest file has all fields filled out correctly.
    Updated and included derived files by running: python3 -m script.hassfest.
  • New or updated dependencies have been added to requirements_all.txt.
    Updated by running python3 -m script.gen_requirements_all.
  • Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

  • No score or internal
  • 馃 Silver
  • 馃 Gold
  • 馃弳 Platinum

@probot-home-assistant
Copy link

Hey there @home-assistant/core, mind taking a look at this pull request as its been labeled with an integration (mqtt) you are listed as a codeowner for? Thanks!
(message by CodeOwnersMention)

@project-bot project-bot bot added this to Needs review in Dev Jul 2, 2020
@project-bot project-bot bot moved this from Needs review to By Code Owner in Dev Jul 2, 2020
vol.Optional(CONF_WILL_MESSAGE): MQTT_WILL_BIRTH_SCHEMA,
vol.Optional(CONF_BIRTH_MESSAGE): MQTT_WILL_BIRTH_SCHEMA,
vol.Optional(
CONF_WILL_MESSAGE, default=dict(DEFAULT_WILL)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why copy it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I want to avoid hard to find bugs because the DEFAULT_WILL ends up modified somewhere. Is it unnecessary?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Voluptuous will already copy the dict.

image

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, but:
image

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're validating against dict in your test, not {}. When you do {} it will check the keys and their values and make a copy.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, I dropped the useless copy.

Dev automation moved this from By Code Owner to Reviewer approved Jul 3, 2020
@emontnemery emontnemery merged commit b636550 into home-assistant:dev Jul 4, 2020
Dev automation moved this from Reviewer approved to Done Jul 4, 2020
@@ -719,7 +740,7 @@ async def async_disconnect(self):

def stop():
"""Stop the MQTT client."""
self._mqttc.disconnect()
# Do not disconnect, we want the broker to always publish will
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't HomeAssistant set the DEFAULT_PAYLOAD_NOT_AVAILABLE explicitly and then disconnect gracefully here? Otherwise, it may take a while until the MQTT broker detects that the client disappeared, leading to an unnecessary delay...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The connection to the MQTT server is actively broken, and the broker will immediately publish the will.

What you describe is an issue if the connection is not actively broken, in which case the TCP connection will linger until it times out.

If you think this is not the case, please provide a way to reproduce the issue you suggest.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Dev
  
Done
Development

Successfully merging this pull request may close these issues.

None yet

4 participants