I wonder if anyone has any experience trying to combine feeds in a virtual feed that dont have the same periodicity. I have feeds that I’ve manually created with the kWh cost and standing charges for my gas and electricity. Since there’s only been a handful of these changes over the last couple of years I use the PHPTIMESERIES format, which currently just has 5 entries for each of the four charge types. Now what I want to do is multiply the gas or electricity unit cost by the kWh consumed to arrive at a cost. The kWh figures are available periodically, every 10 or 60 seconds in a PHPFINA timeseries as usual. When the two are multiplied together in a virtual feed process list I expect the value from the last available cost to be used. That doesn’t seem to happen: the resulting feed is almost entirely NULL values as for each of the kWh datapoints there is no exact time match in the unit cost datapoints.
On a related note, in order to compute the standing charges I need the number of elapsed days to create a cumulative day counter which I could then multiply by the daily standing charge and delta over a day/week/month to get that cost. This seems like something that should be an available processor, but isn’t there.
These two requirements must be common to all domestic users. Has anyone found a neat workaround to solve them?
You could try adding another entry into your manual feed that is far into the future, with the same price as you’re paying now. Then, the virtual feed will be able extrapolate values for “today”.
Also note that you probably need two entries in your feed each time the price changes, so that there’s no interpolation between prices:
some timestamp = old price
new timestamp - 1 = old price
new timestamp = new price
future timestamp = new price
If you were to plot this feed, you should see a stepped line that is perfectly horizontal with jumps up or down whenever the price changes. This might then work with a virtual feed.
Alternatively, instead of a virtual feed, you could have the input process for kWh also multiply by the current value from charges feed, and accumulate that to another feed. I’ve not tested this, but I think it might work.
This assumes that the input is delta of kWh for each reading, and not already accumulated. It might help if you clarified exactly what the input is measuring; is it really energy (kWh) or is it actually power (watts). You may need to do some additional conversion.
One way is to have an external script that runs every day to upload 1 to EmonCMS, then use a standard input processor to multiply this by the current standing charge and add it to an accumulating feed. The same input could be used to do both gas and electric with an appropriate RESET in between.
Thanks for that, it might represent a way to get what I want, however it does seem that the basic EmonCMS system should cater for these requirements and so I cloned the repo and rolled up my sleeves….
A few days later I’ve introduced a couple of new Processes:
SourceCostFeed: this takes a regular PHPTimeSeries and goes behind the scenes to transform it into a cost feed - one where each calculated interval correctly shows the step function of the cost increases, as far into the future as necessary.
Source Feed Delta: this turns a regular feed into it’s deltas. It works like the delta option but can be done within a Virtual Feed as part of a cost calculation pipeline.
Cost Multiplier: similar to Source Cost Feed this does the same thing but operates on the values produced by an earlier process. Combining this into a Process list after a Source Feed Delta produces a Feed with the cost per interval appropriately calculated.
DailyCharges: this takes values produced by an earlier process and multiplies them by the number of days in the interval. Place this after a Source Cost Feed containing a timeseries with your standing charges and voilà you have the correctly calculated standing charges.
The above is available on GitHub at townsen/emoncms on branch calculate_costs. This currently contains a lot of debugging code that I used to work out what was going on, and, more importantly hasn’t been thoroughly checked for corner cases. It does however produce great results. See the picture which shows my electricity costs (and consumption) for the last two years.
We moved in to this house in March 2020 and the first winter we kept all the heating at the same levels as the previous owner. Our costs were high then so the following winter we turned things off and down. You can see that although we’re using less electricity, because of the four price increases we’ve had the costs have risen dramatically. Including the standing charge doubling!
I’m planning to kick the tyres a bit more on this, merge in the latest updates, and then create a pull request.
Yes, it can change as often as you like. The feed is a PHPTimeSeries feed so only stores the points at which the costs become effective. I load those (all four of them in the last 2 years) manually.
The solution I have is a little more flexible than the Agile App as you can keep a permanent feed of the changes and they are applied correctly historically whenever you need a report.
I’ve enjoyed hacking away but have to confess that a mysterious thing has happened to my gas_kWh accumulator over the past two days which has kept me head-scratching. At first I thought I may have done something inadvertently with my code changes, but I’ve now come to the conclusion that I haven’t, (though I may be mistaken). I revived an old post with a similar problem to see if anyone has any ideas. I’d appreciate any thoughts on that
