#Door and window state querying
tender solstice
Leaving aside the fact that the sentence template could be improved by a lot and I don't think it does what you expect it to do, could you also post the content of your DoorsWindows custom intent?
lean stump
Hi, thanks for the reply. And yes, I'll admit it's probably an awful big of coding, but it was working. However, I would of course love to have something that os much more correct (so I can also learn, as I consider myself a rookie). Anyway, here's the response part
# Doors & Windows
intent_script:
DoorsWindows:
speech:
text: "The doors and windows are {{states('sensor.doors_windows_state')}}"
Basically, I just want to be able to ask assist if any of the windows or doors are open. The binary sensor is binary_sensor.doors_windows
Ultimately, what I would love in the future, is for Assist to be able to answer yes or no, and tell which doors or windows are open if so. But I'm guessing that requires a complete redesign of the code (might be necessary anyway, judging by my bodge job lol)
tender solstice
Ultimately, what I would love in the future, is for Assist to be able to answer ...
Let's start with this. You can do that right now with your custom intent, but it is a bit more complicated. And you need 2 intents, I think: one for "are they?" and one for "which are?". This will be your new best friend in this journey: https://community.home-assistant.io/t/unleash-the-power-of-expand-for-template-sensors/136941
Also, before getting into fixing your sentence, let me explain why HA doesn't do this out of the box, as it does with most other binary_sensors: doors can be either {domain: "cover", device_class: "door"} or {domain: "binary_sensor", device_class: "door"}. Same issue for windows. Similar issue for temperature ({domain: "climate", attribute: "current_temperature"} or {domain: "sensor", device_class: "temperature"}) or locks. For now, HassIL can select a single set of criteria (let's call it "a filter") to match entities. It can't make a union from 2 or more filters, which would be required to answer your sentence out of the box. At some point during the infancy of Assist, we decided to provide this mechanism and only then fix the sentences which could query for open windows/doors, unlocked locks etc.
Turns out, not a lot of people were complaining about such things, so Mike spent more time with other, more critical features such as wake words. In the meantime, we've been bouncing ideas to see what may stick. We will get to it, eventually
that said, your sentence does NOT query a "variable" entity name. It's just a static text template, with a hard-coded entity_id in the response. As such, you don't need requires_context. That element just filters out entities before even considering them as a match in default intents, which are designed to work with any exposed entity
slots are also not needed in your case. They would be if they were variable (such as a list:) and you'd want to use the exact user input in the response, but you don't. So that's not needed either
response is used to select a response from a key list for a specific intent. For example, the built-in HassGetState has multiple responses based on what you want: one, which, how_many etc. Your intent, however, is an intent_script with a hard-coded response that you don't reference by key, so you also don't need that response config in your intent data
lastly, the template syntax you used has a bunch of redundancies and also contains capital letters. while neither of these is a capital sin (i.e. it won't break anything), it does slow things down and make it unclear
here's what I would propose you change things to:
# custom_sentences/en/doors_and_whatnot.yaml
language: "en"
intents:
DoorsWindows:
data:
- sentences:
- "(are|is) [there] any [of the] (window[s][ (and|or) door[s]]|door[s][ (and|or) winow[s]]) open"
# configuration.yaml
intent_script:
DoorsWindows:
speech:
text: "The doors and windows are {{states('sensor.doors_windows_state')}}"
This is awesome, thanks so much for the link above, will definitely spend some time understanding template sensors in greater detail from this I'm sure. And thanks so much for the code proposal! Will definitely admit, that the whole software side of HA is my weak side (i'm a mechanical engineer, who specializes in plastic component design by trade, so I'm much more comfortable 'building' gadgets than trying to code them, but really trying to learn).