ToU by Flux Query (and why it is is a really, really bad idea).

[BuongiornoTexas]

Hi All,

Passing on that I have managed to build a ToU system using a flux query. The following screenshot is for our utility (Aurora in Tasmania). I'll share how to build it in following posts and provide a bit of detail on why it's a bad idea to use this approach. On the upside, I'm pretty sure I can do a variation on the approach that will do the job in more flexible way.

We have 2 x peak and 2 x off peak periods on weekdays, and the weekend is completely offpeak. You can switch usage type between $ and kWh using the drop down at the top of the plot. It all runs perfectly cheerfully (if somewhat slowly) and will happily deal with large time ranges - I've tested it on a 5 month range, and the output is in line with actual metering data from the utility (I think errors are from a combo of influxdb integration errors and tesla hackiness).

The rules I've applied for self consumption are:

• Self consumption gives me a savings equivalent to the cost of the buying the electricity from the grid at time of use.
• Consumption is taken to be the "home" power usage. I allocated supply to meet consumption in the following order:
  • Power imported from the grid.
  • Power supplied from the battery on any residual consumption after import.
  • Power supplied from solar on any residual consumption after import and battery.

Exported power is credited per the utility FiT.

I don't account for recorded solar or battery production, as this only has value as either export or household consumption.

More details to follow over the next few days.

[BuongiornoTexas]

Setup step 1: Add a new datasource for the query. Goto grafana settings and add a new "InfluxDB data source". This is in addition to the InfluxDB you will already have for Powerwall-Dashboard, and is required to get flux working. Note: There is also a Flux datasource available - it only works with an https server - which is not the Powerwall-Dashboard default, so I haven't tried this.

The changes I made to get things working were:

