Lazer

Les devices sont ajoutés chez nuit après minuit. Tu peux les forcer immédiatement en cliquant sur le bouton Devices du module virtuel. Ensuite ça devrait être bon.

Oui en effet, espérons que ça se passe bien alors.

Débrouille toi pour installer ces modules le plus proche possible afin qu'ils soient en vision directe par la HC3, et tu n'auras pas de problème. Les bugs rencontrés semblent apparaitre quand ces vieux modules passent par au moins 1 saut de routage. Sinon il faut attendre le moteur v3, mais il est très loin d'être stable, donc fortement déconseillé pour l'instant. D'ailleurs fait bien attention lors de l'install de ton HC3, à bien sélectionner le moteur v2.

Possible, je n'utilise le swagger que pour consulter la syntaxe, je ne réalise jamais les requêtes avec. Je fais mes requêtes avec curl directement (depuis une VM Linux, par habitude puisque maintenant c'est en natif dans Windows), ou bien directement dans le navigateur, ou en LUA...

OK d'accord. Alors energy + power sont donc 2 prérequis pour voir virtualEnergyConsumption Donc si je rectifie ce que j'ai écris, ça donne : La propriété energy peut être mise à jour manuellement (par lecture de la valeur d'un compteur électrique, d'un onduleur, etc), ou bien calculée par la HC3 grâce à l'ajout de l'interface virtualEnergyConsumption Pour l'API, essaye avec un s à la fin : "addInterfaces"

Je dirais que c'est normal, d'après ma compréhension de la logique Fibaro, un module peut avoir soit l'interface energy, soit virtualEnergyConsumption, mais pas les deux. - energy : l'énergie est mise à jour manuellement (par lecture de la valeur d'un compteur électrique, d'un onduleur, etc) - virtualEnergyConsumption : justement là on n'a aucun moyen de connaitre l'énergie, donc on laisse la HC3 le calculer (ça n'est possible que si on met à jour la propriété power (ce qui implique que le module doive impérativement posséder l'interface power)

Pour ajouter une interface, tu ne peux pas le faire injectant un paramètre dans le JSON d'un module. Car il ne s'agit pas que d'ajouter un nouvel élément à la table interfaces du module, cela va également créer des nouvelles propriétés dans le module, qui dépendent de l'interface ajoutée. => il faut appeler la méthode addInterfaces du QuickApp (avec l'ID du parent ou d'un enfant, peu importe ça fonctionne pour les 2) Tu peux regarder comment je fais en LUA dans ma librairie tools que tu trouveras dans tous mes QuickApps du forum. Ou alors directement via une méthode GET en passant par callAction : /api/callAction?deviceID=123&name=addInterfaces&arg1=%5B%22power%22%5D /api/callAction?deviceID=123&name=addInterfaces&arg1=%5B%22virtualEnergyConsumption%22%5D Remarque de fond sur la gestion de modules : Je n'aime pas la technique consistant à créer autant d'enfants que d'informations à remonter. Ex : un enfant de type binarySwitch, un autre de type powerMeter, un autre de type energyMeter, et un autre de type battery... ça surcharge l'interface, et remplie la DB de nombreux modules inutiles. Je préfère sélectionner soigneusement le type de mon module (par exemple binarySwitch), et lui ajouter les interfaces nécessaires, donc dans cet exemple : power, energy (ou virtualEnergyConsumption), et battery => On a 1 seul module dans l'interface, c'est propre, concis, et toutes les informations utiles sont bien présentes. Fibaro a inventé ce concept d'interface sur la HC2, il nous permet depuis la HC3 de l'appliquer aux QuickApps, autant en profiter.

Oui ça c'est normal. Relis bien mon message, ce n'est pas ce que je demandais => Soit mettre le power sur un child existant d'un autre type, soit ajouter virtualEnergyConsumption sur ce child de type powerSensor

