Lazer

Non pas possible, il te faut créer 2 lignes distinctes pour répondre aux 2 conditions.

Sur HC2 HC3 on n'arme plus les modules. Le nouveau panneau d'alarme fonctionne selon la même logique qu'une vraie alarme. On crée des partitions (zones) et on y affecte les capteurs de son choix. Puis on arme la ou les partitions désirées.

Oh la belle XL

Joyeux Noël

Ta variable PrevColor, elle récupère une chaine de caractères de type "string" (qui contient des valeurs numériques séparées par des virgules) Tu ne peux pas injecter directement la string dans la fonction hub.call() qui attend des arguments composés de valeurs numériques. Donc il faut décomposer PrevColor pour extraire les valeurs numériques. Il te faut utiliser la fonction split() qui n'existe pas nativement en LUA mais que tu trouveras sur le forum ou chez notre ami commun Google.

Bonne référence musicale

Ta variable colorSet est définie un peu plus haut, donc c'est de là que doit provenir le problème : local colorSet = fibaro.getValue(1185, "lastColorSet"); Vérifie si la propriété lastColorSet existe bien dans le JSON du module 1185.

Garage Center 3, en disponibilité exclusive pour Noël 2023

Ici c'est un Module Virtuel pour HC2, donc il est normal que tu ne puisses pas l'importer dans la HC3, qui attend un QuickApp. Je n'ai pas de Doorbird, mais regarde par ici, je pense que ça te conviendra mieux :

ça existe déjà : https://www.domotique-fibaro.fr/forum/157-shelly/ (depuis 2 minutes ) Merci pour la suggestion

@PITP2 Ah oui comparé Shelly à Fibaro c'est sûr, surtout depuis que Fibaro a remonté ses tarifs à cause pour profiter de l'inflation. C'est comme je disais, chaque constructeur choisi le prix auquel il veut vendre ses produits, ça ne reflète pas toujours le cout de production. Sinon on n'aurait pas des iPhone à +1500€ (pardon pour la comparaison, elle était facile...) Cela dit, sur le forum GCE Electronics, j'ai vu qu'ils critiquaient les modules Shelly (je ne sais pas quelle référence exactement) car ne disposant pas de protections électriques élémentaires, telle que l'isolation courant fort/courant faible. Mais vu qu'on n'a pas de comparatif avec les autres marques (dont Fibaro), on ne peut pas savoir si ça justifie un cout inférieur ou non.

Pas sûr de comprendre, les Shelly Z-Wave sont plus chers que les modules Wi-Fi ou Zigbee, non ? Bon après ça dépend des marques, tu prends Legrand Zigbee, c'est les mêmes tarifs que Fibaro Z-Wave, donc après chaque fabricant est libre de fixer sa politique tarifaire, si elle est justifiée (image de marque, qualité du produit, fonctionnalités apportés, etc) Mais si tu regardes en moyenne des produits disponibles, entre Zigbee et Z-Wave, y'a pas photo sur les tarifs.

Merci pour ton retour Je comprends mieux le contexte. Est-ce que Daikin ne propose pas un mode vacances, qui permettrait alors de couper complètement le maintient en température du ballon ?

Perso je n'ai jamais utilisé les caméras dans l'application mobile Fibaro/Yubii, ce n'est pas un truc qui me manque. J'utilise l'application de mon NAS, DS Cam, qui est 1000x plus pratique, et surtout prévue pour cet usage.

Le prix, clairement. Zigbee n'a pas été développé pour être un bon protocole, mais pour être économique. L'histoire se répète souvent, l'exemple auquel on pense généralement c'est la cassette VHS... celle là elle ne manque à personne, et pourtant il a fallu la subir de longues années... Fun fact : après avoir regardé ta vidéo, YouTube me propose des vignettes de vidéos qui pourraient me plaire. Celle-ci prête à sourire vu le contexte : Après si ça marche chez 99% des gens et/ou qu'ils n'ont pas de points de comparaison pour constater que ça marcherait mieux avec un autre protocole, à la fin ça ne pose pas de problème...

Je confirme Enfin, c'est possible sur les très vieux radiateurs, des années 90 et avant, c'est à dire les modèles qui ont un thermostat mécanique à bilame, qui n'ont pas de fil pilote, bref aucune électronique, juste un contact mécanique et une résistance. J'en ai un comme ça chez moi, c'est un panneau radiant, et ça fait des années que je le pilote avec un relai FGS. Mais à partir du moment où tu as un thermostat électronique et/ou un fil pilote, c'est déconseillé, tu vas l'user prématurément avec le risque de griller l'électronique et de rendre ton radiateur inutilisable. Cherche en occasion, sur Le bon coin et autre site d'arnaque en tout genre, je suis sûr que tu peux trouver des Qubino d'occasion, car pas mal de monde abandonne Z-Wave pour se tourner vers d'autres solutions (Zigbee ou Wi-Fi surtout) Sinon : - en Zigbee il existe une sortie de câble Legrand qui fait fil pilote, mais aucune idée du support sur HC3 (ça fonctionne sous Home Assistant en tout cas). Attention c'est du Legrand, qualitatif, donc cher. - revenir à la bonne vieille méthode qu'on utilisait avant les modules Qubino : un module relai FGS avec 1 ou 2 diodes, qui te permettront de générer 2 ou 4 ordres (mais pas les 6). Ce sujet a largement été abordé sur le forum et dans les vieux tutos qu'on trouve sur le net.

