Lazer

Pense à utiliser pcall() quand tu utilises http:request() comme je l'ai expliqué dans le tuto. D'une part, ça t'aidera à comprendre l'erreur, et d'autre part ça rendra ton code plus stable, particulièrement dans les scènes qui semblent assez instable par nature... cf discussion récente sur un autre topic.

Les caméras oui sont en 100 Mbps, tout comme la HC3 et beaucoup d'appareils "légers". Ça coûte moins cher, ça consomme moins, et ça reste plus performant en pratique que du Wi-Fi, donc faut pas s'inquiéter c'est normal.

Désolé, pas le temps d'écrire le code LUA des autres... Je passe déjà beaucoup de temps à aider, et à écrire mes propres QA que je partage. Il y a déjà de nombreux QuickApp sur le forum, tu trouveras facilement des exemples pour t'inspirer. Et n'oublie pas que lors de la création d'un nouveau QA, tu as déjà un squelette proposé par Fibaro. Et bien sûr la doc officielle, même si elle n'est pas du tout didactique : https://manuals.fibaro.com/home-center-3-quick-apps/

Oui, mais pas forcément. Je veux dire, faire un polling ininterrompu de la valeur en interrogeant l'appareil ce n'est pas forcément super optimisé non plus, ça consomme des ressources (CPU RAM Réseau) pour rien en fin de compte. Moins grave que de faire des écritures inutiles sur un disque/SSD, mais pas optimal non plus. Si tu veux garder la logique de fonctionnement de ton installation, tu pourrais, dans ton script Python, commencer par vérifier la valeur du module, la comparer, et seulement si elle est différence, envoyer la nouvelle valeur vers la HC3. Ainsi tu appliques la logique de ce que j'ai décrit il y a 2 messages précédemment, sauf qu'au lieu que ça soit un QA qui l'effectue, c'est ton script Python externe. Mais encore une fois, c'est strictement identique, les 2 méthodes exploitent la même API. D'ailleurs j'ai un cas similaire, j'ai FHEM qui tourne dans une VM pour exploiter mes quelques devices EnOcean. Au départ je voulais écrire un QA qui fait un polling régulier, puis je me suis rendu compte que c'était inutile, et que le push effectué par FHEM suffit bien. Ce n'est pas du Python mais du Perl, mais la logique est la même. Pour l'instant je fais un update systématique du device, c'est temporaire car je n'ai pas eu le temps de faire mieux pendant ma migration vers la HC3, mais je vais changer cela : essayer de modifier les lignes perl pour faire un test avant de modifier. Précision : j'ai associé chaque sonde EnOcean à un QA. J'ai donc plusieurs QA, et chacun contient exactement 0 ligne de code, fichier main totalement vide. Difficile de faire plus simple En somme, c'est comme les "Fake Devices" sur HC2, sauf que là c'est propre, chaque QA est un vrai module autonome.

"transparante", presque, car c'est quand même à ton QA de changer ses propres proriétés (le champ value principalement). Mais rien que modifier ce champ value, par exemple true/false si c'est du type binary, ou 0-99 si multilevel, alors c'est la box qui va adapter l’icône en conséquence et le visuel du module. Alors les enfants justement, pour moi c'est tout indiqué dans ton QA. Justement, tu parles de piscine, avec des FGS (donc "binary switch") des capteurs (donc "temperature semsor"), etc Et je me rend compte que tu n'as pas compris la philosophie des QA, tu raisonnes encore sous forme de VD. Ton QA Generic ou Device Controller ne doit contenir sur des choses qui ne peuvent pas figurer dans un QA typé. Du coup, tu devrais avoir un QA parent (Device controller) qui n'affiche rien, si ce n'est un bouton pour créer ses enfants. Une fois fait, tu peux le cacher dans l'interface. Du coup son icone par défaut n'a plus aucune importance. Et les enfants, seront typés chacun comme il faut, te permettant de piloter ta pompe, surveiller la température, etc. Si tu regardes mes QA GCE IPX800 & EDRT2, Surveillance Station, Netatmo, etc, ils fonctionnent sur ce principe. Une fois que le parent a créé ses enfants, il peut être caché, on n'en n'aura plus jamais besoin pour un usage quotidien de la box. Bon sauf si tu as des infos à afficher, ou boutons spécifiques à créer, auquel cas ils ne correspondent à aucun type de QA prédéfini. Dans ce cas, le QA générique garde son intérêt.

#1 Réponse 1 : choix du type lors de la création d'un QA C'est un super QA que tu nous fait là Sérieusement, j'ai aussi ce type de QA, notamment un qui s'appelle "Gestion Maison" et effectue des actions globales : éteindre toutes les lumières, baisser le chauffage, passer la maison en mode vacances, etc. Du coup, aucun des types "simples" ne lui convient (ou plus exactement, aucun des type correspondant à des modules Z-Wave) Dans ce cas, le type "Generic device" est tout indiqué. Ou bien "Device Conroller" s'il aura des enfants (d'ailleurs les enfants peuvent être typés avec un type utile : temperature, etc). En fait ça revient à faire un QA avec une certaine similitude à ce qu'étaient les Virtual Devices sur HC2. Les types Generic et Device Controller n'auront pas d'action associé au clic sur leur icône, ils n'afficheront rien sous leur icône. Il faut les ouvrir (pour afficher leur vue et accéder aux boutons sliders et labels) Par ailleurs, aussi étrange que cela puisse paraitre, on ne peut pas (encore ?) changer leur icône... sauf à utiliser le hack assez simple déjà partagé plusieurs fois sur le forum. Rappel : évidemment, autant que possible, il faut utiliser un des types qui correspond à un module Z-Wave (lumière, température, etc) afin de respecter la logique Fibaro, et surtout en bénéficier : à l'usage un QA correctement typé s'utilise exactement de la même façon qu'un module Z-Wave dans la box ou sur l'application mobile. Très pratique. Dernier point : une fois affecté, un module ne peut pas changer de type. Astuce de contournement : il faut exporter le QA, modifier son type à la main avec un éditeur de texte dans le JSON, puis le réimporter.

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.