PVOutput stuck on invalid date

So I got my 2nd IotaWatt for my PV setup. My PV is fed just after the meter and breaker on the front of the house so I needed a 2nd IotaWatt to capture this info, also my first IotaWatt is used up (no empty CT inputs).

Anyway, I am getting PVOutput setup and I guess I selected to far in the past (prior to the unit power on and setup) and now my PVOutput is stuck. A picture being worth a 1000 words.
image

Also, here is the message log.
2/25/21 17:38:46 Updater: Auto-update is current for class MINOR.
2/25/21 18:30:44 EmonService: started. url=HTTP://192.168.1.24/emoncms, node=IotaWatt_Solar, interval=5
2/25/21 18:30:46 EmonService: Node doesn’t yet exist.
2/25/21 18:30:46 EmonService: Start posting at 02/25/21 18:30:50
3/10/21 08:07:40 PVoutput: started
3/10/21 08:07:40 PVoutput: System Jeremy Hill Power, interval 5, freeload mode
3/10/21 08:07:41 PVoutput: Start status beginning 03/03/21 00:05:00
3/10/21 08:07:43 PVoutput: Unrecognized HTTP completion, upload Bad request 400: Invalid data format [20

Is there any way to edit the config and force it to reset? I tried deleting the PVOutput and setting it back up, but it went right back to that and the log seem to indicate it’s stuck.

Could you post your PVoutput setup and your PVoutput site name so I can see what has been uploaded?

No problem. I have two and both are set to upload.
IotaWatt Solar

IotaWatt House

Here’s a link to the site
https://pvoutput.org/list.jsp?id=93479&sid=82557

So far the house is uploading, I have it reloading historical right now, so maybe that is the cause?

There are a couple of issues here.

You are updating live data from two different sources. I know PVoutput does this with inverters updating separately from consumption meters, but IoTaWatt support was designed and tested to upload everything from one device, in one transaction. I’ll need to revisit their documentation to understand if there is a problem with it.

Second, there is an hourly transaction limit imposed by PVoutput, and you say you are uploading history from one of the units. It looks like you are trying to upload from Jan 1. There is also a look back window limitation.

Both of those limitations are much more liberal for “donators”. If you have not made a donation (like ten bucks or so) in the past year, you will not be able to upload history from 2 months ago.
The transaction limit is 60/hour and 300/hour in “donator” mode. Moreover, the amount of data in each transaction is three times greater. The lookback period is 14 days but increases to 90 days in donator mode.

Right now you are forcing history reload, so it will try to start with the date that you have set. Understand that as long as that “Reload history” is checked, it will reload every time it restarts. You must reset that when the upload is complete.

When you do reset the upload history option, IoTaWatt will request the date/time of the last status update and resume from there. Each unit will do that independently. So if one gets ahead of the other for some reason, and the lagging unit restarts, it will pickup where the other left off, leaving a hole in it’s data. So I don’t recommend updating the same PVoutput site from two IoTaWatt.

If you have access to the mains where the new IoTaWatt is located, I’d recommend putting CTs on the mains there and uploading everything from that IoTaWatt.

I did wonder if that might be an issue. I have both sending to EmonCMS. If EmonCMS can do the upload that would also work since it would be a single source.

There are issues there as well.

To avoid the data restart hole issue, you should be using different Emoncms node IDs for the two IoTaWatt.

II’m not aware of any direct support for PVoutput in Emoncms. I think there are a couple of external scripts/Python methods to extract the data and upload. I’d check to be sure they are not just “real-time” uploads but will upload any backlog if there is a communication lapse.

Incidentally, my understanding is that most all uploaders to PVoutput are “real-time”. When there is a lapse in communication, they pickup at the time of restoration, leaving a hole in the data. Most of the time it’s because the uploading device doesn’t retain the data needed to do a recovery. IoTaWatt is somewhat unique in that it recovers upload sessions in all of it’s uploaders - Emoncms, influxDB and PVoutput.

It would be simpler and better to just add a couple of Mains CTs to the new unit if you have access to the mains there.

EDIT: All that said, I think your topic issue is the rate and lookback limitations of PVoutput, particularly if you have not donated.

EDIT: Reading their docs, the minimum donation for “donator” privileges is $15AUD which is around $12US.