CODEWITHSUNDEEP
influxdbinfluxdb-2
sineverba
sineverba

Reputation: 5172

InfluxDB v2.1 - Task executed but nothing wrote in destination bucket

I'm working with InfluxDB v2.1.

I have this task:

option task = {
   name: "DOWNSAMPLE APRILIA UTILITIES",
   cron: "0 * * * *",
}

from(bucket: "homeassistant-aprilia")
   |> range(start: -2h, stop: -1h)
   |> filter(fn: (r) => r["_measurement"] == "kWh")
   |> filter(fn: (r) => r["_field"] == "value")
   |> filter(fn: (r) => r.entity_id == "shellyem_c45bbe5fed52_channel_1_energy")
   |> aggregateWindow(every: 1h, fn: max, createEmpty: false)
   |> difference()
   |> to(bucket: "downsample-utility-aprilia", org: "sineverba")

it being executed every hour but... it doesn't write anything in the destination bucket.

I have all success logs but nothing in my destination bucket.

If I launch the task directly in source bucket, I can see the value of my interest.

Other, if I don't omit the "to" value, manually launched from bucket it writes the data.

Why?

Upvotes: 1

Views: 1060

Answers (2)

sineverba
sineverba

Reputation: 5172

At the end, I solved with stop at now:

option task = {
    name: "DOWNSAMPLE APRILIA UTILITIES",
    cron: "0 * * * *",
}

option entity_id = "shellyem_c45bbe5fed52_channel_1_energy"

data = from(bucket: "homeassistant-aprilia")
    |> range(start: -2h, stop: now())
    |> filter(fn: (r) => r["_measurement"] == "kWh")
    |> filter(fn: (r) => r["_field"] == "value")
    |> filter(fn: (r) => r.entity_id == entity_id)
    |> aggregateWindow(every: 1h, fn: last, createEmpty: false)
    |> difference()
    |> to(bucket: "downsample-utilities-aprilia", org: "sineverba")

Upvotes: 1

PovilasZ
PovilasZ

Reputation: 301

Sometimes InfluxDB fails to write but doesn't respond with an error. In those cases, success status doesn't mean that the data was written. It means that data was accepted for writing but it might fail later. Try checking the _monitoring bucket. That bucket stores rejected data points with the error message.

For example, in my case, it was a schema mismatch. One type was expected but another was received. I was using implicit schema which means that schema was decided by the InfluxDB itself based on the data I put there. I resolved this by making schema explicit. In this case, InfluxDB returns an error right away at the moment of writing.

Upvotes: 1

Related Questions