jjacques68

rien à voir avec le sujet, désolé, mais @Lazer, tu as donc la boucle d'interrogation du refreshstate dans GEA et dans ce QA ? tu interroges cette API donc à plusieurs endroit différent ? Pas de soucis de performances alors ?

c'est le petit soft que j'avais mis en place pour l'histoire du routage z-wave... auquel j'avais ajouté des fonctionnalités pour télécharger scènes et QA... justement concernant les 2 dernières lignes : la télécommande (id 28) c'est normal, chez moi c'est pareil, les télécommandes ne sont liées directement... par contre c'est le détecteur de fumé (id 65) qui me dérange ! c'est quoi comme détecteur ? parce qu'en plus il sert de lien pour d'autres modules !! Je pense la même chose que @Lazer, à savoir ajouter très vite des modules secteurs...

idem jamais pensé à Varta pour les cycles de charge des batteries NiMh, ça se complique !! Faut savoir le régler !! temps de charge, rampe de montée/descente, tension/courant de charge, privilégier la régulation de tension ou de courant... à l'époque ... on disait de charger les batteries (au plomb) à 1/20 de leur capacité pendant 24 heures... on est loin des charges rapides en Li-Ion ben les gars je vais tester ces piles rechargeable USB... Mais je me fais pas trop d'illusions . en attendant, et comme on est dans le sujet, je vais remplacer les batteries de mon onduleur eaton 5P... Les ai reçu hier, le soucis c'est qu'il faut tout arrêter et pas sûr que tout redémarre . bah en même temps je fais mon test annuel du coup

@Lazer merci pour ta réponse rapide et complète ! Suis d'accord avec les vieux modules z-wave... Il m'en reste plus beaucoup, mais encore... Effectivement certains réglages de certain module, font que je consomme d'avantage... (capteur extérieur °C et lux) Mais c'est volontaire. je vais essayé sur un module everspring (extérieur) avec ces LR06 recherchable par USB... Aucune idée du comportement par rapport à l'auto décharge (ce serait nul en effet ) Curieux de voir le comportement avec la courbe de tension... Question tarif, oui par lot c'est mieux... Sauf quand tu te prends un lot périmé qui a dormi chez le vendeur . Et sur des marques connues. ça m'est arrivé plus d'une fois !!

ah oui oui tout à fait !! désolé, avais mal lu la question initiale

Hello tout le monde : alors suite à une discussion dans un autre sujet, j'ai ouvert celui-ci pour ne pas polluer le précédent... Nous avons vu que l'on pouvait, sur la HC3, retarder une action sur un device, avec cette méthode : api.post("/devices/"..id.."/action/turnOff", {delay = 60}) et la commande ci-dessus nous renvoie ceci : {"id":22,"timestamp":1586330337} il s'agit de l'ID de l'action (retardée) ainsi que son timestamp où elle se déclenchera. ATTENTION : ce n'est pas l'ID du device !! ET dans mon cas, je souhaite pourvoir supprimer cette enregistrement, afin de ne plus exécuter cette action en attente !! En effet, J'ai dans la salle de bain, un PIR qui me déclenche la lumière et la VMC. Quand je quitte la SDB, au bout de 30 secondes la lumières s'éteint, mais la VMC reste allumée pendant 1 minute. d'où ce retard que j'ai mis. Mais si je rentre a nouveau dans la SDB, dans l'interval de la minute, je souhaite que le précédent timestamp de fin soit supprimé pour être remplacé par le nouveau! logique non Mais là, tel quel, si je re rentre dans la salle de bain, il se peut que la VMC se coupe, car la première minute a été atteinte. Bref si vous avez pas compris c'est pas grave... Alors il existe clairement une commande DELETE dans l'API permettant de supprimer l'action retardée !! Il suffit de saisir l'ID de l'action et son timestamp !!! super !!! sauf que !! comment je peux savoir que qu'il y a une action retardée pour ce device ? il manque une info ! si je souhaite supprimer une action retardée d'un device, il faut que je puise au moins la retrouver via l'ID du device qui en est à l'origine ! Sinon je sens bien qu'il va falloir stocker quelque part l'ID du device émetteur et le mettre en relation avec l'ID de l'action retardée et le timestamp de fin !!! du style : {"idTrigger":256, "id":22, "timestamp":123456789} Mais alors pffffffffffff, faire ça soit même !!!! c'est pénible !!!!! C'est obligé que dans l'API, cette information y soit !!! Sinon, comment la HC3 sait, qu'à ce moment là précis, c'est le device (ici 256) qu'elle doit éteindre !!!??, je suis passé à côté de quelque chose ?

