Skip to content

Wattwatchers API Release Notes

v3.6.0

Released: 26 April 2024

  • Changed Added support for the 6MW and 6MW-CER products.

v3.5.1

Released: 11 June 2020

  • Changed "Behind the scenes" updates preparing for upcoming changes related to communications and subscriptions.

v3.5

Released: 25 May 2020

Changes

  • New Capability to set and get label and timezone for a device.
  • Added additional permission levels to API keys relating to changing device metadata and/or configuration.

Endpoints affected

  • GET /devices/{device-id}
  • PATCH /devices/{device-id}

v3.4.5

Released: 08 May 2020

  • Fixed 422 error being incorrectly returned for switch state or metadata changes.

v3.4.4

Released: 07 May 2020

  • Fixed Switching no longer incorrectly available for 6M+One devices.

v3.4.3

Released: 15 Apr 2020

  • Fixed Error 400 no longer returned when the calculated power factors are requested in the query parameters when using software clients that translate + to space.
  • Fixed No longer errors when computing power factor with monthly aggregation.

v3.4.2

Released: 06 Apr 2020

  • Fixed No longer errors when unit conversion is used with monthly aggregation.

v3.4.1

Released: 13 Mar 2020

  • Fixed Issues with wrong CT rating returned in status for uninitialised Rogowski devices.

v3.4.0

Released: 10 Mar 2020

Changes

  • Unit conversion to kilowatt hours (kWh, energy) and kilowatts (kW, power) for short and long energy data values. Includes support for filter[group]=phases to enable 3 phase installations to return kWh for each combined-phase channel.
  • Calculated power factor for short and long energy data packets. (Note: can't be combined with filter[group]=phases)
  • "Timestamp only" return for first and latest short and long energy, and modbus data.
  • Significant performance improvements to first + latest values (utilising caching where possible)

Endpoints affected

  • GET /long-energy/{device-id} support for convert[energy] and fields[energy]=+pf query string parameters.
  • GET /long-energy/{device-id}/first support for convert[energy], fields[energy]=timestamp and fields[energy]=+pf query string parameters.
  • GET /long-energy/{device-id}/latest support for convert[energy], fields[energy]=timestamp and fields[energy]=+pf query string parameters.
  • GET /short-energy/{device-id} support for convert[energy], fields[energy]=+pf query string parameters.
  • GET /short-energy/{device-id}/first support for convert[energy], fields[energy]=timestamp and fields[energy]=+pf query string parameters.
  • GET /short-energy/{device-id}/latest support for convert[energy], fields[energy]=timestamp and fields[energy]=+pf query string parameters.

Note that fields[energy]=+pf cannot be combined with filter[group]=phases.

Fixes

  • Some uninitialised devices being incorrectly returned as "Offline" (GET /devices/{device-id})
  • latestStatus and other fields were not being returned for some devices (GET /devices/{device-id})
  • Issue with changing the CT rating for a channel and the "pending" value not correctly being returned.

v3.3.6

Released: 10 Feb 2020

  • Fixed Issues with incomplete status being returned for some devices.

v3.3.5

Released: 15 Oct 2019

  • Fixed Issues with retrieving switch state for some devices.

v3.3.4

Released: 20 Sep 2019

  • Fixed Issues with setting switch state for some devices, resulting in a 500 error when accessing device status.
  • Fixed GET /devices/{device-id} No longer returns an empty switches collection for non-switching devices.

v3.3.3

Released: 18 Sep 2019

  • Fixed Further fixes for intermittent error with setting channel category ID.

v3.3.2

Released: 14 Sep 2019

  • Fixed Intermittent error with setting channel category ID to "Not set."

v3.3.1

Released: 08 Sep 2019

  • Fixed An issue that would stop processing of switch state using PATCH /devices/{device-id} for recently initialised devices.

v3.3.0

Released: 03 Sep 2019

  • New PATCH /devices/{device-id} now supports setting of channel.categoryId
  • Fixed GET /devices/{device-id} and PATCH /devices/{device-id} now correctly returns channel.ctRating=3000 for Rogowski devices.

v3.2.5

Released: 02 Sep 2019

  • Fixed GET /devices/{device-id} and PATCH /devices/{device-id} now better handle certain cases of device metadata misconfiguration.

v3.2.4

Released: 14 Aug 2019

  • Fixed PATCH /devices/{device-id} now fully validates count and grouping values for specific edge cases.

v3.2.3

Released: 13 Aug 2019

  • Fixed PATCH /devices/{device-id} endpoint now correctly accepts the grouping property.
  • Fixed GET /devices/{device-id} now returns grouping values for irregular CT order (e.g. where count is non-zero and a custom groupings value is specified).

v3.2.2

Released: 29 Jul 2019

  • Changed Performance improvements for Long and Short energy data calls for 5m, 15m and 30m granularity.
  • Fixed Timestamp not being included in combined phase output in some circumstances.
  • Fixed Duration now always returned as an integer in combined phase output (was returned as a float in some circumstances.)

Endpoints affected

  • GET /long-energy/{device-id}
  • GET /short-energy/{device-id}

v3.2.1

Released: 11 Jul 2019

  • Fixed Performance improvements.
  • Fixed Issue with rate limit headers not returned for some endpoints.

v3.2.1

Released: 11 Jul 2019

  • Fixed Performance improvements.

v3.2

Released: 10 Jul 2019

  • New Option to combine Long and Short energy channel output for 3 phase installs into a single data-point per phase. See Phase grouping for details.

Endpoints affected

Enhances functionality of previous API version in a backwards-compatible way, so version number of the API endpoint won't change.

  • GET /devices/{device-id}.phases property returned
  • PATCH /devices/{device-id}.phases property editing available
  • GET /long-energy/{device-id}?filter[group]=phases
  • GET /short-energy/{device-id}?filter[group]=phases

v3.1

Released: May 2019

  • New Write operations for select device properties, such as CT rating and switch state. (Per API key permissions model for write functions.)

Endpoints affected

  • PATCH /devices/{device-id} to set metadata and device properties (incl. switch state)

v3.0

Released: Feb 2019

This release moves to new infrastructure and there are some minor changes in API behaviour that may cause issues for some API consumers porting existing integrations. As such we will increment the API version number for this release, now available at https://api-v3.wattwatchers.com.au.

Please contact the Wattwatchers team if you wish to access the new API, so that we can migrate your API key and device data.

Changes

  • Improved performance
  • Read device config information (e.g. CT rating, channel metadata, switch state)
  • Improved status codes + response payloads in error cases
  • Clearer handling of granularity and fromTs/toTs interactions
  • Reduced rate limiting restrictions

Endpoints affected

  • GET /devices: unpaginated list of all devices authorized for access by the API key
  • GET /devices/{device-id}: NEW: status and metadata information for a specific device
  • GET /devices/channel-categories NEW: returns a collection of the categorisation schema for channels
  • GET /devices/models NEW: returns a collection of valid device models (e.g. 3M, 6M+One etc.)
  • GET /long-energy/{device-id}: as per existing API
  • GET /long-energy/{device-id}/first: NEW: the first long energy data entry for a device
  • GET /long-energy/{device-id}/latest: NEW: the latest long energy data entry for a device
  • GET /modbus/{device-id}: NEW: equivalent of GET /long-energy for modbus devices
  • GET /modbus/{device-id}/first: NEW: the first modbus data entry for supporting devices
  • GET /modbus/{device-id}/latest: NEW: the latest modbus data entry for supporting devices
  • GET /short-energy/{device-id}: as per existing API
  • GET /short-energy/{device-id}/first: NEW: the first short energy data entry for a device
  • GET /short-energy/{device-id}/latest: NEW: the latest short energy data entry for a device

See Differences between v2 and v3+ for information on the (mostly minor) implementation differences between v2 and v3 APIs.