Lazer

Attends, tu parles de quel module ? Le Orvibo ? Pour moi oui, à ce prix là c'est évident que ça passe par le cloud. N'oublie pas, quand c'est gratuit, c'est toi le produit !!

Elle doit être lue dans le champ energy du json du module (auquel cas ça confirme qu'il a conservé son historique depuis sa sortie d'usine) Du coup la conso journalière a été calculée à partir de la différence des index. Si tu regardes la toute première value de ce module dans la table domotique_energy, ça doit être non nul

Tu es sûr de ne pas t'être trompé dans le calcul des timestamps ? Dans le doute prend une plage plus large, donc un timestamps de début largement avant l'inclusion du module. Attention aussi aux timezone, en ce moment on est à GMT+1 (plus pour longtemps) Donc tu mets genre 24h avant, tu es tranquille avec ça.

Dans mon historique j'ai retrouvé que j'avais utilisé httpCanary, si ça peux t'aider. https://play.google.com/store/apps/details?id=com.guoshi.httpcanary

Ah étrange ça J'espère que ce n'est pas un bug de DomoCharts du coup, car il est censé récupérer exactement ce qu'il est retourné par l'API

Ah oui là forcément tu pars avec un handicap Bah je sais pas alors.

Oui, je me suis mal exprimé, on avait la vue de toute la maison, je trouve ça plus pratique d'avoir une vue d'ensemble. Parce qu'un dashboard avec un raccourci pour 3 modules préférés, ça n'a pas de sens, quand on a environ 200 modules (qu'ils soit physiques ou virtuels), comment choisir les 3 préférés ? Potentiellement j'en ai plusieurs dizaines de préférés. Donc au final, ce que je préfère, c'est la vue de toutes les pièces. En un coup d'oeil, tu vois les températures, l'état des ouvrants, des lumières, et tu peux vite rentrer dans une pièce si tu veux voir un module en particulier. Enfin, pour mon utilisation en tout cas.

Euh.... je sais pas là.... surtout si les trames sont chiffrées, tu ne verras rien d'utilisable. Pour moi le sniffer doit être sur le téléphone. J'avais déjà utilisé une telle application, ça marche bien. De mémoire elle émule un VPN en local, donc l'application voit passer le traffic entrant/sortant du téléphone.

Je n'avais pas fait attention, mais effectivement je viens d'essayer, je confirme. Cela ressemble à un bug de l'application mobile, elle permet de sélectionner les favoris désirés, mais en pratique elle n'affiche que ceux qui sont de type Z-Wave, donc tous les QuickApps ne sont pas affichés. Il faudrait remonter le problème à Fibaro. Enfin si ça ne tenait qu'à moi, je demanderais la possibilité de supprimer cette page de favori, ça ne rime à rien, une pauvre ligne avec 2 ou 3 favoris dessus, c'est juste inutile. Soit ils permettent de faire un vrai dashboard personnalisé, soit ils nous remettent la vue de la maison entière par défaut comme c'était le cas sur l'ancienne application. Ce nouveau dashboard, est trop limité en l'état et le rend inutile.

Oui c'est très probable, le WP aurait conservé son cumul de consommation après l'exclusion/inclusion. DomoCharts récupère l'énergie de la veille depuis le panneau de consommation d'énergie de la HC3, donc déjà tu peux regarder les valeurs que tu as là : Si tu veux le faire précisément via l'API comme le fait DomoCharts, c'est cette URL, il faudra remplacer l'IP, le timestamp de début, le timestamp de fin, et l'ID du WP : http://192.168.1.1/api/energy/1612215000/1612251000/compare/devices/power/123 Et tu regardes la valeur du champ kWh dans le JSON retourné. Ensuite, tu peux aller dans la base, avec phpMyAdmin par exemple, pour remettre à zéro les valeur pour cette première journée dans la table domocharts_energy_day afin de corriger le problème, et surtout de ne pas pourrir les graphs avec des valeurs aberrantes.

Bienvenue sur le forum

Nickel, ça rend super bien Merci

Ouh c'est chouette ça, tu pourrais faire le même genre pour la Freebox Mini 4K ? Merci

Et bien, cette doc est bien plus claire Avec ajout de quelques traces supplémentaires : local MyStrom = Net.FHttp("[IP of Bulb]", 80) local data = "action%3Don" local response, status, errorCode = MyStrom:POST("/api/v1/device/[MAC]", data) print(status) print(errorCode) print(response) PS : ne cite pas le message précédent le tient

Elle est étrange leur API. Un truc dans le genre je pense, pour reprendre l'exemple donné : local MyStrom = Net.FHttp("[IP of Bulb]", 80) local data = "single=post://[IP of Bulb]/api/v1/device/[MAC of Bulb]?action%3Dtoggle" MyStrom:POST("/api/v1/device/[MAC]", data) Il faudra que tu remplaces les adresses IP et MAC.

Mouais, ça va changer.... déjà ils ont identifié un bug avec les modules liés dans les zones de climat : https://forum.fibaro.com/topic/53994-virtual-thermostats-do-not-triggered-after-update/?do=findComment&comment=228966 C'est pas encore bien sec tout ça.

Quand je vois les comportements à priori aberrants, je me dit que le panneau des zones climatiques est peut être buggué, donc attention. Et puis, il faut aussi distinguer les actions qui sont effectuées automatiquement par la zone (ex : changement d'heure programmée => nouvelle consigne), et les actions effectuées manuellement par l'utilisateur via l'interface Web. Ce sont 2 choses différentes, l'une peut être bugguée, pas l'autre (ou les 2 lol) As tu regardé dans le Swagger si cet aspect est documenté ? (j'en doute, le swagger n'est pas assez complet à mon gout, mais ça mérite de vérifier)

Salut @flacon030 désolé j'avais complètement loupé ton message Tu as pu faire fonctionner depuis ? PS : pour la Teleinfo, cela fonctionne EXCLUSIVEMENT pour ... la Téléinfo !!! Et rien d'autre. Donc n'essaye pas de l'utiliser pour autre chose (production, compteur, etc) car ça ne fonctionnera pas.

Tu construits le tableau que tu veux en fonction de l'index que tu vas utiliser. Ce n'est pas forcément l'id, ça peut être autre chose, tout dépend de ton besoin. Par exemple dans mon QA GCE, l'index du tableau, c'est le port de l'IPX800 (ou de l'EDRT2). Ex : myTable["A1"] pour le child qui gère l'entrée analogique n°1. Etc... La limite c'est ton imagination

A la fin de la consigne manuelle, pour moi, la zone revient à la programmation horaire préenregistrée. A tester. Pour les child, il faut te construire un tableau index des childs pour pouvoir y accéder rapidement sans devoir parcourir la liste. Ensuite, chacun de mes child charge ses propres variables et les conserve dans son instance (self.mavariable), du coup le parent peut y accéder directement : child.mavariable (en supposant que child pointe sur la bonne entité, cf la suggestion du tableau indexé)

Oui, c'est pas ce que tu voulais faire ? Suffit de récupérer l'API utilisée par l'interface graphique lors de l'ajout. Même si perso je suis pas fan, créer un child c'est un processus simple, l'ajouter automatiquement dans une zone, ça correspond à ton besoin présent, mais pas forcément générique.

Je trouve pas ça gênant, tu le fais en 2 temps : création du child, puis ajout dans la zone. Une fois programmé, à l'usage c'est instantané et invisible pour l'utilisateur.

Aux dernières rumeurs, c'était prévu pour la prochaine version. Vu qu'ils ont mis 5 mois à sortir cette version stable.... donc Q2/Q3 est réaliste, mais de quelle année ? Espérons 2021 !

Voilà j'ai retrouvé, c'était le Orvibo Allone (tout court, pas pro) : https://www.domadoo.fr/fr/controle-infrarouge/2944-orvibo-telecommande-irwifi-allone-pour-smartphone-6928986700001.html En 2015 Bien sûr que si on peut faire de l'UDP avec la HC3, depuis l'été dernier Je m'en sert pour SNMP et Xiaomi.

Ah oui c'est pas gagné. Il y a quelques années Domadoo m'avait prêté un Orvibo justement, mais je ne me souviens plus du modèle, était-ce le même ? En tout cas le fabricant leur avait promis une API, et tout ce qu'ils ont reçu a été un SDK (= des outils de développement sur ordinateur), donc totalement inexploitable sur HC2. Donc au final j'ai laissé tombé. Wireshark, ou trouver quelqu'un qui a déjà fait le boulot et documenté le travail.