Services Reference

Services Reference

The integration registers HA services for actions that don't fit naturally as a button or entity. Currently one service is available; more may land in future versions.

---

smartghar.refill_marker

Manually log a refill event — e.g., when a tanker delivers water and you want a record. Fires a smartghar_refill_marker HA event with metadata for automations to act on.

Why this exists

The integration's event.tank_<n>_fill_event automatically fires when the level rises ≥5% between coordinator ticks. That works for slow fills (municipal supply, pump refills). It can miss:

• Very fast fills (one-shot delivery under one coordinator tick)
• Manual logging where you want metadata (vendor, cost, receipt number) the auto-detection doesn't have

This service complements the auto-detection — it lets you manually log fills with as much context as you want.

Schema

service: smartghar.refill_marker
data:
  tank: sensor.smartghar_<hub>_tank_<n>_level   # optional, but recommended
  volume_l: 5000                                 # optional
  source: tanker                                 # optional, one of:
                                                 #   tanker, municipal, well, rainwater, other
  cost: 450                                      # optional, any number
  note: "Sharma Tankers, receipt 4521"          # optional, free-form text

All fields are optional. Pass whichever combination makes sense for your record.

Behavior

1. Validates the data against the schema
2. Fires HA event smartghar_refill_marker with the data, plus a logged_at timestamp
3. Does NOT update the consumption sensor — refills don't count as consumption (the consumption sensor only counts drains, not fills, by design)

Example: log a tanker delivery

service: smartghar.refill_marker
data:
  tank: sensor.smartghar_004b1299f6dc_tank_1_level
  volume_l: 5000
  source: tanker
  cost: 450
  note: Sharma Tankers, receipt 4521

Example: subscribe to the event in an automation

Once the service fires, you can listen to the event from any automation:

alias: Refill marker logger
trigger:
  - platform: event
    event_type: smartghar_refill_marker
action:
  - service: notify.persistent_notification
    data:
      title: Refill logged
      message: >
        {{ trigger.event.data.volume_l }} L from
        {{ trigger.event.data.source }}
        for ₹{{ trigger.event.data.cost }}

Example: append to a Google Sheet

trigger:
  - platform: event
    event_type: smartghar_refill_marker
action:
  - service: rest_command.append_to_sheet
    data:
      timestamp: "{{ trigger.event.data.logged_at }}"
      tank: "{{ trigger.event.data.tank }}"
      volume_l: "{{ trigger.event.data.volume_l }}"
      source: "{{ trigger.event.data.source }}"
      cost: "{{ trigger.event.data.cost }}"
      note: "{{ trigger.event.data.note }}"

(Requires a rest_command for your sheet's webhook URL — see HA's REST command docs.)

Example: only count tanker fills toward a yearly budget

trigger:
  - platform: event
    event_type: smartghar_refill_marker
condition:
  - condition: template
    value_template: "{{ trigger.event.data.source == 'tanker' }}"
action:
  - service: counter.increment
    target:
      entity_id: counter.tanker_fills_this_year
  - service: input_number.set_value
    target:
      entity_id: input_number.tanker_spending_ytd
    data:
      value: >
        {{ states('input_number.tanker_spending_ytd') | float(0) +
           (trigger.event.data.cost | float(0)) }}

Example: ad-hoc dev-tool call (testing the service)

Developer Tools → Services panel:

Service: smartghar.refill_marker
Service data:
  source: other
  note: testing the service

Click Call Service — fires the event without any side-effects.

---

smartghar.test_buzzer

Preview a buzzer alert pattern on a SmartGhar hub. Available from v0.8.0+. Bypasses the master enable + quiet hours, so it always plays. Useful for confirming the buzzer is wired correctly, demoing which alert sounds like what, or sanity-checking the volume profile.

Why this exists

The hub plays alerts in response to real conditions (overflow, critical-low water, sensor failures, pair success, etc.). To verify the buzzer works without waiting for a real condition to trigger, this service plays the pattern on demand. Same shape as the "Play" button on the hub's local web UI buzzer card and the PWA's HubControls.

Requirements

• Hub firmware rx-v2.8.4+ — exposes /api/v1/hub/buzzer/test which this service calls. Older firmware ignores the call (the service logs a warning).
• A physical buzzer wired to the hub. Without one, the firmware accepts the call but no sound plays.

Schema

service: smartghar.test_buzzer
data:
  entity_id: switch.smartghar_<hub>_buzzer_alerts   # any entity on the target hub
  event: 4                                          # required — see table below
  profile: 1                                        # optional — override volume just for this preview

entity_id can be any entity on the hub you want to test (hub-level switches, tank sensors, the firmware-update entity — anything works). The integration resolves the hub via the device registry.

event values (mirrors firmware buzzer_event_t)

Value	Pattern	When the hub fires this in real life
1	Critical low (<5%)	Tank water drops below 5%, recurring every 60s
2	Overflow (>95%)	Tank water rises above 95%, edge-triggered + gentle 1hr re-nag
3	Sensor offline	TX silent >15min, recurring every 10min
4	Test button	One-shot UI ping (this service's natural choice for "does it work")
6	Pair success	One-shot after RX sends PAIR_ACK to a TX
7	OTA success	First boot after a successful OTA
8	OTA failure	OTA download or perform/finish error

profile values

Value	Loudness
0	Quiet — single short tap, no repeat
1	Standard — design defaults (this is what's used if you omit profile)
2	Loud — longer durations + faster repeat cadence

Example: "Does the buzzer work?" smoke test

Test the buzzer plays at Standard volume:

service: smartghar.test_buzzer
data:
  entity_id: switch.smartghar_004b1299f6dc_buzzer_alerts
  event: 4   # Test button

Same thing but checking loudness for a noisy workshop:

service: smartghar.test_buzzer
data:
  entity_id: switch.smartghar_004b1299f6dc_buzzer_alerts
  event: 4   # Test button
  profile: 2 # Loud

Preview what Critical-low sounds like before setting up automations around it:

service: smartghar.test_buzzer
data:
  entity_id: switch.smartghar_004b1299f6dc_buzzer_alerts
  event: 1   # Critical low

---

Future services (planned)

These were proposed but deliberately not shipped because either HA primitives already cover them, or they're gimmicks:

Proposed	Status	Reason
smartghar.identify_all	❌ Won't ship	Trivially achievable as one automation YAML calling button.press in a loop on identify entities
smartghar.set_low_threshold	❌ Won't ship	Duplicates a proposed number.tank_<n>_low_threshold entity; numeric_state triggers are simpler
smartghar.snapshot_state	🤔 Maybe	Capture a one-shot snapshot of all SmartGhar state for diagnostics. Currently covered by HA's diagnostics download

If you have a use case for a new service that isn't covered, open a GitHub Discussion — we evaluate based on whether HA primitives already do it, and whether multiple users have the same need.