Lazer

OK c'est clair pour l'alim des FGBS, on est bien d'accord Pour tes volets, si tu attends devant l'interface de la box (sans parler du script LUA), est-ce que les modules se mettent à jour avec du retard ? C'est ça qu'il faut que tu testes, pour mesurer et comprendre le délai de réaction de ton installation. Ensuite tu ajusteras le scénario en fonction. Perso je me suis toujours méfié des script ajusté à la seconde près, ça n'est jamais fiable. Je préfère prévoir large, la domotique c'est rarement instantané, il y a toujours quelque chose qui temporise (le réseau, la box, ...). C'est une des raisons pour laquelle j'aime l'approche de GEA, on vérifie des conditions à intervalle régulier, minimum 30s, mais souvent bien plus long, exemple : que faire si la porte est ouverte depuis 5 minutes, etc. Pas de prise de tête avec le chronomètre.

OK je comprends le principe de ce que tu veux faire maintenant. Mais si tes volets mettent 40 secondes à se fermer, alors il faut attendre un peu plus longtemps pour faire la vérification, le temps que le retour d'état de tous les volets remontent vers la box. Il peut y avoir quelques secondes de retard, surtout si le réseau est encombré, ce qui est fortement susceptible d'arriver si 10 volets s'agitent en même temps (sans compter les autres modules du réseau, et en particulier les lumières que tu actionnes au même moment) Tu peux attendre largement plus, par exemple 1 minute, à tester. Forcer le polling est une solution, mais attention, ça génère beaucoup de trafic, et donc ça risque d'être contre productif, car un réseau saturé implique des trames perdues. Normalement tu ne devrais pas avoir besoin de jouer avec le polling, il faut trouver l'origine du problème, et tel que tu le décris, je pense que tu n'attends pas assez longtemps (cf mon paragraphe du dessus) Tiens, un exemple. J'ai une scène qui éteint toutes les prises le soit au coucher. C'est "marrant", parce que j'entends tous les relais de la maison commuter au même moment. Et ce "même moment", parfois tous les relais commutent en moins d'une seconde, ça fait presque un genre de clac géant. Et d'autres fois, c'est plus long, les relais commutent à quelques secondes d'intervalles, cette latence est le signe évident d'une saturation du réseau Z-Wave. Normal étant donné le nombre d'action effectuées simultanément, avec tous les retours d'états qui s'enchainent (nouvelle valeur du relai, mesure de puissance, énergie, etc) Des FGBS sur pile ? Ils tiennent combien de temps ? Tu arrives à dépasser quelques jours d'autonomie sans recharger ? Sinon pour la syntaxe, pas de mystère, il faut lire la doc sur le site de Fibaro, ou bien chercher sur les forums (ici et l'officiel)

Notepad++ (ou n'importe quel autre éditeur), et fonction rechercher/remplacer. Modifier la syntaxe des fonctions est vraiment la partie la plus facile et rapide du portage du code de la HC2 vers la HC3. La logique, c'est plus long... Parlant de logique... je n'ai pas compris ce que tu décris, mais vu que tu parles de temporisation, j'ai comme l'impression que tu as un problème de logique de ton algorithme. A revoir... Peut être tout simplement allonger la tempo. Attention la valeur n'aura pas une valeur numérique, mais un booléen true/false Non, le retour d'état fonctionne même sans polling régulier. Alors attention, la plupart des capteurs sont des modules sur batterie qui sont endormis, la notion de polling n'a pas de sens, et d'ailleurs elle n'existe pas. Tu devrais relire mon mini tuto sur le polling dans la section pour les nuls du forum. C'est valable quelque soit le contrôleur Z-Wave.

OK merci, donc maintenant c'est clair, tu as la même erreur que moi lors de mon test quelques messages plus haut. C'est LUA qui refuse d'exécuter le code, le point d'exclamation n'est pas accepté. C'est donc normal. Mais cela n'explique pas pourquoi ça a été documenté ainsi dans GEA, comme si ça avait pu fonctionner sur HC2...

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.