8000 Adds port/SSL config options for RainMachine by bachya · Pull Request #8986 · home-assistant/core · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Adds port/SSL config options for RainMachine #8986

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

Merged
merged 6 commits into from
Aug 15, 2017

Conversation

bachya
Copy link
Contributor
@bachya bachya commented Aug 14, 2017

Description:

Adds the ability to specify two more configuration options when querying a RainMachine locally:

  • port: the TCP port used by the device for its REST API (default: 8080)
  • ssl: whether HTTPS should be used on all requests (default: true)

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

Example entry for configuration.yaml (if applicable):

switch:
  platform: rainmachine
  ip_address: 192.168.1.100
  password: my_password
  port: 8080
  ssl: true

Checklist:

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

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

  • New dependencies have been added to the REQUIREMENTS variable (example).
  • New dependencies are only imported inside functions that use them (example).
  • New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.

@bachya bachya changed the title Adding port/SSL config updates for RainMachine Adding port/SSL config options for RainMachine Aug 14, 2017
@bachya bachya changed the title Adding port/SSL config options for RainMachine Adds port/SSL config options for RainMachine Aug 14, 2017
Copy link
Member
@MartinHjelmare MartinHjelmare left a comment

Choose a reason for hiding this comment

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

Is this a breaking change?

@@ -42,10 +43,12 @@
vol.Email(), # pylint: disable=no-value-for-parameter
vol.Required(CONF_PASSWORD):
cv.string,
vol.Optional(CONF_PORT):
Copy link
Member

Choose a reason for hiding this comment

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

Set defaults here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Got it.

vol.Optional(CONF_ZONE_RUN_TIME, default=DEFAULT_ZONE_RUN_SECONDS):
cv.positive_int,
vol.Optional(CONF_HIDE_DISABLED_ENTITIES, default=True):
Copy link
Member

Choose a reason for hiding this comment

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

Is removing this a breaking change?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not really:

  1. The functionality of this parameter (a) was acting poorly with the device and (b) didn't provide any tangible benefit.
  2. This parameter was disabled and undocumented to begin with.
  3. Based on the changes made at the bottom of async_setup_platform, even if a user leaves this option in the config, nothing will break.

Copy link
Member

Choose a reason for hiding this comment

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

TLDR: Ok.

Even if the change doesn't break a user's set up it's good to mark the PR as breaking if the user looses configurability. In this case, since the option was not documented, and it's a young platform, it could be ok to not mark it as breaking. Although, if there's a feature or non-feature in the code, you can usually be sure that there's someone that depends on 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.

Got it, good to know – will keep that in mind going forward.

Although, if there's a feature or non-feature in the code, you can usually be sure that there's someone that depends on it.

That made me LOL. 😆

entities.append(
RainMachineProgram(
client, program, device_name=rainmachine_device_name))
if program.get('active'):
Copy link
Member

Choose a reason for hiding this comment

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

I liked the guard clause that was used before. But do as you like here.

Copy link
Contributor Author
@bachya bachya Aug 15, 2017

Choose a reason for hiding this comment

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

The guard is still there – it just looks different (especially considering my above comment):

Previous: "If a program/zone is disabled and hide_disabled_entities is true, skip it."

New: "If a program/zone is enabled, show it."

Copy link
Member
@MartinHjelmare MartinHjelmare Aug 15, 2017

Choose a reason for hiding this comment

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

I was referring to using a guard clause to let the normal path of execution be not indented. But the code is not nested here so it doesn't matter really.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's your call: I'm happy to accommodate. This flow is more readable to me (only include something if it's enabled), but if you'd prefer a guard clause, I can certainly do it.

RainMachineProgram(
client, program, device_name=rainmachine_device_name))
if not program.get('active'):
pass
Copy link
Member

Choose a reason for hiding this comment

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

continue

Copy link
Member
@MartinHjelmare MartinHjelmare left a comment

Choose a reason for hiding this comment

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

Nice!

8000

@bachya
Copy link
Contributor Author
bachya commented Aug 15, 2017

Appreciate your help, @MartinHjelmare!

@MartinHjelmare MartinHjelmare merged commit eb42d59 into home-assistant:dev Aug 15, 2017
dethpickle pushed a commit to dethpickle/home-assistant that referenced this pull request Aug 18, 2017
* Adding port/SSL config updates

* New requirements generated

* Made `port` and `ssl` parameters optional

* Add defaults for new parameters

* Re-adding guard clause

* pass > continue
@bachya bachya deleted the rainmachine_updates branch August 22, 2017 18:12
@balloob balloob mentioned this pull request Aug 25, 2017
@home-assistant home-assistant locked and limited conversation to collaborators Dec 11, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0