Danke @cce66 für den Feature-Request, das klingt sehr cool, Dozzle, das kannte ich gar nicht 
Danke @cicoub13 für die Erwähnung, ich stehe zu dem, was ich damals zum Debugging gesagt habe, es fehlen eindeutig einige Bausteine in Gladys, um das Debugging zu erleichtern.
Seit meiner Nachricht im Jahr 2020 gab es mehrere Ergänzungen in diese Richtung, zum Beispiel die Ansicht „Hintergrundaufgaben“:
Diese Ansicht wird noch nicht vollständig genutzt, da nur bestimmte Teile von Gladys diesen Mechanismus implementiert haben und bisher kein Dienst ihn implementiert hat.
→ Ich wäre dafür, dass die Nutzung dieses Reiter sich verbreitert. Alles, was im Hintergrund läuft, sollte in „Gladys-Jobs“ eingekapselt werden, um in dieser Ansicht angezeigt zu werden, die im Fehlerfall leicht debuggbar ist.
Die MQTT-Integration wird bald (in der nächsten Version) einen „Debug MQTT“-Reiter haben, der es dem Benutzer ermöglicht, den eingehenden MQTT-Traffic auf der Instanz zu sehen, was praktisch ist, um beim Testen zu debuggen:
Das ist nur ein Beispiel, aber ich würde mir wünschen, dass Gladys und die Integrationen in der Oberfläche kommunikativer sind, damit der Benutzer sich weniger verloren fühlt.
Zum Beispiel sind Szenen schwer zu debuggen, es sollte eine Ausführungsgeschichte der Szenen geben, mit allen Informationen, damit der Benutzer versteht, was passiert ist, wenn Probleme auftreten.
Zum Thema zurückkommen
Ich bin mir bei der anfänglichen Anfrage von @cce66 unsicher, Dozzle ist eindeutig ein Werkzeug für Experten, warum sollten wir (was Arbeit bedeutet) ein Werkzeug einrichten, um es in Gladys einfach zu starten, wenn jemand Dozzle verwenden möchte, ist er in der Lage, eine Befehlszeile auszuführen, oder?
Sollen wir den Gladys-Nutzern auch die Botschaft vermitteln: Wir unterstützen es, die Nutzer dazu zu ermutigen, die Logs anzusehen?
Ihr werdet mir sagen, dass ich der Erste bin, der den Nutzern, bei denen Fehler auftreten, die Logs abverlangt, und ihr habt recht 
Aber ich würde gerne, dass sich das ändert!
