Wenn ich kann, kein Problem 
Ich programmiere auch in meiner Freizeit
Der Kreis stört mich auch, er ist kaum sichtbar und wenn wir bei 5% sind, wird der rote Balken wie ein Punkt aussehen. Ich bevorzuge die Fortschrittsleiste.
Eine Frage, die nichts mit der Anzeige zu tun hat.
Betrifft den Kameradienst.
Derzeit gibt es RTSP-Kameras, die nur für einen Kameratyp verwendet werden.
Meine Fragen sind:
- Muss für jeden Hersteller und jede Kamera, die von den Benutzern verwendet wird, ein separater Dienst erstellt werden?
– Netatmo: Innenkamera, Außenkamera, …
– Somfy:
– Xiaomi: … - Kann es der gleiche Dienst sein und der Kameratyp wird in einem Dropdown-Menü ausgewählt?
- Oder funktioniert dieser Dienst für alle Kameras?
RTSP ist keine Marke oder ein Kameratyp, sondern ein Kommunikations-/Datenübertragungsprotokoll. Um deine Frage zu beantworten: Nein, du musst nicht für jeden Kameratyp einen Dienst erstellen, sondern einen Dienst pro Kommunikationstyp (ich kenne nur HTTP und RTSP für Kameras).
Ich weiß nicht, ob @pierre-gilles zwei Dienste geplant hat, aber in Bezug auf die Anzeige wird es gut in derselben Box auf deinem Dashboard sein, und für die Konfiguration denke ich, dass du eine Auswahlliste für die Protokollauswahl hast, oder es wird einfach in Abhängigkeit vom URL-Typ erkannt, den du auf der Konfigurationsseite eingibst.
rtsp://<IP_CAMERA>:port/something
http://<IP_CAMERA>:port/something
Hallo,
die beiden funktionieren bereits
Ich greife auf meine Kameras über RTSP zu und auch über die Synology-API, die eine URL in HTTP bereitstellt.
Für die Kamerasteuerung (ein-/ausschalten/PTZ) könnte man sich vorstellen, dies über ONVIF zu machen, ein Protokoll, das mit 90% der IP-Kameras kompatibel ist! Es gibt eine Node.js-Bibliothek dafür, daher könnte man potenziell einen Dienst erstellen.
Für RTSP, ja, ich weiß, dass es ein Protokoll ist.
Um ehrlich zu sein, habe ich eine Netatmo-Innenkamera.
Ich weiß, dass es eine Dokumentation gibt, aber ich habe keine Ahnung, wie ich sie in Gladys integrieren kann.
https://dev.netatmo.com/resources/technical/reference/security/live
Du hast mich nach „onvif“ verloren.
Für die Netnamo-Kameras scheint es, als müsstest du ein Authentifizierungstoken von ihrer API abrufen. Versuche es mit diesem Tutorial Tutorial für Domoticz.
Die Netatmo ist nicht mit „ONVIF“ kompatibel, schade 
Nichts hinzuzufügen 
Aber ich greife seinen Kommentar auf! Ich bin mir nicht sicher, ob ich einen Dienst pro Protokoll erstellen muss. Ich finde, das ist seltsam für den Benutzer…
Das Problem, das ich mit dieser Methode habe, ist, dass es wirklich « technisch » wirkt. Warum nicht einen Dienst erstellen, der alle Kameras zusammenfasst?
Das ist einfacher und dann liegt es am Entwickler, dieses oder jenes Protokoll zu verwalten. Oder?
Gleicher Meinung. Ein „camera“-Service mit mehreren Protokollen, der maximale Kompatibilität bietet.
Für andere Geräte könnten andere Ansätze verfolgt werden. Ich denke an Bluetooth, das sehr generisch bleibt, aber „Super“-Bluetooth-Dienste, die den ursprünglichen Bluetooth-Service nutzen, je nach Gerätetyp, schließlich denke ich.
Aber wir haben noch ein wenig Weg vor uns, bevor wir dort ankommen.
Das hat nichts zu tun, wie kann man in Gladys 4 ein Gerät vom Typ Schalter (Steckdose) definieren? Danke 
Das wäre tatsächlich sinnvoller, besonders für Normalnutzer wie mich.
Ehrlich gesagt, egal ob durchschnittlicher Nutzer oder nicht, alle wollen sich das Leben einfacher machen
Das kommt im PR, den wir gestern mit @link39 gemacht haben!
Hast du dein Glück gefunden? Ich habe es noch nicht versucht, aber es sollte nicht mehr lange dauern. Spontan würde ich sagen, dass man die entsprechenden Parameter in DEVICE_FEATURE_CATEGORIES und DEVICE_FEATURE_TYPES in server/utils/constants.js hinzufügen muss.
Vielleicht sollte man auch die Funktion „Energieverbrauch“ berücksichtigen, auch wenn sie nicht auf der Steckdose existiert, die du integrierst, und folglich die W/h in den Einheiten hinzufügen.
Oh, das ist ja wunderbar! Auf jeden Fall habe ich das Problem mit dem Browser, der beim Xiaomi-Service abstürzte, behoben. Zumindest hoffentlich.
@pierre-gilles ist zur Rettung gekommen 
Um die Diskussion über die Gruppierung von Peripheriegeräten zu beantworten. Ich bin zu 100% für diese Art von Optimierung, um die Benutzeroberfläche zu vereinfachen, sie linearer und weniger wie einen „DB-Dump in der UI“ zu gestalten.
Man sollte aber den Gebrauch im Hinterkopf behalten:
- Was versucht man anzuzeigen?
- Für wen?
- Warum?
Zum Beispiel finde ich die Batterie nicht unbedingt nützlich. Die Batterie ist nützlich, um eine automatische Benachrichtigung zu erhalten, wenn die Batterie schwach ist, aber ansonsten ist der Nutzen begrenzt. Warum manuell überwachen, wenn eine Maschine das erledigen kann ^^ Das ist doch das Ziel der Automatisierung!
Im Fall des Kameradienstes funktionieren alle Kameras am Ende gleich, daher denke ich, dass wir den Dienst einfach in „Kamera“ umbenennen können. Der Kameradienst verwaltet bereits RTSP + HTTP. Xiami, Somfy und Netatmo sind wahrscheinlich bereits kompatibel
Man wird sehen müssen, ob es mehr Sinn macht, zu gruppieren oder in einem anderen Dienst zu trennen.
Das ist super. Gibt es in Zukunft vielleicht eine Liste der unterstützten Kameras? Die von den Nutzern getestet wurden.
Dadurch kann der Nutzer diese oder jene Kamera auswählen, und er ist sicher, dass sie mit Gladys funktioniert.