# 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://:8090/smarthome-alerts" # <-- your real ntfy host:port/topic method: POST headers: Title: "Possible medical emergency" Priority: "urgent" payload: "{{ message }}" content_type: "text/plain"