168 lines
8.5 KiB
Plaintext
168 lines
8.5 KiB
Plaintext
# 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"
|