[Help]: pi Controller wont connect to app / offline online constant

[DeeXii]

Controller Version

Latest

Describe Your Issue or Question

I have a raspberry pi 4 with mbently docker controller that has been working for months fine until I changed the router. It now won't connect to the omada app and says failed. I see random offline online messages from the app.

It was working before on my previous router.

Locally when trying to connect to via a browser, the login page always loads but logging in often gives a network error but eventually allows me to log in.

The only thing worth mentioning on my previous router was that it was on a different subnet as my edgerouter had 2 ports on a different physical internal switch. However I changed the ip configuration in the pi to the correct settings for the new router. The pi has internet in browsers etc.

I am stumped as to what could cause this. Do I need to forward ports on the router for the controller to work with the app?

Expected Behavior

The app to connect to the controller

Steps to Reproduce

Turn on the pi.
Try to use the omada controller.

How You're Launching the Container

Default

Container Logs

/

Additional Context

No response

[mbentley]

No, the app doesn't require any port forwarding. My understanding is that It works by establishing an connection from the controller out to the TP-Link servers and it keeps that connection open with their service. You should be able to check out to the logs of the controller to see if it is successfully connecting to the cloud service. If you need to force it to re-initiate the connection you can restart the container.

Just a warning to make sure you're taking care to do so - make sure to specify a timeout longer than the default docker stop/restart timeout if you're just natively running the container with docker run commands instead of a compose file so that the controller has time to properly shutdown. See this section of the README for more info.

Here are my logs, filtered on the word Cloud from a restart for example:

08/16/2023 9:42:57 AM
08-16-2023 09:42:57.589 INFO [main] [] c.t.s.o.m.l.p.e.LicenseEventCenterProperties(): licenseManagerTopic: omada.cloud.license.prd.topics
08/16/2023 9:43:04 AM
08-16-2023 09:43:04.107 INFO [main] [] c.t.s.o.s.t.CloudStartUpTask(): record: CloudStartUpTask start
08/16/2023 9:43:04 AM
08-16-2023 09:43:04.108 INFO [main] [] c.t.s.o.s.t.CloudStartUpTask(): record: CloudStartUpTask finished
08/16/2023 9:43:06 AM
08-16-2023 09:43:06.281 INFO [comm-pool-6] [] c.t.s.o.s.t.CloudStartUpTask(): start cloud connect on a reset hwc
08/16/2023 9:43:06 AM
08-16-2023 09:43:06.303 INFO [Thread-6] [] c.t.e.c.c.CloudClient(): CloudClient is started.
08/16/2023 9:43:06 AM
08-16-2023 09:43:06.303 INFO [Thread-6] [] c.t.e.c.c.CloudClient(): Connect SEF server automatically.
08/16/2023 9:43:07 AM
08-16-2023 09:43:07.253 INFO [Thread-6] [] c.t.e.c.c.n(): The result of connection is true, service host is n-device-omada.tplinkcloud.com, port is 443.
08/16/2023 9:43:07 AM
08-16-2023 09:43:07.254 INFO [Thread-6] [] c.t.e.c.c.CloudClient(): Close connection to SEF server.
08/16/2023 9:43:07 AM
08-16-2023 09:43:07.272 INFO [Thread-6] [] c.t.e.c.c.CloudClient(): Connect service server automatically, ConnectionType is PERSISTENT_CONNECTION.
08/16/2023 9:44:22 AM
08-16-2023 09:44:22.105 INFO [check-update-work-group-0] [] c.t.s.o.m.c.f(): Start sync Cloud Users OmadacId(f2c92c2a9b8fb0a427393f413bb16354).

You could try a connection via wget from inside the container to the endpoint your logs mention (not sure if all use the same n-device-omada.tplinkcloud.com endpoint) but just be aware that I am not sure what a normal connection looks like as that service uses a self-signed cert as they might be doing something with mutual TLS there and wget doesn't actually get a HTTP 200 response by default as there is probably some expected user agent or expected endpoint to hit directly.

[DeeXii]

Ok, it does seem to have something to do with shutting down and starting up as I move the controller to my desk to work on it and I get it working more stable. Then when I move it back to the network rack it starts to go wonky again. I'm not even going to pretend to act like I know fully what I am doing. I do not have a lot of experience in Linux. Earlier once you wrote back to me I restarted the container and it seemed to get it nice and stable. So what exactly do I need to do to get it to shut down and start up properl? I appreciate your time in replying to me. I also really appreciate your work on this in creating it. :)

[mbentley]

Proper shutdown is documented in the link I provided earlier. Hopefully your raspberry pi is running the arm64 variant if you want to somehow copy volumes between the two machines because switching the data between armv7l and either arm64 or amd64` will cause issues due to different MongoDB versions. I suppose if you're exporting data directly from the controller and importing it or using the migration tool, that should work fine but I've never tested either.