Lazer

Je rebondis juste là dessus. A un moment donné, le serveur Web en face, c'est à dire le processus HCServer dans la HC3 qui expose l'API HTTP REST, n'a pas répondu dans le temps imparti. Pour une raison ou un autre (saturation en écriture à cause du tampon plein, bug quelconque, etc) Ton application reçoit cette erreur, tu la traites, et tu poursuis l'exécution. Et bien c'est exactement le même principe pour tous nos codes LUA qui tournent dans la box. Je rappelle encore une fois que toutes les interactions avec la box passent par cette même API. Donc les fameux api.get(), mais aussi les fibaro.getValue ou bien encore fibaro.call() qui toutes appellent en backend api.get()... ou api.post() api.put() api.delete() mais c'est pareil. Et justement, je reviens sur la boucle toute simple de @ROBBEJP qui a crashé, il se trouve qu'elle effectue justement des appels à cet API par le biais de fibaro.call() En interne, l'exécution du code LUA des fonctions mises à notre dispositions par Fibaro ne sont pas protégées. Donc l'erreur remonte jusqu'à notre code LUA, qui le fait crasher, bien que ça ne soit pas de la faute des lignes qu'on a écrit. D'où ma suggestion de protéger le code par pcall(). Dès qu'on a un doute, un bout de code qui a tendance à planter, il faut avoir ce réflexe d'utiliser pcall(), cela permet d'attraper l'erreur, de la traiter, et de poursuivre l'exécution sans crasher l'application (la scène ou le quickapp). (attention aux fonctions asynchrones, qui ne sont pas protégés par la fonction pcall précédente... voire mon tuto) Reste à savoir pourquoi les scènes sont plus susceptibles de planter que les QuickApps, ça on ne saura pas, ça se passe dans le code compilé par Fibaro. J'imagine qu'il y a un certain niveau de mécanismes de protections dans les QuickApps, que Fibaro n'a pas (encore ?) implémenté dans les scènes. Mais clairement, sur la HC3, l'accent a été mis dès le départ sur les QuickApps, donc ne perdez pas trop de temps sur les scènes. Comme je l'avais déjà dit, à mon avis les scènes sur HC3 doivent être réservées à des scénarios basiques : un événements (trigger) => une action immédiate. En mode bloc (si on débute) ou code LUA, cela revient au même en fin de compte. C'est bien comme cela que Fibaro a pensé l'usage des scènes.

Sans certitude.... Je ne pense pas que ton application externe cause plus de bugs que n'importe quel autre action. Je veux dire, attaquer l'API depuis la box elle-même (code LUA dans un QA/Scène, module Z-Wave qui envoie son état), ou bien depuis une appli externe, dans tous les cas, ça passe par l'API HTTP, et après le chemin vers la base de données est le même. Donc tous ces événements suivent le même chemin et produisent le même résultat. En revanche, on a constaté depuis un petit moment déjà que trop d'écritures répétées finissent par saturer le tampon d'écriture, ce qui a pour tendance à figer la box (on le constate par l'interface Web qui ne répond plus). La HC2 avait déjà ce comportement depuis la v4. Depuis cette époque, j'avais pris pour habitude de limiter les écritures.... ou plutôt, d'écrire intelligemment. C'est à dire, ne pas demander à la box d'enregistrer une valeur qui est identique à la précédente. C'est pour ça que dans la très grande majorité de mes codes LUA, je commence toujours par vérifier la valeur existante (fibaro.getValue ou getGlobalVariable) avant de la comparer à la nouvelle, et ensuite, seulement si elle est différence, de demander l'écriture de la nouvelle. De cette façon, je limite au maximum les écriture inutile. Plusieurs avantages : - évite la saturation du tampon donc le figeage de la box - améliore les performances : j'avais fait un benchmark, je n'est plus les chiffres en têtes (et ça varie selon les optimisations de firmwares par Fibaro), mais dans l'idée : une écriture c'est 20 fois plus lent qu'une lecture. Si je vérifier ma valeur chaque minute, mais qu'en réalité elle ne change qu'une fois par heure, au final j'aurai un gain de performance = 60/20 = 3. - limite l'usure de la mémoire Flash Je ne sais pas si tout cela est réellement utile, mais j'ai envie de croire que oui, car d'une part c'est logique, et d'autre part malgré le grand nombre de VD/QA que j'ai eu, mes box ont toujours été relativement stables. Plus stable que les box de plusieurs forumeurs qui viennent se plaindre ici, et la différence c'est nos codes LUA. Dans ton cas, pendant que la box reboot, il est évident que tu vas avoir des erreurs sur l'API. C'est une conséquence normale. Par ailleurs si toutes les minutes tu écris 15 nouvelles valeurs, à mon avis ça ne va pas. Ta seconde d'intervalle n'y change pas grand chose. Dans ton script Python, tu devrais tenter de lire la valeur avant de la modifier, comme décrit précédemment.

