Could not fetch consumption: 400

[Deishelon]

System Health details

System Information

version	core-2025.10.2
installation_type	Home Assistant Container
dev	false
hassio	false
docker	true
container_arch	amd64
user	root
virtualenv	false
python_version	3.13.7
os_name	Linux
os_version	6.1.0-38-amd64
arch	x86_64
timezone	Pacific/Auckland
config_dir	/config

Home Assistant Cloud

logged_in	false
can_reach_cert_server	ok
can_reach_cloud_auth	ok
can_reach_cloud	ok

Dashboards

dashboards	6
resources	5
error	/config/ui-lovelace.yaml not found
views	15
mode	yaml

Network Configuration

adapters	lo (disabled), eno1 (enabled, default, auto), br-77613b2ca20e (disabled), br-8615c83c54e7 (disabled), br-89c632e45ab3 (disabled), br-4cbbba1b28eb (disabled), br-57cc98ec3ee5 (disabled), br-9b7bdeaa3f8d (disabled), br-ae281e50cf58 (disabled), br-ed1af2a5b567 (disabled), br-38b4fb232559 (disabled), br-4c3a59b6e38e (disabled), br-7458a444a21f (disabled), br-91aad4d2bad3 (disabled), br-1166aa2c855e (disabled), br-345c2deb6329 (disabled), br-3eceebbf9494 (disabled), br-9585e4a99484 (disabled), docker0 (disabled), br-bb4038f1bf6c (disabled), br-fe4f7f087efe (disabled), br-317b26ee4e9a (disabled), br-353910746b86 (disabled), br-45f6dc33b5c0 (disabled), br-5d5895d224b8 (disabled), br-1cbf6d16d240 (disabled), veth6064040 (disabled), veth45e47fa (disabled), veth594e7ca (disabled), veth254f7a6 (disabled), veth41d5cc1 (disabled), veth6f73018 (disabled), veth50f9323 (disabled), veth039ee0c (disabled), veth7a94659 (disabled), veth099afa1 (disabled), veth54d39c9 (disabled), vethf2a3feb (disabled), vetha791475 (disabled), veth1822a3f (disabled), veth6a4bf32 (disabled), vethedef080 (disabled), veth660d109 (disabled), veth4220092 (disabled), veth7a904ff (disabled), vethf2842ae (disabled), vethb27a4b0 (disabled), vethc81b910 (disabled), vethf6bef24 (disabled), veth22f8cb4 (disabled), veth7318086 (disabled)
ipv4_addresses	lo (127.0.0.1/8), eno1 (192.168.10.137/24), br-77613b2ca20e (172.25.0.1/16), br-8615c83c54e7 (172.21.0.1/16), br-89c632e45ab3 (192.168.112.1/20), br-4cbbba1b28eb (172.19.0.1/16), br-57cc98ec3ee5 (172.28.0.1/16), br-9b7bdeaa3f8d (172.22.0.1/16), br-ae281e50cf58 (172.24.0.1/16), br-ed1af2a5b567 (172.29.0.1/16), br-38b4fb232559 (172.30.0.1/16), br-4c3a59b6e38e (172.23.0.1/16), br-7458a444a21f (192.168.128.1/20), br-91aad4d2bad3 (192.168.160.1/20), br-1166aa2c855e (172.31.0.1/16), br-345c2deb6329 (172.18.0.1/16), br-3eceebbf9494 (192.168.16.1/20), br-9585e4a99484 (192.168.48.1/20), docker0 (172.17.0.1/16), br-bb4038f1bf6c (172.26.0.1/16), br-fe4f7f087efe (172.20.0.1/16), br-317b26ee4e9a (192.168.144.1/20), br-353910746b86 (192.168.32.1/20), br-45f6dc33b5c0 (192.168.96.1/20), br-5d5895d224b8 (192.168.80.1/20), br-1cbf6d16d240 (172.27.0.1/16), veth6064040 (), veth45e47fa (), veth594e7ca (), veth254f7a6 (), veth41d5cc1 (), veth6f73018 (), veth50f9323 (), veth039ee0c (), veth7a94659 (), veth099afa1 (), veth54d39c9 (), vethf2a3feb (), vetha791475 (), veth1822a3f (), veth6a4bf32 (), vethedef080 (), veth660d109 (), veth4220092 (), veth7a904ff (), vethf2842ae (), vethb27a4b0 (), vethc81b910 (), vethf6bef24 (), veth22f8cb4 (), veth7318086 ()
ipv6_addresses	lo (::1/128), eno1 (fe80::5265:f3ff:fe36:dc90/64), br-77613b2ca20e (fe80::140e:3aff:fe24:9fe9/64), br-8615c83c54e7 (fe80::dcac:ceff:fe03:ab20/64), br-89c632e45ab3 (fe80::c05:c3ff:fe90:eece/64), br-4cbbba1b28eb (), br-57cc98ec3ee5 (fe80::bc61:2cff:fef5:6fc/64), br-9b7bdeaa3f8d (fe80::f42a:98ff:feff:6761/64), br-ae281e50cf58 (), br-ed1af2a5b567 (fe80::f1:96ff:fec5:8666/64), br-38b4fb232559 (fe80::2cd5:aff:fe4c:e0a0/64), br-4c3a59b6e38e (fe80::419:7bff:fef7:69dd/64), br-7458a444a21f (), br-91aad4d2bad3 (), br-1166aa2c855e (), br-345c2deb6329 (fe80::8092:3cff:fe9c:d8d4/64), br-3eceebbf9494 (fe80::7455:4fff:fe21:ab14/64), br-9585e4a99484 (fe80::d0c7:63ff:fe36:3abc/64), docker0 (fe80::487:a5ff:fe52:c9be/64), br-bb4038f1bf6c (fe80::d887:c6ff:feee:5478/64), br-fe4f7f087efe (fe80::482d:2fff:fe08:bd9/64), br-317b26ee4e9a (), br-353910746b86 (fe80::6078:21ff:fe42:532e/64), br-45f6dc33b5c0 (fe80::2ca7:57ff:fe31:ac2c/64), br-5d5895d224b8 (), br-1cbf6d16d240 (fe80::84bc:ecff:fef0:af2b/64), veth6064040 (fe80::3033:84ff:fe37:8c32/64), veth45e47fa (fe80::7425:17ff:feff:6afe/64), veth594e7ca (fe80::68be:80ff:fe2f:b7f8/64), veth254f7a6 (fe80::84d5:18ff:fe51:356b/64), veth41d5cc1 (fe80::b817:36ff:fe66:cddf/64), veth6f73018 (fe80::94b7:d2ff:fe71:83cc/64), veth50f9323 (fe80::5411:9bff:febe:8f93/64), veth039ee0c (fe80::d077:ebff:fec7:8071/64), veth7a94659 (fe80::948a:73ff:fe19:e815/64), veth099afa1 (fe80::a84f:b0ff:fe2e:84d7/64), veth54d39c9 (fe80::605b:59ff:fe8b:6fc7/64), vethf2a3feb (fe80::cc1a:9eff:feb7:1262/64), vetha791475 (fe80::889:a1ff:fee8:a5be/64), veth1822a3f (fe80::c453:fcff:fe63:6aa/64), veth6a4bf32 (fe80::583c:e1ff:fe2d:3290/64), vethedef080 (fe80::c004:38ff:fe6b:c858/64), veth660d109 (fe80::24e0:9eff:feb2:a00/64), veth4220092 (fe80::d89e:3bff:fe63:5ef9/64), veth7a904ff (fe80::68d5:20ff:fe26:7d16/64), vethf2842ae (fe80::67:86ff:fe75:80dc/64), vethb27a4b0 (fe80::3c4b:89ff:fed3:44d/64), vethc81b910 (fe80::7834:35ff:feed:fc72/64), vethf6bef24 (fe80::b08f:23ff:fea9:9ccf/64), veth22f8cb4 (fe80::d861:f5ff:fe4b:6892/64), veth7318086 (fe80::f869:beff:fe99:343d/64)
announce_addresses	192.168.10.137, fe80::5265:f3ff:fe36:dc90

Recorder

oldest_recorder_run	October 2, 2025 at 7:16 AM
current_recorder_run	October 14, 2025 at 7:11 AM
estimated_db_size	673.31 MiB
database_engine	sqlite
database_version	3.49.2

Checklist

• I have enabled debug logging for my installation.
• I have filled out the issue template to the best of my ability.
• This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
• This issue is not a duplicate issue of any previous issues..

Describe the issue

After installing the this integration, and adding details (login/password), I got no entities:

So, after enabling the debug logging, I found API/JSON errors for watercare integration.

Reproduction steps

1. Add integration
2. Set it up by providing login
3. Observe no entities are fetches from watercare API

Debug logs

2025-10-14 07:15:04.496 ERROR (MainThread) [custom_components.watercare.api] Could not fetch consumption: 400
2025-10-14 07:15:04.497 ERROR (MainThread) [homeassistant.components.sensor] watercare: Error on device update!
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 807, in _async_add_entity
    await entity.async_device_update(warning=False)
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1314, in async_device_update
    await self.async_update()
  File "/config/custom_components/watercare/sensor.py", line 193, in async_update
    await self.process_data(response)
  File "/config/custom_components/watercare/sensor.py", line 198, in process_data
    billing_periods = json.loads(response)
  File "/usr/local/lib/python3.13/json/__init__.py", line 339, in loads
    raise TypeError(f'the JSON object must be str, bytes or bytearray, '
                    f'not {s.__class__.__name__}')
TypeError: the JSON object must be str, bytes or bytearray, not NoneType

Diagnostics dump

No response

[Deishelon]

Update:

I put a breakpoint (api.py -> get_data -> line 224) where it gets 400 from watercare API,
await response.text() at that point is: '{"code":"INVALID_REQUEST_BODY"}' along with response.status of 400

Perhaps watercare has changed the API, so it would mean that everyone using this integration having this issue ?

[brunsy]

It's still working for me, so doesn't affect everyone.

Do you have a smart meter?
What endpoint did you pick ( halfhourly, dailywithstats, monthly, mechanicalmonthly)?

[Deishelon]

Yes, I have EDMI smart meter like this:

Plus can see the data on the watercare mobile app:

I've started with halfhourly but then upon seeing errors, I've tried all other endpoints and got this:

Errors (400):

• halfhourly - 400 ${"code":"INVALID_REQUEST_BODY"}
• dailywithstats - 400 ${"code":"INVALID_REQUEST_BODY"}
• monthly - 400 ${"code":"INVALID_REQUEST_QUERY"}

Interestingly halfhourly and dailywithstats return INVALID_REQUEST_BODY but monthly - INVALID_REQUEST_QUERY

And oddly mechanical one does not return error, but returns empty array with 200:
mechanicalmonthly - []

Any ideas on what to try next ?

[Deishelon]

Ok, some very interesting progress,
I've got the proxy going so can see what the app is sending to the server (and hoping to see what is different to this script)

And good news? I found the culprit,
The app is sending the GET with from and to query args:

where this script is using startDate and endDate

After doing the following change in the script:

diff --git a/custom_components/watercare/api.py b/custom_components/watercare/api.py
index b81867e..1f8b2fb 100644
--- a/custom_components/watercare/api.py
+++ b/custom_components/watercare/api.py
@@ -212,7 +212,7 @@ class WatercareApi:
 
         url = f"{self._url_base}v1/usage/{self._accountNumber}/{endpoint}"
         if start_date and end_date:
-            url += f"?startDate={start_date}&endDate={end_date}"
+            url += f"?from={start_date}&to={end_date}"

And calling it with as such:

res = await api.get_data("halfhourly", start_date="2025-10-12T11:00:00Z", end_date="2025-10-13T10:59:59Z")
print(f"halfhourly - {res}")

I've finally got the OK response with the data:

truncated example:

[{"timestamp":"2025-10-12T11:00:00.000Z","litres":0},{"timestamp":"2025-10-12T11:30:00.000Z","litres":2}]

But this does mean, we now have to provide the to&from in the call,