Oui c'est ça, avec json.decode(), tu trouveras pas mal d'exemples d'utilisation sur le forum. Tu obtiendras une table avec tous les champs/valeurs bien rangés. Attention je vois que tu as une structure JSON imbriquée, donc ça te donneras des tables à plusieurs niveaux. Les espaces dans le nom des champs c'est un peu pénible mais pas bloquant. Il faut utiliser des crochets : local maValeur1 = maTable.monChamp local maValeur2 = maTable["mon champ avec espace"]

Après on est pas à l'abri qu'une société mette un gros chèque sur la table pour racheter la structure qui porte l'ensemble des développeurs, et comme tu dis, quid des évolutions ?!? Le fait que le produit soit Open Source ne le protège pas particulièrement, c'est souvent l'argument n°1 qu'on entend, ce à quoi il est facile de répondre qu'on ne compte plus les projets open source abandonnés sur le net car l'équipe de développement est passée à autre chose. Il y a un grand nombre de développeurs indépendants qui proposent des intégrations diverses et variées, ce qui fait une grande force du produit, mais combien auraient les compétences, le temps et l'énergie pour poursuivre le développement de la base ? C'est la grande inconnue. Et s'il n'y a plus d'évolution publique, le produit sera vite remplacé par un autre. Bref, qui vivra verra, mais on ne peut pas croire que le produit est intouchable et vivra éternellement du simple fait qu'il soit open source. Le risque existe.

Pourquoi couper l'alimentation électrique de la PAC ? Tu ne peux pas simplement lui donner une consigne d'arrêt ? C'est plus propre. Chez Daikin, tu dois bien avoir une connectivité Wi-Fi / Internet te permettant de la piloter à distance depuis une application mobile, qui passe par leur Cloud. Sinon pour couper l'alimentation électrique d'un appareil de puissance, on n'utilise pas un micro-module domotique, tel que Shelly, Fibaro, ou n'importe quelle autre marque. C'est bien trop dangereux, les borniers, relais, et pistes en cuivre ne sont pas dimensionnés pour supporter de telles puissances. Tu t'exposes dans le pire des cas à un départ d'incendie. Il faut utiliser un contacteur de puissance, c'est une sorte de gros relai qu'on installe dans le tableau électrique, donc juste après le disjoncteur. Le disjoncteur, lui, est toujours indispensable, c'est un organe de sécurité, on n'y touche pas (sauf si on veut couper manuellement l'appareil, mais pas d'intervention possible à distance, il faut être physiquement présent pour agir sur le disjoncteur) En terme de contacteurs, j'aime bien la marque Legrand, parce que c'est français, ils ont un catalogue bien étoffé et documenté, ils ont toutes les normes qui rassurent et notamment le label NF. Je n'ai pas la malchance d'être en triphasé, mais j'ai quand même jeté un rapide coup d'oeil. Il faut un contacteur tétrapolaire, c'est un gros bébé de largeur 2 ou 3 modules sur le rail DIN. Extrait du catalogue, j'ai encadré les modèles qui conviennent, il faut choisir la puissance adaptée, à mon avis prend du 40A pour être tranquille, j'ai peur que 25A soit un peu juste avec ta PAC (que je ne connais pas, il te faut donc vérifier sa puissance électrique maximale dans sa datasheet) : Ensuite, il te faut un moyen de piloter ce contacteur à distance, là on en revient aux micro-modules domotiques, tels que Shelly, Fibaro, Qubino, etc. Et si tu n'as pas de box domotique tu n'es pas sur le bon forum il va falloir se creuser la tête pour trouver un module pilotable à distance, donc dépendant d'un Cloud quelconque. Il est probable que Shelly soit un bon candidat, à creuser.

