Exception at code: device = await client.p110(ip)

[goofy2k]

I use the Python module to acquire data from my P110 smart plug. My overall application is rather forgiving for e.g. failed connections. But I keep track of (rare) exceptions to see iimprove my application step by step.

At a line containing device = await client.p110(ip) I now and then got: Exception: Tapo(Unknown(1003)).

At the same line of code I now get:

Exception: Http(reqwest::Error { kind: Request, url: "http://192.168.2.15/app", source: hyper_util::client::legacy::Error(Connect, ConnectError("tcp connect error", Os { code: 113, kind: HostUnreachable, message: "No route to host" })) })

Between both occurrences I successfully switched from version 0.3.0 of the module to version 0.5.1 . I wonder if both events in fact have the same root cause. So: is it just a matter of a change in the exception message?

[goofy2k]

Tiny detail: please note the typo in the description of the error: "reqwest" should be "request" ;-)

[mihai-dinculescu]

The HostUnreachable error is self-explanatory: the network connection between the plug and the device trying to call it has been lost. reqwest::Error is the type of error. It comes from the rust crate called reqwest, and that's why it shows up like that.

The 1003 error is slightly different, as it's an actual error returned by the plug, and I don't think it has much to do with the other one.

I think the 1003 error code itself means JSON is malformed or the API endpoint is unsupported, none of which make sense for sporadic errors unless the device is doing something else at that time (or another client is sending requests to it).

Are you getting it on login exclusively? What's the frequency? Are there any patterns that you can notice? Also, are your devices using the latest firmware?

[goofy2k]

Thanks. Do I understand you well, that these are two separate errors that still could occur after my update?

I got the reqwest error only one time now. The other error occurred tens of times (once a day, over say 100 calls). I do not have exact data yet.

When the error occurs, my current app just exits and restarts after an hour. I may want to implement a try/except algorithm to do several tries within a single hourly call.

But I find that less usefull if e.g. the error is caused by instability of my WIFI network. As mentioned: my application is forgiving for missing data of hourly calls as it collects daily data.

Op ma 28 okt 2024 22:37 schreef Mihai Dinculescu @.***>:

The HostUnreachable error is self-explanatory: the network connection between the plug and the device trying to call it has been lost. reqwest::Error is the type of error. It comes from the rust crate called reqwest, and that's why it shows up like that.

The 1003 error is slightly different, as it's an actual error returned by the plug, and I don't think it has much to do with the other one.

Are you getting it on login exclusively? What's the frequency? Are there any patterns that you can notice?

— Reply to this email directly, view it on GitHub https://github.com/mihai-dinculescu/tapo/issues/288#issuecomment-2442680011, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGII3TROIBDP3Z3T4PSI2PLZ52OBJAVCNFSM6AAAAABQXWP2JCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBSGY4DAMBRGE . You are receiving this because you authored the thread.Message ID: @.***>

[mihai-dinculescu]

Yeah, you're correct.

I'm not too worried about HostUnreachable. I'm pretty confident that it's a networking issue that has nothing to do with the library or your code.

But if you manage to find a way to replicate the random 1003 error that you're getting, I would be very interested in figuring out if it can be avoided or if it can become a better-documented error.

By the way, version v0.6.0 supports end-to-end logging.

import logging
logging.basicConfig(level=5)

The above will give the most detailed logs, while logging.basicConfig(level=logging.DEBUG) and logging.basicConfig(level=logging.INFO) and so on less.

[goofy2k]

OK. I will go to v0.6.0 and see what I can do with the logging option!

Fred

Op di 29 okt 2024 21:16 schreef Mihai Dinculescu @.***>:

Yeah, you're correct.

I'm not too worried about HostUnreachable. I'm pretty confident that it's a networking issue that has nothing to do with the library or your code.

But if you manage to find a way to replicate the random 1003 error that you're getting, I would be very interested in figuring out if it can be avoided or if it can become a better-documented error.

By the way, version v0.6.0 supports end-to-end logging.

import logginglogging.basicConfig(level=5)

The above will give the most detailed logs, while logging.basicConfig(level=logging.DEBUG) and logging.basicConfig(level=logging.INFO) and so on less.

— Reply to this email directly, view it on GitHub https://github.com/mihai-dinculescu/tapo/issues/288#issuecomment-2445244386, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGII3TUFN5H7LFKRI6PVG5DZ57UIRAVCNFSM6AAAAABQXWP2JCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBVGI2DIMZYGY . You are receiving this because you authored the thread.Message ID: @.***>

[goofy2k]

Updated to V0.6.0. Implemented logging in "production" app. Currently running with DEGUG level logs. Timestamped logs are being saved to file. Waiting for next occurrences of the errors. In version 0.3.0 / 0.5.1 they occurred about once every 2 - 3 days, at 24 (48?) calls a day. Now building more reliable statistics....

[goofy2k]

Have been using improved logging and v0.6.0 in "production" (Linux, Synology NAS, Python 3.8.15) since 2024-10-30 16:41. Doing 2 acquisitions with get_energy_data and EnergyDataInterval.Daily every day just after midnight. No runtime errors detected yet but period is relatively short.

Further improving logging with logging.info ongoing to get more info in case the error occurs.

Keep you posted when an event was detected either in "production" (Linux, Synology NAS, Python 3.8.15) or "dev" (Win32, PC, Visual Studio 2022, Python 3.11.8)

Unfortunately I can not mathch the Python versions on Linux and Win32.