How to debug
Debug messages are intermittent messages of the code communicating/logging it's current state. They help the programmer to understand which steps led up to a failure. Typically, different levels of details are used, dependent on the situation, as too many error messages can also be counterproductive and bury the relevant information.
First, it is important that malfunctions can occur on many different level. For this library specifically, I tried to list all the possible levels below and some primers on how to get a look into them.
Not much I can say here, except for my mantra, that the power supply is surprisingly often the culprit of weird issues. Try a few different ones. Also try to remove as many peripherals as possible during debugging.
Unless you are some sort of wizard, it is most likely, that the problem is in the code you wrote. Try to remove parts of the code and see if the problem persists. Use as simple examples as possible. Then it is usually worth checking weather the lines you want to call are actually being called. This can easily be achieved by adding Serial.println directly after and/or before the command in question. Here, you can e.g. check if variables really have the value you expect them to have. Alternatively, you can also hard-code stuff and see if it works then.
All the debug levels below can also help you in figuring out problems on this level.
On a library-level the debug levels are:
DEBUG_NONE ///< Print no debug messages whatsoever (production)
DEBUG_ERROR ///< Only print error messages
DEBUG_WARNING ///< Only print error and warning messages`
DEBUG_INFO ///< Print error, warning and info messages
DEBUG_VERBOSE ///< Print all messages
These can give you great insight into what is going on 'under the hood' in the library.
Generally I would advice to start at DEBUG_WARNING and if unexpected behaviour occurs to be increased (and set back once the problem was solved). DEBUG_NONE is recommended for production.
After creating up the TR64 connection object (TR064 connection(PORT, IP, fuser, fpass);), you can set the debug level with this connection.debug_level = DEBUG_VERBOSE;.
Beware! You might get WDT (watchdog timeout of the ESP8266/ESP32 core) errors, which can also affect long-term stability. The cause might be excessive debug messages in the tr064.cpp file. This can be prevented by reducing the debug_level. To check if this helps I recommend to first try debug_level = DEBUG_ERROR;.
Down the rabbit hole! The HTTP client underlying this library also has debugging. These are very useful to see the actual HTTP call/response handling. They can be accessed via the Arduino IDE:
You can find more information on the according github page.
Next, you can make sure, the library is actually communicating correctly and the correct content to the router. For this you need to check your API call.
Sometimes the request goes wrong in the router and it is not the scripts fault at all. Or you are trying to do something the router can simply not do (like switching the wrong WIFI). To find these kind of problems, it might help to look at the routers log.
This can be accessed via the routers UI (usually via 192.168.178.1 or fritz.box) and then 'System->Event Log'. Here, you should see entries when the ESP logs in, when a call is placed (or could not be placed and if so an exact reason why), etc. This can be a very powerful tool!
Additionally, wireshark can be used.