-
-
Notifications
You must be signed in to change notification settings - Fork 29.3k
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
Add TRIGGERcmd integration #121268
base: dev
Are you sure you want to change the base?
Add TRIGGERcmd integration #121268
Conversation
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.
Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍 |
I don't know what "Collect information & changes data Expected — Waiting for status to be reported" means. Do I need to provide that data and report status somehow? |
GitHub won't run most workflows on a PR for a first-time contributor to a repository (to protect against people abusing their workflow runners for crypto mining/scams). I believe after someone gets their first PR merged, workflows will then run automatically in the future. I went ahead and triggered the workflows to run 🙂 |
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.
Couple initial review comments...
self._switch.remove_callback(self.async_write_ha_state) | ||
|
||
@property | ||
def device_info(self) -> DeviceInfo: |
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'm not familiar with triggercmd but from the variable names I think we should create a device per computer
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 considered that, but I decided each triggercmd trigger should be represented as a device because the Alexa, Google Assistant, and SmartThings integrations create a virtual on/off switch device for each trigger. It makes it easier to educate triggercmd users if the integrations work similarly. I hope that's ok.
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.
Nope, we should create one device per computer so all triggers of one computer are grouped in the UI, too.
A device includes additional features like disabling a device, which will also disable all entities for that device. It's common for users to disable devices for a certain time of the year (ex. Disable the sprinkler during the winter)
Co-authored-by: Robert Resch <[email protected]>
Co-authored-by: Robert Resch <[email protected]>
Co-authored-by: Robert Resch <[email protected]>
Co-authored-by: Robert Resch <[email protected]>
Breaking change
Proposed change
Add the new triggercmd integration.
Type of change
Additional information
Checklist
ruff format homeassistant tests
)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest
.requirements_all.txt
.Updated by running
python3 -m script.gen_requirements_all
..coveragerc
.To help with the load of incoming pull requests: