Don't fetch with aggregations less than `billing` when account's read resolution is `billing`

[rct]

As discussed in #30, with ConEd, I'm seeing the exception, ValueError: Requested aggregate_type: hour not supported by account's read_resolution: BILLING from both demo.py and the current Home Assistant integration.

I'm not sure if I'm following along correctly, but it seems If the account's read_resolution is billing, than possibly opower shouldn't try to use an aggregation_type "smaller" than billing?

I believe this exception might also be causing the sensor forecast data not to be populated for the account that has quarter hour read resolution.

This is the exception from the home assistant log:

2023-08-12 19:33:39.187 DEBUG (MainThread) [custom_components.opower.coordinator] Updating Statistics for opower:cned_elec_xxxx921_energy_cost and opower:cned_elec_xxxxxxx921_energy_consumption
2023-08-12 19:33:39.198 ERROR (MainThread) [custom_components.opower.coordinator] Unexpected error fetching Opower data: Requested aggregate_type: hour not supported by account's read_resolution: BILLING
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 283, in _async_refresh
    self.data = await self._async_update_data()
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/opower/coordinator.py", line 73, in _async_update_data
    await self._insert_statistics()
  File "/config/custom_components/opower/coordinator.py", line 104, in _insert_statistics
    cost_reads = await self._async_get_recent_cost_reads(
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/opower/coordinator.py", line 214, in _async_get_recent_cost_reads
    return await self.api.async_get_cost_reads(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/opower/opower.py", line 332, in async_get_cost_reads
    reads = await self._async_get_dated_data(
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/opower/opower.py", line 403, in _async_get_dated_data
    raise ValueError(
ValueError: Requested aggregate_type: hour not supported by account's read_resolution: BILLING
2023-08-12 19:33:39.215 DEBUG (MainThread) [custom_components.opower.coordinator] Finished fetching Opower data in 6.651 seconds (success: False)

My ConEd user returns 3 utilityAccounts:

• Meter type: elec with quarter hour readResolution
• Meter type: elec with billing readResolution
• Meter type: gas with billing readResolution

Here's the (sanitized) results of the ei/edge/apis/multi-account-v1/cws/cned/customers query:

2023-08-09 16:36:52.055 DEBUG (MainThread) [/config/opower/opower.py] Fetching: https://cned.opower.com/
ei/edge/apis/multi-account-v1/cws/cned/customers?offset=0&batchSize=100&addressFilter=
2023-08-09 16:36:52.526 DEBUG (MainThread) [/config/opower/opower.py] Fetched: {
  "customers": [
    {
      "id": xxx385,
      "uuid": "XXX-customer-385-duplex-uuid-XXX",
      "legacyOpowerId": "snip",
      "accountNumber": "XXX-cust-385-duplex-acct-num-XXX",
      "accountName": "",
      "address": { 
...SNIP...
      },
      "type": "RESIDENTIAL",
      "utilityAccounts": [
        {
          "id": xxx537,
          "uuid": "XXX-utilacct-duplex-elec-XXX",
          "utilityAccountId": "XXX-cust-385-duplex-acct-num-XXX",
          "utilityAccountId2": "xxxxxxx",
          "servicePointId": 379095,
          "meterType": "ELEC",
          "preferredUtilityAccountId": "XXX-cust-385-duplex-acct-num-XXX",
          "readResolution": "QUARTER_HOUR"
        }
      ]
    },
    {
      "id": 228384,
      "uuid": "XXX-customer-384-halls-uuid-XXX",
      "legacyOpowerId": "snip",
      "accountNumber": "XXX-cust-384-halls-acct-num-XXX",
      "accountName": "",
      "address": {
...SNIP...
      },
      "type": "SMB",
      "utilityAccounts": [
        {
          "id": xxx535,
          "uuid": "XXX-utilacct-halls-elec-XXX",
          "utilityAccountId": "XXX-cust-384-halls-acct-num-XXX",
          "utilityAccountId2": "xxxxxxx",
          "servicePointId": 379093,
          "meterType": "ELEC",
          "preferredUtilityAccountId": "XXX-cust-384-halls-acct-num-XXX",
          "readResolution": "BILLING"
        },
        {
          "id": xxx536,
          "uuid": "XXX-utilacct-halss-gas-xxx",
          "utilityAccountId": "XXX-cust-384-halls-acct-num-XXX",
          "utilityAccountId2": "3584863",
          "servicePointId": 379094,
          "meterType": "GAS",
          "preferredUtilityAccountId": "XXX-cust-384-halls-acct-num-XXX",
          "readResolution": "BILLING"
        }
      ]
    }
  ],
  "offset": 0,
  "batchSize": 100,
  "total": 2
}

[tronikos]

Do you have the changes in https://github.com/home-assistant/core/pull/97823? I just fixed demo.py with https://github.com/tronikos/opower/commit/eef2a589e1cd57183099670a86847786c4d21857

Reopen if you can still reproduce.

[rct]

Thanks! - https://github.com/home-assistant/core/pull/97823 and the fix to demo.py both fix the exceptions from the mismatch of aggregation and read resolution.

I still don't have any sensors, though now I'm only getting a single:

2023-08-13 12:33:56.334 DEBUG (MainThread) [custom_components.opower.coordinator] Updating sensor data with: []

And an FYI to anyone following along since I pulled in the opower integration with all changes that are currently merged (into homeassistant:dev) I picked up the change to DeviceInfo and am getting this error:

[homeassistant.setup] Unable to prepare setup for platform opower.sensor: Platform not found (cannot import name 'DeviceInfo' from 'homeassistant.helpers.device_registry' (/usr/src/homeassistant/homeassistant/helpers/device_registry.py)).

This is due to the change to sensor.py in https://github.com/home-assistant/core/pull/98149

Oh, and:

Reopen if you can still reproduce.

This doesn't need to be reopened, but since you closed it and not the author (me), only a repo collaborator can reopen.

[tronikos]

Not having forecasts and sensors is most likely due to your multiple accounts associated with the same ConEd account. Since I don't have such an account, the only thing I can do is to accept any PR.

I though the reporter could reopen the issue they reported. Good to know that's not the case from now on.