Ecowitt GW2000B: "The entity no longer has a state class"

[sxdjt]

The problem

Just updated to HAOS 2025.12 and got these notifications for my GW2000B sensors:

The entity no longer has a state class

We have generated statistics for 'Ecowitt Event Rain Piezo' (sensor.gw2000b_event_rain_piezo) in the past, but it no longer has a state class, therefore, we cannot track long term statistics for it anymore.

Statistics cannot be generated until this entity has a supported state class.

If the state class was previously provided by an integration, this might be a bug. Please report an issue.
If you previously set the state class yourself, please correct it. The different state classes and when to use which can be found in the developer documentation.
If the state class has permanently been removed, you may want to delete the long term statistics of it from your database.

Do you want to permanently delete the long term statistics of sensor.gw2000b_event_rain_piezo from your database?

What version of Home Assistant Core has the issue?

core-2025.12.0

What was the last working version of Home Assistant Core?

No response

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

No response

Example YAML snippet

Anything in the logs that might be useful for us?

Additional information

[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)}}

[epenet]

This is correct. The invalid state class was removed. You can follow the tepair process, and delete the long term statistics.

[sxdjt]

Thank you for verifying!

[zee36]

Hi @epenet

I have the same message for my GW2000A, in case I proceed with the repair as suggested above, am I still gonna have the long term statistics for my rain history in any ways? In the 'States' sections currently I don't see any 'state classes' to my rain sensors, and I thought this is mandatory to have the long term statistics in home assistant. Many thanks

[epenet]

The state class was only removed from rolling window sensors. The state class for "lifetime total" was not removed.

See #157409 and #155812

[zee36]

The state class was only removed from rolling window sensors. The state class for "lifetime total" was not removed.

See #157409 and #155812

Hi, unfortunatelly this is not the case, the state class attribute is now removed for all of my rain sensors, and I'm worried that I'm loosing the long term history if I proceed with the repair

[dimkin-eu]

@epenet , i do not have any rolling windows from ecowitt, but all rain sensors are screaming now

[epenet]

"yearly" "monthly" "weekly", etc. are rolling windows. The state class was invalid - it has been removed.

You need to follow the repair process, and delete the long term statistics for these sensors.

[BJReplay]

"yearly" "monthly" "weekly", etc. are rolling windows.

@epenet any chance you can clarify the difference between a rolling window and a (resetting) total?

Daily, Weekly, Monthly and Yearly rain totals accumulate until the reset point (1st hour of day, day of week, month and year).

They do not report the rain for the previous 365 days, 30 days or 24 hours.

They are resetting totals.

See history chart in https://github.com/home-assistant/core/issues/157903 where you can see the resets.

Attached is another example of Weekly and Monthly rain showing the resets.

An explanation would be of great assistance.

[Steve2017]

It appears that this "repair" simply deletes all historic data. I tried one repair on daily rain rate and where I used to have years of data, I now have 10 days. Is that the expected outcome of the repair?

[zee36]

It appears that this "repair" simply deletes all historic data. I tried one repair on daily rain rate and where I used to have years of data, I now have 10 days. Is that the expected outcome of the repair?

I think this is the point here, I get that logically these sensors would not require state class, however the side effect is that Home Assistant only puts the stats to long term history, when state class is defined for a certain sensor (measurement, total or total-increasing).
Deleting this attribute will get rid of yearly stats for many of us, and will have visibility only for the past 5days or so.

Look at example below, this is my yearly rain stat, nicely showing the cumulative yearly rain volumes, and I don't have a sensor for total rain measures for my GW2000A, only the 'rolling window' types provided. In case I go forward with the repair suggestion, these all will get deleted.

[Steve2017]

Yes - it is unfortunate that the answer is is quite dismissive or glib. I hope that is not intentional. I get that the change might be necessary, but there is no acknowledgement that the side effect is "start from year zero".

[hendrik001973]

Hi, I absolutely agree. I use this data for generating Plotly graphs for monthly rainfall. I use a HP2564AE_Pro_V2.0.4 in connection with a WS90 station.

All this data would be deleted. I don't have a "lifetime total" entitiy that I could use instead.

[TheFes]

