Lazer

En cas de Mesh c'est encore pire que ça, car certains canaux seront réservés pour la communication entre les bornes, donc inutilisable pour les périphériques. Le Mesh est à proscrire, je sais que toutes les marques grand public (Netgear, DLink, etc) en ont fait une pub d'enfer comme étant leur argument de vente, mais faut bien comprendre que ça occupe des canaux, c'est tout sauf une bonne technologie (cela dit, c'est moins pire que les répéteurs Wi-Fi, les petits boitiers à 30€ qu'on branchait sur une prise murale...) Rien ne remplace des bornes connectées chacune sur leur port RJ45 dédié, c'est la configuration idéale.

Je ne suis pas sûr de bien comprendre, c'est un VD ou un QA ? Sinon c'est dans la section HC2 qu'il doit aller...

Faudrait vérifier sur le site d'Ubiquiti, mais je pense que ça ne pose pas de problème, chaque borne fonctionnera avec sa version... donc tu auras des débits différents selon que ton appareil mobile est connecté à l'une ou à l'autre.

Merci, mais tu devrais en plus mettre le code LUA dans un fichier attaché, car tu sais qu'on ne peut pas copier/coller les codes LUA sur le forum à cause des caractères cachés qui apparaissent de façon imprévisible... alors sur un script aussi long, ça risque d'être compliqué de les trouver.

Ce sont les Long Range qui sont plus puissants, et à mon avis inutiles en intérieur, leur domaine de prédilection c'est la couverture de larges espaces ouverts, comme l'extérieur. Entre le + et le Pro, ce qui va changer, c'est pas tellement la puissance, mais plutôt le nombre de stream, donc en gros le nombre d'appareils que tu es capables de connecter simultanément. A moins d'avoir une domotique basée sur des modules Wi-Fi en grand nombres (cas de ceux qui utilisent des modules Shelly par exemple), je doute que tu aies des dizaines d'appareils connectés, et actifs, simultanément sur tes bornes. Du coup, le choix de la performance ce sont les Pro, mais pas sûr que tu aies un vrai gain en pratique, du coup le choix de la raison c'est le +. Reste à choisir le nombre de borne à déployer dans la maison... tu as de la chance le bois va te faciliter la vie niveau ondes radios, mais après pour le nombre et le disposition, il faut faire des tests chez toi. A ta place, ce que je ferais après l'emménagement, c'est de commencer avec 2 bornes, avec un long câble Ethernet volant, pour faire des tests, et puis tu te balades avec ton téléphone et ton PC partout, surtout aux extrémités de la maison, pour voir si sa capte bien. Puis tu déplaces les bornes, tu les orientes différemment, etc, et tu sauras si tu dois en ajouter une 3ème ou pas. Voire une 4ème...

C'est une voiture piégée ?

Oui c'est ça, cage de Faraday, qui bloque les ondes entrant/sortant de la box. Idéalement, pour un bon fonctionnement du réseau Z-Wave, la box a besoin de communiquer avec un maximum de client. Si tu déportes la box à l'autre bout de la maison, et/ou que tu fais obstruction au passage des ondes, ça ne peut pas bien fonctionner. Car les rares modules qui vont faire relai, vont créer un goulet d'étranglement, et complètement engorger le réseau. Donc ensuite, c'est répétitions de trames, donc surcharge supplémentaire, un véritable cercle vicieux, et au final un délai supplémentaire. Et ultimement, les paquets sont perdus, les ordres ne passent pas, les mesures des capteurs non plus, les modules finissent par passer en nœuds morts... @MAM78 vu que tu es tu 78, je vais faire un parallèle que tu dois bien connaitre. Imagine une ville, au hasard Paris, dans laquelle tu répartie équitablement les logements, les commerces, et les entreprises. Tout se passe très bien, la communication est fluide, tout est accessible à moins de 15 minutes. Ensuite, pour X ou Y raisons, tu décides de transformer la ville en musée à ciel ouvert, avec des lieux touristiques de partout, tout en conservant les entreprises et les commerces, et donc tu déportes les logements de l'autre coté du périf... et puis même beaucoup plus loin que le périf, dans des cités dortoirs à 10, 20, 30 km de Paris. Et puis tu mets une cage de Faraday autour de ces citées dortoirs (des champs, des rivières, des forêts, ou d'autres citées dortoirs), et tu dis qu'il n'y aura qu'un seul chemin pour continuer à se rendre dans la capitale, l’autoroute A13. Et voilà, tu as donc réussi à transformer un réseau urbain maillé et efficace, en un réseau décentralisé qui ne fonctionne plus du tout, qui sature de partout, qui créer des retards des salariés tous les matins, et ultimement des gens qui jettent l'éponge et ne vont plus travailler à Paris car le jeu n'en vaut pas la chandelle, ce sont des paquets perdus (pardon pour l'analogie)

Tient et sinon, explore le forum, il y a des tonnes d'information, par exemple ce tuto pour commencer :

