markruys / gw2pvo

GoodWe to PVOutput
MIT License
45 stars 29 forks source link

Calling with --date fails with KeyError: 0 #41

Closed tsbkelly closed 4 years ago

tsbkelly commented 4 years ago

Calling gw2pvo with --date 2020-06-17 (for example) fails as follows:

ERROR Failed to call GoodWe API Traceback (most recent call last): File "/usr/local/bin/gw2pvo", line 10, in <module> sys.exit(run()) File "/usr/local/lib/python3.7/dist-packages/gw2pvo/__main__.py", line 116, in run copy(args) File "/usr/local/lib/python3.7/dist-packages/gw2pvo/__main__.py", line 74, in copy data = gw.getDayReadings(date) File "/usr/local/lib/python3.7/dist-packages/gw2pvo/gw_api.py", line 75, in getDayReadings eday_kwh = data[0]['p'] KeyError: 0

Steve-Wax commented 4 years ago

There is a good chance that GoodWe is reporting bad data back to you. I have had issues with them in the past not having the total for a day available. That said, the code here has some problems with the --date option which I put in a pull request to correct. See issue #14 and #23 and pull request #25. You may want checkout my fork if you would like to use the --date option regularly. I believe I have it working well now. https://github.com/Steve-Wax/gw2pvo

markruys commented 4 years ago

Should be fixed by 4b97b7a, can you please confirm?

tsbkelly commented 4 years ago

Doesn't appear to be, unfortunately - getting this error:

WARNING HTTPSConnectionPool(host='semsportal.com', port=443): Read timed out. (read timeout=10) ERROR Failed to call GoodWe API WARNING 2020-06-11 - Received bad data {}

markruys commented 4 years ago

@tsbkelly, just to be sure, did you install the commit 4b97b7a? I've just released it as a new package:

pip3 install https://github.com/markruys/gw2pvo/releases/download/1.3.1/gw2pvo-1.3.1-py3-none-any.whl
tsbkelly commented 4 years ago

I hadn't, no, but I'm now getting this error:

Traceback (most recent call last): File "/usr/local/bin/gw2pvo", line 6, in <module> from gw2pvo.__main__ import run File "/usr/local/lib/python3.7/dist-packages/gw2pvo/__main__.py", line 9, in <module> from astral import LocationInfo ImportError: cannot import name 'LocationInfo' from 'astral' (/usr/local/lib/python3.7/dist-packages/astral.py)

When run as a service, systemctl reports:

● gw2pvo.service - Read GoodWe inverter and upload data to PVOutput.org Loaded: loaded (/etc/systemd/system/gw2pvo.service; enabled; vendor preset: e Active: activating (auto-restart) (Result: exit-code) since Sun 2020-06-28 19 Process: 21018 ExecStart=/usr/local/bin/gw2pvo --gw-station-id ****** Main PID: 21018 (code=exited, status=1/FAILURE)

markruys commented 4 years ago

What does /usr/local/bin/gw2pvo --version say?

It looks like you're using the wrong Astral package. You might try to reinstall using sudo:

sudo pip3 install https://github.com/markruys/gw2pvo/releases/download/1.3.2/gw2pvo-1.3.2-py3-none-any.whl

Note I've fixed another issue in the just release 1.3.2 wrt --date.

tsbkelly commented 4 years ago

/usr/local/bin/gw2pvo --version says gw2pvo 1.3.0

I probably do have the wrong Astral version - when I first installed the package it failed due to not being able to import Astral from astral - downgraded to a previous Astral package following someone's suggestion, and it worked. I'll try installing 1.3.2 and see if it works.

markruys commented 4 years ago

Okay, I've updated the installer to enforce Astral 2. Can you please try:

sudo pip3 install https://github.com/markruys/gw2pvo/releases/download/1.3.3/gw2pvo-1.3.3-py3-none-any.whl
tsbkelly commented 4 years ago

That's solved the import Astral from astral problem - now running as a service properly, but running with the --date option produces this error:

WARNING 400 Client Error: Bad Request for url: https://pvoutput.org/service/r2/addbatchstatus.jsp ERROR Failed to call PVOutput API

markruys commented 4 years ago

Well, this is actually a completely different issue. This part of the source code hasn't been changed for some time. Could you please create a new ticket and add the console output when you call it with --log debug? FYI, I can't reproduce the problem yet.