Hello depuis la last maj jai des soucis d’affichage du dashboard sur gladys plus uniquement.
Suis je le seul ?
En local en revanche pas de soucis 
Je sortirais les logs quand je serais sur un pc ^^
@spenceur C’est pas le même souci d’horloge que la dernière fois par hasard ? Je veux bien l’erreur si tu l’as oui !
J’ai pas vu d’erreurs spéciale sur Gladys Plus et tout fonctionne pour moi
Aucun problème de mon côté pour l’affichage.
Par contre je rencontre toujours des problèmes de scènes avec mauvaises récupérations de valeurs, et c’est assez aléatoire.
Ma maison semble toujours vide, des Fakes devices en bouton on/off ne retournent aucunes valeurs (ni 0 ni 1), …
Je vais vérifier toutes les scènes avec envoi de message à chaque étape pour scanner où ça coince…
Alors pour le coup je ne pense pas (jai le soucis sur mobile )
Parfois j’actualise jai mes bouton mais si j’allume une lumiere ou desactive mon alarme, rien ne se passe il faut que je réactualise et je reclique.
Je veux bien les résultats de ton investigation 
hésite pas à créer un sujet spécifique ça sera peut être plus simple pour t’aider !
Tu as le bug partout ? Mobile et sur ton ordinateur, même dans différents navigateurs ?
Je veux bien les logs du navigateur, sans information c’est dur d’aider
@pierre-gilles , j’ai peut-être identifié une piste, certaines scènes se stoppaient en plein milieu sans raison apparente. Les messages telegram à chaque étape m’ont permis de le confirmer.
J’ai testé une scène qui devait allumer et éteindre une prise sur ewelink et aucune réaction.
J’ai donc passé le commutateur de « simple » à « calculée » en conservant la valeur. Elle s’est mise a fonctionner. En repassant en mode simple, ça refonctionnait à nouveau.
Je suis incapable de t’en donner la raison.
Je verrais demain matin si ma scène de levée de volets est aussi corrigée avec cette bidouille.
Ok, il y a clairement un souci avec la nouvelle action « contrôler un appareil »
Si tu as d’autres informations, hésite pas, ça aiderait beaucoup pour débugger
Ca ressemble beaucoup a un bug à cause du passage au nouveau format de scène avec calcul
En nouveau mode simple il y a certainement un traitement qui ne prend que la partie considérée a gauche de la formule et qui exclut la partie calculée à droite, avec l’ancien format je pense que le traitement d’erreur est manquant sur le coté partie vide , en passant en mode calculé il y a eu un enregistrement au nouveau format qui résout le problème et en repassant en mode simple c’est pareil…à vérifier. je l’aurais bien fait mais je sais pas quel module est concerné
Je te confirme que ça résout mon problème. Tous mes volets se sont ouverts ce matin comme avant.
Ca concerne en effet les commutateurs ewelink dans « contrôler un appareil » mais également en fake device créé dans mqtt :
En passant en « calculée », la case était vide pour certains d’entre eux. J’ai donc indiqué la valeur 0 et ça semble corriger le problème.
Je ne sais pas où chercher davantage pour identifier le problème …
Par rapport aux caméras, est-ce que les changements que j’ai fais ont amélioré la latence chez tout le monde ? Je suis preneur de retours 
Ah mais ça c’est effectivement un bug connu, mais qui a été corrigé assez rapidement après la release :
Ce qui a du se passer, c’est que du à du ouvrir la scène lorsque le bug était encore présent, et tu l’as enregistré ce qui a écrasé le champ…
Je vois que tu avais mis un message pour dire que tu avais le bug:
Donc c’est fort probable que ce soit ça
Oui sans doute.
C’était facile à repérer dans un « continuer seulement si » car la valeur 0 n’était plus affichée mais avec un contrôle d’appareil, on ne voit pas qu’il manque le 0 quand le bouton est sur off. Seul le mode « calculée » permet de s’en rendre compte. 
Rien de grave alors …
1 « J'aime »
Chez moi, ce soir en tout cas, ça bufferise très souvent la vidéo. Que ce soit via Gladys Plus ou en local.
Sur ma caméra en direct, je n’ai pas le problème.
Et côté Gladys Plus je ne constate pas d’amélioration sur le délai par rapport au direct.
Autre question :
Ma caméra propose un flux via web sockets, qui est plus réactif et presque en temps réel par rapport au flux RTSP. C’est supporté par la librairie que tu utilises ou pas ?
@lmilcent Ok, il faut trouver étape par étape d’où vient la latence !
Si tu consomme le flux RTSP depuis VLC, quel est le décalage ? Il faut faire étape par étape, si en local c’est déjà pas fou, forcément via Gladys Plus ça sera pas mieux
Ici, je pense que le problème est local.
On utilise ffmpeg pour lire les flux ( FFmpeg Protocols Documentation ), la liste des protocoles n’a pas l’air de contenir Websocket mais franchement ça se tente. ça ressemble à quoi l’URL de ton flux ?
Mon commentaire sur la latence est aussi en lien avec l’avant mise à jour pour tenter de la réduire.
Avant la mise à jour, c’était fluide sans arrêts, mais avec un décalage de 20 secondes environ. Après la mise à jour, ça s’arrête sans arrêt.
ERRATUM Les lenteurs semblaient être causées par ma caméra. Nouveau test ce dimanche matin, et plus de buffer.
Contexte
J’ai créé une caméra avec la Camera Pi 3 Wide et le projet open source suivant, qui me donne des flux WebRTC, RTSP et en MP4 :
Test 1 : Flux RTSP avec VLC
URL : rtsp://192.168.1.84:554/cam
Latence : Entre 3 et 7 secondes de décalage constaté.
Test 2 : Flux HLS (fichier m3u8 et format MP4)
URL : https://192.168.1.84:8888/cam/ dans un navigateur web, et https://192.168.1.84:8888/cam/index.m3u8 sur Gladys.
Latence : Entre 2 et 5 secondes constaté.
La console du navigateur m’affiche environ 2 fichiers MP4 par secondes. Je sais que la configuration du serveur qui gère la caméra peut être modifiée aussi de mon côté pour ajuster la taille de ces « paquets » et leur fréquence.
Test 3 : Flux WebRTC
URL : http://192.168.1.84:8889/cam/. La console indique bien l’utilisation des web sockets avec ws://192.168.1.84:8889/cam/ws.
Latence : presque aucune.
Génial merci pour le test Et du coup, tu arrives à consommer quel flux dans Gladys ?
Edit: Je viens de voir ça passer sur Hackernews: WebRTC support in ffmpeg avec une grande amélioration de la latence !
1 « J'aime »
Comme tu peux le voir, les deux flux HLS et RTSP. Si on compare l’heure affichée dans le flux et celle affichée en haut du téléphone on co’nstate vite que le RTSP à moins de latence.
Mais plus de problème de buffer.
1 « J'aime »
C’est encore moi @pierre-gilles 
J’ai testé à nouveau via Gladys Plus et je confirme que les flux RTSP sont fluides quand les mêmes flux HLS (.mp4) bufferisent pas mal.
J’ai aussi eu cette erreur, je pense que c’est lié :
Ok top! La latence en RTSP est vraiment pas mal
Effectivement, faire du HLS par dessus du HLS ça n’a pas trop de sens et ça fait du buffering. L’erreur que tu vois est bien une erreur de buffering reste en RTSP !
Un message a été scindé en un nouveau sujet : Ajout d’un flux vidéo RTSPS (RTSP over TLS)
J’ai un petit bug à remonter. Soit c’est temporaire, soit c’est le bug impossible à prévoir 
Contexte : Ma caméra est un Raspberry Pi 3, sur port micro USB. Mon fils à voulu la cacher pour jouer et à fait bugger le Rpi pendant quelques secondes.
Le flux vidéo s’est arrêté, puis s’est relancé après quelques secondes (pas de reboot).
Côté Gladys (Plus ou local), la vidéo en live se relançait à quelques secondes avant la déconnexion, puis bufferisait en infini.
- Rechargement de la page ==> Même comportement
- Arrêt du live et reprise ==> Même comportement
- Appuyer manuellement sur « tester » dans l’integration caméra ==> Rien ne change
C’est après plusieurs minutes que le live s’est coupé tout seul et finalement à retrouvé la connexion.