Prochaine mise à jour en approche : https://forum.fibaro.com/topic/50641-features-postponed-after-2020/?do=findComment&comment=232246 5.080 In the next upcoming updates, which will be released as 5.080 we will give The first two features are for testing : We will start an early access program for users to test the new Z-wave engine (This is the latest z-wave engine using all new features offered by Z-wave Alliance - it is a certified engine) (S2, firmware update from file etc) We will launch Early Access program for Elero device support. From the functionalities that the customer will benefit from we should mention: Gateway connection; HC3 with HC3, Yubii or HC3L Energy panel Support for green energy - photovoltaics Of course, in addition to this there will be smaller novelties, a lot of optimizations and corrected problems. Le nouveau moteur Z-Wave, ça fait un moment qu'ils en parlent, visiblement ça sera en mode "test", méfiance donc. Par contre j'adore la mise à jour des firmware depuis des fichiers, si j’interprète bien on pourra mettre à jour les firmwares Aeotec sans devoir les exclure et faire l'opération avec une clé dédiée. Top ça, la HC3 deviendrait vraiment la box Z-Wave ultime

Tu devrais lire ce topic sur le forum officiel, c'est très instructif, et je pense que tu as exactement le même problème : https://forum.fibaro.com/topic/54552-scenes-crashes-without-an-error-message En synthèse, le setTimeout (ou sleep) n'a rien à voir dans l'affaire, c'est juste que l'erreur redescend jusque là. Le bug se situe plus loin, dans la partie à laquelle nous n'avons pas accès. Difficile à situer précisément, mais il semble que toutes les pistes convergent vers les requêtes sur l'API de la box elle-même (puisque tout ce qu'on fait en LUA attaque l'API à un moment ou à un autre) Et il semble bien ne concerner que les scènes, pas les QuickApps. Perso comme je n'utilise plus les scènes (j'en ai seulement 2, qui se déclenchent ponctuellement et ne tournent pas en boucle, ça ne leur laisse pas le temps de planter). En revanche j'utilise massivement les QuickApps, et c'est vraiment ultra stable (pour peu que ça soit bien codé, donc la responsabilité nous incombe) Laisse tomber le support, ils sont complètement à coté de la plaque. Ils ne savent répondre que des banalités, alors ça aide bien le débutant ou les box crashées, mais ils ont incapables d'aider les développeurs. Et d'ailleurs c'est très bien ton câble RJ45, il ne faut pas utiliser le Wi-Fi. Bref, résolvons tes problèmes : arrêter d'utiliser les scènes, je l'ai déjà dit plusieurs fois sur le forum, la philosophie depuis la HC2 a changé. Avec la HC3 il faut mettre nos efforts de développement sur les QuickApps, qui permettent de faire tout ce que font les scènes, et bien plus... et en prime c'est plus stable ! que ça soit dans une scène ou un QuickApp, il faut utiliser pcall() pour protéger l'exécution d'un code, dès qu'on a un doute sur son bon/mauvais fonctionnement : QuickApp : fonctions http:request(), tcp:send(), tcp:receive() et les classiques json.encode() et json.decode() (comme sur HC2) Scènes : visiblement le code complet.... Et oui, la migration de la HC2 vers la HC3 est un process très lourd, il faut tout reprendre, ce n'est pas pour rien que j'ai mis exactement 1 an à le faire. Bon il faut dire que j'ai pas mal de codes LUA dans tous les sens, d'interdépendance entre tous les éléments de la maison, etc. C'est vraiment pas l'exclusion/inclusion des modules qui est longue dans l'histoire, ça ne m'a pris que quelques heures (réparties sur 1 semaine, j'ai fait ça en douceur). Mais le codage des QuickApps, ça c'était long.

Avec le Z-Wave, c'est bien le but de piloter à distance, oui Je comprends bien qu'il ne faut pas dépasser 28°C, mais du coup je ne sais pas si les thermostats domotiques savent le gérer correctement. Comme dit, regarder les marques que je t'ai cité. Sinon Qubino aussi, ils font des micro-modules spécial thermostat. En revanche, c'est du micro-module, donc pas prévu pour être affiché au mur, mais plutôt caché. Si tu as un schéma électrique de ton installation, je pense que ça facilitera la compréhension. PS : je suis au chauffage électrique (enfin, je veux dire des radiateurs), du coup je n'ai aucune expérience concrète des planchers chauffants.

Ah bien ça Est-ce que tu pourrais faire la variante avec les 2 battants ouverts, afin que ça soit encore plus visible ? (je trouve les icônes de la nouvelle application trop petites, du coup c'est moins visible que sur HC2)

Euh... mais pourquoi se prendre la tête ? Il te suffit l'aller récupérer directement la value du device associé au capteur de pluie (plugin Netatmo). C'est ce que je fais depuis des années sur HC2, et ça marche pareil après passage sur HC3. GEA.add({"Value+", id["PLUIE"], 0}, 0, "Il pleut")

Tu veux prendre en compte l'information de la sonde située DANS la plancher chauffant ? Dans ce qu'il te faut, c'est un thermostat mural Z-Wave qui gère cela. Regarde chez Heat-It (Thermoflor) ils font surement cela. Ou bien Secure, mais je pense que leurs thermostats ne savent gérer que leur propre sonde d'ambiance interne (donc DANS l'air de la pièce)

Bienvenue sur le forum

C'est pareil. fibaro.getValue() simplifie l'écriture, mais cette fonction appelle elle-même api.get() Donc tu choisis celui qui te plait le plus.

Tant mieux

J'ai eu un reboot, il y a 1 an, (avec un vieux firmware donc), et c'était clairement à cause de l'un de mes QuickApps qui faisait n'importe quoi. C'est à ce moment là que j'avais constaté le reboot. Depuis plusieurs jours, j'ai basculé toute ma production sur la HC3, et je dois dire que ça fonctionne très bien, malgré les nombreux QuickApps qui tournent. Après, 15 jours, c'est un nombre que je n'atteindrai jamais, vu que j'ai un backup auto chaque week-end (et tous les services sont automatiquement redémarrés)

OK, donc ça doit correspondre à la version 5.1. Il y a un endroit bien précis où tu peux faire la mise à jour : avec une box Fibaro. Et c'est tout. Comme tu le sais déjà, Fibaro ne partage pas ses firmwares.

Bah du coup je préfère ton retour d'expérience, car tu as montré que ça fonctionne depuis plusieurs mois, et les spécifications techniques annoncées sur la page de domotique-store sont OK, et même mieux que l'alimentation d'origine. Du coup c'est leur remarque que je ne comprends pas.

C'est quand même indiqué incompatible avec la HC2, car elle consomme trop. Pourtant 12V 2A max. (24W max.) c'est bon, et même mieux que l'alimentation d'origine si on en croit le relevé effectué par Gorn sur sa propre alim (cramée !)

Moi aussi je travaille dans l'ingénierie, j'aime bien creuser les choses pour comprendre et faire un choix judicieux. Et le choix le plus judicieux, c'est souvent le plus simple. Qui dit plus simple, dit plus fiable, plus robuste, plus simple à maintenir, à faire évoluer, etc. KISS = Keep It Simple & Stupid comme on dit. Parce que les usines à gaz, comment dire.... Et justement, je profite de ma migration HC3 en cours pour revoir pas mal de trucs complexes que j'avais fait en domotique à l'époque, faute de produits existants à ce moment là. Donc un exemple : je vais virer un Raspberry PI, qui sera avantageusement remplacé par un Eco Device RT2. C'est plus cher oui, mais ça sera plus simple, plus fiable et facile à maintenir dans le temps. J'ai encore du EnOcean qui traine, et pour l'instant je l'ai conservé car ça a été migré en 10 minutes, mais à terme je vais le virer et remplacer les quelques modules par du Z-Wave. Là encore, ça sera plus simple et plus fiable. Sinon oui les contacteurs c'est cher, c'est clair. Mais la qualité reste, le prix s'oublie

Je n'ai pas l'impression que ça soit des informations correspondant à la version du firmware. Sur ta Lifedomus, tu utilises la clé Aeotec ? Il faudrait la brancher sur un PC, et avec le logiciel Z-Wave PC Controller de Silicon Labs tu peux interroger le module pour connaitre toutes ses informations, dont le numéro de version.

je n'ai pas de retour d'état réel, mais j'ai un retour d'état théorique. En effet, tout l'intérêt d'utiliser un contacteur c'est qu'il "copie" la commande. Donc si le relai du l'IPX (FGS) est fermé, alors le relai du contacteur est fermé. Et inversement s'il est ouvert. Obligatoirement, par principe de construction. Même après une coupure de courant. Et c'est très fiable. (en complément, j'ai aussi une pince ampéremétrique sur la phase qui part vers la lampe, donc j'ai un vrai retour d'état de consommation électrique) Ton test du télérupteur semblait montrer que le télérupteur conserve son état après un coupure de courant, donc ça marche aussi, mais il faut également que le FGS/IPX garde lui aussi son état pour que ça fonctionne. Et là c'est plus difficile, je pense, car puisque tu pilotes un télérupteur, le relai de commande se ferme puis se réouvre quelques millisecondes plus tard. Ce n'est donc pas l'état du relai qu'il faut conservé, mais l'état de la charge (stocké où ça... dans la box domotique ?) Bref, les télérupteurs en domotiques, c'est la plaie. Perso je les ai tous virés de mon installation, puisque les modules domotiques jouent déjà pleinement ce rôle. Et j'ajoute les contacteurs dans les cas de puissance / appel de courant important. Le fonctionnement d'un contacteur est tellement basique qu'il n'y a pas à réfléchir, tu branches, et tu n'as plus à y penser, il copiera l'état du relai de commande domotique quoi qu'il arrive. Tu te fais des nœuds au cerveau pour rien, ce sont les télérupteurs qui sont compliqués, pas les contacteurs. Ou comment apprendre à oublier ce qu'on sait déjà pour repartir sur des bases propres PS : avant la domotique, j'avais même des modules DIN "télévariateur", des trucs super sophistiqués du 20ème siècle qui permettent de faire varier la lumière par un appui long sur n'importe lequel des boutons poussoirs de la pièce. Exactement ce qu'on fait avec un Dimmer FGD tout simple.... pour un volume 10 fois moindre. Et moins cher en plus !

Non, là encore tu mélanges les circuits de puissance et les circuits de commande Le contacteur de puissance n'alimente pas le FGS. Voici le schéma correspondant à la photo présentée précédemment (enfin presque, le disjoncteur n'apparaissait pas sur la photo, et en réalité chaque circuit de lumière est sur 1 disjoncteur différent. Sécurité maximale... mais j'ai simplifié le schéma en ne représentant qu'un seul disjoncteur) (et puis les néons ont été remplacés par les rubans LED + alimentation, de toute façon l’icône de la lampe ne correspond pas) Il te suffit de remplacer les borniers de l'IPX800 par le contact sec du FGS, c'est exactement pareil. L'IPX800 prend son alimentation sur un circuit séparé (protégé par un disjoncteur de faible puissance), mais dans le cas du ton FGS, tu peux prendre son alimentation sur le disjoncteur qui alimente le contacteur et la lampe. Pour reprendre ta formulation, on pourrait écrire : le disjoncteur alimente : le contacteur de puissance qui lui-même alimente les LED le FGS (ou IPX) qui lui pilote le conctacteur Et pour faire un câblage dans les règles de l'art, car on a 2 circuits (puissance et pilotage), alors on devrait avoir 2 disjoncteur séparés : un de 16 A pour le circuit de puissance un de 2 A pour le circuit de pilotage D'ailleurs, le contacteur devrait être alimenté comme le FGS, sur le circuit de contrôle. ça parait bien compliqué tout ça, mais en fait c'est exactement le principe du contacteur de puissance du chauffe-eau qu'on utilise depuis des lustres, rien de nouveau.

Effectivement, le mail stipule bien que la tentative d'accès se fait bien sur le site de Fibaro, et non pas sur ta box. Est-ce que tu n'aurais pas un Google Home, Alexa, ou autre service qui tenterait de s'y connecter ?

Ta box n'affiche pas cette information ? Mais ce qui est certain, c'est que tu ne pourras pas le mettre à jour sans box Fibaro. Pour info les versions connues à ce jour du Smart Implant FGBS-222 : 5.2 DS18B20 temperature sensor support has been improvements to make it more reliable, especially in long wiring cases. Optimized input/output behavior after power reset. Other minor improvements. Support for version 5.2 devices is available from 4.601 Beta for HC2/HCL. 5.1 Initial release 

Meanwell c'est top. Mais c'est "brut", sans connecteur DC, donc il faut acheter les connecteurs séparément, souder, mettre de la gaine thermo.... à voir si tu es bricoleur. Sinon n'importe quelle alimentation 12V et suffisamment puissante (la HC2 consomme 14W, donc je dirais que l'alim doit faire au moins 20 voire 30 Watts pour le démarrage. En fait je ne souviens plus, regarde la puissance de l'alim d'origine c'est encore le mieux. De toute façon l'alimentation d'origine de la HC2 c'est du générique chinois standard à pas cher, typiquement le genre de produit que tu trouveras sur Amazon. Souvent vendues pour alimenter des rubans LED d'ailleurs...

Je n'ai aucune idée de la tension d'un chargeur de voiture... Regarde ici, tu as les 2 références de carte mère connues pour la HC2, avec des liens vers les docs. Tu y trouveras les brochages, et les tenions inadmissibles, qui sont plus large que juste 12V.

Sans le bandeau de LED, la carte mère devrait au moins démarrer, et avec un clavier USB branché dessus tu devrais pouvoir accéder au BIOS.... enfin, si tu as un affichage avant le plantage !

Attention, si tu mesures l'alimentation à vide, ça ne veut rien dire. Il faut mesurer sa tension en charge, ce qui est difficile avec le connecteur branché.... Si la tension s'effondre avec la box allumée, c'est qu'elle est morte. Je te conseillerais quand même de tester une autre alimentation.