Assist prompt example so it does does the task with minimal talking

Hi Folks,
I have HAOS and ollama working, but I need a prompt so that it executes the command (like"turn off gaming room lights") without a 10 minute diatribe of all the tools it needs to check or what it’s doing during the command. Besides the AI component, it’s a pretty basic HA setup with some Hue lights assigned to various rooms, and some motion/enviromental sensors with ollama running qewn3 4B. Everything works, but assist blabs and blabs about all the stuff it’s doing instead of you doing it. Here’s an example:
How can I assist?

turn off gaming room lights

Okay, let’s see. The user wants to turn off the gaming room lights. First, I need to figure out which devices are in the gaming room that are lights.

Looking at the static context provided:

  • names: Gaming room
    domain: light
    areas: Gaming room

Wait, that’s a bit confusing. The static context lists “names: Gaming room” with domain light and area Gaming room. Then there’s another entry: “names: shapes 5455” with domain light and area Gaming room.

So the gaming room has two lights: “Gaming room” and “shapes 5455”. But the user said “gaming room lights”, so maybe they mean all lights in the gaming room.

But the user is asking to turn off the gaming room lights. Since the function for turning off is HassTurnOff, I need to specify the area and the device name.

Wait, the function HassTurnOff requires parameters like area, domain, name, etc. The static context shows that the gaming room (area) has lights with names “Gaming room” and “shapes 5455”.

But the user might be referring to the lights in the gaming room area. So I should call HassTurnOff with area “Gaming room” and domain “light”. However, the function parameters need to be specified.

Wait, the function HassTurnOff’s parameters are: area (string), device_class (array), domain (array), floor (string), name (string). But the user is asking to turn off all lights in the gaming room. Since the domain is light, and area is Gaming room.

But the static context says that the “Gaming room” area has lights named “Gaming room” and “shapes 5455”. So to turn off all lights in the gaming room, I should specify the area as “Gaming room” and domain as “light”.

Wait, but the function might require the name. However, if the user says “turn off gaming room lights”, it’s all lights in that area. So maybe the correct approach is to use the area and domain.

Wait, the function HassTurnOff takes a name and domain. But in this case, the name might be the specific light name. But the user is asking for all lights in the gaming room. Hmm.

Wait, the static context shows that the area “Gaming room” has two lights: “Gaming room” and “shapes 5455”. So to turn off both, I need to specify the area and the domain.

But the function parameters for HassTurnOff: the name is a string, but if it’s a list of devices, maybe we need to specify the area and domain.

Wait, looking at the function definition for HassTurnOff: it’s for turning off a device or entity. So perhaps the correct way is to specify the area and the domain as “light”.

Wait, but the function might require the name. For example, in Home Assistant, turning off all lights in an area might be done by specifying the area and domain.

Alternatively, maybe the user expects to turn off the lights in the gaming room area. Since the static context lists the area “Gaming room” with domain light.

So the function call would be HassTurnOff with area: “Gaming room”, domain: [“light”].

Wait, but the function’s parameters for domain is an array of strings. So the domain here is “light”.

But the user says “turn off gaming room lights”. So the correct tool call is HassTurnOff with area “Gaming room” and domain “light”.

Wait, but in the static context, the area names are listed as “Gaming room” (the area), so the area is “Gaming room”.

So the tool call should be:

{
“name”: “HassTurnOff”,
“arguments”: {
“area”: “Gaming room”,
“domain”: [“light”]
}
}

But wait, does the function require a name? The function’s parameters include “name” as a string, but if the user is asking for all devices in the area, maybe the name is not specified. However, in Home Assistant, when you turn off a device, you need to specify the entity. But since the user says “gaming room lights”, it’s all lights in that area.

Alternatively, maybe the function is designed to handle the area and domain without a specific name, so the name can be omitted. But the function’s parameters have “name” as a required field? Wait, the function definition says the parameters are: area (string), device_class (array), domain (array), floor (string), name (string). So name is a string, but maybe it’s optional? The function definition’s parameters have for some, but the tool description says “prefer passing just name and domain” when controlling a device.

