# Home Assistant automations built on RuView's semantic-state MQTT entities.
#
# See README.md's "Automations built on RuView's semantic states" section before
# using this — in particular: every entity_id below is a PLACEHOLDER, not a
# confirmed real one. RuView's own README documents the semantic-state NAMES
# (someone-sleeping, possible-distress, bathroom-occupied, ...) but not their
# exact post-MQTT-discovery Home Assistant entity_ids (domain, underscore vs.
# hyphen, per-node naming). Check Developer Tools -> States on your real HA
# instance after provisioning a node and correct every entity_id below before
# relying on any of this — same "VERIFY against a live instance" discipline as
# TRUSTED_ENTITY_PREFIXES/AREA_ATTRIBUTE elsewhere in this project.
#
# Paste whichever rules you want into your own configuration.yaml / automations.yaml
# (or the individual automation.*.yaml files HA's UI editor creates) — this repo
# does not merge this file into your HA config for you, same "nothing under this
# repo builds the HA side" convention as everywhere else automations appear.
#
# rest_command: block at the bottom is shared by more than one automation below —
# add it once, not once per automation.

automation:
  # --- 1. Someone asleep -> dim that room's lights ---------------------------
  # One instance per room with a RuView node. Dims rather than turns off, on the
  # assumption a fully dark room is a worse experience if someone gets up in the
  # night than a low, warm glow — change brightness_pct/color_temp_kelvin to taste.
  - alias: "RuView: someone sleeping in bedroom -> dim lights"
    trigger:
      - platform: state
        entity_id: binary_sensor.ruview_bedroom_someone_sleeping # VERIFY real entity_id
        to: "on"
    action:
      - service: light.turn_on
        target:
          area_id: bedroom # your real HA area — must match the room the light
                            # physically sits in, not the RuView node's naming
        data:
          brightness_pct: 10
          color_temp_kelvin: 2200

  # --- 2. Possible distress -> alert everyone home ----------------------------
  # "Possible distress" is RuView's own closest documented inference to what you
  # described as "a heart attack" — see README.md's honesty note: this repo does
  # not build its own medical-anomaly detection on top of RuView's raw signals,
  # it bridges RuView's OWN inferred state to a household-wide alert. Whatever
  # RuView's real false-positive/false-negative rate turns out to be is entirely
  # upstream's accuracy, not something this automation can improve on.
  #
  # One instance per room with a RuView node — duplicate this block per room,
  # changing the trigger entity_id and the {{ }} room name in the message.
  - alias: "RuView: possible distress (living room) -> alert everyone home"
    trigger:
      - platform: state
        entity_id: binary_sensor.ruview_livingroom_possible_distress # VERIFY real entity_id
        to: "on"
    action:
      # Urgent ntfy push — same ntfy instance/topic every other service in this
      # stack already uses (see rest_command: block below).
      - service: rest_command.ruview_alert_ntfy
        data:
          message: "RuView detected possible distress in the living room. Check on them now."
      # Whole-house TTS announcement — list every media_player you actually have
      # (thin clients, headless audio endpoints, the touch panel) so this reaches
      # people even if their phone is elsewhere in the house. Silently no-ops on
      # any media_player that's off/unavailable at the moment — HA does not error
      # the whole action out over one unreachable target.
      - service: tts.speak
        target:
          entity_id:
            - media_player.living_room_thinclient # VERIFY / replace with your real media_player entities
            - media_player.kitchen_audio_endpoint
            - media_player.touch_panel
        data:
          message: "Possible medical emergency detected in the living room. Please check on the household."
      # A strong, unmissable visual signal too — useful if whoever's near a light
      # can't hear the announcement, or is the person in distress themselves.
      - service: light.turn_on
        target:
          entity_id: all
        data:
          rgb_color: [255, 0, 0]
          brightness_pct: 100
          flash: long

  # --- 3. Two people's heart rate elevated at the same time, same room -------
  # "Rises concurrently" is approximated here as "both people's heart rate is
  # SIMULTANEOUSLY above an elevated threshold" rather than a true rate-of-
  # change/derivative trigger — derivative triggers on noisy CSI-derived vitals
  # are much more prone to false triggers than a plain threshold, so this trades
  # a little precision for a lot more reliability. Adjust `above:` to a real
  # resting-heart-rate-plus-margin for your household if the flat 100 bpm
  # default doesn't fit.
  #
  # HIGH-RISK UNVERIFIED ASSUMPTION, more so than anything else in this file:
  # RuView's fetched README does not confirm whether a single node actually
  # distinguishes and reports MULTIPLE people's heart rates concurrently within
  # one room at all — multi-target vital-sign separation from WiFi CSI is a
  # genuinely hard, actively-researched problem, and RuView may only report one
  # aggregate/first-detected person's heart rate per node. Confirm you actually
  # have two distinct per-person heart-rate entities for a room (Developer Tools
  # -> States, after provisioning) before trusting this rule can ever fire as
  # described — if there's only one heart-rate entity per node, "two people's
  # pulse rising together" isn't something this hardware can currently tell you,
  # and this rule needs a different design (or dropping) once you know that.
  - alias: "RuView: two people's heart rate elevated concurrently (living room) -> alert lighting"
    trigger:
      - platform: numeric_state
        entity_id: sensor.ruview_livingroom_heart_rate_person1 # VERIFY this entity exists at all, see note above
        above: 100
      - platform: numeric_state
        entity_id: sensor.ruview_livingroom_heart_rate_person2 # VERIFY this entity exists at all, see note above
        above: 100
    condition:
      - condition: numeric_state
        entity_id: sensor.ruview_livingroom_heart_rate_person1
        above: 100
      - condition: numeric_state
        entity_id: sensor.ruview_livingroom_heart_rate_person2
        above: 100
    action:
      - service: light.turn_on
        target:
          area_id: living_room
        data:
          rgb_color: [178, 0, 255] # violet — swap for magenta [255, 0, 144] or
                                    # red [255, 0, 0] to taste, or cycle between
                                    # them with a light.turn_on + delay + repeat
          brightness_pct: 100

  # --- 4. Bathroom occupied -> external door indicator ------------------------
  # You mentioned you'll likely add a dedicated light/actor outside the door for
  # this — swap switch.bathroom_door_indicator below for whatever you end up
  # picking (add it to components.md's Zigbee list once chosen, same as every
  # other Zigbee actuator in this project).
  - alias: "RuView: bathroom occupied -> door indicator on"
    trigger:
      - platform: state
        entity_id: binary_sensor.ruview_bathroom_occupied # VERIFY real entity_id
        to: "on"
    action:
      - service: switch.turn_on
        target:
          entity_id: switch.bathroom_door_indicator # VERIFY / replace once hardware is chosen
  - alias: "RuView: bathroom vacated -> door indicator off"
    trigger:
      - platform: state
        entity_id: binary_sensor.ruview_bathroom_occupied # VERIFY real entity_id
        to: "off"
    action:
      - service: switch.turn_off
        target:
          entity_id: switch.bathroom_door_indicator # VERIFY / replace once hardware is chosen

# Shared by automation #2 above — same ntfy instance/topic pattern chores/
# trash-calendar/etc. all already POST to directly from Python; this is the HA-
# side equivalent for automations that need to reach it. Fill in your real ntfy
# host/topic (same NTFY_URL/NTFY_TOPIC style as chores.env.example) and put the
# actual URL in HA's own secrets.yaml, same pattern as identity's rest_command
# example in identity/README.md.
rest_command:
  ruview_alert_ntfy:
    url: "http://<container-host>:8090/smarthome-alerts" # <-- your real ntfy host:port/topic
    method: POST
    headers:
      Title: "Possible medical emergency"
      Priority: "urgent"
    payload: "{{ message }}"
    content_type: "text/plain"
