-
Notifications
You must be signed in to change notification settings - Fork 0
FAQ
Quick answers to frequent questions. For deeper guidance see Home or Troubleshooting.
No. The integration is purely local. The hub's only outbound internet use is for its own OTA firmware checks (every 24 hours), which is independent of HA. HA itself never makes outbound requests on behalf of the integration.
No. A SmartGhar account is required to use the PWA at tanksync.smartghar.org (cloud + away-from-home access). The HA integration is local-LAN only and never authenticates against any cloud service.
DHCP rotations are handled automatically by zeroconf re-discovery. The hub re-broadcasts its mDNS service when it reconnects to Wi-Fi, and HA's zeroconf listener updates the integration's stored IP transparently — typically within an hour without any action from you.
Yes. Each hub broadcasts independently and gets its own HA device. Entities are namespaced by hub_id (MAC-derived) so collisions are impossible. See Multi-Hub-Setup.
| Firmware version | What it enables |
|---|---|
rx-v2.7.0 |
SmartGhar Protocol v1 — mDNS service + /api/v1/* REST + WebSocket |
rx-v2.7.1 |
Identify endpoints (hub + per-tank), reboot endpoint |
rx-v2.7.2 |
Per-tank identify in the local web UI (no functional change for HA) |
rx-v2.7.10 |
MAC-anchored device identity (paired with tx-v2.0.11). Needed for HACS v0.8.0's async_migrate_entry and entity-cleanup hooks. |
rx-v2.8.0 |
Buzzer alerts — physical buzzer on GPIO02 plays boot tone + critical-low + overflow + sensor-offline + opt-in events. Controllable today via the PWA and the hub local web UI. HA-native entities land in HACS v0.8.0 (requires rx-v2.8.4+). |
rx-v2.8.3 |
sensor_stuck variance detection — second safety net alongside sensor_error. Catches defective JSN-SR04M / AJ-SR04M sensors that report a constant ~20-25 cm reading regardless of actual water level. Surfaces as state.sensor_stuck boolean in /api/v1/devices — HACS v0.8.0 exposes this as binary_sensor.smartghar_<hub>_tank_<n>_sensor_stuck. |
rx-v2.8.4 |
HACS-friendly buzzer endpoints at /api/v1/hub/buzzer (GET / PUT) and /api/v1/hub/buzzer/test (POST). HACS v0.8.0 reads + writes buzzer config via these. Without this version, the buzzer entities in HACS won't register (they self-suppress when the endpoint isn't there — no permanent-unavailable clutter). Also fixes a false-positive Critical-low beep on tanks that haven't sent their first packet yet. |
The integration silently degrades on older firmware — it'll fall back to polling if WebSocket is unavailable, or hide newer features.
Yes. The full HTTP + WebSocket spec is at docs/protocol/v1.md, Apache-2.0 licensed. Anyone can write a third-party client.
Pre-1.0 SemVer allows occasional breaking changes during the early-feedback period. We'll cut v1.0 after a ~6-week stability soak and a HACS default-repo submission. The protocol itself (firmware-side) is stable v1; only HA-side entity shapes might shift in HA-side minor versions.
GitHub Issues with diagnostics download attached. See Troubleshooting#filing-a-bug.
Yes — the integration is designed cross-product. When PowerSync ships, it'll auto-discover under the same SmartGhar integration without you needing a second HACS install. The integration's device_kind taxonomy already accounts for power, gas, pump_relay, soil, door, air.
Yes — the LoRa frequency is configurable in the firmware (default 865 MHz for India/EU; switch to 915 MHz for US/AU). The HA integration is region-agnostic — it speaks to the hub via Wi-Fi LAN regardless of LoRa frequency.
No, and not on the roadmap. We recommend the community lovelace-fluid-level-background-card paired with our assets/tank-silhouette.svg. See docs/lovelace-beautification.md.
This is a deliberate non-goal. The community card already delivers ~90% of the visual benefit at much lower maintenance cost than us shipping our own.
Energy-Dashboard has the full walkthrough. Quick version: Settings → Energy → Water consumption → Add water source → pick the SmartGhar tank's _water_consumed sensor.
Yes. Use the text.smartghar_<hub>_tank_<n>_name entity. The change propagates to the SmartGhar PWA via the existing config-sync MQTT path within seconds.
No, deliberately. Wi-Fi credentials are sensitive and editing them from HA is the kind of operation that should require physical proximity to the hub. Use the SmartGhar PWA or the hub's local web UI for that.
The hub keeps working. The TXs keep transmitting. The SmartGhar PWA keeps receiving cloud-mediated updates. When HA comes back online, the integration reconnects and resumes.
HA entities go unavailable. The integration retries with exponential backoff. When the hub returns, entities recover automatically.
Toggle any entity (e.g., LED brightness) — that triggers a coordinator refresh. Or restart HA, which re-runs the first config entry refresh.
That's a TX-side voltage reading mode where it reports the input/USB voltage rather than the battery cell. It can happen during charging, on USB-powered TXs, or with TX firmware variants that don't have proper voltage-divider calibration. Not an integration issue. See Troubleshooting#tx-battery-voltage-shows-503-v.
~/.homeassistant/custom_components/smartghar/
(or wherever your HA config directory lives). Don't edit these manually — HACS manages them.
HACS → SmartGhar → ⋮ → Remove
Settings → Devices & Services → SmartGhar → ⋮ → Delete (if entries remain)
Settings → System → Restart Home Assistant
Hub itself + PWA are unaffected.
Built by SmartGhar · GitHub · Discussions · MIT licensed (code) / Apache-2.0 (protocol)