1. Give the data source a unique name (e.g. "Flux DS for ToU function").
2. Set the url to InfluxDB on your Powerwall-Dashboard system (the same as the other InfluxDB setup http://server.local:8086 or similar).
3. Specify and organisation name.
4. Set the Query Language to Flux.

Setup step 2: Add the new dashboard by importing the following json.

ToU Dashboard JSON

{
  "__inputs": [
    {
      "name": "DS_ORAC_INFLUX DB - FLUX QL",
      "label": "Orac influx db - Flux QL",
      "description": "",
      "type": "datasource",
      "pluginId": "influxdb",
      "pluginName": "InfluxDB"
    }
  ],
  "__elements": {},
  "__requires": [
    {
      "type": "panel",
      "id": "barchart",
      "name": "Bar chart",
      "version": ""
    },
    {
      "type": "grafana",
      "id": "grafana",
      "name": "Grafana",
      "version": "9.1.2"
    },
    {
      "type": "datasource",
      "id": "influxdb",
      "name": "InfluxDB",
      "version": "1.0.0"
    },
    {
      "type": "panel",
      "id": "stat",
      "name": "Stat",
      "version": ""
    }
  ],
  "annotations": {
    "list": [
      {
        "builtIn": 1,
        "datasource": {
          "type": "grafana",
          "uid": "-- Grafana --"
        },
        "enable": true,
        "hide": true,
        "iconColor": "rgba(0, 211, 255, 1)",
        "name": "Annotations & Alerts",
        "target": {
          "limit": 100,
          "matchAny": false,
          "tags": [],
          "type": "dashboard"
        },
        "type": "dashboard"
      }
    ]
  },
  "editable": true,
  "fiscalYearStartMonth": 0,
  "graphTooltip": 0,
  "id": null,
  "links": [],
  "liveNow": false,
  "panels": [
    {
      "datasource": {
        "type": "influxdb",
        "uid": "${DS_ORAC_INFLUX DB - FLUX QL}"
      },
      "fieldConfig": {
        "defaults": {
          "color": {
            "mode": "palette-classic"
          },
          "custom": {
            "axisCenteredZero": false,
            "axisColorMode": "text",
            "axisLabel": "",
            "axisPlacement": "auto",
            "fillOpacity": 80,
            "gradientMode": "none",
            "hideFrom": {
              "legend": false,
              "tooltip": false,
              "viz": false
            },
            "lineWidth": 1,
            "scaleDistribution": {
              "type": "linear"
            }
          },
          "mappings": [],
          "thresholds": {
            "mode": "absolute",
            "steps": [
              {
                "color": "green",
                "value": null
              }
            ]
          },
          "unit": "none"
        },
        "overrides": []
      },
      "gridPos": {
        "h": 10,
        "w": 23,
        "x": 0,
        "y": 0
      },
      "id": 2,
      "options": {
        "barRadius": 0,
        "barWidth": 0.97,
        "groupWidth": 0.7,
        "legend": {
          "calcs": [],
          "displayMode": "list",
          "placement": "bottom",
          "showLegend": true
        },
        "orientation": "auto",
        "showValue": "auto",
        "stacking": "normal",
        "tooltip": {
          "mode": "multi",
          "sort": "none"
        },
        "xField": "_time",
        "xTickLabelRotation": 0,
        "xTickLabelSpacing": 100
      },
      "targets": [
        {
          "datasource": {
            "type": "influxdb",
            "uid": "${DS_ORAC_INFLUX DB - FLUX QL}"
          },
          "hide": false,
          "query": "import \"date\"\r\nimport \"math\"\r\n\r\nshowenergy = if \"${usagetype}\" == \"$\" then false else true\r\n\r\n// Flux doesnt support timezones for influxdb 1.8. \r\n// Hobart DST is UTC+11\r\nUTC_offset = 11\r\n\r\n//localhour = (t) => {\r\n//}\r\n\r\n// be nice to do costs with a dict, but not available in InfluxDB 1.8?\r\nidx_import = 0\r\nidx_saving = 1\r\nidx_export = 2\r\ncosts_energy = [-1.0, 1.0, 1.0]\r\ncosts_peak = [-0.33399, 0.33399, 0.08883]\r\ncosts_offpeak = [-0.15551, 0.15551, 0.08883]\r\n\r\nsupply_charge = if showenergy then\r\n  0.0\r\nelse\r\n  1.09903 / 24.0\r\n\r\nchargerate = (pp, idx) => {\r\n  return if showenergy then\r\n    costs_energy[idx]\r\n  else if (pp==\"peak\") then\r\n     costs_peak[idx]\r\n  else \r\n    // cheating a little as my w/e is the same as weekday off peak\r\n    costs_offpeak[idx]\r\n}\r\n\r\naddperiod = (r) => {\r\n  // flux for influxdb 1.8 does not support timezones. \r\n  // (in fact, does no support most date math functions)\r\n  // so we have to play silly buggers with manual time correction.\r\n  // add an extra 24h so modulo always returns postive remainder!\r\n  ltz_hour = (24 + date.hour(t: r._time) + UTC_offset) % 24\r\n  // this next bit only works for a positve UTC offset.\r\n  ltz_weekday = if ltz_hour < UTC_offset then\r\n     // add an extra 7d so modulo always returns postive remainder!\r\n     (7 + date.weekDay(t: r._time) + 1) % 7\r\n  else\r\n     date.weekDay(t: r._time)\r\n  return {\r\n    r with\r\n      //ltz_hour: ltz_hour,\r\n      //ltz_weekday: ltz_weekday,\r\n      period: if (ltz_weekday == 0) or \r\n        (ltz_weekday == 6) then \r\n          \"weekend\"\r\n      else if ((ltz_hour >= 8) and (ltz_hour < 11))\r\n        or ((ltz_hour >= 17) and (ltz_hour < 22)) then\r\n          \"peak\"\r\n      else\r\n        \"offpeak\",\r\n  }\r\n}\r\n\r\naddrates = (r) => {\r\n  self_bat = math.mMax(x: 0.0, \r\n      y: math.mMin(x: r.home - r.from_grid, y: r.from_pw))\r\n      * chargerate(pp: r.period, idx: idx_saving)\r\n  self_solar = math.mMax(x: 0.0, \r\n      y: math.mMin(x: r.home - r.from_grid - r.from_pw, y: r.solar))\r\n      * chargerate(pp: r.period, idx: idx_saving)\r\n  return {r with\r\n    \"self battery\": self_bat,\r\n    \"self solar\": self_solar,\r\n    \"self total\": self_bat + self_solar,\r\n    // just set to 0 for show_energy case\r\n    \"supply charge\": supply_charge\r\n  }\r\n}\r\n\r\ndata = from(bucket: \"powerwall/kwh\")\r\n  |> range(start: v.timeRangeStart, stop: v.timeRangeStop)\r\n  |> filter(fn: (r) => r._measurement == \"http\")\r\n  // create new usage variables\r\n  |> pivot(rowKey: [\"_time\"], columnKey: [\"_field\"], valueColumn: \"_value\")\r\n  // use dedicated function as far as possible. \r\n  // add periods before doing next round, as following ops cant be completed until it is\r\n  // is in place.\r\n  |> map(fn: (r) => addperiod(r: r))\r\n  |> group(columns: [\"period\"])\r\n  // add calculated rates\r\n  |> map(fn: (r) => (addrates(r: r)))  \r\n  // deal with flux spack attack on modifying field in raw table \r\n  // doesnt work in function. Works here. I hate this language.\r\n  |> map(fn: (r) => ({r with \r\n    from_grid: r.from_grid * chargerate(pp: r.period, idx: idx_import),\r\n    to_grid: r.to_grid * chargerate(pp: r.period, idx: idx_export),\r\n  })) \r\n  |> drop(columns: [\"_start\", \"_stop\", \"month\", \"year\", \"solar\", \"home\", \"to_pw\", \"from_pw\"])\r\n  |> rename(columns: {to_grid: \"grid export\", from_grid: \"grid import\"})\r\n  |> yield()\r\n  \r\n",
          "refId": "B"
        }
      ],
      "title": "Usage Data - ${usagetype}",
      "type": "barchart"
    },
    {
      "datasource": {
        "type": "datasource",
        "uid": "-- Dashboard --"
      },
      "fieldConfig": {
        "defaults": {
          "color": {
            "mode": "thresholds"
          },
          "mappings": [],
          "thresholds": {
            "mode": "absolute",
            "steps": [
              {
                "color": "green",
                "value": null
              }
            ]
          },
          "unit": "none"
        },
        "overrides": []
      },
      "gridPos": {
        "h": 8,
        "w": 11,
        "x": 0,
        "y": 10
      },
      "id": 4,
      "options": {
        "colorMode": "value",
        "graphMode": "area",
        "justifyMode": "auto",
        "orientation": "auto",
        "reduceOptions": {
          "calcs": [
            "lastNotNull"
          ],
          "fields": "",
          "values": false
        },
        "textMode": "auto"
      },
      "pluginVersion": "9.1.2",
      "targets": [
        {
          "datasource": {
            "type": "datasource",
            "uid": "-- Dashboard --"
          },
          "panelId": 2,
          "refId": "A"
        }
      ],
      "title": "Summary - ${usagetype}",
      "transformations": [
        {
          "id": "seriesToColumns",
          "options": {
            "byField": "_time"
          }
        },
        {
          "id": "organize",
          "options": {
            "excludeByName": {},
            "indexByName": {
              "_measurement offpeak": 1,
              "_measurement peak": 8,
              "_measurement weekend": 15,
              "_time": 0,
              "grid export offpeak": 3,
              "grid export peak": 10,
              "grid export weekend": 17,
              "grid import offpeak": 2,
              "grid import peak": 9,
              "grid import weekend": 16,
              "self battery offpeak": 4,
              "self battery peak": 11,
              "self battery weekend": 19,
              "self solar offpeak": 5,
              "self solar peak": 12,
              "self solar weekend": 18,
              "self total offpeak": 6,
              "self total peak": 13,
              "self total weekend": 20,
              "supply charge offpeak": 7,
              "supply charge peak": 14,
              "supply charge weekend": 21
            },
            "renameByName": {}
          }
        },
        {
          "id": "reduce",
          "options": {
            "includeTimeField": false,
            "mode": "reduceFields",
            "reducers": [
              "sum"
            ]
          }
        }
      ],
      "type": "stat"
    },
    {
      "datasource": {
        "type": "datasource",
        "uid": "-- Dashboard --"
      },
      "fieldConfig": {
        "defaults": {
          "color": {
            "mode": "thresholds"
          },
          "mappings": [],
          "thresholds": {
            "mode": "absolute",
            "steps": [
              {
                "color": "green",
                "value": null
              }
            ]
          }
        },
        "overrides": []
      },
      "gridPos": {
        "h": 4,
        "w": 11,
        "x": 0,
        "y": 18
      },
      "id": 6,
      "options": {
        "colorMode": "value",
        "graphMode": "area",
        "justifyMode": "auto",
        "orientation": "auto",
        "reduceOptions": {
          "calcs": [
            "lastNotNull"
          ],
          "fields": "",
          "values": false
        },
        "textMode": "auto"
      },
      "pluginVersion": "9.1.2",
      "targets": [
        {
          "datasource": {
            "type": "datasource",
            "uid": "-- Dashboard --"
          },
          "panelId": 2,
          "refId": "A"
        }
      ],
      "title": "Sub-totals - ${usagetype}",
      "transformations": [
        {
          "id": "merge",
          "options": {}
        },
        {
          "id": "reduce",
          "options": {
            "includeTimeField": false,
            "mode": "reduceFields",
            "reducers": [
              "sum"
            ]
          }
        },
        {
          "id": "organize",
          "options": {
            "excludeByName": {},
            "indexByName": {
              "_measurement": 0,
              "grid export": 2,
              "grid import": 1,
              "self battery": 3,
              "self solar": 4,
              "self total": 5,
              "supply charge": 6
            },
            "renameByName": {}
          }
        }
      ],
      "type": "stat"
    }
  ],
  "refresh": false,
  "schemaVersion": 37,
  "style": "dark",
  "tags": [],
  "templating": {
    "list": [
      {
        "current": {
          "selected": true,
          "text": "kWh",
          "value": "kWh"
        },
        "description": "if $, returns costs including supply charge, if kWh returns energy values",
        "hide": 0,
        "includeAll": false,
        "label": "Usage type",
        "multi": false,
        "name": "usagetype",
        "options": [
          {
            "selected": true,
            "text": "kWh",
            "value": "kWh"
          },
          {
            "selected": false,
            "text": "$",
            "value": "$"
          }
        ],
        "query": "kWh, $",
        "queryValue": "",
        "skipUrlSync": false,
        "type": "custom"
      }
    ]
  },
  "time": {
    "from": "now-7d",
    "to": "now"
  },
  "timepicker": {},
  "timezone": "",
  "title": "ToU demonstrator",
  "uid": "n6LN9pf4dsfgfk",
  "version": 3,
  "weekStart": ""
}

The heavy lifting is done by the Flux query supporting the first plot. Next post for an outline of the key elements and stuff that needs changing to localise for different utilities and timezones.

[BuongiornoTexas]

Flux query

import "date"
import "math"

showenergy = if "${usagetype}" == "$" then false else true

// Flux doesnt support timezones for influxdb 1.8. 
// Hobart DST is UTC+11
UTC_offset = 11

//localhour = (t) => {
//}

// be nice to do costs with a dict, but not available in InfluxDB 1.8?
idx_import = 0
idx_saving = 1
idx_export = 2
costs_energy = [-1.0, 1.0, 1.0]
costs_peak = [-0.33399, 0.33399, 0.08883]
costs_offpeak = [-0.15551, 0.15551, 0.08883]

supply_charge = if showenergy then
  0.0
else
  1.09903 / 24.0

chargerate = (pp, idx) => {
  return if showenergy then
    costs_energy[idx]
  else if (pp=="peak") then
     costs_peak[idx]
  else 
    // cheating a little as my w/e is the same as weekday off peak
    costs_offpeak[idx]
}

addperiod = (r) => {
  // flux for influxdb 1.8 does not support timezones. 
  // (in fact, does no support most date math functions)
  // so we have to play silly buggers with manual time correction.
  // add an extra 24h so modulo always returns postive remainder!
  ltz_hour = (24 + date.hour(t: r._time) + UTC_offset) % 24
  // this next bit only works for a positve UTC offset.
  ltz_weekday = if ltz_hour < UTC_offset then
     // add an extra 7d so modulo always returns postive remainder!
     (7 + date.weekDay(t: r._time) + 1) % 7
  else
     date.weekDay(t: r._time)
  return {
    r with
      //ltz_hour: ltz_hour,
      //ltz_weekday: ltz_weekday,
      period: if (ltz_weekday == 0) or 
        (ltz_weekday == 6) then 
          "weekend"
      else if ((ltz_hour >= 8) and (ltz_hour < 11))
        or ((ltz_hour >= 17) and (ltz_hour < 22)) then
          "peak"
      else
        "offpeak",
  }
}

addrates = (r) => {
  self_bat = math.mMax(x: 0.0, 
      y: math.mMin(x: r.home - r.from_grid, y: r.from_pw))
      * chargerate(pp: r.period, idx: idx_saving)
  self_solar = math.mMax(x: 0.0, 
      y: math.mMin(x: r.home - r.from_grid - r.from_pw, y: r.solar))
      * chargerate(pp: r.period, idx: idx_saving)
  return {r with
    "self battery": self_bat,
    "self solar": self_solar,
    "self total": self_bat + self_solar,
    // just set to 0 for show_energy case
    "supply charge": supply_charge
  }
}

data = from(bucket: "powerwall/kwh")
  |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
  |> filter(fn: (r) => r._measurement == "http")
  // create new usage variables
  |> pivot(rowKey: ["_time"], columnKey: ["_field"], valueColumn: "_value")
  // use dedicated function as far as possible. 
  // add periods before doing next round, as following ops cant be completed until it is
  // is in place.
  |> map(fn: (r) => addperiod(r: r))
  |> group(columns: ["period"])
  // add calculated rates
  |> map(fn: (r) => (addrates(r: r)))  
  // deal with flux spack attack on modifying field in raw table 
  // doesnt work in function. Works here. I hate this language.
  |> map(fn: (r) => ({r with 
    from_grid: r.from_grid * chargerate(pp: r.period, idx: idx_import),
    to_grid: r.to_grid * chargerate(pp: r.period, idx: idx_export),
  })) 
  |> drop(columns: ["_start", "_stop", "month", "year", "solar", "home", "to_pw", "from_pw"])
  |> rename(columns: {to_grid: "grid export", from_grid: "grid import"})
  |> yield()

Dumping this for now - more detail later today or tomorrow after I've had some downtime.

[BuongiornoTexas]

OK last round going through the query and the problems with doing it this way.

TLDR: Flux is hard to use for moderately complicated queries and not at all flexible for parameterising and/or implementing alternative code paths (a problem given how many different tariff types there are). It is also hideously incomplete and internally inconsistent for InfluxDB 1.8, and agonising to debug. Some of these limitations will go with a transition to a newer version of InfluxDB, but not all.

So while this post demonstrates it is possible to build a ToU system in flux, each tariff type would need a custom implementation, and even then it will probably need a fair bit of manual intervention to keep up with changes in rates and seasons.

I've started work on an alternative approach using a python agent that will implement the same functionality, but in way that allows implementation of flexible tariff families and simple(-ish) configuration from a JSON file.

However, it will take a bit of time to pull the new agent together. So, if you want to build up your own flux ToU in the meantime, the elements of the query are as follows (I'm happy to help/provide pointers):

The main data filter starts from the line: data = from(bucket: "powerwall/kwh")", which,

• Pulls hourly kWh data from influx.
• Creates a period tag and allocates each record to a ToU period.
• Creates self consumption values.
• Applies costs if needed.

This filter works pretty well and is easy to understand.

The rest of the file provides implementation elements. Working through these from the top:

• The block starting with idx_import = 0 up to and including the function charge_rate = (pp, idx) => ... implements the tariff cost data and the usage cost implementation. This works but is ugly. It could be made better with dictionaries in more recent flux versions, but updating the data will still be painful (might be possible through the python api?). You will need to modify both the data and the lookup conditional to reflect your tariff.

• The addperiod = (r) => ... function works out which ToU period each record falls into. Setting up for your own tariff requires adjusting the condtional logic (which could get messy with a more complex set of tariffs). Unfortunately, Flux for InfluxDB 1.8 also has no time zone awareness, so there are local variables in this routine for local time zone weekday and hour calculation. To use this, you need to modify the UTC offset at the start of the file. You may also need to tweak the UTC offset and the logic on a regular basis if your ToU changes with seasons. And finally, the ltz_weekday calculation does not work for negative UTC offsets (I ran out of energy, and I live in a positive UTC zone ...) - so you will need to sort this if you live in one of these zones.

• addrates = (r) ... implements the self consumption elements (and was definitely the easiest part to implement).

[ThePnuts]

Hi @BuongiornoTexas I also started working on this in a similar but different fashion, however, I am purely on Influx2+ and this I am completely Flux and not influxQL at all. On the flip side, I am quite literally learning all of this as I go...

I am no where near where you are at, but ill share what I have so far. I also want to deep dive your code as I am going to learn a lot from it. I already didn't know I could do functions and such like you are or that I could assign multiple values to a variable like I see you are doing. Its going to take me a little bit to fully understand everything you are doing and then mess with it enough to work on my end due to slight differences from the default setup.

My current plan is between converting the variables at the top to global variables on the dashboard or creating a separate table (in influx) with the information that I can just reference since the values will change year over year and I would like to calculate total values so I can identify actual break even and such over time.

I'm also curious how you did the clickable expand down so its easier to read your replies without the code just being there

import "date"
import "timezone"

option location = timezone.location(name: "America/Los_Angeles")

peakcost = 0.39
offpeakcost = 0.37
seasonalpeakcost = 0.43
seasonaloffpeakcost = 0.49
//24hour
peakstart = 16
peakend = 21
//month
seasonalstart = 6
seasonalend = 10

data = from(bucket: "tesla_energy")
  |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
  |> filter(fn: (r) => r["_measurement"] == "kwh")
  |> filter(fn: (r) => r["_field"] == "grid" or r["_field"] == "powerwall" or r["_field"] == "solar" or r["_field"] == "home")
  |> map(fn: (r) => ({r with season: if date.month(t: r._time) >= seasonalstart or date.month(t: r._time) < seasonalend then 0 else 1}))
  |> map(fn: (r) => ({r with peak: if date.hour(t: r._time) >= peakstart and date.hour(t: r._time) < peakend then 1 else 0}))
  |> map(fn: (r) => ({r with
          cost: if r.season == 1 and r.peak == 1 then r._value * seasonalpeakcost
          else if r.season == 1 and r.peak == 0 then  r._value * seasonaloffpeakcost
          else if r.season == 0 and r.peak == 1 then r._value * peakcost
          else r._value * offpeakcost
      }))

  |> drop(columns: ["_measurement","_start", "_stop"])
  |> yield(name: "data")

and view directly from influx2+

[BuongiornoTexas]

Hi @ThePnuts - What you are doing makes sense for what looks like a ToU with two seasons and a single peak and offpeak period per day. And flux is much better suited for it than InfluxQL! I can also see how you could use dashboard variables to set up and evaluate performance on a year by year basis.

Unfortunately, this kind of breaks down in my local context - and my tariff is pretty simple compared to some:

• Our seasons change with daylight saving. Which is the first Sunday of April and October.
• We have a daily peak/offpeak/offpeak/peak/offpeak cycle, with different time ranges in summer and winter.
• Our tariffs change annually in mid winter.

Like you, I would also like to be able to run historical data and also evaluate tariff alternatives - which gets real messy real fast for my tariff and is much worse for people with shoulder and super tariffs. So the python approach will be to setup a calendar of tariffs, pull the data, process through the calendar and return to grafana.

Answering your question about hiding elements, use the slash commands beta drop down on the top left of the edit box:

Specifically this one!

[BuongiornoTexas]

Also - the approach I'm planning should work with any version of influxdb >= 1.8

[ThePnuts]

Oh wow, that is a pretty intensive ToU plan your utility uses.

Everything you mentioned about setting up a calendar and pulling it is well out of anything I know, so I look forward to seeing how the end result.

Thank you for the tip for how to collapse things, that will be super helpful going foward.

Secrets

O.o

[youzer-name]

@BuongiornoTexas said:

// doesnt work in function. Works here. I hate this language.

I've picked up multiple programming languages without any formal training, at least to the point where I can muddle through modifying some existing code to make it do something else, but Flux has me FLUmmoXed! I just don't have any desire to try to figure it out. It's like SQL, javascript, PHP, and Python are Italian, Spanish, Portuguese and French, and you can use the basic word roots and grammar to speak a few words in each, but Flux is a minor dialect spoken on the third moon of the yet-undiscovered Planet X by a race of silicon-based insects that make sounds by rubbing their wings together 😄

[BuongiornoTexas]

It took me a couple of days to get to grips with thinking in it - and I could see how it could be good.

But: Even the most current version is still a pretty inflexible beta (and the version in InfluxDB 1.8 is very not current), the syntax is opaque and the documentation is woeful. It took me several days of trial and error to work out when a function should be enclosed in () or enclosed in {} or be a nested ({}) or nested {{}}. Even now, trial suck it and see is often easiest.

And the chrongraf REPL is a disaster. Errors in code can give a completely unrelated error 50 lines down the stack.

I don't know how much of this is just working with 1.8, but the even the latest version still looks pretty painful for transforms as simple as we are doing with ToU.

On the upside, for basic data extraction, it is so much cleaner than InfluxQL!