Saltar a contenido

Multi-user / family management

El smart home no es solo vos. Si tu pareja, hijos, o visitantes interactúan con él (incluso pasivamente al entrar/salir), tu setup necesita responder a cada persona apropiadamente. Patrón base: input_boolean.<name>_* para cada persona + per-user notification routing + presence tracking que respeta privacidad. Sin esto, el smart home se vuelve "el sistema de Paulo que la familia tolera".

Contexto

Esta página existe porque la meta "invisible" del usuario aplica a todos los habitantes, no solo a vos. Si tu pareja se despierta a las 3 AM porque tu sistema gritó "ATENCIÓN" por una battery low de un sensor, perdiste. Estos patterns evitan que el smart home erosionе la convivencia.

Contenido

Modelo: una persona = un set de helpers

Para cada habitante (excluyendo visitantes), crear:

input_boolean:
  paulo_at_home:
    name: "Paulo en casa"
  paulo_sleep_mode:
    name: "Paulo durmiendo"
  paulo_do_not_disturb:
    name: "Paulo no molestar"
  paulo_in_meeting:
    name: "Paulo en meeting"

input_select:
  paulo_status:
    options: ["home", "work", "commuting", "vacation", "unknown"]

Replicar por persona. Estos son la interfaz entre la persona y el sistema.

Presence detection — opciones por privacidad

Método Accuracy Privacy impact
GPS via HA Companion app Alto App tiene location, va al server local — bajo si self-hosted
WiFi presence (router data) Medio Solo presencia del device, no location detail
BLE beacon en persona Alto, room-level Local, no cloud
Bluetooth de phone scan Medio Phone sólo, no fine-grained
Routine inference (siempre sale a las 8am) Bajo Cero datos personales

Recomendación: GPS via Companion app + WiFi presence como complemento. Suficiente para "está en casa o no" sin invadir.

Per-room presence: NO usar GPS para esto (resolución insuficiente). Usar PIR/mmWave del cuarto.

Per-user notification routing

Cada automation que notifica debe filtrar por persona:

action:
  - service: >
      {% if state_attr('person.paulo', 'source') in ['gps','mobile_app'] %}
        notify.mobile_app_paulo_phone
      {% else %}
        notify.telegram_familia
      {% endif %}
    data:
      message: "..."

Reglas:

Evento Destinatario
Esperan delivery Quien lo encargó (input_text.delivery_expected_for)
Battery low de su device personal El owner del device
Door left open Último que salió por esa puerta (con device tracker)
Emergency (smoke, leak) Todos (broadcast familiar)
Daily digest Solo Paulo (mantiene visibilidad técnica)
Sleep mode violation Solo quien duerme

Modos contextuales

"Nadie en casa"

binary_sensor.nobody_home:
  value_template: >
    {{ not is_state('person.paulo', 'home')
       and not is_state('person.partner', 'home')
       and not is_state('person.hijo', 'home') }}

Cuando on → activate vacation-light mode, lower HVAC, increase camera sensitivity, lock all doors.

"Pareja durmiendo, vos no" (caso común)

condition:
  - condition: state
    entity_id: input_boolean.partner_sleep_mode
    state: 'on'
  - condition: state
    entity_id: input_boolean.paulo_sleep_mode
    state: 'off'

# entonces: notifications de Paulo van a su phone, no TTS speakers
# luces master bedroom NO se prenden
# automations comunes corren silenciadas

"Kids home alone"

Detección: presencia de hijos sin adults. Cambios: - Stove / oven monitoring activo (alert si on > N min). - Front door alert tier 1 al adulto cuando se abre. - TV puede prenderse pero NO ver contenido adult (DNS filter para esa hora? extension de policy de router). - Camera entrada sensibilidad aumentada.

"Guest mode"

input_boolean.guest_mode:
  name: "Visitas"

Cuando active: - Voice control disabled (visitas pueden decir cosas raras al speaker). - WiFi guest VLAN distribuye QR auto. - Camera de áreas privadas desactivada (en respect). - Automation "schedule diario" del usuario disable o más permisiva.

Privacidad — el contrato familiar

Pre-deployment discussion con cohabitants:

  1. ¿Cámaras indoor? Solo si TODOS están de acuerdo. Áreas comunes no áreas privadas (baños, dormitorios).
  2. ¿Presence tracking detallado? Granularidad mínima necesaria para los use cases que TODOS valoran.
  3. ¿Quién ve qué dashboard? Cada persona puede tener vista distinta — kids ven menos.
  4. ¿AI Task con visión? Snapshots procesados local-only o cloud explicitado.
  5. ¿Reports que persisten history? Decide qué se loguea (sleep patterns son sensitive — opt-in explícito).

Esto no es opcional — el smart home invisible solo es invisible si la familia no lo pelea.

UX: la persona no-técnica como usuario primario

Vos sos el admin. Tu pareja / hijos son usuarios. Diferencia:

Como admin (vos) Como user (familia)
Tocás YAML NO debe necesitar app a menos que quiera
Sabés qué tier es cada notification Recibe lo apropiado sin saber qué tier es
Controlás vía Telegram + HA UI Switches físicos + voice (si está) + dashboard simple
Querés data + metrics Querés "el lugar funciona"

Anti-patterns explícitos:

  • ❌ "Para apagar la luz del baño, abrí HA app y vas a..." — UX inaceptable. Switch físico siempre disponible.
  • ❌ Voice command obligatorio para algo trivial. Switch físico está bien.
  • ❌ Surprise automations sin acuerdo. "Le programé al sistema que apague todo a las 11pm" — sin consenso, generás resistencia.
  • ❌ Cámara nueva sin avisar. Trust violado.

Dashboard per-persona

Cada habitante tiene su dashboard:

  • Paulo (admin): todo. Sistema, métricas, agent activity, configs.
  • Partner: lights, climate, locks, doorbell, calendar próximo.
  • Kids: lights de su cuarto + media. Nada más.
  • Guest (kiosk tablet en living): lights áreas comunes, música, "llamar a Paulo".

Mushroom cards o equivalente simple. NO Lovelace default que es overwhelming para no-técnicos.

Per-user automations queue

Algunas automations son del owner único, no shared:

automation:
  - alias: "Paulo morning routine"
    trigger:
      - platform: state
        entity_id: person.paulo
        from: 'home'
        to: 'work'
    # solo Paulo

Vs shared:

automation:
  - alias: "Nobody home goodbye"
    trigger:
      - platform: state
        entity_id: binary_sensor.nobody_home
        to: 'on'

Convención de naming: automation.<owner>_<scope>_<action> (ej. automation.paulo_personal_morning_routine vs automation.shared_security_lock_all).

Edge case: separación / mudanza de un cohabitant

A futuro: si una persona se va de la casa permanentemente, hay que purgar sus helpers / automations / device trackers de manera respectuosa. No olvidar: - Disable person.<name> entity. - Remove input_boolean.<name>_*. - Revoke long-lived access tokens si los tenía. - Borrar history en recorder (privacy). - Eliminar de notify groups.

Caso humano más que técnico. Documentar el procedimiento como una de las runbooks.

Relaciones

Citas / evidencia

Abierto / gaps

  • Templates concretos de dashboards Mushroom per-persona.
  • Pattern para teen presencia (independiente pero supervisado).
  • Adoption playbook: cómo introducir el smart home a un cohabitant sin generar resistencia.