Back to

📢 Migration issue

Dear all,

We have just conducted some days of data migration on our servers and we have encountered some issues in the process.

We are currently working on resolving the issue, but we wanted to let you know about the current situation and what to expect.

What’s the problem

We are migrating our server infrastructure from one datacenter to another. In the migration process, we have experienced an unexpected issue that made some data gaps in the time-series in the database. These gaps are not consistent and are of unknown origin to us. We believe it’s related with the database indexes, but the complexity of the issue doesn’t allow us to be certain of the root-cause.

What’s the situation

We have recovered all historic data from the beginning of the project until January 7th 2024. There is no gaps in the data there. We have reconnected everything, so data as of January 19th 2024 is back to normal.

Between January 7th 2024 and January 19th 2024 there is currently a gap of data that is not visible to anybody.

What’s the solution

We are currently taking the data between January 7th and January 19th 2024 from our backups to re-inject it. This will take some days, but we expect to recover the majority of it.

What to expect

All new data (January 19th onward) will be present, same as data previous to January 7th 2024.

We can’t be certain that we will recover all the data between January 7th and January 19th, although there are some particularities:

  • Data between January 12th and January 19th we believe will be fully recovered
  • Data between January 7th and January 12th will be partially recovered

We are sorry for any inconvenience and we hope to fix the issue as soon as we can.


Hello everybody!

Our recovery process has been concluded. Now you should be able to see most of the data back, according to:

  • Data between January 12th and January 19th we believe will be fully recovered
  • Data between January 7th and January 12th will be partially recovered

Please, let us know if you encounter any issues on a case to case basis and we will try to look at it.

Thank you! :heart:

Thanks for the update and for the efforts to restore the missing data. Appreciate the effort that has gone in to this. But I’m afraid I am still missing most of my data from 7th to 19th Jan, including 12th to 19th. Grateful if you were able to look into this.

I’ve got seven kits each with 11 sensors so producing 264 hourly summaries each day. Six were intalled before 7 Jan, and one sometime between 7 Jan and 19 Jan. Table below shows number of hourly summaries per kit from 6 Jan to 20 Jan. So most of the data appears to be there for two of the kits (BWD3/6) but four still missing throughout (BWD1/2/4/5) and BWD7 missing for at least part of the time.

Many thanks!


Hi @nick.bailey

Thanks for the report. Can you put the list of devices ids here? Or are they all under nick.bailey username?

Hi @oscgonfer
User id ‘NickB’. Device ids:



Just re-triggered the job for these devices and the checks seem fine on my side.

BTW, at least I see one device that seems to have 0ug/m3 on the pm_(x)?

That’s great - yes, readings look pretty complete now. ‘16978’ is the one that I added latest (on 16/01) and has some gaps on 20/01 that I know about - flat battery!) Should be able to work with what I have now so many thanks for the follow up.

And yes, with one device, the pm_x sensors don’t seem to be registering anything. (Another one is outside in a plastic bag so may have no/minimal readings there but that is fine.) At the moment, my main interest is temp and humidity so not a big issue but maybe more in future. Any simple fix for that?


That’s great!

As far as the PM sensor… it could be many things, but two things to check:

  • Physical clogging: the PM is clogged or something is blocking it
  • Configuration: if you have 0.9.8_PM version of the firmware, you can do:
SCK > control pm
PM 1.0: 
Available commands:
* powersave: [0-1] Sets powersave (turn off PMS after reading it)
* warmup [seconds] Changes warm up period for sensor
* debug [0-1] Sets debug messages

And turn off the one-shot/ powersave feature by:

control pm powersave 0

This will make the PM sensor continuously on, which will consume more power, but you can see if it’s a matter of low stability on the PM readings.

1 Like