Feature Request: Enhanced Service Call Descriptions with Secondary Information
Summary: Requesting the enhancement of service call descriptions in Home Assistant to include secondary information by default. This feature aims to provide more detailed insights into the specific actions and configurations within each service call, improving overall clarity and usability.
Description: Currently, Home Assistant allows users to rename each component of a service call for better understanding. However, when copying and pasting service calls, users must manually adjust all the renamed parts, which can be time-consuming and error-prone.
This feature would enable the default description of a service call to automatically include secondary information, such as the specific parameters and settings of each action. This would offer a more comprehensive and accurate description of what each part of the service call is doing, providing a clearer high-level overview.
Benefits:
Enhanced Clarity: Including secondary information in the default description allows users to see detailed configurations at a glance.
Simplified Maintenance: Reduces the need for renaming components and adjusting descriptions when duplicating and updating service calls.
Improved Usability: Supports users in managing and understanding their service calls more effectively, whether they are novices or advanced users.
Example: Current State:
Service Call: āCall a service āClimate: Set HVAC modeā on iZone Controllerā
Parameter: Heat
Proposed Enhancement:
Service Call: āCall a service āClimate: Set HVAC modeā on iZone Controllerā
Description: āSets HVAC operation mode to Heat on iZone Controller.ā
Action: Set HVAC mode (Description: āSets HVAC operation mode.ā)
Parameter: Heat (Included in the description)
This feature will significantly enhance the functionality and user experience within Home Assistantās service call interface by providing more detailed and accurate descriptions.
I mean, you have markdown available, you can put whatever you want in a description now in most any format.
And if you want auto stuff put in there, how would it know what to put there. When the description is written the automation is not running. You likely have not even picked entities , devices, or events then.
You would have to describe a better use case and how this could possibly work.
Not sure what you are saying of if you understand what i have described, even though i thought the image was prety clear
Ok let me tray again
all im asking for is the default description that populates for an action part of the automation could have more info ie As you can see from the picture, the description part of the automation doesnāt not reference any part of the HVAC Mode.
The current default description when you dont rename the action step is:
āCall a service āClimate: Set HVAC modeā on iZone Controllerā
IM saying this part should also reference the secondary/parameter of what ever you call it when a service is called the default description should read
Call a service āClimate: Set HVAC mode to Heatā on iZone Controller
does that make sense? I ahve fixed up mu original post as well, as i can see the confusion
You would need this for your first, what 3 automations, then delete it because it got in the way of actual functionality. I really donāt see a need, but it is probably a [FR]. Good luck getting someone to help with it.
Suggested Reading: More about Feature Requests.
I think this is a reasonable FR and in fact plenty of automation parts already have this kind of information.
For example conditions that require a specific state for a specific time do include that in the autidescription.
So it would definitely make sense to include the parameters of the service calls.
Another example would be set cover position service. Itās frankly a bit weird that the auto description didnāt include the information on what is the position supposed to be set to.
With some service calls it might be a bit problematic if there are a lot of parameters, but I think it would be fine to either list them all or just some and add āand moreā at the end.
I think this is going to be very hard to understand to people who donāt actually use the visual interface of automations.
Hereās an example of an actual automation I run, that calls the light.turn_on service 3 times, but each time with different parameters. The screenshot is in Polish, but it should give you an idea still:
If this FR would be done, then each light.turn_on would include the parameters that are set (brightness, transition, color temperature in this specific case). Which would make it easier for the future me to understand at quick glance what I did in this automation.
I think your title and description was just a bit too general, while in reality this is specifically about service calls and their parameters. If a FR is super general, it makes it easier to see it as unachievable, which is I think what happened here.
I just checked for device trigger , and device condition using a device that reports temp and humidity and its the same. I think it need to be something thats system wide meaning service calls, devices entities etc
if the description gets to long then just hide it, they do that for the Labels. when its over 2 labels, see image
oh well, i think it just completes things a bit more, makes everything unified, easy to understand what the automation is doing. This all came about as im doing some big climate automations for each room
Bear with me. Still not completely following, but I will give you this that might help.
If this is a thing where state triggers have the information you use, but device triggers do not, then you could write up an issue against the frontend as a feature parity problem, explaining this thing can so this great thing, and another feature that to the user should do that same thing does not.
That is a legit request and you will find those are often able to be fixed.
When there is a basis and another function does a thing, but this function that presents very similar does not do it, often that is leverage to get them both to do it by presenting an issue in that way.
