1.9.1

The conversation agent no longer controls locks. If you have a lock exposed to Assist and a fallback agent configured, lock sentences now go to that agent instead.

Why

#5 reported that turn_on was described to the model as "unlock it" and turn_off as "lock it", while Home Assistant's intent component reads them the other way round for a lock. Measured before the fix, driving the real conversation.async_converse:

"unlock the front door" -> lock.lock(lock.front_door)
"lock the front door"   -> lock.unlock(lock.front_door)

The sentence matcher is bypassed by then, so response.speech is empty and nobody hears a confirmation either way.

Swapping the two clauses fixes the service call and leaves the README untrue, since it already said a probability with no explanation should not hold a lock while lock sat in the controllable domains. So lock is out of that list. The agent never describes a lock to the model now, and the same probe calls no lock service at all.

Automating a lock with Jev still works and is the better shape anyway: ask for it with an explicit lock/unlock choice and call lock.lock yourself, as example 13 does.

A second fix, found writing the test the report asked for

A house with exposed entities and no area assigned to any of them built an area question holding nothing but none_of_these. jevclient refuses a one-option choice, so every spoken command raised ValueError before it reached the API. The area question is now asked only when there is a room to name.

Documentation that was wrong

The README and the docs site said media players and covers go to the fallback agent. The new per-domain test shows they do not: cover maps to open_cover and close_cover, media_player to turn_on and turn_off.

Contributors need Python 3.14. The pinned pytest-homeassistant-custom-component requires it and CI already used it, but the README did not say so, so 3.13 failed at install.

The exposure boundary now says which path it covers. The conversation agent describes only what you exposed to Assist. The four service actions send whatever an automation targets, exposed or not, which is deliberate but was not written down. Worth knowing with include_attributes: true on a device_tracker.

Tests

11 new parametrised cases, one per controllable domain, asserting the service that actually fires. Every conversation test before this used light, which is why the cover clause being right and the lock clause being wrong both went unnoticed.

204 passed, 12 skipped, coverage 96%. mypy --strict clean over 16 files.

Thanks to @MrJev for the report, which came with the Home Assistant source quoted and the version it was checked against.