Si je peux pas de soucis 
je code aussi à mes temps perdus
Le cercle aussi me dérange, c’est peu visible et lorsque l’on sera a 5% la barre rouge ressemblera a un point. Je préfère le progress-bar
1 « J'aime »
Une question qui n’a rien avoir avec l’affichage.
Concernant le service de caméra.
Pour l’instant il y a RTSP caméra qui sert uniquement pour un type de caméra.
Mes questions sont:
- Est ce qu’il faut créer un service pour chaque fabricant et caméra qui est utilisé par les utilisateurs?
– Netatmo: caméra intérieur, caméra extérieur,…
– Somfy:
– Xiaomi: … - Est ce que ça peut être le même service et en sélectionnant dans un menu déroulant le type de caméra?
- Ou ce service fonctionne pour toutes les caméra?
RTSP n’est pas une marque ou un type de caméra mais un protocole de communication / transfert de données, donc pour répondre à ta question, non il ne faudra pas créer un service pour chaque type de caméra, mais un service par type de communication (je ne connais que HTTP et RTSP pour les caméras).
Je ne sais pas si @pierre-gilles a prévu de faire deux services mais en terme d’affichage ça sera bien dans la même box sur ton dashboard, et ou pour la config oui je pense que tu auras une select list pour le choix du protocole, ou bien ça sera simplement détecté en fonction du type d’URL que tu rentreras dans la page de config.
rtsp://<IP_CAMERA>:port/something
http://<IP_CAMERA>:port/something
Salut,
les deux fonctionnent déjà 
J’accède à mes caméras par RTSP et aussi par l’API Synology qui fourni une url en http.
Pour la gestion des caméras (allumer/eteindre/PTZ), on peut imaginer le faire par onvif, c’est un protocole compatible avec 90% des caméras IP ! Il existe une lib node pour ça, donc potentiellement on peut créer un service.
Pour le RTSP, oui je sais c’est un protocole.
Pour rien te cacher j’ai une cam intérieur Netatmo
Je sais qu’il y a une doc, mais je n’y connais rien pour l’intégrer dans Gladys.
https://dev.netatmo.com/resources/technical/reference/security/live
Tu m’as perdu après “onvif”
Pour les caméras Netnamo j’ai l’impression que tu as besoin de récupérer un jeton d’authentification depuis leur API, essaye en suivant ce tuto Tuto pour Domoticz.
la netatmo n’est pas compatible “onvif”, dommage 
Rien à rajouter 
1 « J'aime »
Par contre je rebondis sur son commentaire ! Je suis pas sur de devoir faire un service par protocole. Je trouve que c’est bizarre pour l’utilisateur …
Le soucis que j’ai avec cette méthode c’est que ca fait vraiment “tech”. Pourquoi ne pas faire un service qui regroupe toutes les caméras ?
C’est plus simple et comme ça c’est au développeur de gérer tel ou tel protocole. Non ?
Même avis. Un service “camera” multi-protocole qui couvrira un max de compatibilité.
Pour d’autres devices, d’autres points de vue pourraient être entamés. Je pense au Bluetooth qui reste très générique, mais des “super” services Bluetooth, qui utiliseront le service Bluetooth initial, par type de device, enfin je pense.
Mais on a encore un peu de chemin à faire avant d’en arriver la.
Qui a rien a voir, comment sur Gladys 4 peut on définir un device de type switch (prise electrique). Merci 
C’est vrai que ça serait plus pertinent surtout pour l’utilisateur lambda comme moi.
Honnêtement utilisateur lambda ou non tout le monde préfère se simplfier la vie 
2 « J'aime »
ça arrive dans la PR qu’on a fait avec @link39 hier!
1 « J'aime »
T’as trouvé ton bonheur? Je n’ai pas essayé encore mais ça ne devrait pas tarder. De but en blanc, je dirais qu’il faut ajouter les paramètres qui vont bien dans DEVICE_FEATURE_CATEGORIES et DEVICE_FEATURE_TYPES dans server/utils/constants.js.
Peut-être penser à la feature “energy-consumption “ même si pas existante sur la prise que t’intègres et par conséquence, ajouter les W/h dans les unités.
Oh mais c’est merveilleux ! Génial en tout cas j’ai réglè le soucis avec le navigateur qui plantait sur le service xiaomi. Enfin normalement.
@pierre-gilles est arrivé à la rescousse 
1 « J'aime »
Pour répondre au débat sur le groupage des périphériques. Moi je suis 100% pour ce genre d’optimisation pour alléger l’UI, rendre ça moi linéaire et moins « dump de la DB dans l’UI ».
Je pense qu’il faut néanmoins bien penser à l’usage:
- qu’est-ce qu’on essaie d’afficher?
- pour qui?
- pourquoi?
Par exemple, la batterie je trouve pas nécessairement ça utile. La batterie c’est utile d’avoir une notification automatique quand la batterie est faible, mais le reste du temps bon l’intérêt est limité, pourquoi s’embêter à surveiller manuellement quand une machine peut le faire ^^ c’est ça l’objectif de l’automatisation!
Dans le cas du service caméra, toutes les caméras fonctionnent pareil au final donc je pense qu’on va pouvoir renommer le service en service « camera » tout simplement. Le service caméra gère déjà le RTSP + HTTP. Xiami, Somfy et Netatmo sont probablement déjà compatibles
A voir au cas par cas pour voir si il y a plus d’intérêt à regrouper où à séparer dans un autre service.
C’est super ça. Est ce que par la suite, il pourrait y avoir une liste des caméras supportés? Qui ont été testé par les utilisateurs.
Cela peu permettre à l’utilisateur de prendre tel ou tel caméra, il sera sure qu’elle fonctionne avec Gladys.