jjacques68

alors oui, mais alors... pfffff c'est compliqué... Le panneau de chauffage est pas assez convivial pour une utilisation poussée. Dans mon cas : Les zones sont déclarées dans le panneau de chauffage (comme ça les têtes Danfoss sont automatiquement associées). J'utilise le panneau de chauffage uniquement pour la planification de tous les jours. j'ai un QA parent/child, avec un Child de type thermostat par zone. Pour éteindre ou mettre en manuel une zone, je passe par le QA, qui modifie la zone directement par l'API. Mais franchement, je viens de le relire... c'est horrible , Entre la gestion des consignes, la gestion des zones, la gestion des child, la gestion de l'IHM, la class pour les child, ... c'est indigeste... mais ça marche très bien ! pas de méthode KISS non plus là ci joint mon QA, si tu veux avoir mal à la tête Heating_Manager_V2.fqa Oublies tout ce qui est Display_Soft, c'est pour mon interface réalisée avec windev... PS : même merde avec le panneau d'arrosage

méthode KISS, je la connais celle-la... pourtant, pour le coup...

oh ben mince alors, La ré-inclusion à corrigé le problème de mise à jour ! 2 ans qui me fait chi--- ce truc... !! J'ai l'air c--- là... ... ... ben merci à vous !

je n'utilise pas GEA... j'ai un autre truc qui fait plus ou moins la même chose... bref... je crois que je vois l'outil dont tu parles, mais je pense pas que ça existe sur HC3... Mais bon y a quand même certain script bien spécifique où il faudra renseigner le nouvel ID suite à la réinclusion... après j'exagère un peu en disant que c'est lourd comme manip Tout est tellement mieux organisé sur la HC3 que ça ira vite... plus aucunes scènes, quelques QA... Je regarde ça demain... mais reste sceptique quand même sur le résultat

non ! ça pas fait ! un peu lourd comme essai car il faudra reparamétrer quelques script, mais pourquoi pas...

tu peux vérifier que tu as bien "once" dans la fréquence d'envoi pour le device qui te pose soucis ? Moi j'en avais un qui était sur "1 par heure" , mais c'est pas lui qui me posait soucis... Du coup... dans le doute...

ben j'aimerais bien trouver l'équivalent sur la HC3... mais je vois pas où... Même dans l'API je trouve où il stocke cette alerte (je parle pas de la notification, ça je sais où c'est : /api/notificationCenter, je parle bien de la mise à jour)

(sous IOS) Vous avez aussi un soucis avec la pastille rouge affichant le nombre de notifications ? J'ai ça depuis toujours... même avec l'application précédente... J'ai toujours minium 100 : si je lance l'application dans l'exemple ci-dessus, je retombe à 100 ??? Si il y a une mise à jour de l'application, la je retombe à 0, du moins jusqu'à la première...

ben c'est ce qui va finir par arriver si je trouve pas une bidouille, mais c'est dommage, car il fonctionne bien sinon...

hello tout le monde, Depuis mes début sur la HC3, j'ai un FGMS qui me pose soucis. Il me propose systématiquement une mise à jour : Cette mise à jour ne fonctionne tout simplement pas. En tout cas, il ne va pas au bout. J'ai tout essayé, des multiples réveils du modules pendant le processus, avec une pile neuve, placé le FGMS à côté de la HC3, bref... rien ne marche. J'ai donc, via l'API, forcé la version "3.3" en "3.4", en me disant que du coup il me proposera plus la mise à jour : et bien non. Il continue ! Je sais plus où chercher pour essayer de désactiver cette mise à jour. ça me saoul d'avoir en permanence ceci dans les icones à cause de ce module : si qqun a une idée ? merci d'avance...

tiptop merci !!

ce que je constate aussi, c'est qu'elle met plus de temps à démarrer... M'en suis rendu compte avec le backup auto. J'ai du mettre le timeout général à 15 min. La taille du fichier est toujours de 24-25 Mo. Le cycle de backup complet (avec téléchargement du fichier) prend un peu plus de 10 min. bref rien de grave mais ça évolue... au fait @Lazer tu as pu jeter un œil sur ton script de backup auto depuis nos bug de l'autre fois ? actuellement, j'ai toujours mon pseudo-script windev qui tourne à la place...

tu as raison, chose faite. merci...

alors je viens d'essayer un petit module Zigbee : Xiaomi Mi GZCGQ01LM - Capteur de luminosité (16€ - amazon) en vu de remplacer les capteurs de LUX Everspring ST815 qui vieillissent très mal et qu'on trouve plus... Ben c'est pas mal du tout : le range est de 0-83000 lux (comparé au ST815 qui va que jusqu'à 3000 lux) Par contre, usage intérieur... je l'ai quand même mis dehors pour vois comment il se comporte... après vu le prix... Pas d'options de paramétrage, c'est très rudimentaire. Le changement de valeur met quelques secondes à remonter... Petite erreur, dans l'API, son unité de mesure est en % au lieu d'être en LUX (pourtant "LX" apparait dans l'interface web, alors d'où il sort ça ... ???) Corrigé avec un api.put(). EDIT : ah ben nan, c'est marrant, le "%" reviennent systématiquement dans l'API... Les remontés dans l'API RefreshState() sont nickel, comme un module Zwave ! Plutôt satisfaisant pour un premier contact

oui moi aussi, ça m'a rendu fou, j'ai désactivé toutes les notifications de tous les device à batterie. Et je me suis fait un petit QA qui tourne 2x par jour pour vérifier l'état. Avec compte rendu par mail.