Costs - following on from #49

[nightcustard]

I've been using a modified version of v0.1.0 where I've added tariff costs to config.py and to the database as part of the CT data acquisition. The reason I've done it this way is mainly because I'm on a split tariff scheme where tariffs change during the day. I looked at continuous queries but I struggled to find a way to link them to time.

I'm fortunate that I've got a 240v feed which only becomes active during off-peak hours, so I power a dc PSU from this feed which is connected to GPIO17. My modified power_monitor.py code monitors that GPIO, using it to determine which tariff gets written into the database.

The current tariff data is written to each ct so I can display the cost of individual cts. This is rather profligate but it was much simpler to do it this way(!)

To display the data on Grafana I've created a number of continuous queries, such as:

CREATE CONTINUOUS QUERY "ct1_cost" ON "power_monitor" BEGIN SELECT last("tariff") * integral("power")/3600000 INTO "autogen"."ct1_cost" FROM "power_monitor"."autogen"."raw_cts" WHERE "ct" = '1' GROUP BY time(1m) END

I've ported over the changes to the v0.2.0 code (and anticipate doing the same for the v0.3.0 code) but it would of course be very handy if this functionality were to be available in the released code - is this something worth considering? I admit there probably aren't too many people with an ac feed which becomes live during off/peak periods, so a GPIO read capability is probably too much to ask for but I suppose if you don't ask......

Thoughts?

[David00]

I think solving the cost tracking feature is the biggest challenge - the GPIOs would be easy to do, especially with the new TOML config format in v0.3.0.

I'm not too familiar with the time of use energy rates (as I don't have one myself), but I'm thinking of a config setting to set up specific start/stop times for various energy rates... so in the config, something like:

[time_of_use]
enabled = true

[time_of_use.rate_period_1]
# Active from 7AM until 7PM
name = "On-Peak"
start = "07:00:00"  # HH:MM:SS, 24-hour time
end = "19:00:00"  # H:M:S, 24-hour time
rate = 0.13  # cost per kWh, in dollars/pounds/etc

[time_of_use.rate_period_2]
# Active from 7PM through 5AM next morning
name = "Off-Peak"
start = "19:00:00"  # HH:MM:SS, 24-hour time
end = "05:00:00"  # HH:MM:S, 24-hour time
rate = 0.06  # cost per kWh, in dollars/pounds/etc

[time_of_use.rate_period_n]
# You'd be able to create as many `rate_period` intervals as you want following the above format

The Python side would determine which rate_period the current sample period falls in, and calculate the cost using the rate within the rate_period, and then store that cost to a costs measurement, along with the name of the rate period that was used.

I think this would work for most people that have a fixed time interval time of use... but for your case, it sounds like the off peak just happens whenever it wants.... which brings us to the GPIO subject.

Your use case is very specific (and a good one, at that!!), and I'm trying to think of an approach that would ease the general use of the GPIO pins. In other words, I'd prefer to integrate something modular that can be expanded by the user rather than something super specific that only does one thing.

[nightcustard]

The above config looks spot on and would work for me, although one quirk is my on-peak/off-peak times are fixed to GMT (winter time in the UK) (ie) in the winter my off peak period is between 12:30am and 07:30am local time, so in the summer it's between 01:30 and 08:30am local time. That's primarily why I chose to use a GPIO flag to define which tariff is applicable - the other reason was I wasn't really sure what the peak/off-peak times are as the utility company seems strangely reluctant to publish them.

Looking to the future, I believe there have been proposals here to offer flexible tariffs which vary during the day depending upon demand. This may or may not happen and in any case there are too many unknowns to be able to do anything about that now.

[nightcustard]

Hi David

Although I haven't looked into the detail, having been introduced to the Influxdb client, it strikes me I could sort out the GPIO tariff detection external to the power_monitor code and insert the tariff status into the database via the client. From there I could use continuous queries to work out the costs. Just a thought; it would actually be very nice to have something like the capability you outlined above in the power_monitor code. Mike

[nightcustard]

Hi David - a quick update on the tariff issue.
I've upgraded to your v0.3.0 version and as I suggested above, instead of modifying the code I've written a simple python script to write the tariff data into the influxdb database. It seems to work very well, so hats off to you for pointing me in the direction of the influxdb_client!
Many thanks again - Mike
write_tariff.txt