Jev for Home Assistant

How we reviewed this: we ran its test suite and type checks in Docker, read the voice path end to end, and checked its behaviour against Home Assistant’s own intent implementation. We made no Jev calls.

What it does

HA-Jev, by AboveColin, brings typed decisions into Home Assistant two ways. Sensors ask a question about your house on an interval — one request per context, with every question for that context batched together. And a conversation agent handles spoken commands the sentence matcher couldn’t, asking six or seven questions in a single request:

What should happen? · Does this request contain more than one distinct command? · Which device should receive this?

What we liked immediately: brightness is not asked of the model. It’s parsed with a regex, and a comment explains why — the model separated the options by 0.06, while a comparison in code separated them by 0.69. That instinct, of measuring and then not using the model where code does better, runs through the project. So does the engineering: 192 tests, mypy --strict, HACS and hassfest checks in CI, diagnostics with redaction tests, and a persisted request budget.

The locks were backwards, and are now gone

Home Assistant’s own intent code states the convention plainly:

if state.domain == LOCK_DOMAIN:
    # on = lock
    # off = unlock

HA-Jev’s criteria tell the model the opposite:

"turn_on":  "Switch something on, open it, start it, or unlock it",
"turn_off": "Switch something off, close it, stop it, or lock it",

So a model that follows the criteria correctly produces turn_on for “unlock the front door” — and Home Assistant locks it. “Lock the front door” produces turn_off, which unlocks it. (The same line handles covers, where “open it” / “close it” matches HA’s convention exactly — it is only the lock clause that is inverted.)

Two things make this worse than a typo. Because the sentence matcher was bypassed, there is no spoken response template, so the user hears nothing at all. And the conversation tests only exercise lights, so nothing in CI covers a lock.

The README said this integration is “not for safety decisions” and that “a probability with no explanation should not hold a lock” — but lock was in the controllable domain list, so it did.

Fixed in 1.9.1, the day after we reported it. The author reproduced the inversion against the real conversation pipeline, then took the stronger of the two fixes we suggested: rather than swapping the clauses, lock is out of the controllable list and the lock wording is gone from both criteria, so a door command now reaches the fallback agent untouched and the README’s own line is true. An automation with an explicit lock/unlock choice still works, which is the shape to use for a door.

Writing the per-domain test that the fix needed turned up two more things: covers and media players were documented as going to the fallback agent when they don’t, and a house with exposed entities but no areas assigned built an area question with a single option, which the client refuses — so every spoken command raised before reaching the API. Both are fixed too. The suite is 204 tests now.

What leaves the house

The voice path respects Assist’s exposure list and sends entity id, name, domain, area and state for up to 150 entities, plus your sentence verbatim.

The four service actions do not. They build state without consulting exposure, so a template that points at an entity you never exposed will send it — and with attributes enabled, that includes things like a device tracker’s latitude, longitude, battery level and MAC address. The claim in the code that nothing else is ever sent held for the voice path only.

The author kept this behaviour deliberately and documented it instead: an automation names its entities on purpose, and silently dropping a targeted entity would let it answer against a state it couldn’t see was incomplete. As of 1.9.1 the gap is written down in the module, the README and the actions page, with the device-tracker case named. That’s a defensible call, and the disclosure is what was missing.

Diagnostics keep your last twenty sentences; the README tells you to check before attaching them to a bug report, which is the right instinct.

Verdict

The most professionally built custom integration we’ve reviewed in this ecosystem — quality bar documented, types checked, budgets persisted, decisions justified with measurements.

If you use the actions rather than the voice agent, pick your entities deliberately: the exposure list you rely on elsewhere doesn’t apply there, by design. On 1.9.1 or later, locks are no longer in scope; on anything earlier, don’t give it locks.

For the same split in other hosts, see Jev-cu and voice-browser.

See how it compares with other tools in Best Jev tools, tested hands-on.

Review updated Sep 20, 2026. Numbers quoted from the project are its author's own; we don't publish our own measurements of Jev.