Sinon, l’autre option, c’était de faire une action de scène qui fait ça automatiquement et de laisser l’utilisateur la programmer quand il veut…
Avantage: L’utilisateur la programme quand il veut, c’est puissant
Inconvénient: Moins clé en main
1 « J'aime »
Je pense qu’il faut que ça soit clé en main cette partie. En revanche, on peut aussi avoir un déclencheur de scène pour permettre de garder la puissance ?
Côté notifications, je plussoie, il faut une seule notification pour tous les équipements qui ont plus de batterie.
Enfin, j’ai remarqué que certains capteurs Aquara tombent de 100% à 0%, voire se coupent à 100%. En gros, ils mettent jamais à jour le niveau de batterie…
Dans ce cas, faisons que la fonctionnalité clé en main 
Si il y a de la demande pour plus (je ne pense pas honnêtement) on fera
ça pour le coup on peut rien y faire, l’utilisateur recevra la notification trop tard (ou jamais…)
C’est du boulot d’émettre un message MQTT sinon ?
Vu qu’il est possible d’écouter n’importe quel message MQTT, ça serait un compromis. Après c’est vrai qu’il faut faire au plus simple plutôt que perdre du temps à s’éparpiller.
Faisons simple!
1 « J'aime »
@pierre-gilles: Voila le resultat en mode « box » pour l’écran de configuration système
Qu’est ce que tu en penses ?
Je viens de mettre le cron sur tout les samedi a 9h du mat. Et j’ai rajouté cette mention dans la description
6 « J'aime »
Moi je trouve ça super clean !
1 « J'aime »
Hyper clean @Lokkye !
1 « J'aime »
@pierre-gilles
La PR est prête :
2 « J'aime »
Merci pour la PR
J’ai fais une review: Add warning system for battery level by callemand · Pull Request #1936 · GladysAssistant/Gladys · GitHub
@pierre-gilles : J’ai pas eu le temps de faire les modifs, tu as déjà mergé la branch. Je fais une petite PR avec les micro changements ?
Salut, erreur de ma page, j’ai revert ensuite ! Tu peux re-ouvrir la PR complète !
@pierre-gilles : Je n’ai pas pu ré-ouvrir la PR, donc je viens d’en créer une autre :
Merci !
J’ai un petit souci en l’utilisant, le champ est assez bizarre à utiliser, il perd le focus à chaque saisi de caractère. Exemple pour passer de 10% à 20% :
Oui j’ai remarqué aussi cela mais comme les autres champs dans la même page on le même comportement. Je n’ai pas passé plus de temps dessus.
Le problème viens du setState qui force un redraw et on perd le focus.
Je vais investiguer un peu plus sur le problème.
ah merde, effectivement t’as raison j’ai le même souci avec « Délai avant expiration d’un état » !
Tiens moi au courant
Bon le problème viens de la propiété disabled qui est « bindé » sur un etat de la sauvegarde de la valeur. Pour le moment, en supprimant ce « bind » tout est ok mais il n’y pas de retour au niveau de la sauvergarde. Mais j’ai l’impression que les autres composants qui n’utilise pas d’input n’ont pas non plus de retour de la seauvegarde.
Est ce que cela te conviens si on supprime le « bind » ?
Mmm là comme ça c’est dur de savoir comment ça rend, ça rend bien ?
J’ai commit/push le code Ce sera plus clair
Ok effectivement c’est beaucoup mieux !
Encore un truc, du coup la validation fait que ça rend l’utilisation bizarre, mais je sais que c’est pareil à d’autres endroits dans Gladys (sur le tableau de bord par exemple pour éditer le nom d’un appareil)
Exemple, si j’ai 20 et que je veux mettre 30, quand je supprime le 20 avec « Backspace » 2 fois, ça fait ça (Un 0 est inséré)
Je sais pas ce qu’on pourrait faire pour dissocier la validation de la saisie. Un debounce plus long ?