I see more and more people asking for help on the Forum and it’s always difficult to understand the problem without a minimum of information.
I suggest a button in the Settings > System section that would allow extracting a file (or text) containing basic information (Gladys version, system version, device on which Gladys is installed) and an excerpt from the latest logs (by service?).
This would allow novice users to get help more easily on the forum.
I agree on the problem, not necessarily with the solution.
Let’s go back to the root of the problem.
What types of user problems do we encounter on the forum?
If you see other specific cases of posts on the forum, let me know 
In 1., it’s a communication issue: our documentation is not rich enough and the user thought it would work, whereas we do not manage the device. The interface could have warned them by saying « No device detected. Is your device in the list of managed devices? [INSERT LINK TO LIST HERE] ».
In 2., it’s a lack of clarity in the interface. The interface could provide more feedback on what the backend « sees » in « raw ». We need to see service by service how we could make the interface clearer with more detailed status returns of the data actually received by the backend. Example: in the case of Xiaomi, we could display a list of the last 10 messages received by Gladys, in a quasi-raw format.
In case 3., often a simple description of how to reproduce the bug is enough to reproduce it on the developer side.
The problem I see with a solution like « we release a file export of the Gladys instance and the user posts it on the forum » is that it encourages the user to be passive in their debugging, and it puts the user in a « user ↔ customer support » relationship with the forum. The file is likely to be a large block filled with technical jargon that the user will not read (as it is unreadable for a non-initiated person), they will simply copy it to the forum.
The result? The support load on the forum will only increase, and user satisfaction will paradoxically decrease as the user will have to wait for a response from an « expert », an « expert » who will not be available because they will have too many requests to answer.
What I see instead
The user should have, in my opinion, all the keys in hand within the product to see what is wrong, and thus be an actor in the resolution of the problem.
We need to go through each service to identify frequently blocking points, and add more messages (error messages, information) in the interface for each identified blocking point.
For simple understanding issues (what is compatible with Gladys?), we need to better redirect to the documentation instead of the forum so that the user can self-answer and get their answer without waiting
What do you think?
I know my post may be overly complete for the simple feature you requested, but I think it is crucial to lay the right foundations to avoid hours of unnecessary support where a clearer interface often suffices. It’s simple UX choices like this that will determine whether the v4 can « scale » to thousands of users or not.
@VonOx @AlexTrovato I’m tagging you here, I think there’s a big project coming up on this topic.
Currently, we have no information when something goes wrong with certain integrations (Z-Wave, Bluetooth, Xiaomi). There is a real need to reflect on how we can facilitate debugging, always in the user-friendly spirit of v4 and leaving as much room as possible for the user to get an idea of what’s wrong themselves.
Let me take a simple example: the Xiaomi service.
Summary of the requests we have:
I think that by working on the UI instead of redirecting to the forum, everyone benefits: the user finds their answers in the product, and we are less solicited for minor problems.
I completely agree to avoid turning the forum into customer support. It’s very time-consuming and sometimes infantilizing for users.
I like the idea of services responding to a few user interaction standards. I think we all have the technical vision but that UX requires some effort to facilitate its use.
And we can really feel in this v4 the direction you want to give. What is complicated during the integration of hardware is the diversity of devices and bug cases.
I will try to propose an additional Help page in the documentation with a guide to identify the main known problems and give more autonomy to users.
We can also add an FAQ at the bottom of the Integrations pages (case of Xiaomi gateways for example).
I also think that we need to differentiate between novice users who want to install and configure everything just by clicking and those who know how to develop, read logs, connect to Docker, etc.
Both categories will benefit if there is more information in Gladys (doc and product) and the second category may be more inclined to understand/fix bugs or get involved in additional integrations.
I think that’s more in the product where these helps should be found. Documentation is an additional help in tutorial mode, but the product must be the default source of truth.
The question to ask is: when you install an app on your iPhone, have you ever referred to a user manual? Personally, never 
Everything works and when there is a bug in an app, the app tells me in the app: it should be the same in Gladys.