Strange type swapping in measurement

Hi, I’m new to influxdb and have a very strange behavior that I don’t understand, maybe someone can enlighten me:

I have a python script (see some code below) that reads multiple sensors and inserts it to influxdb in several measurements.

Problem I have is with the measurement “soilMoistureMapped”. First I had the code below without the explicit float cast.
The values of the sensor go from 0.0 to 10.0, so being a float with 1 decimal.

First everything worked as expected.
Then at some point this measurement stopped working with this error:

influxdb_client.rest.ApiException: (422)
Reason: Unprocessable Entity
HTTP response headers: HTTPHeaderDict({'Content-Type': 'application/json; charset=utf-8', 'X-Influxdb-Build': 'OSS', 'X-Influxdb-Version': 'v2.7.11', 'X-Platform-Error-Code': 'unprocessable entity', 'Date': 'Fri, 23 May 2025 20:21:48 GMT', 'Content-Length': '236'})
HTTP response body: {"code":"unprocessable entity","message":"failure writing points to database: partial write: field type conflict: input field \"capacitive\" on measurement \"soilMoistureMapped\" is type float, already exists as type integer dropped=1"}

So it says "you give me a float (which is correct), but I expect an int (which is nonsense since it alwas used to be float).

First I thought it’s because data is going through JSON, so I guessed that some X.0 value got interpreted as int and (somehow) changed the type of the whole measurement to int.
This was when I added the expicit float() cast to the python code you can see below.
And I deleted the measurement by:

influx delete --bucket growpi --start 2024-01-01T00:00:00+02:00 --stop 2026-01-01T00:00:00Z --predicate '_measurement="soilMoistureMapped"'

After that everything worked again (besides having lost some data).
But now the very same issue came up again, so it seems the missing type cast was not the issue.
Now I found another pattern in causing the error. It always comes up when I reboot the system that holds both, the influxdb and the python script for the sensor (which is a Raspberry Pi 5 , if that should matter).

However I have no idea how / why this is happening.
Anyone can help?

Btw. all the other readings, which are int or even also float (but with 2 decimals) and also come from the same JSON and python script work just fine.

I now issued the delete above again and for now it is working again and even losing data is fine for now, since it is still development / testing phase, but it will not be ok later on to be forced to lose all data on each reboot of the system.

It this point I start to wonder if it would be better to use a typesafe language like golang instead of python. Don’t know if this would make it any better, since the script seems to give float to the db, which actually is the expected behavior.

import influxdb_client

# ...

conf = getConfig()
client = influxdb_client.InfluxDBClient(
    url=conf["influxdb"]["url"],
    token=conf["influxdb"]["token"],
    org=conf["influxdb"]["org"],
)
write_api = client.write_api(write_options=influxdb_client.client.write_api.SYNCHRONOUS)

# ...

def processData(data):
    values = json.loads(data)

# ...

    write_api.write(
        bucket=bucket,
        org=conf["influxdb"]["org"],
        record=influxdb_client.Point("soilMoisture")
        .tag("sensor", "analog")
        .field("capacitive", int(values["capacitiveSoilHumidity"]))
        .field("current", int(values["currentSoilHumidity"])),
    )
    write_api.write(
        bucket=bucket,
        org=conf["influxdb"]["org"],
        record=influxdb_client.Point("soilMoistureMapped")
        .tag("sensor", "analog")
        # cast to foat to ensure field is ALWAYS float since json may suggest int
        .field("capacitive", float(values["capacitiveSoilHumidityMapped"]))
        .field("current", float(values["currentSoilHumidityMapped"])),
    )

# ...

EDIT: forgot to mention… I use influxdb 2 (2.7.11-1)

I came across something similar for a tool I developed… it turned out that local format settings were the problem. I had to modify my tool to be explicit about what formatting was used.

I have no idea if this is related to what you’re seeing, but it sparked a memory so I thought I’d post.

This is the thread describing the issue I had: CPU Temperature on Windows - #7 by Bedas

Thanks for the hint. But I don’t think this is the problem. Actually I’m from germany and “,” is used here as decimal delimiter. But everything in my sensor / script pipeline works strictly with “.” and besides right after reboot (when this one measurement type magically switches from float to int) everything actually works just fine.

Strange… are you sure that your database is persistent after reboot? I’m wondering if there’s something happening where a reboot clears the database, and then the first sensor measurement posted happens to be 0, for example. That could be interpreted as an integer, any any subsequent measurements posted with a decimal value would cause the error?

Just spitballing, sorry if this is off base!

Thought something similar too, but there is no other source of data then this script which is triggered by a cronjob every 5 minutes.
And it generates some more measurements in the same bucket as well.
And those measurements survived those 2 reboots and have consistent data since about 2 days now (when I setup the system).

Is there a way to delete the whole measurement (without deleting the whole bucket)?
As far as I understand with this statement I only delete all data inside the measurement:

influx delete --bucket growpi --start 2024-01-01T00:00:00+02:00 --stop 2026-01-01T00:00:00Z --predicate '_measurement="soilMoistureMapped"'

Yeah, that’s my understanding of how it works. This thread seems to cover the usage: Delete measurement in a bucket - #12 by scott

But as for the persistence: You are right as far as this sepcial measurement is concerned. Because I also have a grafana dashboard on all the data. And after reboot it also says “No data” for the visualizations of this measurement.
So it seems reboot not only changes the type of this measurement but also drops all data in it.
On the other hand I can’t insert new data unless I explicitly drop all the data in it.
All in all the whole behavior is just strange.

So other measurement populated by the same script ARE persistent, but this one measurement is not? That’s bizarre.

However, the fact that all of the data is gone on reboot (regardless of what the reason is) probably means that the data type is effectively gone as well, and it will be re-established by the first record entered. So, if that first record is sent without a decimal place, it would establish the data type as int. At least that’s my theory.

With that in mind, are you able to force decimal values? In other words, if the measurement is 10, have the value recorded be 10.0. If my theory is correct, then at least you shouldn’t see the data type changing. You’d still have to track down the persistence problem, though.

Give me some minutes until I have a few data points together again, I will test something.

Ok what I now did is: I changed the measurement name inside the script from “soilMoistureMapped” to “soilMoistureMapped2” (and also in the grafana dashboard).
Now everything works, it survived 2 reboots.
So whatever happened here, it seems that the measurement / “table” / data track itself is broken in the database.
This does not strengthen my confidence in the database, but I can live with it for now.

To be fair: The system is running on a raspberry pi, therefore on a sd card, so I guess it is some sd card block corruption issue.

Could be! For whatever my single experience is worth, Influx has been rock solid for me. I’ve got measurements going back over 6 years, and I’ve never seen problems like what you’re describing.

Right now the plan for the future is to use it on “real hardware” running home assistant after all … so I don’t really care for sd card issues on dev system too much.