y aurait pas une histoire aussi de clearTimeout() ? pour annuler un setTtimeout() en cours...

le reboot fonctionne bien. Mais pas le shutdown... Edit : et le suspend() semble faire un reboot ! On est vraiment coincé, si on veut éteindre proprement cette box par script !!

juste pour donner des news : plus de soucis de relais qui "collent" depuis que ce petit module est installé. ça fait 1 mois maintenant. merci

ah ?? non pas chez moi...

:) franchement j'ai pas encore lu la liste :)

@Barelle, je ne connais pas du tout... Suis plutôt axé windev, vu que je l'utilise énormément au boulo...

oui je comprend l'intérêt du delta maintenant, bien vu !! tout à fait @Lazer ! Mais tu sais que j'aime faire moi même quand je peux... Même si je réinvente la roue... Le plaisir de passer des heures à coder...

oké !!! merci pour les explications ! je faisais fausse route là.. l'idée était de voir se qu'il se passe les très rares fois où la HC3 freeze. je pensais développer une application tierce qui récupère les infos des CPU à coup de requête http, afin de les stocker en base et donc pouvoir les exploiter. Je voulais le faire depuis une application extérieure justement pour ces freeze... Pas sûr de les voir passer depuis un QA... si ça freeze, le QA est dans les choux aussi. avec l'application extérieures, je pourrais tracer la non réponse de la requête, et voir si ça coïncide avec ce que j'observe !

ben justement !? je me demandait pourquoi il fallait faire ce calcul avec Delta ?? pourquoi cela ne marche pas à l'instant t ? Par exemple interroger toutes les 5 secondes et voir l'évolution à l'instant t ! on a une répartition entre le user, le système et le non-utilisé !! Je comprends pas l'intérêt de mémoriser le n-1 et de faire la différence ! y a peut-être un truc que j'ai pas compris alors ?

merci @Lazer ! donc visiblement, d'après, le QA diagnostics c'est : (user+nice+system)*100/(user+nice+system+idle)

Mise à jour OK pour moi à première vue... RAS.

ok merci @Lazer. @Sakkhho : celui fourni en lien par @Did a mis 15 jours à arrivé en effet !! et comme tu dis, c'est par moment, souvent le soir... !?!

Fait. Bon j'ai 3 transfos, avec 3 ou 4 spot led dessus, donc il est branché entre la sortie Qx du FGS et le primaire des 3 transfos. Curieux de voir à la longue... Mais y a quoi dans ce petit "truc" ?

bon c'est clair. et commandé. merciiiiiii !

en série ?? c'est pas comme le by-pass de Fibaro ? et j'ai un transfo pour les led (12v), donc même chose ? @Did : j'ai tapoter avec le tournevis mais voulait rien savoir. J'arrive à le décoincer en m'existant sur l'interrupteur (on-off-on-off) du coup je dois changer le FGS ?

Hello tout le monde ! petite question : J'ai 1 des 2 relais d'un FGS-222 qui semble resté collé après l'allumage. Car quand je souhaite l'éteindre, il reste allumé (pourtant le retour d'état sur la HC3 est bien éteint !!! - comportement vraiment étrange ce retour d'état du coup...) Ce relais alimente 10 petits spot LED encastrés dans les meubles haut de la cuisine. Alors comme je sais que les LED ont un courant fort à l'allumage, je me dis que le relias est peut-être HS... Mon raisonnement est juste, où je fais complètement fausse piste ? Merci d'avance !

tout est dit

ouai... donc moi perso je passe mon tour. Là tout marche très bien, pas envie que ça change.

bien vu j'ai pas pensé