Reference · built on requestConnectorSensors, meters & gateways

Wattwatchers

Circuit-level energy, voltage, and current per channel from Wattwatchers monitors through API v3 (Mercury).

Request accessPricing ↗

About

Wattwatchers makes cellular and Wi-Fi monitors that meter individual circuits through current transformers. API v3, named Mercury, serves at api-v3.wattwatchers.com.au. It lists the devices an API key can see, describes each device's channels, phases, and switches, and returns energy in two series: short energy at 30 second intervals held for 31 days, and long energy on a 5 minute base that rolls up to 15m, 30m, hour, day, week, and month. Devices with a Modbus meter attached return cumulative kWh and kvarh. Each device stores at least one month locally and back-fills after an outage.

An operator on Fibric polls long energy forward from the last timestamp it stored and proposes the load change or the ticket for your approval.

This is a reference listing. It documents what Fibric would read from Wattwatchers and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Devices visible to the key through GET /devices, and each one's status, channels, phases, switches, and signal quality through GET /devices/{device-id}
  • Short energy at 30 second intervals through GET /short-energy/{device-id}: eReal, eReactive, vRMS, iRMS, and frequency, at most 12 hours per request
  • Long energy through GET /long-energy/{device-id} at 5m, 15m, 30m, hour, day, week, or month, with eRealPositive, eRealNegative, vRMSMin, vRMSMax, iRMSMin, and iRMSMax
  • First and latest entries through /short-energy/{device-id}/latest and /long-energy/{device-id}/first, which bound an import
  • Cumulative Modbus meter data through GET /modbus/{device-id}: voltage, current, power factor, and kWh and kvarh totals, at most 7 days per request
  • Channel category definitions and device models through GET /devices/channel-categories and GET /devices/models

Proposed actions

  • Target capability: propose a device label, timezone, channel label, ctRating, or categoryId change through PATCH /devices/{device-id}
  • Target capability: propose a switch state change through PATCH /devices/{device-id}; the API returns 202 Accepted while the device applies it

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Find the load that runs after hours

    Read 5 minute long energy per channel and compare it with the site's operating hours. When a circuit draws outside its schedule, propose the switch change or the ticket with the channel and the kWh involved.

    With Schedule Leak, After-Hours Audit

  • Shed a circuit before the peak lands

    Watch 30 second short energy across the mains phases. When demand climbs toward your threshold, propose which switch-controlled circuits to drop, in order, for your approval.

    With Peak Demand

  • Catch a monitor that went quiet

    Compare /long-energy/{device-id}/latest with the clock and read signal quality from the device record. When data stops or a channel reads zero for hours, propose the site check.

    With Sensor Health, Submeter Drift

Requirements

  • An API key issued by Wattwatchers for the devices you own, sent to api-v3.wattwatchers.com.au
  • Unix timestamps in seconds for fromTs and toTs; a timestamp marks the end of the period it covers
  • A timezone parameter for long energy at hour granularity or coarser
  • Case-sensitive paths and query parameters, with no trailing slash
Authentication
Bearer token authentication with an API key beginning key_ in the Authorization header; Wattwatchers provisions each key against a device set, and existing customers see theirs in the Fleet Management app.

Limits

  • Per key and per day: devices times (288 + 2,880 + 288) requests plus a buffer; per second: devices divided by 3. Both scale with device count
  • Long energy windows depend on granularity: 7 days at 5m, 14 days at 15m, 31 days at 30m, 3 months at hour, 3 years at day
  • After an outage a device may take up to 6 hours to catch up, so recent intervals can arrive late
  • GET /devices returns every device with no pagination; skip and limit were removed in v3

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Wattwatchers ↗

Questions and answers

How fresh is Wattwatchers data?
Short energy is recorded every 30 seconds and kept for 31 days; long energy is on a 5 minute base. A device keeps at least one month locally and can take up to 6 hours to catch up after an outage, so Fibric polls forward from the last stored long energy timestamp.
What are the rate limits?
Per API key, scaled to its devices. Daily requests are devices times (288 + 2,880 + 288) plus a buffer; per second requests are devices divided by 3. Every response carries X-RateLimit headers. Over the limit returns 429 with TOO_MANY_REQUESTS_TPS or TOO_MANY_REQUESTS_TPD and a Retry-After.
Can Fibric switch a circuit?
Only on devices fitted with switches, and only as a proposal you approve. The change goes through PATCH /devices/{device-id} and the API answers 202 Accepted while the device applies it. Fibric records what changed, why, and how to reverse it.
Ask about Wattwatchers

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Wattwatchers through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy