HA 2025.12.0 removes useful statistics from Ecowitt core integration

[BJReplay]

The problem

As noted in https://github.com/home-assistant/core/pull/155812 included in the change log for 2025.12.0, as suggested here, rather than have rain sensors with a state class of total, the state class was removed.

This results in the repairs for all of the associated rain entities:

However, it should be noted that the fix - deleting long term statistics - is not a useful fix: the long term statistics are actually useful, and the former state class of total is correct: Entities tracking a total amount have a value that may optionally reset periodically - the Ecowitt sensors are not a moving window, but reset on boundaries - e.g. daily, weekly, monthly, etc.

This history chart of weekly and monthly stats clearly shows the resetting nature of the sensors:

What version of Home Assistant Core has the issue?

core-2025.12.0

What was the last working version of Home Assistant Core?

core-2025.11.3

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Ecowitt

Link to integration documentation on our website

https://www.home-assistant.io/integrations/ecowitt

Diagnostics information

ecowitt-5b58a9310031db4cf36c0d93425fa3f5-GW1100C-885f4e2ed564cfb24b2a61fdbb140a73.json

Example YAML snippet

Anything in the logs that might be useful for us?

Nothing found - searched for ecowitt.

Additional information

Repairs listing:

{
  "version": 1,
  "minor_version": 2,
  "key": "repairs.issue_registry",
  "data": {
    "issues": [
      {
        "created": "2025-12-03T22:55:10.200269+00:00",
        "dismissed_version": null,
        "domain": "sensor",
        "is_persistent": false,
        "issue_id": "state_class_removed_sensor.gw1100c_event_rain_rate"
      },
      {
        "created": "2025-12-03T22:55:10.201103+00:00",
        "dismissed_version": null,
        "domain": "sensor",
        "is_persistent": false,
        "issue_id": "state_class_removed_sensor.gw1100c_hourly_rain_rate"
      },
      {
        "created": "2025-12-03T22:55:10.201906+00:00",
        "dismissed_version": null,
        "domain": "sensor",
        "is_persistent": false,
        "issue_id": "state_class_removed_sensor.gw1100c_daily_rain_rate"
      },
      {
        "created": "2025-12-03T22:55:10.202833+00:00",
        "dismissed_version": null,
        "domain": "sensor",
        "is_persistent": false,
        "issue_id": "state_class_removed_sensor.gw1100c_weekly_rain_rate"
      },
      {
        "created": "2025-12-03T22:55:10.203908+00:00",
        "dismissed_version": null,
        "domain": "sensor",
        "is_persistent": false,
        "issue_id": "state_class_removed_sensor.gw1100c_monthly_rain_rate"
      },
      {
        "created": "2025-12-03T22:55:10.204759+00:00",
        "dismissed_version": null,
        "domain": "sensor",
        "is_persistent": false,
        "issue_id": "state_class_removed_sensor.gw1100c_yearly_rain_rate"
      },
      {
        "created": "2025-12-03T22:55:10.205763+00:00",
        "dismissed_version": null,
        "domain": "sensor",
        "is_persistent": false,
        "issue_id": "state_class_removed_sensor.gw1100c_24h_rain"
      }
    ]
  }
}

[home-assistant[bot]]

Hey there @pvizeli, mind taking a look at this issue as it has been labeled with an integration (ecowitt) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of ecowitt can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign ecowitt Removes the current integration label and assignees on the issue, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

ecowitt documentation ecowitt source _{^{(message by IssueLinks)}}

[BJReplay]

Tagging @ogruendel and @zweckj - I think that the change included in 2025.12.0 was incorrect.

The change from TOTAL_INCREASING to TOTAL, in https://github.com/home-assistant/core/pull/155358/files was correct - rain is an increasing total that resets, rather than a total that is always increasing, but is not a sliding window.

Removing the state class entirely, however, was a step too far.

I have made some notes above about the impact of removing the state_class entirely.

My view is that people will lose useful long-term statistics if they accept the repairs, but I could well be wrong.

[Orange-GT3]

I have the same repairs for my WS2900:

[Orange-GT3]

Looks like this issue got flagged during the 2025.12 beta: https://github.com/home-assistant/core/issues/157425

[dimkin-eu]

same 7 piezo fails for sensor.gw2000a_event_rain_piezo-like entries

[zee36]

Hi Everyone I have the same issue, state class attributes are completely removed for my GW2000A rain sensors

[epenet]

Duplicate of #157882 See the resolution there.

[BJReplay]

@epenet as noted above these are resetting totals - as can clearly be seen in the attached history chart.

The daily sensor is not the last 24 hours, but resets at 9am each day.

The Weekly sensor resets at 9am on Sunday.

The Monthly sensor resets at 9am on the 1st of each month. It doesn't cover a rolling 30 days.

They are resetting totals, not rolling windows.

Whilst this issue is a duplicate, the fact is that the the sensors are not rolling windows.

[hendrik001973]

Duplicate of #157882 See the resolution there.

This is no resolution, because many user don't have the lifetime total as sensor/entity.

[g0hww]

I am not inclined to accept these repairs, as I consider this to be a bug. Please fix it.

[Rhonus-nl]

Same issue here, and I believe the correct solution should be to add the 'SensorStateClass.TOTAL_INCREASING' to these sensors:

The sensor's value may reset to 0, and its value can only increase: state class SensorStateClass.TOTAL_INCREASING. Examples: energy consumption aligned with a billing cycle, e.g. monthly, an energy meter resetting to 0 every time it's disconnected

These statistical sensors for rain will only increase (no negative rain is counted) but they do periodically (per hour, day, etc) reset back to 0. So by the description and example given by the HA documentation, this seems to be the right setting. Right?

[roccobar]

Same here

[CHr1sKL]

same here since Core 2025.12.0 with Ecowitt GW3000

[BDBAfH]

same here

[MSVF]

Same here. As workaround, I customized the class_state via the configuration.yaml. Well let me know if this is actually an workaround, at least the repair events disappeared.

[Shiroe93]

Same here. As workaround, I customized the class_state via the configuration.yaml. Well let me know if this is actually an workaround, at least the repair events disappeared.

how did you do it exactly? cuold you share your yaml?

[MSVF]

Same here. As workaround, I customized the class_state via the configuration.yaml. Well let me know if this is actually an workaround, at least the repair events disappeared.

how did you do it exactly? cuold you share your yaml?

homeassistant:
  customize:
    sensor.your_sensor_name_here:
      state_class: total_increasing

[makerwolf]

I don't understand what the fix should have fixed in the first place, because it seems it broke more things than it fixed.

These long term stats are indeed important for me and my setup.

I'm also going to temporarily fix it with the customize: field in my config.yaml.

[Grabuck]

I can't get the yaml to work for me (newbie). I have 14 repairs. I will restore to 11.3 until fixed. Looked like such a good release to. Reely wanted it.

[BJReplay]

I can't get the yaml to work for me (newbie). I have 14 repairs. I will restore to 11.3 until fixed. Looked like such a good release to. Reely wanted it.

@Grabuck - look at the name of the sensors mentioned in each of your repairs - each one mentions the sensor name in the form of sensor.gw1100c_hourly_rain_rate where the gw1100c is the type of Ecowitt device you have.

Look in your configuration.yaml file - I assume you've found it.

If you don't already have a line that starts with homeassistant: (at the very left hand side - not space indentation), add it.

Underneath, add, with two spaces, customize:, then list each sensor with a colon, and then state_class: total or total_increasing (either will work).

Here's an example that you can cut and paste - all you need to do is change gw11000c to your Ecowitt device (and remove / add any other rain sensors).

homeassistant:
  customize:
    sensor.gw1100c_24h_rain:
      state_class: total_increasing
    sensor.gw1100c_yearly_rain_rate:
      state_class: total_increasing
    sensor.gw1100c_monthly_rain_rate:
      state_class: total_increasing
    sensor.gw1100c_weekly_rain_rate:
      state_class: total_increasing
    sensor.gw1100c_daily_rain_rate:
      state_class: total_increasing
    sensor.gw1100c_hourly_rain_rate:
      state_class: total_increasing
    sensor.gw1100c_event_rain_rate:
      state_class: total_increasing

[Steve2017]

Here's an example that you can cut and paste - all you need to do is change gw11000c to your Ecowitt device (and remove / add any other rain sensors).

I'm not sure that is an enduring fix. For a start when I did something similar, all my historic rain data disappeared - as though I had accepted the fix and deleted the historic data. So nothing was achieved.

The change that caused this is listed here: https://github.com/home-assistant/core/pull/155812

and the new code for the integration is here: https://github.com/home-assistant/core/blob/4419c236e23f67bd7a824f1c1f39ad8b0c325f9e/homeassistant/components/ecowitt/sensor.py

That deals with state_class, so I am not sure that "customize" entries will be the right way to go in the long term. It might create a conflict.

This should have been a breaking change or as it's now labelled "Backward Incompatible Changes". Better still a transition plan should have been implemented.

[BJReplay]

I'm not sure that is an enduring fix.

Nor am I! But I had not accepted the suggested fix 😉 which would have deleted the statistics. Instead I added a measurement class back to the sensors.

This should have been a breaking change or as it's now labelled "Backward Incompatible Changes".

Agree

[epenet]

Anyone can create a PR to revert #155812 and/or #157409 If you do it today, maybe it will be in 2025.12.1

[mike-nott]

So is the best option to just leave the repairs showing in HA until 2025.12.1 and they will self resolve?

[thowiegit]

So is the best option to just leave the repairs showing in HA until 2025.12.1 and they will self resolve?

That way at least you will not lose your already recorded historic data. But if you simply wait no new data will be recorded to the long term archive. You already have a gap now. So best option is to mitigate this problem inside your configuration.yaml as shown above, last time from BJReplay 9 hours ago.

[gjsiii]

So is the best option to just leave the repairs showing in HA until 2025.12.1 and they will self resolve?

I found that the issue with long-term stats being deleted from other integrations too so I restored to a backup of 2025.11.3. The other integrations that seemed to be missing long-term stats were for my water usage (Phyn integration) and electric usage (Rainforest Eagle integration). I'll skip 2025.12 and wait for 2025.12.1.

[MarkusTec]

Joining the chorus here....same!

The ".12" release appears to have had a downstream impact to all Ecowitt Weather Station users, with across the board sensor state class warnings (specific to all rain entity sensors only).

Even Claude (my go to ai for HA code), along with other LLM's are advising not to delete the history and sit tight for a patch release. That said, at least core functionality is preserved!

[gclenaghan]

I think the issue is that this state class (or absence thereof) applies to seven different sensors, some are rolling windows and some are totals with resets.

IIUC: event: total hourly: rolling daily: total weekly: total monthly: total yearly: total 24h: rolling

so the fix is more subtle than a simple revert (though I would personally favor a revert followed by a proper fix)

[Hattuma]

Same problem here. Hopefully it gets repaired soon. I love my statistics.

[DeepHyperspace]

2025.12.1 was released, after installing that version the error is vanished 🥇