The lifetime sensor will still have all long term statistics data which you can use for these graphs

[hendrik001973]

Dear Martijn,

thanks for the hint, but as I wrote: I don't have a lifetime sensor. Can you give me advice how to activate it? The rain sensors I have are:

• rain rate (per houir)
• rain event
• rain hour
• rain day
• rain week
• rain month
• rain year ...but no rain lifetime total

Best Regards Hendrik

[zee36]

The lifetime sensor will still have all long term statistics data which you can use for these graphs

Yes, this is the catch, it seems like many of us just don't have a lifetime rain sensor available to the weather station (not in Home Assistant and not even in the Ecowitt native application).

[Onlinehead]

I can confirm this problem on my installation too. After the repair only last days visible, no long term history. Extracting it from the main rain piezo is annoying, because I am not sure Statistic Graph supports the same rolling windows as Statistic Card + they both are not easy to work with and internal stats of the station is (potentially) more precise.

[GarfieldMZ]

I used the customize option and no more notifications are shown

[Roman-Ber]

I have got the same repair message. This should not be an issue. Yes, you will loose the long term statistics for the mentioned sensors but you should have a sensor called total_rain. It was created by default (in my case).

This sensor still contains the long term statistics, even if you do the repair.

If you have broken statistic diagrams just repair them by replacing the sensor and change the stat type to "change"

Regards, Roman

[Onlinehead]

@Roman-Ber That is probably depends on the station model. I have a GW2000B and it has no total_rain sensor, only hourly, 24h, daily, weekly, monthly and yearly.

[zee36]

I used the customize option and no more notifications are shown

Great stuff, this makes the magic!

[vanrobi]

Unfortunately, this fix seems to be removed by (i guess) the integration after subsequent restarts.

[garry0garry]

[il77781]

@epenet, Hello! @BJReplay's arguments seem pretty convincing to me. Judging by the reaction (here and in another similar issues), it doesn't just seem that way to me only... I ask you to comment on these arguments. Yes, using state_class=SensorStateClass.TOTAL_INCREASING (as well as state_class=SensorStateClass.TOTAL) was incorrect, since the "accumulation" of data for the corresponding period (hour, day, etc.) is handled by the Ecowitt device itself... But it seems to me that it is also absolutely wrong to remove state_class completely, since this will completely lose the data presented in a convenient way in the graphs below. Many people do not have some kind of "common" sensor that accumulates data, and even if it is available, the graph for this sensor will not always have a convenient representation... Therefore, I think it is necessary to return state_class=measurement for all these sensors. What do you think about this?

[garry0garry]

@sxdjt Why is the ticket closed?

[vanrobi]

@sxdjt can you please reopen this ticket?

[I-am-Joel]

Forgive my ignorance, but isn't this a breaking change? I get that fixing and improving code and function is a permanent task, but this is the sort of change that appears to be negatively and irreversibly affecting a fair few users. I would have wanted the opportunity to review and understand this before updating HASS today.

[cousinhub57]

Same for me with gw3000a. 7 entities in correction error. Bad i was new owner and happy with integration in HA. Maybe it will be fixed.

[lancer73]

My station does not have a total_rain sensor (GW2000A)

[thowiegit]

"yearly" "monthly" "weekly", etc. are rolling windows. The state class was invalid - it has been removed.

You need to follow the repair process, and delete the long term statistics for these sensors.

That is no repair, it destroys data which we don't like to lose!

I used the customize option and no more notifications are shown

This is a repair. And it is the route which the Integration should have gone instead of removing the state_class, which we clearly don't like.

Forgive my ignorance, but isn't this a breaking change?

Yes, it clear is!

I get that fixing and improving code and function is a permanent task, but this is the sort of change that appears to be negatively and irreversibly affecting a fair few users. I would have wanted the opportunity to review and understand this before updating HASS today.

Fortunately, I never install an update without first checking what others are reporting, because I once had to work really hard to fix the consequences of a hasty update and therefore don't do that anymore.

And fortunately, there is:

homeassistant:
  customize:
    sensor.xxx:
      state_class: measurement

A simple way to mitigate this. However, I'd rather not know how many people will be caught off guard and how many will then be in a really bad mood afterwards -- and with good reason.