jojo

pour la config auto des modules sur batterie, voici comment je l'interpraite : quand tu fais une reconfig générale de tous les modules, il va soit la pousser uniquement sur les non-batterie ou également sur les batterie, qui devront soit être réveillés manuellemet, ou soit recevront la nouvelle config àleur prochain réveil

ce qui est fait est fait, ceci dit tu peux toujours l'échanger dans les15j relais virtuel : imagine que tu dois prendre une action dans une scène en fonction d'un status 0 ou 1. Plutôt que de créer une variable avec les 2 valeurs (et donc faire le test sur la valeur de la variable) tu peux tester en fonction du second relais (on ou off, qui a été modifié suite àune autre scène) . Chez Fibaro, en mode bloc, on peut facilement faire une scène qui inverse le status, et ça c'est beaucoup plus facile avec un module "virtuel" qu'avec une variable

Manu, Si je puis me permettre, je commanderais les fgs222 au lieu de fgs212 : ils sont au même prix avec 2x1500 W, tu as plus qu'assez même si tu n'utilise qu'un seul des deux relais, tu en as un deuxième, que tu pourras peut-être utiliser demain, ou dans un scène l'utilisé comme relais "virtuel".

je confirme que ce code est dans la main loop, même si l'entête a été copié (pour rien) d'une scène, car HC2:POST ne fonctionne pas dans une scène

ok, c'est normal qu'il reboot la box si ce code est dans le main loop, car le main loop s'exécute toutes les 3s

dans ton code, je vois une entête de scène avec un autostart, ie démarrage automatique de la scène au démarrage de la box. Je n'ai pas encore lu plus loin, mais es-tu sà»r que c'est un VD et pas une scène en mode LUA ? Car alors, c''est tout à fait logique que ta box reboot en continu .. ce n'est pas un bug

avec un FGS-221 tu pourras commander ta porte comme dit par Did. regarde dans ma signature ce que j'ai fais en utilisant un FGBS pour savoir le status de la porte (Ouvert/Fermé/partiellement fermé). Cette dernière information est utile pour moi, car elle peut signifier qu'il a quelque chose dans le chemin, qui empêche la forte de se fermer correctement. J'utilise également se status pour refermer automatiquement la porte, si on l'a oubliée, et que l'alarme est mise.

si tu ouvres le 22, que tu es chez toi, et seulement durant l'intervention, le risque me semble limité. Que ça se passe bien

oui, mais làil ne risque de pas y avoir beaucoup de femme. Pas trop pour moi alors ... Les quelques femmes du forum, qu'en pensez-vous ?

perso, pour éviter ce genre de soucis familial, je suis resté longtemps en 3.600 et ait suivi les péripéties des autres geek. J'ai donc fait l'upgrade vers 4.042 lorsque j'ai lu que globalement cela faisait un certain temps que tout allait bien. Et maintenant tout va bien en 4.042, et je n'ai donc pas de besoin de faire un ugrade. Il ne faut faire des upgrades que quand : il y a une nouvelle fonctionnalité qui t'intéresse dans la nouvelle version ET qu'elle a été validé par d'autres avant, sans aucune mention d'un bug concernant une fonctionnalité qui est importante Le risque est ainsi beaucoup plus limité

oui, en tant qu'expert Fibaro, je confirme que l'erreur 503 est liée àune défectuosité du bouton on/off OU du bouton recovery (une analyse plus approfondie dans nos laboratoires est nécessaire), mais je confirme avec certitude que cela n'a rien àvoir avec un problème software, stype db sql ou firmare

je viens de voir pourquoi j'avais le problème. Dans le VD, la longueur de la variable qui est affichée en DEBUG est limitée. Dans une scène il n'y a pas de limite. Et Steven a proposé une scène. Mais moi j'avais pris la version pour 3.6 (j'étais en 3.6 àl'époque) qui est une version VD. Et donc en v4.x, comme il y a beaucoup plus d'id, cela explosait.

Pour ceux qui préfèrent le debug des scènes, j'ai créé une version scène du bouton backup (et qui évite de devoir supprimer les lignes [DEBUG] de la table ConfigHP)

Pour ceux qui préfèrent le debug des scènes, j'ai créé une version scène du bouton backup

j'ai publié une v1.1 avec une optimisation du code du bouton backup grâce àSteven. Aucun changement de fonctionnalité.

si elle est toujours sous garantie, ils n'auraient pas àdiscuter. C'est àeux àprouver, que si c'est le bouton qui est mort, que c'est suite àune mauvaise utilisation

@mprnfo, tu confirmes : ils n'ont AUCUNE politique de test sérieuse. Exple : on sort la 4.046 vendredi, puis la 4.047 samedi. Qui a testé ??????????? Impossible àfaire

si on regarde l'aspect positif de la chose : ils ont trouvé le bug et l'ont corrigési on est réaliste : je développe -> je fais quelques PETITS tests -> je mets en prod aucun plan de test sérieux, ce qui conduit à ces situations c'est à pleurer

le fait que tu fasses play et que ta scène démarre, confirme que le code de la scène est ok les triggers de la scène sont morts. En effet, le play by-passe les trigger

et alors PITP2, comme ton bouton est HS, ils te proposent de remplacer la box sous garantie ?

perso, si tu n'as pas de soucis en 4.042, reste en 4.042, sinon passe en 4.047

et pourtant, j'explique à Mme que grâce à ma domotique elle peut avoir de l'eau chaude pour sa douche à 11h30, alors qu'avant c'était douche froide, mais dès qu'il y a quelque chose qui "foire" (= il faut rééteindre une lumière manuellement (comme avant) alors qu'elle devrait s'éteindre en auto, j'en ai encore mal aux oreilles)

vous êtes tous les 3 des grands malades, je fais des gros efforts pour essayer de vous suivre, mais là je ne peut plus .

j'ai également déjà entendu ça quelque part ... la domotique c'est donc impossible qu'elle soit WAF ?

non, mais pour l'afficher en permanent, je d'explique l'astuce que Lazer m'a donnée en son temps : comme le dit également clarkkent, avec une boucle qui tourne toutes les 9s, sauf si c'est dans ton main loop qui tourne toutes les 3 sec (alors pas nécessaire SI pas de sleep)