Lazer

Tient c'est curieux ça. Tu peux activer le mode debug pour avoir plus d'informations à l'écran (attention le QuickApp sera alors très verbeux). Pour cela il faut créer une variable "debug" dans le QuickApp, et lui attribuer la valeur "true" (note que je parle bien des variables du QA, pas du code LUA qu'il ne faut pas toucher) De plus, tu peux me donner le résultat de la requête suivante sur ton EcoDevices (ajoute l'IP te remplace juste apikey si nécessaire) : /api/xdevices.json?key=apikey&Get=TI

C'est le même qu'en première page

Il est fort probable que tu l'aies armé par erreur, ça m'arrive régulièrement dans l'application mobile quand on glisse le doigt dessus (alors que je cherche juste à défiler verticalement les pages)

Et bien bravo Hâte de suivre la suite Mais vu que tu sembles te planquer au Wakanda, pense à ramener un peu de Vibranium pour renforcer ton engin

GEA est une scène Et on sait depuis des années que Scène + erreur 403 sur la HC2, c'est parce que tu as l'alarme activée. Donc il faut que tu cherches quel est le module armé dans ton installation, tu le désarmes, et tout rentrera en ordre.

Bien bien bien ça. Il m'intéresse fortement pour mettre en extérieur, sous abris, à coté de la sonde Netatmo (qui a la fâcheuse tendance à ne plus remonter aucune température quand le cloud est inaccessible... forcément "work as designed".... et c'est extrêmement gênant quand on base ses scénarios de chauffage sur la température extérieure. Pas besoin de précision énorme pour cet usage, donc à vrai dire je me moque un peu que ça soit +/-0.4°C ou plus, mais évidemment plus c'est précis, mieux c'est.

Très clairement, les scènes blocs sont prévues pour des scénarios ultra simples, du genre si ... alors... Du coup, tu as plusieurs scénarios, donc plusieurs scènes, une pour chaque scénario, c'est logique, simple, efficace. Ne t'inquiète pas, ce ne sont pas 5 scènes en mode bloc qui vont mettre à genoux la HC3. Si tu veux tout regrouper en une seule scène, je pense que le mode bloc n'est pas du tout adapté. Le mieux est encore de faire ça avec GEA. Sans connaitre le LUA, tu peux écrire des règles prenant en compte différentes conditions, et effectuant les actions correspondantes, tout cela depuis un point unique (un QuickApp)

Je pense que tu devrais partir sur un QuckApp de type "com.fibaro.colorController", et ensuite tu ajoutes les boutons désirés pour chaque couleur.

Oui tout à fait avec la méthode updateProperty ça devrait fonctionner (cf l'URL que j'ai donné en page précédente). J'ai regardé dans GEA, il appelle setProperty, ce qui semble être un reste de la HC2, et j'ai l'impression que cette méthode n'est plus implémentée dans les QuickApps. @Dragoniacs ou les autres adeptes des belles icones, vous avez testé de mettre à jour les icones des autres modules via GEA ? Parce que tel que c'est là, ça ne doit jamais fonctionner. Sinon je remplacerai par updateProperty

ah oui tient, et c'est logique en fin de compte. As-tu testé via l'API HTTP ?

Sans même regarder le log, l'erreur est évidente : tu ne peux pas créer un interrupteur (binary switch) avec une entrée virtuelle C'est soit un interrupteur avec une sortie, soir un simple capteur binaire avec une entrée une entrée sur l'IPX800 = un capteur (sensor) sur la HC3 une sortie sur l'IPX800 = un actionneur (switch, ...) sur la HC3 Cela me fait penser que dans une prochaine version, il faudrait que j'ajoute des contrôles supplémentaires pour éviter ce genre d'erreur de configuration.

Oui impressionnant. C'est combien de temps de travaux, entre la conception, et la réalisation ?

Les anciens, ça on savait qu'ils fonctionnaient parfaitement. Le souci, c'est avec les derniers modèles (Gen5 Z-Wave+, référence ZMNHJD1, objet de ce topic). Et plus particulièrement le dernier firmware connu, le H1S1P5 (indiqué sur l'étiquette) C'est bien avec ce firmware que vous avez réussi l'inclusion (tant sur HC2 que HC3) ???

Ouais pas nous on n'est pas aussi barbus que toi Bon sérieusement, tu as pu inclure un module Fil pilote sans soucis sur la HC3 ??? Parce que les autres Qubino, y'a aucun problème, mais le fil pilote, son firmware est buggué....

Non en effet, comme je n'ai pas ce capteur je ne me suis pas penché sur la question. Je vais ajouter ça à ma liste. En attendant tu devrais pouvoir l'ajouter manuellement, il faut connaitre la formule de calcul et ajouter formula = function ... end dans la section value = { ... } comme expliqué en 1ère page

Je n'ai jamais vu de remonté de température sur les 2 switchs Unifi 8 ports que j'ai, dommage que cette info ne remonte pas dans le Controller

Et bah pour le coup, c'est une très bonne chose qu'ils aient prévu une sécurité, je ne savais pas, mais c'est rassurant. De toute façon, boitier métal ou pas, les appareils électroniques c'est très rarement prévus pour fonctionner par des températures ambiantes de 35°C. Surtout le matos réseau, en général c'est dans des salles machines ou des bureaux, donc des endroits où la température est bien contrôlée, ça dépasse rarement 25°C. Si tu veux du matos renforcé pour faire fonctionner dans le grenier, tu peux regarder du coté de chez Cisco. Ce n'est pas le même tarif par contre.... Remarque : mon routeur Ubiquiti Edgerouter, en métal lui aussi, est enfermé dans mon tout petit coffret réseau, là où la température peut aisément dépasser 30°C en été (je n'ai jamais mesuré). Par précaution, j'ai placé un ventilateur 12V que j'alimente en 5V (USB), ainsi il tourne tout doucement, juste posé sur la coque du routeur. Le boitier métal passe de bouillant à tout juste tiède. Est-ce nécessaire ? Je ne sais pas, mais au moins le routeur n'a jamais planté. Dans ce même coffret, j'ai un Raspberry PI 1 qui a planté une fois à cause de la chaleur, et 2 switchs CISCO qui n'ont jamais bronché.

Bah après la chauffe elle est dépendante de la consommation de l'appareil... ça on ne le maitrise pas. Faut juste retenir que le boitier métal est là pour évacuer la chaleur. ça fait 10 ans qu'on lit partout que la HC2 est trop chaude, qu'on peut y faire cuire un oeuf, et pourtant pas une seule n'est tombée en panne à cause de la surchauffe. Justement par ce que c'est normal. Donc tu n'as pas lu ce que j'ai écris. Le plastique ne conduit pas la chaleur, donc celle-ci est enfermée à l'intérieur.

Oui donc c'est le classique module RGBW. Il peut fonctionner de 2 façon : - piloter un ruban LED en RGB ou RDGW, c'est à dire avec 3 couleurs + blanc optionel pour produire une infinité de nuance - piloter 4 canaux individuels de LED mono-couleur (blanc en général), avec variation lumineuse (si les LED le supportent)

Non ça ne chauffe pas sans raison. La raison est parfaitement connue, c'est exactement la même que pour la HC2 avec son boitier alu. Le métal ça conduit très bien la chaleur, comme je l'ai dit au dessus, ça fait radiateur. Pour la même raison, on met d'énormes radiateurs au dessus des processeurs dans les ordinateurs (et quand ça ne suffit pas, on ajoute un ventilateur) Il est parfaitement normal que le boitier soit chaud, puisqu'il évacue la chaleur interne des composants. A l'inverse avec un boitier plastique, la chaleur n'est pas évacuée, et les composants internes sont plus chaud... donc risque de plantage accru, usure prématurée (surtout des condensateurs chimiques). Alors que le boitier plastique, lui, reste froid au toucher... normal, il ne conduit pas la chaleur (comme le bois, etc)

checkCertificate = false, à ajouter dans les options de ta requête http

J'ai un Switch-8-60 et je n'ai jamais eu aucun plantage de mon coté. Il faisait combien dans ta pièce ? Mais à ce jeu là, le Lite 8 sera encore plus en difficulté, avec son boiter plastique, il ne risque pas de dissiper la chaleur correctement. Ce n'est pas pour rien que tous les équipements réseaux pro sont en métal, le boitier fait radiateur (en plus de cage de Faraday) Ce nouveau Lite 8 c'est plus pour faire des switchs d'appoints, pour les bureaux typiquement.

OK, mais du coup ça va être ta résidence principale ? Ou c'est vraiment juste pour les voyages ? Je suis d'accord, le 230V n'est pas pertinent, avec toutes les pertes lors des conversions. Mais ne serait-ce pas plus pertinent encore de passer en 24V DC ? Tous les éclairages LED existent en 24V (je ne pose que ça chez moi, pas de 12V), ça permet plus de puissance, donc un meilleur éclairage, sans augmenter la section des câbles, surtout sur de grande longueur.... donc cout (et poids) inférieur. Et à partir du 24V avec des convertisseurs DC/DC tu peux descendre à 12 et 5V pour les équipements qui le nécessitent (USB, etc) Ton sujet est dans éclairage car il ne traite que... d'éclairage ! Tu peux créer un sujet dans mes installations domotique pour présenter ton installation de façon plus générale, entre les panneaux, les onduleurs, les batteries, le circuit électrique, etc il y a effectivement pas mal de sujets à aborder.

Juste une remarque, as-tu bien pris en compte la consommation relativement importante de la domotique en générale, et des modules Z-Wave en particulier ? 1W par ci, 1W par là, ça peut finir par tirer pas mal d'Ah sur ta (tes ?) batteries. A prendre en compte si tu ne veux pas te retrouver avec le car en panne un matin. Et le Z-Wave n'est pas fait pour être coupé régulièrement, donc tu peux l'éteindre totalement pendant les périodes à la maison, mais dès que tu seras en itinérance, il faut calculer pour que la domotique soit connectée 24/7

Je pense que c'est normal, ce que tu appelles la "perte de connexion" c'est la même chose que l'absence de communication.