homeassistant

12072 readers

21 users here now

Home Assistant is open source home automation that puts local control and privacy first. Powered by a worldwide community of tinkerers and DIY enthusiasts. Perfect to run on a Raspberry Pi or a local server. Available for free at home-assistant.io

founded 1 year ago

MODERATORS

GreatAlbatross@feddit.uk

Responding Services: What are the Use Cases? (lemm.ee)

submitted 1 year ago by Deez@lemm.ee to c/homeassistant@lemmy.world

9 comments fedilink hide all child comments

In Home Assistant 2023.7 a feature was added to allow services to provide a response.

This release brings in a change to Home Assistant, which we consider to be one of the biggest game changers of the past years: Services can now respond with data! 🤯

It is such a fundamental change, which will allow for many new use cases and opens the gates for endless possibilities.

In this release the functionality has only been enabled for a couple of services, but I’m having trouble picturing what we can use this for now and in the future.

What are some use cases you can think of on how to use this new feature?

you are viewing a single comment's thread
view the rest of the comments

[–] Qpernicus@lemmy.world 7 points 1 year ago (1 children)

I think eventually it will lead to more call-answer automations. More granular control in automations that depend on data from the device.. How high is temp? 40 degrees: turn on airco on position 5. 30? Turn on at position 4. And then more simple to write as an automation I guess. But granted I don’t fully see all the usecases yet compared to current ‘statuses ‘ of device or parameter

[–] Deez@lemm.ee 5 points 1 year ago (3 children)

Thanks for your reply. I’m sure I’m missing something, but in the scenario of a temperature sensor, wouldn’t that info already be available in the temperature entity’s state.

So you could already write a script like this one:

service: climate.set_fan_mode
data:
  fan_mode: >
    {% if states(‘sensor.temperature’) > 40 %} 5
    {% elif 30 > states(‘sensor.temperature’) > 40 %} 4
    {% else %}  3
    {% endif %}
target:
  entity_id: climate.bedroom_thermostat

But again, I’m probably missing something.

Thinking about the calendar service they added, maybe the response is useful for returning multiple pieces of data.

Perhaps a use case is return a history of the previous states, so in your example, you could have a history service that could give you historical values from the temperature sensor. You call asking is the temperature trending up or down, it checks the history and provides a response. Then again, maybe you can already do that with derivative sensors.

Sorry for the scattered response, I feel like I’m on the verge of understanding the feature, but not quite there yet.

[–] RunningInRVA@lemmy.world 1 points 1 year ago

I’m struggling with this too, but I think the idea is that it allows for fully synchronous requests. You can wait for something long running to finish or for response data to be returned (this could be a generated AI response) and still close out the initial request. The old way to do it was to issue the service call and then monitor the state of the entity to confirm it changed.

I also think it can help with multiple service calls tied into the same verbal request (e.g. “Turn on the light and open the shades”).

[–] Qpernicus@lemmy.world 1 points 1 year ago

I think it indeed is about the multiple responses. So more along the lines of when was the temp above X or below Y or Between both. Some along those lines

[–] draecas@lemmy.world 1 points 1 year ago* (last edited 1 year ago) (2 children)

Imagine you have a household with 2 adults and 2 kids, and you've setup some level of presence tracking. You want to use automations to turn off everything if nobody is home, turn on some things if only kids are home, turn on other things if only adults are home, and turn on everything if kids and adults are home. You could build this logic into every automation you have, but it's a lot of repeated logic to put in every time you wanna add something cool.

Blueprints mean you don't have to write it out in every automation. But I've never found them to be especially convenient for updating. And they still have the automation doing all of the heavy lifting.

You could have a home State sensor that you depend on automations to manually update. But this is only as up to date as you make it, either running every so often (stale data) or using automations based on a change in presence tracking to update a sensor (buggy maybe? have not tried it but sounds prone to race conditions and misfires to me). Closer, but unideal IMO.

Or you could pull this logic into a service that returns 1 of 4 possible states - full, empty, kids, adults. Your automation no longer has any logic to figure out what the state is or who's home, it just asks what set of rules are in effect and can apply them. This lets the automation focus on a smaller area, which means less shit that needs updating if you change something, less chance for bugs.

There's not a ton new you can do now that you couldn't accomplish before, but you can do it in smarter, more maintainable ways.

[–] Deez@lemm.ee 1 points 1 year ago

Thanks for the detailed response!

Ok, so I’m thinking script responses would be useful for a sections of logic, that have one (or more) of the following characteristics:

It is more complex than you would want to process in a template sensor (as Scripts have the Trace log, and GUI support)
It is logic that is currently evaluated in multiple scripts/automations, so you can simplify and centralise
It is an evaluation you want to run on demand
It is data that you don’t want to keep in the history database

I think I’m wrapping my head around scripts responses. Still need to imagine how it will work for other services.

[–] 4am@lemmy.world 1 points 1 year ago

Users don’t create their own services, services are how you initiate actions with integrated devices and entities.

You’d still need to create automations based on the first method you described, and it’s already extremely simple using an entity group.