J'ai l'impression que c'est une limitation actuelle de la box... je n'ai pas non plus cette option sur les powerSensors, alors que je l'ai que les autres types de modules (sur ma capture d'écran d'hier, c'était un binary switch, à laquelle j'ai ajouté l'interface "power") Barelle, plutôt que de créer un child dédié pour la mesure de puissance, est-ce que tu ne pourrais pas l'ajouter en tant qu'interface power sur un module existant (parent ou enfant) ? Si le type est différent, je pense que la HC3 laissera l'utilisateur activer l'option virtualenergyconsumtion. Autre piste, forcer l'ajout du virtualEnergyConsumption via l'API sur le child en question, je pense que ça peut marcher (auquel car ça serait juste une limitation de la page Web, mais pas de la box, ce ne serait pas la 1ère fois que Fibaro nous fait le coup)

Voilà une capture d'écran : Barelle ne pourra pas cliquer à ta place

Oui j'ai vu, super prix, mais y'a un doute sur le fait qu'il soit neuf ou reconditionné....

Les modules qui remontent une puissance (power, en Watts) ne sont pas gérés par le panneau d'énergie. Comme son nom l'indique justement, il ne présente que les données issues des capteurs qui remontent une énergie (energy, en kWh) Ce que tu peux faire à partir d'un module qui remonte la puissance, c'est d'activer l'option virtualEnergyConsumption, il y a une case à cocher pour cela dans les propriétés du module. La box va automatiquement calculer l'énergie en kWh à partir de la consommation instantanée en W, et donc le module devrait être géré par le panneau d'énergie.

Ah oui pas bête la DHT22, j'oublie toujours que le nouveau Smart Implant est compatible.

Entre la fiabilité toute relative du capteur de température intégré, le fait qu'il soit situé sur la fenêtre (donc élément froid), et en hauteur (donc au dessus de la tête), et le fait que ça soit un module sur batterie donc pas adapté à remonter la température chaque minute, il est clair que ce type de module ne peut pas être utilisé pour de la gestion de chauffage. Ces capteurs de températures intégrés aux modules domotiques (FGK, FGMS, FGSD, etc), c'est du gadget plus argument commercial que réellement utile. A la limite ça donne une indication de l'ambiance générale de la pièce, mais c'est insuffisant pour gérer du chauffage. Le mieux ça reste la sonde Dallas (une originale, pas une clone chinoise) branchée sur un FGBS Smart Implant, ça c'est ultra fiable et précis. Le souci évidemment, c'est d'amener une alimentation électrique.

@jjacques68 hum.... c'est moche Quick & Dirty comme ils disent .... ça marche, et puis un jour ça ne marchera plus

Donc tu as tout réécris ? Tu est bien motivé...

Ah, changement de comportement constaté lors de l'utilisation de net.httpClient() Lorsqu'on appelle http:request(), si l'hôte distant est joignable, la fonction success() est appelée, avec les entêtes et les données dans la variable response, qui est une table : httpClient:request(url, { success = function(response) print(response.status) --> Exemple : 404 print(response.data) --> Exemple : "" end, error = function(message) end, }) Quand le code retour est 404 (page non trouvée), la variable response.status contient bien le code 404, comme avant. En revanche, dans ce cas précis, le variable response.data est une chaine vide, même si l'hôte distant a retourné quelque chose (car plusieurs serveurs Web affichent un message personnalisé pour avertir l'utilisateur que le page demandée n'existe pas). Précédemment, response.data contenait cette page, ce n'est plus le cas maintenant. QuickApp affecté : Network Monitor Fibaro a dû considéré que le contenu de la page n'avait pas d'importance quand le code retour est 404, c'est bien dommage....

@henri-allauch mon HC3 était stable dès le 1er jour, et plus que la HC2 qui a planté 6 fois durant sa dernière année de fonctionnement en production (redémarré automatiquement par mon watchdog sur NAS). Durant les 6 mois suivants, ou j'ai laissé tourné la HC2, mais sans aucun module Z-Wave, celle-ci n'a pas craché une seule fois => ma conclusion, le nombre de modules Z-Wave important faisait planter ma HC2... bon il faut dire qu'elle n'a jamais subit de recovery, donc elle fonctionnant dans son jus, avec la base de données d'origine en v3 migrée en v4. Pas si mal en fin de compte. @mprinfo : tous mes QA sont taggués, aucun souci.

