# Help! Problem with aggregation?

**URL:** <https://community.gladysassistant.com/t/help-probleme-avec-lagregation/6630>\
**Category:** Configuration\
**Created:** [October 25, 2021, 5:54pm UTC](https://community.gladysassistant.com/t/help-probleme-avec-lagregation/6630 "2021-10-25T17:54:08Z")\
**Posts on this page:** 1\
**Showing post:** 39

<div class="post-metadata">

**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\
**Post date:** [December 3, 2021, 10:00am UTC](https://community.gladysassistant.com/t/help-probleme-avec-lagregation/6630/39 "2021-12-03T10:00:03Z")

</div>

@lmilcent I just looked at the database you sent me, and I’m very surprised by its content 😃

You have device\_feature\_state values that are «&nbsp;NaN&nbsp;» (Not a Number). It’s very strange that this was inserted, given that the field is a «&nbsp;double precision&nbsp;», and «&nbsp;NaN&nbsp;» is not a double precision…

Of course, this crashes the aggregation that expects numerical values, not a string.

 ![Screenshot 2021-12-03 at 10.46.21](https://gladys-assistant-community.b-cdn.net/uploads/default/original/2X/3/384dd467c3b8a2faafe7c94f0325f55ae32e8c0f.jpeg)

After investigation, these values come from the Zigbee2mqtt integration.

I created a GitHub issue to fix the problem:

- Add a DB migration to clean up these lines that shouldn’t be there
- See why the validation and the DB accepted these values that are not Numbers.

> <https://github.com/GladysAssistant/Gladys/issues/1392>
>
> \- \[\] In Zigbee2mqtt integration, fix what could cause that
> \- \[\] In Gladys Cor…e, it shouldn't be possible to accept NaN values
> \- \[\] Clean existing NaN values in a DB migration
> 
> https://community.gladysassistant.com/t/help-probleme-avec-lagregation/6630/39?u=pierre-gilles

In the meantime, @lmilcent and @Albenss, the SQL query to fix your DBs is:

```sql
DELETE FROM t_device_feature_state WHERE value = 'NaN';

```

@lmilcent More generally, I don’t know if you keep all your historical sensor data (you keep them all), but I would advise you to clean up some very verbose deviceFeatures, because currently to perform the aggregation on my Mac, some sensors contained so many values that it took more than 1.5 Gb of RAM to perform the total aggregation (since it’s a first aggregation, it starts from the beginning. This will not be the case later)

Otherwise, by removing the NaN, it works very well for me on your DB:

 ![Screenshot 2021-12-03 at 10.57.17](https://gladys-assistant-community.b-cdn.net/uploads/default/original/2X/3/369b717e4d0d127814b9814b3450ba0b1ad0a871.jpeg)

---

_[View the full topic](https://community.gladysassistant.com/t/help-probleme-avec-lagregation/6630)._