Salut, je ne te conseille pas trop d'utiliser les scènes, c'est plus adapté pour des scénarios qui doivent se déclencher à intervalle ponctuel, sur événement. Sur HC3, les efforts sont tournés vers les QuickApp. Honnêtement je n'ai pas le temps (ou l'envie, puis le temps ça se prend) de t'écrire ton QA pour faire ce que tu veux, donc je te conseille de partir des QA exemples proposés par Fibaro, d'essayer de comprendre la logique du onInit() puis de la façon de créer une boucle infinie (sujet évoqué sur le forum), pour ensuite récupérer la valeur de ton modules (en t'inspirant de l'extrait de code LUA que je t'ai proposé), puis il te restera à mettre ça sous forme de CSV affiché dans la console par exemple, que tu pourras copier/coller dans Excel. Mais ça me parait bien fastidieux, et même si c'est toujours intéressant de réinventer la roue pour progresser, est-ce qu'il ne serait pas plus simple d'utiliser ce qui existe déjà ? Par exemple DomoCharts, qui ira stocker les valeurs dans une base de données, que tu pourras exploiter à loisir, tout en profitant des graphiques déjà intégrés ?

Ah ben voilà ce qui arrive quand on habite à coté des allemands et de leur réseau électrique tout pourri 190 V c'est hors spécifications Enedis, c'est pas normal du tout.

En effet.

C'est pas une bonne idée, mais il n'y a qu'en le testant chez toi que tu sauras si la dégradation du réseau est acceptable pour ton usage.

ouh là là, c'est HS ici, tu devrais ouvrir un nouveau topic dans HC3 / Support

Bravo pour tes recherches et merci pour le partage de tes trouvailles. Pour récupérer les valeurs des modules, il faut commencer par regarder leur JSON, accessible à l'URL suivante sur ta box : /api/devices/ID Et tu remplaces ID par l'ID du module qui t'intéresse. Là tu vas avoir une longue liste, il faut que tu regardes dans "properties", il y a pleins de champs. Normalement le champ "value" contient la valeur principale du module, mais tu peux aussi en avoir dans "power", "energy", etc, cela dépend du type de module ("type" que tu trouveras dans le JSON d'ailleurs) Ensuite en LUA, tu peux récupérer la même information avec api.get() : local id = 123 local myDevice = api.get("/devices/" .. tostring(id)) local myValue = myDevices.properties and myDevices.properties.value if myValue then print("La valeur de mon device est :", myValue) else print("Erreur : impossible de récupérer la valeur de mon device") end (non testé, j'espère qu'il n'y a pas d'erreur)

Si j'en crois mon historique, le changement de comportement serait apparu depuis la version 5.142.83 Beta (et les Stables suivantes) en octobre 2023.

Merci du tuyau, maintenant que tu le dis, je viens de constater que j'ai le même problème avec mon script, je ne m'en étais pas rendu compte. Il va falloir que je corrige ça.

J'ai pensé la même chose sur le coup

Vous semblez avoir le même souci, puisque dans les 2 cas vous semblez lire les propriétés des modules. Conclusions : vérifiez bien que les valeurs des propriétés que vous lisez existent bien... s’agissant de tables imbriquées façon poupées russes, il faut vérifier que la table parent existe avant de parcourir la table enfant, etc... jusqu'à arriver à la valeur désirée. ça donne des codes LUA à rallonge avec une série de if ... then, ou bien l'usage de "and" qui permet de racourcir l'écriture en 1 seule ligne. Si je reprend le cas de @jjacques68 ça donne : if self.childDevices and self.childDevices[self.Liste_OUT_ID[i]] and self.childDevices[self.Liste_OUT_ID[i]].properties and self.childDevices[self.Liste_OUT_ID[i]].properties.value == true then Encore mieux : if type(self.childDevices) == "table" and type(self.childDevices[self.Liste_OUT_ID[i]]) == "table" and type(self.childDevices[self.Liste_OUT_ID[i]].properties) == "table" and self.childDevices[self.Liste_OUT_ID[i]].properties.value == true then

Ben c'est marqué : non Vu qu'il n'est pas sur la liste. Sinon faut demander à ChatGPT, qui va se faire un plaisir de donner la procédure pour l'inclure

En tout cas la vidéo fait envie Si tu vas sur la page produit, la réponse est assez claire : https://na.niceforyou.com/products/smart-home/hr40-remote-control/

Si tu ne trouves aucun topic existant en rapport avec tes questions, tu peux créer un (ou autant que nécessaire) nouveau sujet(s) dans la section HC3 / Support

Il te manque des accolade autours des conditions pour les grouper : GEA.add({{"Sensor+", id["WALL_PLUG_TV"], 4}, {"Time","08:00","18:00"}}, -1, "", {"TurnOn", 147}) Par contre attention, un déclenchement instantané (durée = -1) avec une condition de consommation électrique (Sensor) c'est une mauvaise idée, car ça varie tout le temps, donc ça va déclencher à tout va, et consommer beaucoup de ressource CPU. La bonne pratique c'est d'utiliser le cycle normal de GEA (durée = 0, ou 30, etc) dès lors qu'on utilise des conditions de puissance. La suite sur le topic support GEA.

Oui ces 2 règles devraient fonctionner telles quelles je pense. Par contre attention, les options "Time" et "Days" doivent être dans les conditions, pas dans les actions, là tu utilises une très vieille syntaxe provenant des toutes premières versions de GEA.

Regarde là justement, car NissanGTR nous fait un retour sur sa migration des modules vers HC3 : Et attention seuls les modules Z-Wave peuvent être migrés, tout le reste, à savoir Scènes et Modules virtuels doivent être recréés.

Sans savoir ce qui ne fonctionne pas ça va être difficile de t'aider Des douzaines de scènes GEA ? Ce n'est pas normal du tout, le principe de GEA c'est de regrouper tous les scénarios au même endroit. Cet endroit était une scène sur HC2, et c'est maintenant un QuickApp sur HC3, mais le principe est le même : la syntaxe des règles est la même, c'est juste les valeurs que peuvent prendre les modules qui ont changées, comme je te le disais plus haut. Mais ce n'est pas lié à GEA proprement dit, mais plutôt à la façon que la HC3 a de gérer les valeurs des modules (avant tout était en string, maintenant c'est du number, boolean, etc). EDIT : par contre si tu vais des dizaines de scènes non GEA (en mode bloc, en LUA), alors c'est pareil sur HC3, mais il faudra tout refaire, car elles ne sont pas migrées.