Ah OK, oui le QA Surveillance Station, mais en fait il fonctionnait avec une mise à jour vers la 5.100. Ce qui ne fonctionnait pas, c'était uniquement la création de nouveaux enfants, donc typiquement quand on fait une nouvelle installation avec une box neuve, ...... ou alors un recovery chaque semaine

J'ai modifié des QA, mais ce n'était pas une condition nécessaire pour cette mise à jour. Ce qui m'a retenu tout ce temps, c'était les instabilités (reboot, serious problem detected, ...), qui semblent avoir été résolues avec cette mise à jour. Car la 5.070 était vraiment très stable. Seul problème non bloquant, des freeze de temps en temps... on verra si ceux-là sont toujours présents avec la 5.100 ou non.

Et voilà, je viens de faire la mise à jour sur ma box de production. Un peu long... plusieurs longues minutes, mais c'est passé et tout fonctionne. Ne pas oublier le célèbre vidage de cache après la mise à jour (CTRL+F5 suffit) J'étais en 5.070, donc depuis mars 2021, soit 11 mois ! Je vais pouvoir profiter des nouveautés.... espérons que cette version 5.100 stable soit vraiment stable

Exemple, là c'est pas du Grafana, mais du PHP + JavaScript, mais c'est juste pour montrer que SQL permet de manipuler des données sur de longues périodes (ici 12 années), et les performances sont excellentes, les graphs sont générés dans la seconde : Et sous Grafana j'avais fait ça, un tableau de bord de la répartition des consommations électrique par catégorie, les données sont issues de la base SQL DomoCharts :

En réalité, InfluxDB est conçu pour l'ingestion massive de données, exactement ce qu'on fait avec la domotique. En réalité il est même plus adapté que MySQL pour cet usage. Mais je trouve que sa configuration est complexe, la manipulation des données peu aisée, enfin surtout l'aspect historisation à long terme. C'est pour cela que je préfère SQL, je connais le langage depuis des années, je fais vraiment ce que je veux de mes données, et j'ai trouvé les bonnes optimisations (clés, index, etc) pour conserver de bonnes performances même avec des millions de lignes dans la base de données. Rien que pour la Téléinformation, j'ai plus de 10 ans d'historique (depuis qu'on habite dans la maison), et ça tourne comme une horloge. Donc pas de raison de changer en ce qui me concerne. Et vu que Grafana peut aller piocher les données aussi bien dans une base SQL que InfluxDB, j'ai fait mon choix Après les beaux tableaux de bords sous Grafana, ça n'a rien à voir avec la base choisie (SQL, InfluxDB, ou autre), c'est juste de la manipulation dans Grafana. On trouve pas mal de tutos et d'aide sur Internet, il faut pas mal fouiller, car là aussi, c'est loin d'être simple de prime abord.

Ah tu vas mettre les données dans InfluxDB ? Tu vas voir, c'est assez compliqué... perso je n'ai pas aimé, on n'a pas une bonne maitrise sur la conservation des données à long terme, de ce coté là je préfère rester en SQL, que je maitrise relativement bien.

Oui ce courant de fuite suffit à alimenter le module. Mais en fait attention à ce que tu dis, il n'y a pas de relai dans le module, c'est justement pour cela que ça fonctionne. Dans un dimmer (FGD), c'est un triac, donc une sorte de transistor Cela ne peut pas fonctionner pour un relai, c'est la raison pour laquelle tous les modules avec relais (FGS chez Fibaro, ou autre marque) ont impérativement besoin du neutre. Pour en revenir eu Dimmer, oui le dimmer est obligatoire en pratique à cause des LED. Cela dit, même avec un un bypass, ça ne fonctionnera jamais aussi bien qu'avec le neutre, donc autant que possible, il faut essayer d'amener le neutre en passant une aiguille en nylon dans les gaines. Pour du ON/OFF, ça marche bien, mais quand on fait de la variation (soft start & stop, ou bien gradation partielle), c'est pas trop avec les LED. Comme je dis souvent, pour mettre toutes les chances de son coté, il faut utiliser le neutre, et des LED des gammes professionnelles des grand fabricants reconnus (Ex : Parathom Pro chez Osram/Ledvance) Avec les LED chinoises, c'est la loterie, parfois ça fonctionne bien, parfois mal...