Help

[marvinludigkeit-cloud]

Title: Face recognition: “person gallery is unavailable” — enroll_person always fails with AttributeError: 'NoneType' object has no attribute 'enroll_from_image' (even after a complete reset including a Postgres recorder migration)

Description:

I can’t get face recognition working. On every startup, this warning appears:

WARNING (MainThread) [custom_components.home_generative_agent] Face recognition is enabled but person gallery is unavailable; disabling face recognition for this entry.

Every call to enroll_person fails with:

File "/config/custom_components/home_generative_agent/init.py", line 3297, in _handle_enroll_person
ok = await dao.enroll_from_image(
AttributeError: 'NoneType' object has no attribute 'enroll_from_image'

Environment:

•	Home Assistant Core 2026.9.1 (Home Assistant OS 18.2, Supervised)
•	Home Generative Agent v3.38.1 (latest per HACS)
•	Model provider: ChatGPT/OpenAI (cloud deployment)
•	Postgres: goruck/addon-postgres-pgvector 0.1.0 add-on
•	face-service: goruck/face-service, CPU backend, buffalo_l model, running as a standalone systemd service on a separate host, reachable via face_api_url; /status returns 200 with all submodels on CPUExecutionProvider

What I’ve already tried/verified:

1.	face-service is set up correctly and reachable (/status returns a healthy response)
2.	face_api_url is correctly set in the integration options (verified via the API)
3.	face_recognition: true is set in options
4.	Tested the PostgreSQL connection directly: credentials are correct, a CREATE TABLE test as ha_user on the ha_db database succeeded
5.	Migrated the entire Home Assistant recorder from SQLite to that same PostgreSQL/pgvector instance (recorder: db_url:) — recorder confirmed running on PostgreSQL 17.5 afterward
6.	Performed a full Home Assistant restart
7.	Completely removed the integration and rebuilt it from scratch (new config entry, new model provider subentry with API key, all 4 feature subentries relinked, Sentinel subentry created via “Advanced Setup”)
8.	Called enroll_person again after each of the above steps — identical error every time

Question: What exactly initializes the dao object (the “person gallery”)? Is there an additional, undocumented configuration step or service call required to explicitly initialize the gallery, beyond setting face_api_url + face_recognition: true?

Thanks for any help — everything else in the integration (chat, camera analysis, Sentinel) works flawlessly with ChatGPT as the provider.

[yudin-s]

The missing piece is the integration database, not the Home Assistant recorder database.

In the current setup path, person_gallery is only created after Home Generative Agent has its own Postgres database URI/subentry, opens an AsyncConnectionPool, creates the LangGraph store/checkpointer, runs migrate_person_gallery(pool), and then constructs PersonGalleryDAO(pool, hass). That migration creates public.person_gallery with a VECTOR(512) embedding column and an ivfflat index.

If build_database_uri_from_entry(entry) returns no HGA database URI, or if the pool/migration fails, setup falls back to MemorySaver/NullStore and leaves person_gallery = None. A few lines later the code does exactly the warning you are seeing:

if face_recognition and person_gallery is None:
    LOGGER.warning(
        "Face recognition is enabled but person gallery is unavailable; "
        "disabling face recognition for this entry."
    )
    face_recognition = False

So migrating Home Assistant recorder to Postgres can still leave the gallery unavailable. Recorder storage and the HGA gallery pool are separate concerns. The face service being healthy is also necessary, but it is downstream of the DAO; the DAO has to exist before /analyze can be used for enrollment.

I would check these in order:

1. Confirm the HGA config entry has a Database subentry / DB settings, not only recorder: db_url: in Home Assistant.
2. Check the logs before the warning for Error opening postgresql db, Postgresql setup failed, or Error migrating person_gallery database schema.
3. In that HGA database, verify public.person_gallery and hga_schema_version exist. Because the column is VECTOR(512), the DB also needs pgvector available before the migration can succeed.
4. After a clean setup, look for the log line that counts visible gallery rows. That is a good sign the same connection can see the table.

There is also a probable bug in the service path you hit: enroll_person dereferences entry.runtime_data.person_gallery directly, so when it is None it raises AttributeError instead of returning a clear "gallery unavailable" error. But the root cause of the warning is still that HGA did not initialize its own PersonGalleryDAO.

If this points you to the HGA database/subentry rather than the recorder database, please mark the answer as solved.

[marvinludigkeit-cloud]

Thanks, that's very helpful! I checked and confirmed: there is no database URL/URI field anywhere in the integration's options schema or as a subentry type (only model_provider, feature, stt_provider, tts_provider, sentinel exist). I also searched for all three log strings you suggested ("Error opening postgresql db", "Postgresql setup failed", "Error migrating person_gallery database schema") — zero matches, even at a wide time window. This suggests build_database_uri_from_entry(entry) isn't even attempting a connection — it's returning empty before that point.

I also checked the postgres-pgvector add-on's metadata via the Supervisor API: it reports "discovery": [] (empty) — no discovery service is being published by the add-on. Could HGA be relying on Home Assistant's hassio discovery mechanism to auto-find the Postgres add-on, and if so, does goruck/addon-postgres-pgvector need to declare a discovery service type that it currently doesn't?

[marvinludigkeit-cloud]

Follow-up: I checked directly — ha_db only contains the standard Home Assistant recorder tables (events, states, statistics, etc.). There is no person_gallery table and no hga_schema_version table anywhere in the database. This confirms the migration never ran — HGA never attempted to connect to a database for the gallery at all.

[yudin-s]

Your direct check lines up with the current code.

I do not think the recorder database or the add-on discovery metadata is the main boundary here. In home-generative-agent, build_database_uri_from_entry(entry) only resolves a DB URI from:

1. a config subentry with subentry_type == "database";
2. legacy db_uri;
3. legacy discrete DB fields: db_name, username, password, host, port.

If none of those are present, it returns None, and setup never reaches AsyncConnectionPool, migrate_person_gallery(pool), or PersonGalleryDAO(pool, hass). That matches your log result: no "Error opening postgresql db", no "Postgresql setup failed", and no migration tables.

The interesting source mismatch is that the repository already has flows/pgvector_db_subentry_flow.py, and that flow would render a Database form with host/user/password/db fields. But the current HomeGenerativeAgentConfigFlow.async_get_supported_subentry_types() return map lists model provider, feature, STT, TTS, and sentinel only. I do not see SUBENTRY_TYPE_DATABASE: PgVectorDbSubentryFlow registered there, and the flow is not imported in config_flow.py.

So the fix surface looks like:

from .flows.pgvector_db_subentry_flow import PgVectorDbSubentryFlow

...

return {
    SUBENTRY_TYPE_DATABASE: PgVectorDbSubentryFlow,
    SUBENTRY_TYPE_MODEL_PROVIDER: ModelProviderSubentryFlow,
    ...
}

with SUBENTRY_TYPE_DATABASE included in the const imports if it is not already imported.

The add-on's config.json currently has no discovery block, so automatic add-on discovery may be a separate nice-to-have. But the integration setup path I see does not rely on hassio discovery before connecting; it relies on the integration having DB settings/subentry data. Registering the existing database subentry flow should be the first thing to check, because without that there is no UI path to create the DB config that build_database_uri_from_entry() is looking for.

After that is wired, I would still validate the actual host value from the Home Assistant core container. The recommended defaults in the integration are localhost, port 5432, database ha_db, user ha_user; those only work if localhost:5432 is actually reachable from where the integration runs.

[goruck]

Thanks for the thorough report, and thanks @yudin-s for the diagnosis — it is right on the mechanism. Let me fill in the piece that was missing.

What creates the gallery: person_gallery only exists when the HGA config entry has a Database subentry. Your log evidence (no Error opening postgresql db, no Postgresql setup failed, no migration tables) is exactly what happens when that subentry is absent: setup never tries to connect and falls back to in-memory storage. Not related: migrating the recorder to Postgres (separate concern entirely) and add-on discovery (HGA does not use hassio discovery, so the add-on's empty discovery list is not a problem).

Why you cannot find it: "Database" is intentionally not one of the + buttons on the integration page. It is created by + Setup:

• Basic creates it automatically with the recommended defaults (ha_user / ha_db / localhost:5432).
• Advanced walks through each feature and ends with a Database setup form that tests the connection before saving.

The trap is that in Advanced mode the feature subentries are written before the Database step. If the wizard is closed at that step — for instance after a "cannot connect" error — you end up with all four features configured and no database, and the entry loads without complaint. That matches your description of the rebuild.

Fix on your side:

1. Confirm the state: in .storage/core.config_entries, the HGA entry should contain a subentry with "subentry_type": "database". I expect it does not.
2. Click + Setup → Advanced again, click through the features (they are pre-populated), and complete the Database setup form. With the pgvector add-on, localhost / 5432 / ha_db / ha_user is correct from the HA core container, because the add-on runs with host_network: true. If the form reports "cannot connect", that is the thing to chase — the wizard will not save until it succeeds. (Basic setup also works but overwrites your feature/provider assignments with defaults.)
3. Reload. You should see DB env: db=ha_db ... and Gallery rows visible to this connection: 0 in the log, and the warning goes away. The first startup runs the migrations, so person_gallery and hga_schema_version will appear in ha_db. Then enroll_person will work.

What is a bug on my side: enroll_person (and the upload card endpoint) should have told you "no database configured" instead of an AttributeError, and the integration should warn loudly at startup when it is running without a database — right now it is silent, which is why nothing pointed you at the real cause. I opened #615 for that, and I will also weigh @yudin-s's suggestion of exposing the database as its own subentry so it can be added or reconfigured without re-running the feature wizard.

Please report back once the Database step is saved — if it still fails after that, post the DB env: line and anything logged around it and we will dig further.

[goruck]

@marvinludigkeit-cloud the fix for #615 is in PR #616 and will ship as v3.39.1 shortly. I can't reproduce your starting state on my own system (my entry has a database), so you are the ideal person to verify it in the field. Would you mind running through this once the release shows up in HACS?

1. Update to v3.39.1 with your entry still in its current state (no Database subentry, don't fix it first):

• Restart. The log should now carry a WARNING starting with No database is configured for this entry; running with in-memory storage only instead of the old "person gallery is unavailable" warning.
• Settings → Repairs should show "Home Generative Agent is running without a database" with instructions.
• Call home_generative_agent.enroll_person once more. Instead of the AttributeError traceback you should get a clear error: "Face recognition needs a configured database, and this entry has none...". If you use the enroll card, the same message appears there.

2. Then fix the configuration: + Setup → Advanced, click through the features, complete the Database setup form (localhost / 5432 / ha_db / ha_user with the pgvector add-on).

• On the reload the repair issue should disappear and the log should show DB env: db=ha_db ... and Gallery rows visible to this connection: 0.
• enroll_person should now succeed and person_gallery / hga_schema_version should exist in ha_db.

If step 2's Database form reports "cannot connect", that is the thing to chase and I'd like to hear about it — the repair issue is designed to clear as soon as the subentry exists, even if the connection fails, so please tell me what the entry's state is in that case.

Thanks for the detailed report; it turned up a couple of things beyond your case (the repair issue would have fired on every fresh install, for one), all fixed in the same PR.