-
-
Notifications
You must be signed in to change notification settings - Fork 37.5k
Wake on LAN for UI-configured Samsung TVs #33621
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
2836644
3eb10a2
e3e5205
0569bdc
23e31fa
4b81515
70a893b
336edd1
0fa89eb
ade860c
485b8a3
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,10 +1,12 @@ | ||
| """Config flow for Samsung TV.""" | ||
| from functools import partial | ||
| import socket | ||
| from urllib.parse import urlparse | ||
|
|
||
| from getmac import get_mac_address | ||
| import voluptuous as vol | ||
|
|
||
| from homeassistant import config_entries | ||
| from homeassistant import config_entries, core | ||
| from homeassistant.components.ssdp import ( | ||
| ATTR_SSDP_LOCATION, | ||
| ATTR_UPNP_MANUFACTURER, | ||
|
|
@@ -15,6 +17,7 @@ | |
| CONF_HOST, | ||
| CONF_ID, | ||
| CONF_IP_ADDRESS, | ||
| CONF_MAC, | ||
| CONF_METHOD, | ||
| CONF_NAME, | ||
| CONF_PORT, | ||
|
|
@@ -174,3 +177,41 @@ async def async_step_reauth(self, user_input=None): | |
| self.context["title_placeholders"] = {"model": self._title} | ||
|
|
||
| return await self.async_step_confirm() | ||
|
|
||
| @staticmethod | ||
| @core.callback | ||
| def async_get_options_flow(config_entry): | ||
| """Define the config flow to handle options.""" | ||
| return SamsungTVOptionsFlowHandler(config_entry) | ||
|
|
||
|
|
||
| class SamsungTVOptionsFlowHandler(config_entries.OptionsFlow): | ||
| """Handle a SamsungTV options flow.""" | ||
|
|
||
| def __init__(self, config_entry): | ||
| """Initialize.""" | ||
| self.config_entry = config_entry | ||
|
|
||
| async def async_step_init(self, user_input=None): | ||
| """Manage the options.""" | ||
| if user_input is not None: | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No validation?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The only risk here is a malformed MAC address, which is no different than a wrong MAC address. This is an advanced feature, and the input will most likely be pasted (unless obtained automatically). The wrong/malformed address will fail quickly and be easy to fix. Given all of the above, I don't think the validation overhead is worth it.
OnFreund marked this conversation as resolved.
|
||
| if CONF_MAC not in user_input or user_input[CONF_MAC].strip() == "": | ||
| user_input.pop(CONF_MAC, None) | ||
| return self.async_create_entry(title="", data=user_input) | ||
|
|
||
| if CONF_MAC in self.config_entry.options: | ||
| current_mac = self.config_entry.options[CONF_MAC] | ||
| else: | ||
| hostname = self.config_entry.data[CONF_HOST] | ||
| try: | ||
| current_mac = await self.hass.async_add_executor_job( | ||
| partial(get_mac_address, **{"hostname": hostname}) | ||
| ) | ||
| except OSError: | ||
| LOGGER.info("Could not find mac address for %s", hostname) | ||
| current_mac = "" | ||
|
|
||
| schema = { | ||
| vol.Optional(CONF_MAC, description={"suggested_value": current_mac}): str | ||
| } | ||
| return self.async_show_form(step_id="init", data_schema=vol.Schema(schema)) | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to unload and setup the entry again? The action is created at runtime and saved at
hass.data[DOMAIN][ip_address][CONF_ON_ACTION]. Why do we not override it and use this directly in the entity?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting point. TBH I haven't thought of this direction until you wrote this.
Updating
hass.data[DOMAIN][ip_address][CONF_ON_ACTION]won't be enough - the entity currently gets its processedon_scripton initialization. We can have the entity listen to the update and handle accordingly. It might be a bit simpler, but potentially a bit more error prone.The advantages of the unload/reload approach are:
Anyway, pros and cons to both approaches - I'm fine with whatever you choose.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we going to wait for the linked issue? I would decide for the most future proof way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see a reason to wait - this PR provides benefits as it is, even without the arch issue ever being implemented. The link is just to support the unload route as the more future proof one.