Lazer

Ah je n'avais pas compris tu veux faire juste une seule action, pas un ON/OFF ? Dans ce cas, tu peux faire un QA de type generic, avec un seul bouton, mais ça ne sera pas utilisable directement dans l'application, il faut d'abord ouvrir sa webview, ce qui est lent et parfois (trop souvent) ne fonctionne tout simplement pas.

Que veux-tu dire gérer "par code" ? Tu veux dire que le BinarySwitch doit avoir des actions différentes, selon une condition ? Dans ce cas oui, puisque tu codes en LUA, tu fais ce que tu veux. Les fonctions QuickApp:turnOn() et QuickApp:turnOff() peuvent appeler une autre fonction (perso j'utilise QuickApp:setValue(value) pour garder la compatibilité avec les MultilevelSwitch). Ensuite tu fais ce que tu veux, par exemple selon l'heure, la date, une variable globale, l'état d'un module, etc. Ce qu'il faut juste respecter, c'est qu'à la fin de l'action effectuée, tu dois penser à mettre à jour la propriété value du QA, afin que l'état du module, donc l'interface Web et l'application mobile se mettent à jour : self:updateProperty("value", true) ou self:updateProperty("value", false)

ça c'est clair ! C'est pas pour rien qu'historiquement la quasi totalité des installations photovoltaïques en France ont été faites dans le sud. 50% en plus, ça fait une sacrée différence.

Yes.... En attendant, tu pourrais me donner le log que tu avais quand tu as tenté avec ce fameux point d'exclamation derrière l'ID. Si ça a été documenté, c'est que ça a fonctionné à un moment donné, ce que je trouve étrange, il doit y avoir une explication.

Effectivement dans ce cas particulier, un "Inverses" serait bien utile. Je regarderai à l'occasion, mais sans garantie, la gestion du "Inverse" est quelque chose à laquelle je ne n'ai pas du tout touché dans GEA, je n'ai aucune idée de la façon dont Steven l'a implémenté.... et le code de GEA est ultra complexe. Certaines modifications sont très simples à faire, tandis que c'est l'enfer pour d'autres. Je ne connaissais pas du tout la syntaxe avec le point d'exclamation derrière l'ID ! Mais je ne vois pas comment ça pourrait fonctionner, c'est syntaxiquement incorrect en LUA, on ne peut pas coller un tel caractère derrière un nombre. Exemple simple et rapide : > print(101) 101 > print(101!) stdin:1: ')' expected near '!'

"Inverses", oui pourquoi pas, mais il faudrait que j'étudie la faisabilité (la complexité de mise en œuvre...), je n'en ai aucune idée. Mais en as tu réellement besoin ? Attention à la logique inverse, à vouloir tout négationner, ne vas tu pas rendre ta configuration illisible et difficile à maintenir ? Pour la seconde, tu as une erreur de syntaxe, il y a un point d'exclamation collé derrière le crochet fermant de l'ID de ta condition. Dans le log tu dois probablement avoir une erreur LUA, ou bien GEA qui te le signale par un message (pas forcément très clair, je n'ai jamais vu cette erreur)

ça se passe dans l'onglet Réseau des outils de développement. Exemple pour Firefox, mais c'est complètement similaire avec Chrome. Là j'ai choisis le mode Heat. La requête est de type POST : Comme c'est du POST, il y a des données envoyées, qu'on peut retrouver dans l'onglet Requête : Et on peut voir la réponse du serveur Web (la HC3) dans l'onglet du même nom. En faisant un clic droit, tu peux facilement copier l'URL, les données envoyées, la réponse, ou même la syntaxe complète de la commande CURL, ce que j'aime bien personnellement, étant un peu habitué à Linux. On remarque qu'il y a de nombreuses autres requêtes, c'est normal, c'est l'interface Web de la HC3 qui se rafraichit en permanence avec la fameuse API refreshStates (celle-là même qui a été largement discutée sur le forum, qui permet de gérer les triggers dans les QuickApps, comme le fait GEA par exemple)

Nouveau record aussi aujourd'hui, 32,88 kWh

Je n'utilise pas les scènes bloc, mais ce que tu décris ressemble à un bug. Signale le au support Fibaro, ou mieux, sur le forum officiel, ils sont plus réactifs. PS : la section pour les nuls ce n'est pas pour y poser des questions, ce sont uniquement des mini-tutos pour débutants. Et effectivement, ça a été fait à l'époque de la HC2, rien n'a été fait depuis la HC3...

Attention Pascal, ici c'est bien le topic du Smoke Sensor, qui n'est pas certifié NF machin truc, donc ce n'est pas un DAAF selon la loi bidule truc. Après comme tu dis, vu les dates de péremption, je suis certain que 99% des capteurs installés chez les gens ne sont plus au norme, et personne ne va les remplacer. La domotique, Fibaro, Orange, ou Norgut lui-même n'y changeront rien

Nouveau record aujourd'hui, à 31.1 kWh. Mon sapin est toujours présent, j'estime que l'impact de son sombre est une diminution de 10% de ma production. Pas gênant pour l'instant, vu tout ce que je ne consomme pas tout en cette belle saison. Depuis quelques jours j'ai constaté que mon pic de puissance maxi en milieu de journée baisse un peu, malgré que le soleil soit de plus en plus haut (donc se rapproche de la perpendiculaire des panneaux). Je montais à 4200W il y a quelques jours, et aujourd'hui ça a plafonné à 3900 W, pourtant le soleil était radieux avec ciel bleu. Après réflexion, c'est normal, c'est l'impact de la chaleur, qui diminue le rendement des panneaux (26° à l'ombre, donc bien plus sur les panneaux) C'était parfaitement prévu par les simulations PVGIS, qui montrent bien qu'on a plus puissance en avril que durant l'été, à cause de la chaleur. (cela dit on produit plus en été, car les jours sont plus longs) J'avais oublié ce point important. Je me demande bien combien j'aurai lors des grosses canicules à 40°C, mais surement beaucoup moins, ça sera intéressant à observer.

Attention quand même, ces détecteurs ne sont pas aux normes NF. Cela explique le prix ridicule (surtout qu'on trouve des détecteurs aux normes pour le même prix.... certes non connectés)

On fait infiniment plus de choses en LUA, mais c'est plus complexe bien sûr. En pratique, je fais tout en LUA (et mes scénarios via GEA... qui est écrit en LUA), je n'utilise pas du tout les scénarios graphiques, etc. Mon panneau d'alarme contient un seul capteur, c'est une entrée d'un module Fibaro Universel, qui me permet de remonter automatiquement le statut de l'alarme (la vraie) dans la domotique. C'est tout. Donc je n'utilise pas les possibilités du panneau d'alarme de Fibaro. Et dans mon cas, c'est l'activation de la vraie alarme, qui va activer le mode Absent sur la box (une règle dans GEA s'en charge), donc là aussi, sans passer par les scénarios graphiques. Du coup, bah... J'ai du mal à répondre aux questions en apparence basiques Mais n'hésite pas à poser des questions en tout cas.

Oui rien de positif, mais Z-Wave n'a pas été conçu pour ajouter une fonction accessoire sur un appareil type caméra/alarme/portier... c'est du gadget pour le coup. Donc tu passes à coté de l'essence même de Z-Wave (qui est conçu pour faire un système domotique complet), donc pas étonnant que tu sois déçu. ça fera des heureux sur LBC Je me souviens de l'époque où on payait les Smoke Sensor au prix imbattable de 9€ neuf, merci Orange

Il faudrait prier très fort que @Steven passe par ici pour se pencher sur ton problème, c'est le seul qui maitrise le code GEA sur HC2. Mais ta remarque est étrange, la v4 elle est vieille maintenant, et elle fonctionne super bien avec GEA, j'ai fonctionné ainsi pendant des années, sans rencontrer de plantages de GEA.

J'utilise très peu (= de façon ultra basique) le panneau d'alarme, donc je ne sais pas répondre à tes questions. Pour info j'ai une vraie alarme. En ce qui concerne les modes (je viens de me rendre compte que ça a changé de nom, ça s’appelait profiles avant), c'est totalement indépendant du panneau d'alarme, ça permet de gérer des modes de fonctionnement distincts de la maison. Tu peux en créer autant que tu veux ou modifier ceux qui sont prédéfinis. Si tu veux lier les modes avec l'alarme, tu peux le faire via des scènes normalement. Par exemple dès que tu passes le mode en absent, alors ça active l'alarme. Ou l'inverse d'ailleurs, après c'est toi qui construits les scénarios en fonction de tes usages. Mais perso vu que c'est GEA qui gère tout ça, je ne saurai pas t'aider sur les scènes en mode blocs.

Il n'est pas possible de faire communiquer les détecteurs entre eux, car en Z-Wave, les modules sur pile sont endormis et n'écoutent pas le réseau. Ils sont uniquement capables d'émettre des trames à destination du contrôleur, ou bien d'autres modules (qui eux sont branchés sur le secteur, type relais, sirène, etc) Pour mettre à jour le firmware des modules Fibaro, il faut impérativement une box Fibaro. Ta clé Aeotec te permettra juste d'inclure les modules sur un autre logiciel domotique, comme par exemple Jeedom, Home Assistant, Domoticz, etc. Le réglage de l'unité de température (Degrés Celcius/Fahrenheit) n'est pas un paramètre du module, cela se configure dans ton logiciel/contrôleur/box domotique. Vu que c'est une Ring, il faut voir avec son fabricant s'il propose cette option, car je ne connais pas du tout.

Bienvenue sur le forum

Ah ? Tu sais pourquoi ? J'ai un QuickApp Thermostat qui fonctionne toujours très bien. Mais il n'est pas géré par une zone de chauffage, le changement de comportement doit provenir du panneau de chauffage dans ton cas.

Ah oui c'est le temps des travaux... OK donc faudra s'adapter en attendant. Sinon, il est peut être possible d'initialiser ton pont Hue en le mettant sur un autre réseau équipé d'Internet, puis de le déplacer après.

Mais tu comptes rester sans accès Internet ? Dans ce cas il est préférable de concevoir une domotique totalement indépendante du cloud, ce qui exclue le pont Hue, ainsi que la grande majorité des produits connectés grand public.

Mettre ta SIM dans un routeur 4G connecté en Ethernet sur ton Switch/routeur. Huawei en fait par exemple, on en trouve d'occasion à pas trop cher sur eBay qui viennent des autres pays d'Europe. Je ne sais pas s'il y a d'autre solution simple. Brancher le téléphone sur un PC imposerait d'utiliser Linux pour faire du routage des paquets, c'est tout de suite beaucoup plus compliqué.

Si ça se trouve, sur HC2 ils ont fait comme sur HC3.... c'est à dire la suppression de la possibilité de rebooter la box via le code LUA. Je n'ai plus d'HC2, donc je ne pourrai pas investiguer d'avantage.

De mon coté, non désolé pas encore.

Désolé trompage de topic, j'ai effacé mon message et reposté au bon endroit avant que tu ne postes Pour ta réponse, sache que tu peux découvrir toute l'API en utilisant les outils de dev du navigateur (avec F12) quand tu es sur l'interface Web de la HC3. Puisque tout passe par l'API, c'est très pratique. Après tout se passe comme d'habitude avec fibaro.call() (ou hub.call() sur les firmwares récents si tu préfères) : fibaro.call(123, "setThermostatMode", "Auto") fibaro.call(123, "setHeatingThermostatSetpoint", 20) fibaro.call(123, "setCoolingThermostatSetpoint", 22) fibaro.call(123, "setThermostatFanMode", "Auto") Sinon pour connaitre les actions et les valeurs de propriétés acceptées par le thermostat, il faut regarder dans son JSON via /api/devices/<ID> Il y a tout ce qu'il faut. Exemple pour le Remotec ZXT-600 : Et là où c'est le plus fort, c'est que si tu crées ton propre QuickApp de type thermostat, tu peux définir tes propres valeurs autorisées, c'est à dire les modes Auto/Heat/etc, les bornes de consigne min/max, etc. Exemple (à mettre dans le onInit() du QuickApp) : self:updateProperty("supportedThermostatModes", {"Off", "Auto", "Heat"}) self:updateProperty("supportedThermostatFanModes", {"Auto", "Low", "Medium", "High"})