toggledbits
commented
6 years ago OK. I've now submitted a revision with exception handling on the Vera requests that seem to be quite stable, and without a broad-brush exception trap. I think this is a satisfactory middleground, because as I mentioned in my other comment, although various json parsers are giving mixed responses to errors (not always json.decoder.JSONDecodeError), they seem to all consistently follow the suggestion that they be derived from ValueError.
In addition, this version adds our own exception class for the above errors, and restructures the polling loop so that its exception trap only contains the code where those exceptions would be expected to be raised. There is also a blanket exception trap bracketing only the callback call, to trap any problem untrapped by the callback itself and log it, but not let it take down the polling thread.
pavoni
Harden the polling loop by checking the request Response object in some detail to detect various anomalies that can occur during Vera luup reloads. Since not all JSON implementations stick to de-factos for exception handling, and the requests module returns no error on disconnect with no data, widen the net for catching problems and handle them within a smaller subset of exceptions the polling thread and other callers can manage. Streamline the polling thread code itself just a bit, and add some logging in a few places where it may help to address future issues.