[FEAT]: Start if devices cannot be reached

[JulianWowra]

Hello,
I have a device which unfortunately has poor WLAN reception and is sometimes unreachable.

Current behaviour:
Server is waiting for a response from the configured devices.
Attempting to connect to the 1 configured device(s)...

Expected behaviour:
The server starts, regardless of whether the devices are available.

Question:

• What happens if devices only come online at a later time?
• What happens if the WLAN connection is interrupted? Is an attempt made to reach the device again at a later time?

[ClementNerma]

The devices are checked at startup to ensure that your configuration file is correct, which prevents surprises later.

This is also how the server works: on startup, it connects to the device, and stores the session internally for all the server's duration.

In case of connection problems, you can manually refresh the session with the /refresh-session?device_name=...

[JulianWowra]

Sounds good. Thank you for your work.

[JulianWowra]

The server cannot start if a device cannot be reached. This means that I cannot renew the session at a later time via /refresh-session either...

Tapo-REST-Bridge  | | Attempting to connect to the 2 configured device(s)...
Tapo-REST-Bridge  | | 1 remaining...
Tapo-REST-Bridge  | Error: Failed to login into P110 plug 'P110 - 2': Http(reqwest::Error { kind: Request, url: "http://<< IP >>/app", source: TimedOut })
Tapo-REST-Bridge exited with code 0

How could you solve the problem at startup? Unfortunately, the connection of one device is very unreliable.

How about this?

If a device is not reachable at startup, a warning is written to the log and started anyway. If the device is now requested by a client via the API, another attempt is made to establish a connection. If the device does not match, an error is printed in the log and further requests are rejected directly with an API error?

[ClementNerma]

In which context do you need to start the server with the devices not being reachable at that moment?

[JulianWowra]

If the software crashes or a cyclical restart of the Pi is performed.

Unfortunately, I cannot say exactly when the internet connection to the plug in the device is unstable. That depends on several factors. If the Pi restarts at the moment when the connection is unstable, its server ‘crashes’ again and my software cannot retrieve any data from your interface

[ClementNerma]

Hi, sorry for the long delay since the last message.

I'll consider that, but the problem is that it requires to change how the core of the program works. Concretely, it establishes connections on startup to get an "object" that will act as a client interface. Changing it would require to change the structure of how the program works.

I'll see if it can be done, but no promise.

[riven8192]

Firstly let me say I appreciate tapo-rest because it makes integrating with Tapo so much easier!

Like the topic-starter, I ran into some issues where we are dealing with the real-world: devices that are poorly reachable (either unplugged, or faulty, or whatever may be the case). This can cause issues at startup, but also at runtime, because it seems that when I'm making calls from multiple threads, to multiple devices, that whenever 1 device times out, all other requests are blocked too. It feels like the service is single-threaded, is that correct? Or maybe there is locking that is allowing only 1 thread to do I/O at a time.

This kinda overlaps with the issue described above.

My workaround is that I parse the devices.json file myself, let's say it contains 8 devices. Then I create 8 device-*.json files, each with only 1 device. Then I spawn 8 instances of tapo-rest, each handling 1 device only, on an unique port.

That seems to work incredibly well. This allows using tapo-rest in the real-world where device connectivity is not a given, and where a single problematic device should not interfere with communications to other devices.

[ClementNerma]

Well, I have good news!

I finally found time to work on the project, and I just released a version that have both:

• Support for unreachable devices on startup
• (Theorically) proper multi-threading

At startup, the server will try to connect to each individual device in parallel. Devices that are unreachable won't prevent the server from starting. When trying to communicate with them later on, a connection will be established in real time.

This should do the trick! Please tell me if anything doesn't work properly.

[riven8192]

Thanks for natively supporting my hacky external workaround! I will probably have some time tonight to give it a whirl, checking how it copes with randomly unplugging devices :)

[riven8192]

Finally got some time to integrate the new version into my application, and it works nicely. Unplugging devices no longer seems to cause queries to other devices to hang.