Marco issue for missing services on-boarded documentation (thru developer tools/services tab in HA UI).
Easy fix. Perfect for #Hacktoberfest 馃槃
Edit of 09/09/2019: Not always so easy fix as there are some subtleties. Please read the Warning part at the bottom of the issue.
Home Assistant release with the issue:
0.101.0_dev0
Description of problem:
A lot of current integrations are registering services but provide and empty services.yaml
file. It's mean users have no clue how to use the service by using the service tool integrated in HA, except going on online documentation website.
You will find below the current list of integrations with this scenario with a link on the documentation where you should find the data for filling the services.yaml
file.
Integrations to be reviewed:
Integrations OK with an empty services.yaml
file:
I will update this list according to our analysis and your comments in this issue.
configuration.yaml
fileconfiguration.yaml
fileconfiguration.yaml
fileIntegration with services describe in an other integration services.yaml
file and need code rework:
media_player
integrationdevice_tracker
integrationvacuum
integrationWarnings
This issue is not so simple as:
services.yaml
file (for example if services are registered with user defined named like rest_command
).services.yaml
file in an integration folder describe services for the domain of this integration (defined in manifest.yaml
file). It's mean that services registered by platforms added in this integration should be documented in the services.yaml
file in the platform domain folder (example neato
integration registers a specific service for the platform vacuum
and the service documentation is in homeasssitant/components/vacuum/services.yaml
In consequence, please update only services documentation for integration you can test with your home-assistant install. Ideally provide a screenshot in your PR as proof of your validation.
There is some history in #23197
@oncleben31 I would like to take this issue :)
Cool. Avoid grouping your contributions in only one PR. I will update the issue according to the contributions.
Just thinking out loud... Could it be interesting to actually review the services.yaml
format and build a part of the documentation from that file instead of having to duplicate the information in the documentation and in the services.yaml
file?
In this case it will always be up to date :)
@RomRider good idea but this should be discussed with the core team. Perhaps you can open a dedicated topic on the forum or go on discord to start the discussion or open an issue in the architecture repo.
Note that for some of these integrations solving the problem isn't as easy as just filling in or moving the yaml to a new file. The service might be registered under the domain where the yaml description currently resides so the service registration needs to change too before moving the yaml description.
Already taking take of iCloud here : https://github.com/home-assistant/home-assistant/pull/26590
Just a request but please make sure everyone is properly testing the services.yaml
and maybe even provide screenshots showing the service and the description so we all know its working. Some of these services need to have the correct name and need to be under the correct domain as pointed out by @MartinHjelmare
I realised that. I will update the issue description
I swear I've searched for past related issues. I missed the #23197, I don't know how.
I added the entries for the downloader component #27553
@oncleben31 shell_command is basically the same as rest_command in terms of services.
So you should properly move it to 'Integrations OK with an empty services.yaml file'.
And the services.yaml file of the todoist integration is not empty. Tested it on my system and the description is completely visible. Just so you know :)
Thank you to @springstan and @Mofeywalker. Initial list updated.
I added the entry for the media_extractor component.
I also added the entry for the stream component. :)
Documentation for local_file
service local_file_update_file_path
is already added to the services.yaml
file of camera
integration.
Should it be moved to local_file
instead?
Added description for the route53 service.
Documentation for channels
services is already added to the services.yaml
file of media_player
integration.
Should it be moved to channels
instead?
apns service names depend on the notifier name specified in configuration.
Documentation for icloud
services is already added to the services.yaml
file of device_tracker
integration.
Should it be moved to icloud
instead?
It looks like the update_records
service from the cloudflare
component doesn't need anything in its services.yml
file as it's not taking any parameters, only info from the component configuration.
I add for squeezebox. #28247
I added for duckdns. #28248
Added for ness alarm #28250
Seems that the local_file
component already gets its descriptions and example data from somewhere else.
@karouf yeah see: https://github.com/home-assistant/home-assistant/issues/27289#issuecomment-543082787
Missed that one, my bad :sweat:
Onvif
component service has defined in camera
component. https://github.com/home-assistant/home-assistant/issues/27289#issuecomment-543115397
was just going to add the description to the facebox
services.yaml
and found out it's already part of the image_proccessing
component at
https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/image_processing/services.yaml#L10
Thank you all for the contributions, I've updated the issue.
I've some doubts about local_file
(#28330) and onvif
(#28349) PR. @ZiroNL and @fabaff, according to my knowledge it shouldn't work without python code rework. Can you check the service description is working and sharing proof ?
@oncleben31
This is my local dev setup (Dutch)
And
@ZiroNL thank you. I still have a doubt according to @dshokouhi comments in another related PR.
To be sure it's working you should test with your modification and by removing the duplicate description in the services.yaml
of the camera integration. Can you come back to us after testing this?
The service in bluetooth_tracker
is in the device_tracker domain instead of the bluetooth_tracker domain. It would need a code update as part of the services.yaml update
Same issue for flux
, epson
, blackbird
, bluesound
, econet
, html5
, and harmony
using the wrong domain. For harmony
, it is two services that need updates, harmony_change_channel
and harmony_sync
For anyone submitting changes here, please make sure before you decide to update the service domain check the UI and determine if it makes sense. A lot of services are under a certain domain so the drop down to select the entities is populated accordingly. Things like local_file
and harmony
and others allow the user to select the entity based on the domain. Changing the service domain gets rid of this filtering and shows all entities regardless of domain. It makes the UI less user friendly in this case and we should avoid that.
Added my thoughts about that here: https://github.com/home-assistant/home-assistant/pull/28890#issuecomment-556556724
I proposed an architecture change to address this issue as referenced above
Per @balloob's comment here: https://github.com/home-assistant/home-assistant/pull/28890#issuecomment-558485691 we should not worry about entity discovery in the Dev Tools UI when considering moving services to the proper domain
OK! I have updated all custom services to the proper domain that I could find.
As far as I can tell, there are three integrations remaining with empty services.yaml that aren't explained in the original comment:
configurator
joaoapps_join
apns
apns
and joaoapps_join
need to have empty services.yaml's because they are registering services, but the service names are dynamic. Unclear what to do about configurator
but I will leave that to someone else to figure out.
We can drop the services for configurator.
Is there anything left to do to solve this issue?
I believe this can be closed as the only integrations that are left with empty services.yaml
are expected to have empty files
馃帀 Great job everyone ! 馃帀
Most helpful comment
Just thinking out loud... Could it be interesting to actually review the
services.yaml
format and build a part of the documentation from that file instead of having to duplicate the information in the documentation and in theservices.yaml
file?In this case it will always be up to date :)