Hi Bob, I probably didn’t explain myself clearly enough. When IoTaWatt is able to support PVoutput uploading of both PV generation and consumption I shall switch off the Raspberry Pi and SBFspot. I plan also to introduce additional CTs to make use of more IoTaWatt channels to obtain a better picture of my power consumption and I shall use Emoncms for that. I look forward to seeing PVoutput implemented in IoTaWatt in due course.
Emoncms has some good presentation apps, but you can get at all of the data and visualize using only your IoTaWatt.
Also, I intend to allow use of the six additional metrics in PVoutput when it’s in donator mode. So that’s another avenue to upload detailed usage.
C[quote=“bcosta, post:13, topic:377”]
My first version was a whole lot simpler until I tried to work around this bug.
The fact that I was losing 5 min of data at the end of each day was very surprising to me and I was also surprised that I couldn’t find anything about it online. I assumed for a while I was just doing something wrong. I was planning to post to PVOutput forums and ask, but didn’t get around to it.
So I’m moving along and the last piece is the status update functionality. I’m looking at the code with the 23:59:59 timestamp and the whole confusion around crossing midnight. Trying to get a grip on this issue I think I’ve got it figured out. The basic problem, I think, is what the timestamp means to IoTaWatt, and what it means to PVoutput:
When you query the IoTaWatt datalog for power used at some particular time, you get back the average power used, for the requested interval, up until that time. Similarly, if you ask for energy used at some particular time, you get back the energy used during the interval preceding that time.
If I post a 5 minute status to PVoutput for a particular time, the energy that it computes is for the interval that begins at that time. So assuming a 5 minute interval, when you give it a power figure for 00:00:00 - say 2076 Watts, it computes energy of 173 Wh (2076/12). That is the energy it will associate with the 00:00:00 status and it represents the energy that will be consumed between 00:00:00 and 00:05:00.
So IoTaWatt is measuring the preceding interval, PVoutput is recording the following interval. The set of 288 status records from 00:00:00 to 23:55:00 for a given date contain 288 energy values representing 1,440 minutes (except for DST transition).
Since IoTaWatt always reports average values for the period, it’s valid to allow PVoutput compute energy from that, as long as the data is normalized by shifting the IoTaWatt measurements by the interval so that they are both looking forward. I will do that and hopefully the messy 23:59:59 problem will disappear.
That sounds like the root of the problem and will probably solve the issue without the 23:59:59 complexity. I should have seen that.
It looks like you are making great progress. Thanks for working on this, it will be great to have official support for PVOutput.
I want to thank you for the wonderful point work you did on this. My MO is usually to jump in, write something, learn a ton about the problem, then start over. I like to code so I don’t mind 86ing the first attempt. Your code enabled me to start fresh and get it right without the do-over.
Plus-which I have written it as a class, which you demonstrated very nicely, and I think you will recognize a lot of other features that I carried through. The groundwork was adding more robust local-time capabilities to IoTaWatt, which you did not have.
I was impressed by the level of understanding that you had for the various logs, the subtle differences between the history and current logs. Your approach to skipping zero-time records demonstrates that.
The new class has a more utilitarian approach to doing the HTTP requests, necessitated by the use of more APIs. I made a separate class to parse responses from PVoutput. There is also support for donator mode. I hope to have this in ALPHA end of next week.
Testing has been difficult, because of the inherent limitations in the API interface and the inability to delete large amounts of data to retest. So there may be some straggler issues that will only come out in field trials.
Here’s a sample of live PVoutput. Just a few loose ends and add some useful comments. I don’t have PV (I have a lot of very tall pine trees instead), but I am confident that will work as it’s really no different than the consumption feed,
Looking forward to trying this out. Great work.