res = await api.get_data("halfhourly", start_date="1970-10-12T11:00:00Z", end_date="2025-10-13T10:59:59Z")
print(f"halfhourly - {res}")

If I set the start_date in 1970 (epoch-ish), I get the response with data that goes all the way back to the start of my account for this property.

But (!), it's not that simple... it seems like they have a limit on a DB query, or API response limit, as it limits number of entries to 7755 (odd number, huh?)

So the script would need to do paginated calls, if the script was to query all.

So unsure yet, how we could plug this into HA.

What's odd is that this works for you, and I observe another behaviour. Yet we call the same API version endpoint.
Could they be doing dynamic routing on the server side?
Do you have another smart water meter vs me ? (could that take another code path on watercare backend?)

[brunsy]

Thanks for looking into this.

I’m no longer on a smart meter so could be that every other endpoint needs updating…

Sorry I’ve been really busy IRL and I won’t really have time in the next week to look into this myself but happy to merge in any PRs that fix it for you.

[BadCo-NZ]

Any progress on this? I just found this integration today and am having the same issues.

Thanks for all your efforts so far @Deishelon @brunsy

[brunsy]

I've pushed the update as a pre-release, could you let me know if it resolves this.

If anyone else wants to take a look at batch fetching the data I did something similar in my frankenergy repo. Which you can probably copy across.

[DataBitz]

0.1.0 beta 3 seems to be working for me now, however I was running 0.0.1 so probably not a valid test.

[BadCo-NZ]

I was on 0.1.0 beta2, updating to beta3, restarted and re-added the integration and still no entities

Logger: homeassistant.components.sensor
Source: helpers/entity_platform.py:807
integration: Sensor (documentation, issues)
First occurred: 9:28:51 PM (2 occurrences)
Last logged: 10:33:23 PM

watercare: Error on device update!
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 807, in _async_add_entity
    await entity.async_device_update(warning=False)
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1314, in async_device_update
    await self.async_update()
  File "/config/custom_components/watercare/sensor.py", line 193, in async_update
    await self.process_data(response)
  File "/config/custom_components/watercare/sensor.py", line 198, in process_data
    billing_periods = json.loads(response)
  File "/usr/local/lib/python3.13/json/__init__.py", line 339, in loads
    raise TypeError(f'the JSON object must be str, bytes or bytearray, '
                    f'not {s.__class__.__name__}')
TypeError: the JSON object must be str, bytes or bytearray, not NoneType

This error originated from a custom integration.

Logger: custom_components.watercare.api
Source: custom_components/watercare/api.py:230
integration: Watercare (documentation, issues)
First occurred: 9:28:51 PM (2 occurrences)
Last logged: 10:33:23 PM

Could not fetch consumption: 400

[gunkaaa]

from and to appear to be mandatory parameters now, which aren't being provided as of 0.1.0-beta3

$ curl  -H "authorization: Bearer $BEARER" "https://customerapp.api.water.co.nz/v1/usage/$ACCOUNTNUMBER/halfhourly"
{"code":"INVALID_REQUEST_BODY"}

$ curl -H "authorization: Bearer $BEARER" "https://customerapp.api.water.co.nz/v1/usage/$ACCOUNTNUMBER/halfhourly?from=2025-10-12T11:00:00Z&to=2025-10-13T10:59:59Z"
[{"timestamp":"2025-10-12T11:00:00.000Z","litres":(.....)

edit: sorry, I really should read through other responses properly...

[brunsy]

So can you guys confirm whether this is still a problem on 0.1.0-beta3 as it should be using from and to now.
If it is can someone create a PR for this.

As I mentioned above I no longer have a smart-meter so am unable to test what these endpoints return anymore.

[gunkaaa]

I can confirm that it's not using from and to: Calling API URL: https://customerapp.api.water.co.nz/v1/usage/(...)/halfhourly with headers {'authorization': (...)

I'm not a python person, but as far as I can see async def get_data(self, endpoint: str, start_date: str = None, end_date: str = None) is only ever called as await self._api.get_data(endpoint=self._endpoint)