Hey,
I’m trying to figure out how to do cost calculations correct using an input with dynamic pricing.
I have the pricing input in place and working:
All you really need to do it multiply the power input with your cost input and log that to a new “cost” feed, there maybe some scaling involved to accommodate watts vs kw’s etc.
It would be difficult to tell you how this might fit in with your existing processing without seeing that processing, but if it cannot be “slotted in”, then all you need to do is add
reset to zero
add power input (watts I assume?)
x 0.001 (to convert to kw)
x input “cost” (in cents?)
log to feed “running cost” (in cents per hour)
x 0.1 (required to adjust the scaling of the next process from W->kW to do cents->euros)
power to kwh “total cost” (running total in euros)
to (each of ?) the power input’s processing list(s) in question.
I hope I’ve got the scaling right, doing it off the top of my head so not tested. Hopefully it at least points you in the right direction.
I really don’t have much at this point, 2-nd day in 
Currently only this:
Mmmmmh! Ok, I’ve never looked that closely at the openEVSE stuff. The only value that is useful for what you want is the “wh” as there is no “power” (or so it appears, I don’t know for sure). I also do not know off-hand if that rolling “wh” total value can reset or rollover at source, the whacc (Wh accumulator) process in emoncms is designed to accommodate rollover or resets BUT that process only passes on a running total Wh to the next process and if you multiply that by your cost price what you end up with is a total cost of energy used had the unit price always been set at the latest price since the start because it would be multiplying the all time use with the current price.
I’m not sure what that “1:Current_energy_usage” input is exactly but if it is in fact as the name suggests “energy” as opposed to “power” then the same (below) applies, but for now I will assume you want “cost of ev charging”
It is notoriously difficult and inaccurate to reverse calculate power from energy in emoncms, therefore the same can be said for trying to calculate cost per hour.
The lack of “power” value from the source and the default use of the “whacc” in emoncms makes things somewhat tricky but not impossible to do what you want. I’m surprised this isn’t accommodated better in a energy focused software.
What I think you will need to do is use the pulse_count_to_total_increment process instead of the whacc process. The pulse_count_to_total_increment process works slightly differently and calculates the increase in counts at each update (usually pulses but can work just as well for Wh’s), with that info you can then both add that count to a generic accumulator (to equal the original whacc process) and also use that “count” to multiply by your current cost and save to another generic accumulator for a rolling total cost. You will have to forego the cost per hour (as with the “power”) feeds due to the issues with calculating power from energy.
So input openevse:wh might look something like this.
pulse_count_to_total_increment
log to feed “evse_energy” (energy used this reporting period in Wh)
x 0.001 (to convert to kW)
Accumulator “evse_kwh” (rolling total kWh)
reset to zero
I have just noticed that there is a estimated power derived from multiplying the “amps” by 230, this doesn’t take any voltage fluctuations or regional variations (or if you have PV, my grid voltage with PV pumping in is around 250VAC that’s almost a 9% difference) into consideration (nor PF if that’s a factor with ev charging), so you could go the easy route and use that (with my original example), but IMO that would be just as inaccurate as calculating realtime power values from energy consumed.
The only way to learn and decide for yourself is to experiment and hopefully understand what’s what
FYI, the way emoncms input processing works (if you aren’t yet aware) is that each time an input is updated via a http api call or mqtt, that inputs process list is triggered and each process is executed in turn. Therefore any pricing sums must go in the input that measures the usage so that the usage is calculated using the current cost at that time, if you were to put the calc’s in the current cost input processing then it would only get called when the current price value gets updated.