Wait, the user wants to turn off the gaming room lights. So the area is Gaming room, domain is light. The name is not specified (since it’s all lights in that area). But the function requires a name? Hmm.

Wait, perhaps in Home Assistant, to target all lights in an area, you can use the area and domain. For example, the entity might be “light.gaming_room” and “light.shapes_5455”. So the correct way is to specify the area and domain.

But according to the function’s parameters, name is a string. So maybe the name here is the area name? Or perhaps the function is designed to handle this by area and domain.

Alternatively, maybe the function expects the name to be the specific device name, but since the user says “gaming room lights”, we need to list all lights in that area.

But given the static context, the gaming room area has two lights: “Gaming room” and “shapes 5455”. So the user wants both turned off.

But the function HassTurnOff is for turning off one device. Wait, no, maybe it’s for a group. Wait, the tool description says “HassTurnOff Turns off/closes a device or entity”. So it’s for one entity. But the user is asking to turn off all lights in the gaming room.

Ah, here’s the problem: the user is asking to turn off all lights in the gaming room, but the function is for a single entity. So maybe the correct approach is to use the area and domain to find all entities and turn them off.

But according to the instructions: “When controlling a device, prefer passing just name and domain.” So if the user says “turn off gaming room lights”, it’s all lights in that area. So the function call would be HassTurnOff with area: “Gaming room”, domain: [“light”].

Wait, but the function’s parameters have a “name” field. So perhaps the name is optional. If the user doesn’t specify a name, we can omit it, but the function might require it. Hmm.

Wait, looking back at the static context: the areas are listed as “Gaming room” (area), so the area name is “Gaming room”. The domain is “light”.

So the correct tool call is HassTurnOff with area “Gaming room” and domain [“light”].

But the function parameters for HassTurnOff require a name? Let me check the tool definition again.

