Lazer

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"})

Je viens de regarder avec les outils de développement du navigateur en passant par le cloud Fibaro Les requêtes ne sont pas évidentes du tout, il y a toute une encapsulation qui est faite autour de l'API documentée que l'on connait. Exemple pour allumer un Binary Sensor, c'est du style : POST https://home.fibaro.com/newProxyLite?user=1234&hc=HC3-00056789&temp=XXXXXXXXXXX_XXXXXXXXX-XXXXXXXXXXXXXXXXXXXXX&req=/api/devices/100/action/turnOn Sachant qu'il y a également des données dans la requête : {"args":[56,"turnOn"]} Et également un cookie passé dans les en-têtes de la requêtes (cookie probablement issu lors de la phase d'authentification sur la page Web) Bref, c'est chaud, vraiment chaud.  Pas certain que ça vaille la peine de passer des heures à comprendre le fonctionnement pour le reproduire, sachant que c'est sans garantie de succès, ce n'est pas documenté, et que Fibaro est susceptible de changer ce proxy cloud à tout moment. Une alternative pourrait être de sniffer les requêtes émises par la nouvelle application mobile Yubii, vu qu'elle passe par le cloud. Mais pas forcément plus simple que la méthode précédente... Bref, par ordre de simplicité, je dirais : - ouvrir et rediriger un port sur le routeur vers la box domotique - établir un VPN - monter un reverse proxy (avec HAProxy, ou Ngynx, etc) - reverse engineering via l'une des 2 méthodes exposées plus haut. L'ouverture de port étant la moins sécurisée, le VPN la plus sécurisée, et le reverse proxy quelque part entre les 2 selon la configuration mise en place. 

ça dépend de ce que tu appelles "de suite", tu remarqueras que je n'ai pas encore édité la 1ère page

Dans ce cas, pas certain que la HC3 permette d'écouter les broadcast du réseau, je ne pense pas que ça soit prévu. J'avais bien vu dans ton log que l'erreur provenant du receive(), mais c'est justement parce que la HC3 considère qu'elle ne reçoit rien (malgré les paquets envoyés précédemment) que tu as cette erreur. Tant que ta PAC enverra en broadcast, tu ne recevras rien dans ton code LUA, car ce n'est pas une réponse à un paquet destiné à la HC3. Mais si tu dis que tu peux communiquer en TCP, pourquoi ne pas utiliser ce protocole ?

Je les mets tous dans la même pièce du module, et je cache ceux font je n'ai pas besoin (c'est à dire la majorité en fait) Comme sur ton screenshot. Sinon plutôt que le support Fibaro, tu peux tenter le forum officiel, c'est parfois plus réactif, et les intervenants (salariés Fibaro) plus compétents que le support.

ça te défrise Je vais l'ajouter, mais en temps normal on s'en fout en fait, puisqu'il n'y a de toute façon aucun graph à visualiser le premier jour, le temps que les données s'accumulent.

1. Je n'ai eu aucun problème pour lancer les mises à jour.... demande au support Fibaro 2. Tous mes modules RGBW remontent la consommation sur le module principal, je n'ai jamais eu de consommation sous chaque module enfant. Il faudrait que tu arrives à faire les mises à jour de firmware, puis peut être refaire une exclusion/inclusion pour uniformiser tout ça. 3. La télécommande permet d'utiliser facilement les déclencheurs de .... scène justement ! Perso je n'utilise pas les scènes, les modules sont cachés, donc je ne les vois plus. Si Fibaro les affiche dans les scènes, c'est justement à raison. 4. C'est un comportement "normal" sur HC3 (comprendre : c'est tout le temps comme ça), mais je ne trouve pas ça normal, perso je préfère les repasser systématiquement en polling régulier, ça permet de détecter les éventuels noeuds morts. Mais attention, c'est consommateur de bande passante, c'est pour ça que Fibaro préfère désactiver le polling par défaut sur HC3. Si tu le réactives, il faut bien faire attention à augmenter le paramètre général d'intervalle de polling.

Merci @jojo, du coup petite mise à jour du graphique :

Tous les dimanches pour être précis, pas tous les jours. Mais je ne sais pas si ça a une incidence, certains utilisateurs évoquent un plantage dans les moins de 24h qui suit le redémarrage.