A couple of times, may be more in the last few weeks, the upload to PVoutput has stopped. Looking at the log, which I’ve PM’d to you, there are a few entries like this:
6/11/19 01:01:08z PVoutput: Transaction Rate-Limit exceeded. Waiting until 02:100:
I’d be grateful if you could take a look at the log please.
I was one of the early buyers, via OEM, some twenty months ago and haven’t really had any issues until this one. My current IoTaWatt installation is fairly minimalistic but I plan to change that later in the year.
Let me know if you require any further information.
You are reporting two, maybe three, different issues.
First, the “Kiss-o-Death” messages are unrelated to any PVoutput issues. IoTaWatt queries a time server every hour, and the time server pool being used in the current release sometimes rejects such a request if it feels you are pestering them with excessive requests (“rate”). These are not causing any problem in the logs you posted. Subsequent requests succeeded. The next release will use Google time services which don’t seem to care how often you ask and I believe have greater local presence globally.
Second, PVoutput has a limit on the number of transactions you can do each hour. You get a lot more when you donate a few bucks, but the free service is fine for ordinary operation. When IoTaWatt gets a response that the limit is reached, it pauses until the next period when the quota is restored. In your case, you have set PVoutput to upload history beginning on 5/24, and so it does that each time it restarts, forcing you to exceed the transaction limit. So on 6/10 it took three hours to upload that history, pausing shortly into each hour as the transaction limit was exceeded. If you clear the upload history date in the PVoutput service, that should stop.
The third problem is the “Fatal response” from PVoutput. I think this is because 5/24 exceeds the lookback period for uploading live data for non-donator mode. I’ll look into that, but I think if you remove the upload history date as suggested in the issue above, that will go away.
You may exceed the transaction limit on restart as it tries to continue from wherever it left off, but if you are patient, it should catch up and work fine going forward.
Sorry to bump a few-week old thread, but I’m having the fatal response problem after having power off to IoTaWatt for half an hour. I had this problem when I first set up IoTaWatt, but it seemed to resolve itself when I added voltage as an uploaded output. I can’t seem to figure out a way to get it to upload now. I am a PV Output donor, so I’m not sure if the other things mentioned above are relevant or not.
** Restart **
SD initialized.
7/23/19 02:49:46z Real Time Clock is running. Unix time 1563850186
7/23/19 02:49:46z Power failure detected.
7/23/19 02:49:46z Reset reason: Power on
7/23/19 02:49:46z ESP8266 ChipID: 6308344
7/23/19 02:49:46z IoTaWatt 5.0, Firmware version 02_04_00
7/23/19 02:49:46z SPIFFS mounted.
7/22/19 22:49:47 Local time zone: -5:00
7/22/19 22:49:47 Using Daylight Saving Time (BST) when in effect.
7/22/19 22:49:47 device name: IoTaWatt
7/22/19 22:49:50 Connecting with WiFiManager.
7/22/19 22:49:53 MDNS responder started for hostname IoTaWatt
7/22/19 22:49:53 LLMNR responder started for hostname IoTaWatt
7/22/19 22:49:53 HTTP server started
7/22/19 22:49:53 WiFi connected. SSID=XXXXX, IP=XXXXX, channel=11, RSSI -65db
7/22/19 22:49:53 timeSync: service started.
7/22/19 22:49:53 statService: started.
7/22/19 22:49:53 Updater: service started. Auto-update class is MINOR
7/22/19 22:49:53 dataLog: service started.
7/22/19 22:49:53 dataLog: Last log entry 07/22/19 22:49:25
7/22/19 22:49:54 historyLog: service started.
7/22/19 22:49:54 historyLog: Last log entry 07/22/19 22:49:00
7/22/19 22:49:55 Updater: Auto-update is current for class MINOR.
7/22/19 22:50:03 PVoutput: started
7/22/19 22:50:03 PVoutput: System XXXXX, interval 5, donator mode
7/22/19 22:50:03 PVoutput: Reload status beginning 07/21/19 00:05:00
7/22/19 22:50:23 PVoutput: Fatal response
7/22/19 22:50:23 PVoutput: Stopped.
I can’t see anything obvious. I have a new release that is days away from ALPHA. It addresses PVoutput halts with more diagnostic information and perpetual retries. Worst case is you wait for that and it solves the problem directly or provides information to further diagnose. Either way, the data is still being logged and it will backfill.
If you want to get it going right now, you could try setting the upload history from date to 7/22/19 and see if it skips over the issue. If so, be sure to remove he date after it catches up. Once the new release is out, you can set the date back to the 21st and fill in the 19 hour hole.
Before trying any of that though, could you set consumption with the max function as described in the documentation? And also set generation to
SolarPV max 0
`which will also preclude negative numbers. Sometimes the inverter standby power registers as a negative production. I don’t think this is causing the problem, but it’s possible. PVoutput wants positive numbers.
So a quick update – I was able to get it to begin uploading again this morning by choosing today’s date and checking reload history. I think one of a few unusual things may have caused this:
-I had power disconnected from IoTaWatt for 15 minutes while I swapped in a new GFCI outlet. When I powered everything back up, a handful of my inputs started showing showing reverse values. My initial configuration was still there, but I had to check or uncheck reverse for the mains inputs plus two others.
-This resulted in a handful of minutes of both missing data (while power was off), and erroneous negative consumption (mains + solar). I upload generation, consumption, and voltage to PV Output, so I wonder if the negative consumption values were the culprit.
I tried to reupload yesterday’s data, and ran into the fatal response error. Switched it back to uploading today’s again, and is working fine.
OK, that’s starting to make sense. You probably reversed the VT polarity which is the same as reversing CTs. You can logically reverse both VTs and CTs with the “reverse” option in the input setup. So rather than reverse all the CTs, might have been better to reverse the VT (or just physically reverse it).
You should probably add the “max 0” function to the end of both the consumption and generation outputs in your PVoutput setup to guard against stopping if the output goes negative for any reason.
I’ll take a look at the code to double check that as well.