The function definition for HassTurnOff says: {object {“area”:{“type”:“string”},“device_class”:{“type”:“array”,“items”:{“enum”:[“identify”,“restart”,“update”, … ]},“domain”:{“type”:“array”,“items”:{“type”:“string”}},“floor”:{“type”:“string”},“name”:{“type”:“string”}}}

So the parameters are area (string), device_class (array), domain (array), floor (string), name (string). So the name is required? But the user is asking for all lights in the area, so maybe the name is omitted.

Wait, the tool’s description says: “When controlling a device, prefer passing just name and domain.” So if the user says “turn off gaming room lights”, the name is the area name? Or perhaps the name is the device name.

This is a bit confusing. Let me think.

In Home Assistant, to turn off all lights in a specific area, you might use the area as the area parameter and the domain as light. But the function’s name parameter is required here. Wait, but maybe in this context, the name can be left empty or the system handles it.

Alternatively, perhaps the correct way is to use the area and domain, and omit the name. But the function’s parameters list name as a required field (since it’s in the JSON schema with type string). Hmm.

Wait, the tool definition says “object ”, which might mean that the arguments are optional. But the parameters have “name” as a string.

Given the user’s query is to turn off gaming room lights, the intended action is to turn off all lights in the Gaming room area. So the function call would be HassTurnOff with area: “Gaming room”, domain: [“light”], and name omitted? But the function requires name.

Alternatively, maybe the name here refers to the area name. Wait, no. The name is the device name.

Wait, in the static context, the lights in Gaming room are named “Gaming room” and “shapes 5455”. So the user probably means both.

But the function HassTurnOff is for a single entity. So perhaps the correct approach is to call HassTurnOff for each light in the Gaming room area. But the user asked to turn off all, so the assistant should do it in one call by specifying the area and domain.

Wait, the problem says: “When controlling a device, prefer passing just name and domain.” So if the user is controlling a device (plural), but the function is for one device, maybe the assistant should handle it by area and domain.

Given the instructions, the assistant should call the tool with the area and domain. So the tool call would be:

HassTurnOff with area: “Gaming room”, domain: [“light”]

But the function parameters have a “name” field. Since the user didn’t specify a particular light name, perhaps we leave name as empty? But the tool’s JSON schema says name is a string. Hmm.

Wait, looking at the example in the tool description: For locks, HassTurnOn does a ‘lock’ action. So maybe for lights, the name is the light’s name.

But the user says “gaming room lights”, which are multiple. So the correct way here is to use the area and domain to target all lights in that area.

In Home Assistant, you can use the area and domain to find all entities. So the function call would be HassTurnOff with area: “Gaming room”, domain: [“light”]

But the function’s parameters require a name. Maybe the name is optional here. The tool’s description says “prefer passing just name and domain”. So if the user doesn’t specify a name, we can omit it.

Wait, the function’s arguments have “name” as a string, but perhaps it’s allowed to be null or empty. But according to the tool definition, it’s a string.

This is a bit tricky. Let’s try to proceed.

The user’s command is “turn off gaming room lights”. The area is Gaming room, domain is light.

So the tool call is HassTurnOff with arguments:

{
“area”: “Gaming room”,
“domain”: [“light”]
}

But the function might require the name. However, since the user is asking for all lights in that area, the name can be omitted, but the tool’s parameters might require it. Wait, the tool’s function definition says the arguments are an object with those fields. Maybe in this context, the name is optional.

Alternatively, the name could be the area name, but that’s not standard.

Given the time I have, I’ll go with the area and domain, and omit the name since the user is asking for all lights in the area.

Wait, but the static context shows that the Gaming room area has two lights. So the correct function call would be to specify the area and domain.

So the tool call is:

{
“name”: “HassTurnOff”,
“arguments”: {
“area”: “Gaming room”,
“domain”: [“light”]
}
}

But I need to check if the domain is an array. The domain is “light”, so the array is [“light”].

Yes, that seems correct.

Another point: the static context lists “names: Gaming room” with domain light and area Gaming room. So the area name is “Gaming room”.

Yes, so the function call should be as above.

Okay, let’s see. The user asked to turn off the gaming room lights. I called the HassTurnOff function with area “Gaming room” and domain [“light”]. The response from the tool shows that it successfully targeted two entities: “Gaming room” (the area) and two lights: “light.gaming_room” and “light.shapes_5455”.

Wait, the response has “targets” as an empty array, but “success” lists the entities. So the action was successful for those two lights. The user wanted to turn off the gaming room lights, which are those two lights. Since the tool response says “success” for both, I should confirm that the lights were turned off.

The user’s original request was to turn off gaming room lights, so the response should be a confirmation that both lights are now off. The tool response shows that the targets were successful, so I can say something like “The gaming room lights have been turned off.”

No need for extra details since the user just wanted to confirm the action. Keep it simple and truthful.

The gaming room lights have been turned off.

It’s one of three things. Most likely the first.

You are using a thinking model and haven’t turned off the thinking.

Your model param depth (the 4b part) simply isn’t big enough for the task and when given context (prompt) it gets confused.

Your context is too big for your model (qwen4b, I think 8k max) (how many ents did you expose to assist)

Or some combination of those.

So qwen4b. Running on?

Also using a good prompt might help too. If there is still room in your prompt you can tell it to answer in no more then say 50 to 100 words or something like that.

1 Like

Qwen3 4b running in a OpenWebUI LXC via ProxMox.giving it 8cores, 16Gb of mem, and 3080 Super/ti 16Gb VRAM. It’s pretty quick to answer. 16 entities exposed to it. I’ll see if I can turn off thinking.I’m not tied to Qwen3, I’ve tried other models with good success. I’m looking for prompt examples that have work well for people.

This is why it’s decent. A 4b model with plenty of room to breathe and only 16 ents. Instill submit it will absolutely have trouble following instructions the 4b Is particularly bad and I’m not at all surprised about the runon. Mistral does the same if not worse. Ultimately you’ll be MUCH happier with a better model. Check out the new qwen35 small stuff that shipped last week. You should be able to find a better model in the same mem space. (yes I’m saying you will continue to fight with that model to get it to behave… And if you have 16g vram you can do better)

To make it behave - you need prompt basics.

Sorry the thread is long but everything you need is in there. I PROMISE.

I turned off reasoning, but it still blabs. I’ll checkout that link.I had a prompt at one point that did the trick with just a snarky response, but I didn’t save a copy of the text. Thank you for the replies and advice!!