Gute Frage, stimmt, es ist nicht gut erklärt, was man momentan alles machen kann!
Momentan funktioniert nur die Integration von Owntracks über Gladys Plus, aber das Ziel ist es, die Verwaltung der Owntracks-Nachrichten in den MQTT-Service zu integrieren. Ich habe ein Issue auf GitHub erstellt. Wenn jemand Lust hat, bei diesem Issue mitzuhelfen, wäre das cool!
Das ist mein Reisefieber 
Stimmt, man könnte näher heranzoomen, aber wir haben darüber diskutiert und es ist nicht einfach, den Fokus zu setzen, wenn mehrere Personen im Haus sind, mit unterschiedlichen Standorten? Wie berechnet man dann den Zoom-Level? (Das ist eine offene Frage, das ist nicht das Thema hier, ich lade dich ein, auf einem anderen Thema oder auf dem GitHub-Issue zu antworten, wenn du am Debattieren teilnehmen möchtest :D)
Guter Hinweis! Die CalDav-Integration ist auf einem guten Weg. Wir warten auf die zweite Überprüfung des Pull Requests, meiner Meinung nach wird es für die RC klappen. Es wird tatsächlich eine Nachricht benötigt, die erklärt, wie man Gladys mit CalDav synchronisiert, in der Kalenderansicht.
Falls CalDav nicht rechtzeitig fertig wird, müssen wir den Tab entfernen, das ist klar.
Ich glaube nicht, dass wir das wollen. Gladys 4 macht zwar wenig, aber das macht es gut: Wir aggregieren Daten, aber lassen die Super-Apps der Kalender ihre Arbeit machen, was die Erstellung betrifft. Ich möchte den aktuellen Workflow der Nutzer nicht ändern. Ich möchte, dass die Leute weiterhin das tun, was für sie am einfachsten ist: Ihre Events auf ihrem Telefon erstellen und dann kümmert sich Gladys darum, dass sie dort ankommen.
Ich finde, mit den Kameras, Xiaomi, Z-Wave und Philips Hue kann der Nutzer bereits eine solide Gladys-Installation erstellen, oder? Wir decken bereits Hunderte (eher Tausende) von Geräten ab, oder?
Und ich finde, wir verwalten die führenden Integrationen jedes Typs:
- Philips Hue für Beleuchtung
- Xiaomi für Sensoren
- Z-Wave für viele Dinge
- Kameras aller Art, solange RTSP oder HTTP unterstützt wird.
Denkst du an bestimmte Integrationen?
Ich werde dir mein Ziel für den Release der RC erklären.
Eine Version « RC » zu veröffentlichen, ist Kommunikation. Neue Versionen von Gladys 4 veröffentlichen wir täglich! In Gladys ist das Deployment kontinuierlich, also geht jeder Merge einer neuen Funktion direkt an alle Nutzer (Docker ist toll!). Also brauchen wir keine RC, um die Software zu verbessern, das machen wir täglich.
Das Problem ist, dass die Bezeichnung « Beta » die Leute etwas blockiert: Niemand weiß wirklich, ob es fertig ist, und außer wenn du wirklich täglich den Forum besuchst, weißt du nicht, wie der Projektfortschritt ist. Derzeit sagen sogar Entwickler: « Ich warte auf den Release ». Dabei ist Gladys 4 für mich bereits veröffentlicht! ^^ Es ist nur ein Problem der Vision und Kommunikation.
Das Ziel der Veröffentlichung einer RC ist es, ein Signal « Es ist fertig » an alle zu senden. Es ist zu sagen « Wir sind stolz auf das, was wir gemacht haben, und wir denken, dass es für den täglichen Gebrauch geeignet ist ».
Natürlich wird es nicht alle Integrationen der Welt geben. Es wird mehrere Jahre dauern, bis wir den Punkt erreichen, an dem wir in Gladys 3 waren, denn es hat uns vier Jahre gebraucht, um dorthin zu kommen, wo wir in der v3 waren, und das werden wir nicht in zwei Monaten, sechs Monaten oder einem Jahr schaffen, was in vier Jahren erreicht wurde!
Aber ich denke, wenn wir eine solide und saubere Basis haben, die ersten Integrationen wirklich sauber sind und wir dieses Signal an die Community senden, dann wird das ein Momentum schaffen, das alle motiviert, noch mehr auf die v4 zu migrieren 
.
Aber grundsätzlich, wenn jemand Netatmo hat und bei der Entwicklung helfen kann, damit es vor der RC fertig wird, super!