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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scaffold device automation #26871

Merged
merged 1 commit into from Sep 27, 2019

Conversation

@balloob
Copy link
Member

commented Sep 24, 2019

Description:

Scaffold script to bootstrap device automations.

  • python3 -m script.scaffold device_trigger
  • python3 -m script.scaffold device_condition
  • python3 -m script.scaffold device_action

Docs home-assistant/developers.home-assistant#321


async def async_get_triggers(hass: HomeAssistant, device_id: str) -> List[dict]:
"""List device triggers for NEW_NAME devices."""
registry = await entity_registry.async_get_registry(hass)

This comment has been minimized.

Copy link
@dmulcahey

dmulcahey Sep 24, 2019

Contributor

Should the script expose the ability to have both device and entity based triggers? Ex: in the case of stateless devices (remotes) there are no entities. Maybe pass the device to a private method to add device triggers, get the entities and then pass them to a private method to add entity triggers if necessary?

This comment has been minimized.

Copy link
@balloob

balloob Sep 24, 2019

Author Member

I've added a comment with some commented out code from the ZHA integration.

)


async def async_get_conditions(hass: HomeAssistant, device_id: str):

This comment has been minimized.

Copy link
@dmulcahey

dmulcahey Sep 24, 2019

Contributor

Same as above. Should this expose the ability to do this at both device and entity levels?

This comment has been minimized.

Copy link
@balloob

balloob Sep 24, 2019

Author Member

We should aim for device conditions to be a layer on top of existing state conditions. We should not have device conditions that get data that is not available in the state machine.

return test_is_on


async def async_get_actions(hass: HomeAssistant, device_id: str) -> List[dict]:

This comment has been minimized.

Copy link
@dmulcahey

dmulcahey Sep 24, 2019

Contributor

Same as above. Should this expose the ability to do this at both device and entity levels?

This comment has been minimized.

Copy link
@balloob

balloob Sep 24, 2019

Author Member

Added a comment to the generated code. Let me know if you think that it's enough.


# Add triggers for each entity that belongs to this integration
# TODO add your own triggers. It's ok to not have any triggers.
triggers.append(

This comment has been minimized.

Copy link
@dmulcahey

dmulcahey Sep 24, 2019

Contributor

Should these blocks just be part of the comment above to illustrate how to do this? Or is there value in assuming/treating everything works like an on/off type of device? It looks like the script is designed to treat everything like a toggle entity.

This comment has been minimized.

Copy link
@balloob

balloob Sep 24, 2019

Author Member

It was mainly to get tests going and show people how it should look.

You think that we should comment it out to emphasize that it's an example ?

This comment has been minimized.

Copy link
@dmulcahey

dmulcahey Sep 24, 2019

Contributor

If you’re not worried that people will leave it in their implementations then leave it.

This comment has been minimized.

Copy link
@balloob

balloob Sep 25, 2019

Author Member

Let's leave it in and see what the PRs do.


# Add conditions for each entity that belongs to this integration
# TODO add your own conditions. It's ok to not have any conditions.
conditions.append(

This comment has been minimized.

Copy link
@dmulcahey

dmulcahey Sep 24, 2019

Contributor

Same as above. Should this just be part of the comment?


# Add actions for each entity that belongs to this integration
# TODO add your own actions. It's ok to not have any actions.
actions.append(

This comment has been minimized.

Copy link
@dmulcahey

dmulcahey Sep 24, 2019

Contributor

Same as above. Should this just be part of the comment?

@balloob balloob referenced this pull request Sep 24, 2019
5 of 5 tasks complete
@balloob balloob force-pushed the scaffold-device-automation branch 2 times, most recently from eb20b84 to ae25772 Sep 24, 2019
@balloob

This comment has been minimized.

Copy link
Member Author

commented Sep 24, 2019

I have updated the templates to match our new device automation organisation. It's now 3 templates : device_trigger, device_condition, device_action.

device_action
@balloob balloob force-pushed the scaffold-device-automation branch from ae25772 to f0d9812 Sep 25, 2019
@MartinHjelmare MartinHjelmare moved this from Needs review to Review in progress in Dev Sep 26, 2019
@balloob balloob merged commit 77654da into dev Sep 27, 2019
11 checks passed
11 checks passed
CI Build #20190925.4 succeeded
Details
CI (FullCheck Mypy) FullCheck Mypy succeeded
Details
CI (FullCheck Pylint) FullCheck Pylint succeeded
Details
CI (Overview CheckFormat) Overview CheckFormat succeeded
Details
CI (Overview Lint) Overview Lint succeeded
Details
CI (Overview Validate) Overview Validate succeeded
Details
CI (Tests PyTest Python36) Tests PyTest Python36 succeeded
Details
CI (Tests PyTest Python37) Tests PyTest Python37 succeeded
Details
cla-bot Everyone involved has signed the CLA
codecov/patch 100% of diff hit (target 94.14%)
Details
codecov/project 94.14% (target 90%)
Details
Dev automation moved this from Review in progress to Done Sep 27, 2019
@delete-merged-branch delete-merged-branch bot deleted the scaffold-device-automation branch Sep 27, 2019
@lock lock bot locked and limited conversation to collaborators Sep 28, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
Dev
  
Done
4 participants
You can’t perform that action at this time.