Je ne suis pas un pro, et encore moins un vrai pro, seul @PITP2 l'est ici. Je n'ai personnellement jamais développé de communication avec une clé USB donc c'est difficile de te répondre précisément, mais en gros c'est une combinaison des deux. Des trois, même : - une partie matérielle : la clé, avec son chipset, son antenne, ses filtres, son amplificateur, etc - une partie firmware : du logiciel embarqué dans le matériel, c'est à dire dans la clé - une partie logicielle : ce qui tourne sur la box/logiciel domotique et qui fait l'interface avec la clé On voit bien chez Fibaro, rien que sur le HC3, entre ce qu'ils appellent le moteur Z-Wave v2 (qui est assez similaire à ce qu'on avait sur HC2), et le nouveau v3 (en beta encore...), il y a plein de différences. Même constat sur les solutions OpenSource (Jeeom, HA, ...) qui sont passées de la librairie OpenZWave à Z-Wave JS. Et si tu compares les box Fibaro, entre la HC3, et la HC3 Lite, tu n'as pas le même hardware embarqué. Antennes, filtres, et amplificateurs de meilleur qualité sur la HC3 par rapport à la HC3 Lite, en pratique ça veut dire plus de portée / moins de perte de paquets. Je me souviens à l'époque où le Raspberry PI était à la mode (avant qu'il ne coute aussi cher qu'un lingot d'or...), il y avait la carte enfichable RaZberry qui était connue pour fonctionner beaucoup moins bien qu'une clé USB branchée sur le même Raspberry PI. Il doit aujourd'hui exister des différences similaires entre les différentes clés USB disponibles, toutes ne se valent pas. J'ai juste testé une vieille clé USB Aeotec (qui me sert encore occasionnellement), mais il y a eu de nouvelles version depuis, mais je n'ai pas de quoi comparer en pratique. Autre chose, on dit souvent que le chipset permet de supporter les nouvelles fonctions du Z-Wave (chiffrement S0 apporté par le Z-Wave+ avec les chipset de série 500, puis le chiffrement S2, etc) Pourtant Fibaro a apporté le support du chiffrement S0 dès la HC2 avec son vieux chipset série 300, grâce à une implémentation purement logicielle. Bref c'est compliqué et il n'y a pas de réponse unique à ta question.

Ah oui effectivement ce point n'est peut être pas très clair. Comme le dit EDF, la journée d'une couleur commence bien à 6h (et fini le lendemain à 6h, soit 24h après). Mais mon QA, en revanche, va positionner la couleur du jour avant, en fait il le fait dès Minuit le jour J, soit avec 6h d'avance sur l'horaire réel de démarrage. Dans le développement de mon QA, j'ai raisonné en jour calendaire, pas en jour au sens EDF. Cela peut éventuellement être utile si tu veux que tes scénarios anticipent la couleur activée aux HP à 6h. Par exemple entre minuit et 6h du matin, tu sais que la couleur du jour ça va être Rouge, alors tu peux chauffer la maison plus que la normale pour gagner en inertie thermique (ce que je fais.... +1.5°C sur la consigne) Autre chose : EDF ne communique la couleur du lendemain qu'à 11h, ce qui est relativement tard. Comme mon QA va chercher l'info à la source chez RTE, on a la couleur bien plus tôt, à partir de 7h du matin (et au maxi jusqu'à 10h30, heure à laquelle la couleur du lendemain est définitivement confirmée) Dans mon QA, EDF n'est utilisé que pour confirmer la couleur qui a déjà été obtenue chez RTE. C"est très pratique, ainsi j'ai la couleur du lendemain en notification sur mon smartphone avant même mon réveil, et je peux m'adapter en conséquence. Et là je parle de scénarios non domotiques, par exemple choisir ses jours de télétravail ou de présence au bureau en fonction de la couleur du lendemain. C'est ce que j'ai fait sur les 3 premières jours rouges de la saison, autant être absent de la maison, ça fait encore gagner quelques kWh et autant d'euros. En plus le chef est content de me voir

Non ce n'est pas nécessaire, ce QuickApp est pleinement utilisable sans l'EcoDevice. C'est juste un bon complément. Utilisé seul, il te donne la couleur du jour et du lendemain provenant de 2 sources (RTE et EDF). Avec ça tu as toutes les infos en main pour écrire tes scénarios. Exemple : si la couleur du jour est ROUGE (lisible dans la variable globale) et qu'il est entre 6h et 22h (condition à mettre dans GEA par exemple avec une option "Time") tu peux éteindre tous les appareils non indispensables, baisser le chauffage, etc.

Non désolé pas à ma connaissance. Des tutos en ligne peut être, il faut chercher... après la souci c'est qu'il faut maitriser le LUA sur HC2, car il y a pas mal de petites subtilités : comprendre le mécanisme de fonctionnement de la main loop, des boutons, les interactions avec l'API Fibaro, etc. Tout existe sur le forum car cela a été abordé dans les années passées, mais il faut faire des fouilles archéologiques car c'est dilué dans la masse d'information. L'autre souci c'est qu'il n'y a quasiment plus personne sur HC2, donc plus de nouveaux développements. Les gens sont passés soit sur HC3, soit parti vers une autre solution domotique.

Non effectivement, il ne gère pas les HP/HC, car c'est déjà géré par le QA GCE qui récupère la téléinfo du compteur via EcoDevice RT2. Par sécurité, ce QA compare la couleur du jour avec le tarif HP remonté par la téléinfo entre 6h et 22h, afin de s'assurer que la couleur correspond bien entre EDF, RTE, et Enedis. Sécurité maximale, car il ne s'agirait pas de louper un jour Rouge !

Bienvenue sur le forum