New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
http interfacer "UnboundLocalError: local variable 'reply' referenced before assignment" #144
Comments
I suppose this come back to what causes emonhub to buffer data.
The HTTP interfacer is looking for I note the HTTPInterfacer also uses this
But never checks the return code. No other interfacer uses it (no surprise). The suggestion is that this function is moved to the HTTP interfacer (as well as the reply being fixed). |
@TrystanLea, I suggest this is a fairly critical issue. I am surprised it has not come up more often. |
Ref #89 Obvious now what the problem was. |
Thanks for the info on the issue above. Here's my fix so far, suggestions welcome:
Example of the log:
|
Or with the apikey placeholder printed?
|
I've merged this into the master branch for further testing, seems to be working fine for me. |
I've merged the second option with the apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y placeholder shown |
@TrystanLea - you have not removed the code from
Did you force loss of network? |
Sorry for the delay on this, yes removing the phone line from a BT Router results in the following error printed in the log:
The data is buffered and posted successfully when the connection is re-established |
I still see the HTTP code in the main interfacer. I think this can be removed along with the import statement. |
See https://community.openenergymonitor.org/t/emonhub-died/16489?u=pb66
Recommend further indenting line 258 of emonhub_interfacer.py so it becomes part of the Exception and change
reply
in that one line to a fixed value or error code etcemonhub/src/emonhub_interfacer.py
Lines 249 to 258 in ca13484
also there probably needs to be another level of exception unless line 257 will definitely catch all possible exceptions.
And, potentially more important, why is this "http" code in the core interfacer code rather than the http interfacer?
The text was updated successfully, but these errors were encountered: