Lazer

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.

Voilà une réponse qui n'a pas du te plaire vu ton projet ! En tout cas ce n'est pas la sécurité qui l'inquiète, mais juste la perte d'énergie. Rassurant alors. Sinon c'est intéressant cette histoire de LED à courant constant montées en série, je ne connaissais pas du tout, je suis curieux de voir si ça va se développer à l'avenir comme il le prédit.

Ah je connaissais pas cette marque, merci pour le tuyau

La zone de climat permet de faire du off sur les thermostats, ce qui n'existait pas sur HC2 Fonctionnalité que la vanne Danfoss ne sait pas gérer, contrairement aux QA ou au Remotec ZXT par exemples. Donc @jjacques68 utilise un QA intermédiaire pour émuler cette fonction. Après la question c'est pourquoi il veut faire du off et ne se limite pas aux températures comme sur HC2. A mon avis la réponse c'est : pour la beauté du geste

Oui, les relations entre 2 HC3 sont identiques aux relations entre 2 HC2 : - c'est soit le transfert de box manuel en passant par le cloud Fibaro en cas de panne de la première - soit le mode passerelle qui n'a absolument rien à voir avec du failover, car il permet d'agrandir l'installation par la création d'un 2nd réseau Z-Wave (éventuellement déporté) Pas possible de faire avec Fibaro ce que permet Jeedom et les VMs.

app.lua ? Bizarre ça... en tout cas, je vois un espace entre id et le crochet ouvrant, déjà c'est pas bon. Si ce n'est pas ça le problème, c'est que tu as un symbole inattendu quelque part, donc un caractère caché.

ça me semble correct @Nico je crois que tu l'avais expliqué à l'époque, mais que t'apporte les modules liés ? Il me semble que ça a voir avec ta gestion du chauffage qui est un peu particulière, car tu n'utilises pas de thermostat justement (pas de vanne thermostatiques dans les pièces), mais plutôt des vannes motorisées dans le local technique, du coup les modules liés te permettent de les contrôler en mode ON/OFF, et de se servir du panneau de chauffage, grâce aux modules liés, pour faire la régulation de température. J'ai juste ? Dans ce cas, ça n'a rien à voir avec le cas de @jjacques68

Ah ben oui, le coup du 1, je n'avais pas fait attention, mais pourtant je l'ai déjà dit plusieurs fois sur ce topic et sur l'autre. Sur HC3, les modules ne prennent plus la valeur 1, donc si tu testes cette valeur avec GEA, forcément ça ne va jamais déclencher la règle. Pour tous les détecteurs binaires, c'est true ou false. Bref, il y a une seule règle à retenir : sur HC3 regardez le JSON des modules pour voir quelle valeur prendre le champ "value", c'est le seul moyen efficace de ne pas se tromper.

Beau travail

Oui je n'ai plus le lien sous la main mais il y a un VD avec régulation PID sur le forum. L'idéal sera de reprendre l'algorithme. Mais attention, à ne pas utiliser avec un tête Danfoss, qui est déjà un thermostat. C'est prévu pour piloter des appareils sans régulation, ou à la régulation basique, genre vieux radiateurs électrique, ou bien chaudière en mode ON/OFF (pas les nouvelles avec Opentherm)

Tu vas y arriver Je viens d'établir ma première communication entre la HC3 et le robot aspirateur Xiaomi, je suis tout ému

Oui voilà, il faut sortir la tête de la zone et laisser le QA fait l'intermédiaire. Donc la logique, tu l'as déjà avec ton QA Heating Manager, il faut juste que tu le "transforme" en thermostat, afin qu'il s'intègre nativement dans la logique de la zone de climat Yapuka

Ben tu fais simples et efficace : - le QA reçoit le température de consigne, et la transmet à la Danfoss, tel quel - si par contre le QA reçoit un ordre OFF, alors il donne une consigne très basse à la Danfoss De cette façon tu auras ajouté le support de la fonction Off en 2 lignes de LUA, tout en conservant la régulation de la tête Danfoss (car tu ne feras pas mieux, aucun intérêt de la bypasser dans ton cas)