Service call feedback

Feature Requests
1

Hi,

When doing automations in NodeRED (similar to the internal HA automations) it is possible to issue service calls to get HA to change entity states etc. Unfortunately there is no feedback on that service call. So after making the service call, it is not possible to check if the call has been properly processed.

However, this is not only the case with NodeRED. Even when calling a service in Developer Tools there is no feedback on the success of the call, other than human interaction to see if the requested action actually worked. The same applies to API calls, which do give you feedback but only tell you if the web call itself was successful but provides no information about the status of the actual service call.

This is properly documented with just about every Home Assistant video released (even those by Nabu Casa themselves), as a device is always used (usually lights) to show HA has taken action, instead of there being some programmatic (JSON) response.

In many cases this is not necessary as (NodeRED and internal) automation has been working fine without this. However, giving feedback is simply good development, and in some cases you would definitely want to know (and be able to check in an automation) if a service call has resulted in an error or not.
For example when arming (or disarming) the alarm, where you may want to take additional action on a failed call. Or when processing a conversation where you would want feedback on what HA has done or not.

And with conversation.process we have the one notable exception (afa i can see in the docs @ Conversation API | Home Assistant Developer Docs). With a conversation.process call an API call does result in feedback on successes, fails and errors. So HA is technically capable of gving service call feedback, it’s just not showing it in DevTools\Services and NodeRED calls.

I would propose a change to HA to be able to give feedback (in automations, DevTools and also NodeRED) when making a service call.
For automations (and in NodeRED) i would propose an optional checkmark with the service call (node) to tell the automation to wait for a response.

2

You might see a success, fail or error, but it is not what you think.
It is just the status of the actual call going out and not actually a representation of the result of it.

This might help:

3

Indeed, it is not what you think, that is my point. In NodeRED the service call output only replicates the command as configured (or an error if there was a problem with the config), and not the actual result of the service call.

I’m not exactly sure why the Retry Service integration is relevant here. While it does retry for a number of times as long as the given expected state is not reached, which may be a kind of workaround in some cases, it still does not give any feedback on what HA has actually done with the service call.
For example: when doing a toggle service call to a light it would be nice to have feedback on what state the light has been toggled in to.

Again: the conversation.process call “turn on the lights in the living room” (from text, by Telegram or Signal for example) refers to the living room area where all lights should be swiched on. I’d want to give textual feedback on which lights in the office area have been turned on and which ones have not, or what (if anything) has failed.
A conversation API call will return that info (as documented: Conversation API | Home Assistant Developer Docs), an HA internal process call (by DevTools or NodeRED) will not.

4

I think you will find so many exceptions to this feature that it would be better to make the test yourselfb ith what tools are already available.

This feature will have to handle technologies with no feedback, like RF.
Scripts and automation will need feedbacks coded in.
Timeouts will have to be set to get an acceptable level of false positives, because even though technologies have feedback, then there is rarely a set timeout in actions.
Timeouts might have to be set differently for each device, because a curtain motor will be slower to reach its goal than an on/off lightbulb.
Leaving timeouts up to the user will create hell with false positives, so it has to be centrally administrated.

HA makes the service calls available and HAakes the sensors available where possible.
It will have to be up to you to connect those in an automation.

5

I realise this feature request has some complications and consequences. And as I’ve already said: it is not always needed, and indeed there are integrations that do not (are not able to) even provide feedback on a given command. And for the most part, if the technology is reliable, that is fine (well… sort-of…).

However, I do feel that for integrations where logic feedback is given (like conversation.process) this feedback should be made available to an automation. Whether that’s being done natively or in node-red. (And in Node-RED this could easily be done by adding a checkbox: “Wait for reply” with a given time-out in the call service node).

If you look at the history of Smart Home technology, the first devices just provided control and no feedback. Newer technologies (Zigbee, Zwave, Matter) have since advanced to not only give command status feedback, but now also allow querying the state of a device (without changing its state). This is progress, and while I understand the implications it may have for HA as an application, it appears HA is not always following suit here.

Telling me as a user “yeah, just work your way around it…” is imho an easy way out, and does not help progress. Nor will a focus on obstacles instead of possibilities. This needs to start somewhere.

Furthermore, as more advanced technologies (like speech & AI) become available for use (perhaps even locally), logic feedback will become more and more important. It’s fine and dandy to incorporate local speech recognition as input (although I do feel this is way overhyped and other issues could benefit from some development love), the other side of the coin is that output ánd automation need to be addressed too.

Currently, HA is somewhat lacking here and it will need to ready itself for this. The “fire-and-fingers-crossed” approach may work for the majority of devices, but for more advanced functions it is outdated, by no means future-proof, and (dare I say it…) not a good developement strategy. Especially considering this feedback is given when calling an API.

Logic feedback is a necessity for advanced functions like speech recognition where automation logic needs to be able to understand what exactly has been done and what not (and why), at least so it can inform the user but even more importantly: so the automation is able to act on it.

6

The majority of smart home actions is occurring due to a persons presence and that person will be able to detect the action faster than any feedback will ever be, because the underlying technology does not provide that feature.
Trying to force that feature through with a lacking technology will just result in a lot of false positives cases.

I agree that there might be a few automation cases where there is no action based on a persons presence this would be great, but NodeRed have a “Wait for” node and HA have it in its script commands.
The functionality is there, but just not as part as the service call.
This way it can be applied in only those cases where it makes sense.

7

Fortunately the HA team has realized the need for service call feedback and has begon to make changes to implement this with the latest release. Starting with service calls where this makes sense.
I can only hope this will expand in the future.

With this my Feature Request is implemented, this topic is no longer an open issue.