Lazer

En fait c'est pas opposé à ce que j'ai fait. En gros @PITP2 te dit que ça fonctionne bien en Wi-Fi, et mal en Zigbee. Perso j'ajouterais que pour le Wi-Fi, ça dépend quand même du point d'accès. Car il y a un monde entre le Wi-Fi intégré dans box box/modem/routeur Internet fourni par les opérateurs, et celui proposé par des marques pro comme Unifi. @Sakkhho j'ai envie de te demander est-ce que le budget est un critère de choix ? Car entre du Z-Wave et du Zigbee/Shelly, c'est pas le même prix. Idem pour la box/contrôleur d'ailleurs. Également, selon si tu déménages avec tes modules existants, ou bien si tu dois tout racheter...

Justement, c'est bien le problème. Le Zigbee utilise la même bande de fréquence que le Wi-Fi, donc il se fait perturber. Car dans une maison, le Wi-Fi est quasi indispensable, il est difficile de s'en passer sauf à vivre comm un Amish. Du coup, c'est le Zigbee qui n'a pas trop sa place dans l'histoire, il est arrivé après. La solution c'est de limiter les canaux du Wi-Fi, afin de laisser la place au Zibgee. Reste que ce n'est pas une solution idéale, car tu brides ton propre Wi-Fi, tu as besoin de tous les canaux, notamment si tu as plusieurs bornes Wi-Fi, et/ou que tu es en environnement dense où tu captes le Wi-Fi des voisins. En plus le Wi-Fi ça émet plus fort que le Zigbee, donc quand il y a compétition entre les deux, le Zigbee se fait écraser (analogie : dans un environnement bruyant c'est celui qui crie le plus fort qui se fait entendre) J'ai vu d'autres solutions évoquées qui consiste à ne plus utiliser le WiFi 2.4 GHz et à forcer le 5 GHz, mais c'est une mauvaise solution car : - de vieux appareils ne savent communiquer qu'en 2.4 GHz, donc impossible de s'en passer - le 5 GHz porte moins loin, donc on a toujours besoin du 2.4 GHz dès qu'on s'éloigne de la borne Là où je suis triste, c'est que Thread (poussé par Matter), qui est censé mettre tout le monde d'accord puisque destiné à remplacer Zigbee, utilise la même fréquence, du coup ça ne laisse pas présager un protocole domotique radio qui sera aussi fiable que le Z-Wave. Dommage pour le Z-Wave, car même si techniquement ça reste un meilleur protocole, ce qui lui a fait du mal c'est son cout (la licence du chipset et la certification des modules), mais aussi une très mauvaise intégration de la part d'une certains librairie OpenZwave historique, aujourd'hui abandonnée par tous. En même temps si le consortium avait ouvert les spécifications, ça ne serait peut être pas passé ainsi...

Il y a déjà 2 QuickApps sur le forum pour être averti de la couleur des jours Tempo.... mais c'est pout HC3 uniquement ! Il va vous falloir tout réécrire sous forme de Module Virtuel pour HC2. Quant aux API, pas la peine de se prendre la tête, il suffit d'utiliser celle d'EDF qui est publique : https://particulier.edf.fr/services/rest/referentiel/searchTempoStore?dateRelevant=2023-12-17 { "couleurJourJ": "TEMPO_BLEU", "couleurJourJ1": "TEMPO_ROUGE" }

On est bien d'accord que ça n'a rien à voir avec les caméras Hikvision ? J'ai aussi eu la mise à jour de l'application mobile DS Cam, il a fallu que je me reconnecte avec mon utilisateur pour retrouver tout comme avant.

Je ne me suis pas du tout intéressé à Airzone, mais en fait la difficulté elle n'est pas vraiment dans le QA, mais dans la moyen de s'interfacer avec la pompe à chaleur. Quelque soit la marque, si le système peut être interfacé avec ESPHome, alors il fonctionnera avec le QuickApp, éventuellement au prix de très légères adaptations. Donc faites vos recherches avec ESPHome. Et comme dit plus haut, si un jour vous basculez sur Home Assistant, ça sera nativement pris en charge, la migration n'en sera que plus facile.

Oh my god

bah non puisque tu as dit quelques messages plus haut que self:updateProperty() fonctionnait encore

Au fait, tu es bien sur le dernier firmware 5.150.18 ? Pour essayer de savoir à partir de quelle version l'API aurait changé... Sinon ton profil n'est pas à jour

Attention sur le forum Fibaro tu as mis la même chose (juste un espace de différence après la virgule) :

Et bien, avant si on utilisait updateProperty pour tous les modules, d'après tes tests maintenant c'est setProperty pour les modules Z-Wave, et updateProperty (comme avant donc) pour les QA.

Pour une lumière, prenons l'exemple suivant : si tu as l'habitude qu'un bistable soit en position haute quand la lumière est éteinte, et en position basse quand elle est allumée, tu vas machinalement appuyer au bon endroit du bouton en entrant/sortant de la pièce, sans même regarder l'interrupteur en question. C'est ce qu'on appelle la mémoire musculaire (à défaut d'être musclé, j'aime bien me consoler en pensant que mon cerveau est musclé ). Si entre temps, la domotique a changé le statut de la lumière, alors la position de l'interrupteur ne correspond plus à ce que ton cerveau attendant, et là c'est le bug. Au moins 1s pendant laquelle le cerveau doit rebooter pour s’adapter à la nouvelle configuration Et rebelote la fois d'après, car finalement tu as 1 chance sur 2 de trouver ton interrupteur dans la mauvaise position. C'est le même problème avec les montages que j'appelle "de grand père" en mode va-et-vient, comme on en trouvait souvent avant. Au moins avec un monostable, tu n'as pas cette problématique, l'interrupteur est toujours dans la même position (en haut), et il faut cliquer en bas pour agir sur la lumière. Que ça soit pour l'allumer ou l'éteindre. Et non pas besoin de laisser le doigt appuyé dessus. Tu n'as pas déjà des télérupteurs chez toi ? C'est très courant dans les couloirs, cages d'escalier, etc. C'est exactement le même principe. Un appui court dessus, et la lumière s'allumer ou s'éteint, c'est le télérupteur qui mémorise l'état, et cela quelque soit le nombre d'interrupteurs monostables connectés (en parallèle) sur le circuit. C'est exactement pareil avec le module domotique (FGS ou FGD) qui remplace totalement le télérupteur. En ajoutant quelques bonus, puisque outre la connectivité domotique permettant un contrôle depuis l'autre bout du monde (il faut souligner le caractère indispensable de pouvoir allumer la lumière de son salon quand on a les doigts de pieds en éventail au bord de la plage), on a l'appui prolongé qui permet de faire varier la luminosité (avec les FGD) et le double clic qui permet de remettre immédiatement le gradateur à 100%. En fait ce n'est pas vraiment nouveau, ça existait déjà avec les "télévariateurs", Legrand faisait ça par exemple, et même si c'était assez rare d'en trouver, c'est devenu complètement obsolète depuis l'arrivée des micromodules domotiques.

Tu peux, mais c'est moins pratique justement parce que l'interrupteur conserve sa position, et donc cela risque de ne pas correspondre au statut réel du volet si celui-ci a été changé par la domotique (ce qui est le but en fin de compte...) Perso j'ai remplacé mes interrupteurs bistable par des monostables (aussi bien pour les lumières que les volets) au fur et à mesure que j'ai domotisé les appareils. Mais encore une fois, rien ne t'y oblige.

Il faudrait poser la question sur le forum officiel pour tirer cette histoire au clair, est-ce que c'est un changement voulu ou non, est-ce que ça s'applique aux QA ou aux autres modules, etc. Pas eu le temps de faire des tests/recherches de mon coté, mais tout cela semble bien flou pour l'instant.

A mon avis pas besoin de QA dédié pour gérer les échanges MQTT, ça alourdirait le fonctionnement du bouzin. Je ne suis pas fan des QA interdépendants les uns des autres, ça rend le système plus complexe à maintenir... suivi des versions, indisponibilité d'un QA qui impacte les autres, etc. En plus, l'utilisation de MQTT est vraiment facile, ça se fait en quelques lignes dans un QA, c'est pas beaucoup plus compliqué que de faire une requête HTTP, et moins compliqué que de faire des communications TCP/UDP avec une socket. Voir la doc de Fibaro qui donne la syntaxe à utiliser. Limite la doc est plus compliquée sur l'utilisation. Au moins pour une fois ils ont rédigé une doc complète sur le sujet. En fait comme toujours, la difficulté c'est d'organiser correctement la structure de son QA, puisque tu mentionnais sur un autre topic que tu n'es pas très à l'aise avec ça.

Bienvenue sur le forum

oui mais pas dans la section pour les nuls, ce sont des mini tutos en lecture seule. Je déplace du coup... dans éclairage vu le besoin.

Merci @jojo et bravo pour le travail Comme je le disais sur l'autre topic, je suis certain que ça fonctionnait avant car j'ai encore mon fichier des règles de GEA que j'ai testé avant partage sur le forum, ainsi que tout un tas d'URL de la forme suivante que j'ai utilisé dans mes tests pour forcer les propriétés de tel ou tel device directement à l'aide de la fonction updateProperty() depuis le navigateur web : /api/callAction?deviceID=100&name=updateProperty&arg1=value&arg2=true /api/callAction?deviceID=101&name=updateProperty&arg1=value&arg2=false /api/callAction?deviceID=102&name=updateProperty&arg1=value&arg2=0 /api/callAction?deviceID=103&name=updateProperty&arg1=dead&arg2=false Je pense donc qu'on est face à une modification non documentée de l'API de la part de Fibaro.

Tu étais au bon endroit C'est dans la sous-fonction action() que ça se passe. En fait toutes les fonctions des modules (Z-Wave, Zigbee, QuickApp, entité extra-terrestre...) ne sont pas listées dans la section actions du JSON. Normalement le updateProperty setProperty est systématiquement implémenté, ça fait partie des fonctions de bases de tous les modules, encore une fois qu'ils soient physiques ou virtuels. Je pourrais te prendre un autre exemple, c'est la fonction QuickApp:debug() qu'on utilise en long en large et en travers pour afficher des informations dans la fenêtre de debug. On ne l'a défini nul part dans notre propre code LUA, pourtant elle existe belle et bien. Pourtant elle n'est pas listées dans actions. En fait elle est héritée de la classe parente du QuickApp. Conséquence : appeler la fonction debug() d'un autre QuickApp permet de lui faire afficher n'importe quoi ! Donc là c'est un autre bug, on appelle la mauvaise fonction. Mais ça m'interpelle quand même, j'ai l'impression qu'on est face à une modification non documentée de l'API de la part de Fibaro. Il faudrait enquêter, car je suis certain que ça fonctionnait avant, j'ai encore mon fichier des règles de GEA que j'ai testé avant partage sur le forum. Du coup, rectificatif : modification incluse dans le "other minor fix" du changelog

à ma connaissance on ne peut pas, c'est pareil pour tous les modules (Z-Wave, Zigbee, QuickApps, etc), donc ce n'est pas lié à Zooz en particulier (je sais pas pourquoi le nom de cette marque me fait marrer ) On peut juste désactiver les notifications pour le monde en question.

Hitachi, aucune idée. Pourtant je suis formé et certifié Hitachi... ah non zut, c'est leurs baies de stockage, rien à avoir avec leurs climatisations, c'est incroyable l'étendue du portefeuille de ces conglomérats japonais. Qui pour piloter une pelleteuse de la même marque ? Dans mes recherches, j'étais tombé sur une ébauche de projet similaire pour Daikin, consistant à exploiter le port de communication local des splits. L'année dernière c'était en mode beta, je ne sais pas s'ils sont arrivé au bout, je n'ai pas suivi ni mémorisé le lien. Et pour la marque chinoise Midea ça existe déjà. Enfin les Midea récentes, car mon vieux split Midea de 9 ans d'âge n'a pas de port local, dommage (du coup pilotage par Remotec ZXT 600 en infra-rouge)

Pour avancer, et pour obtenir de l'aide, tu devrais décomposer ton besoin en plusieurs petits besoins élémentaires à traiter dans l'ordre, un à la fois. Et ouvrir un sujet correspondant dans la bonne section du forum.

Bienvenue sur le forum

OK bon, il faut reporter le bug sur le topic de dév GEA pour que je pense à l'analyser plus tard.

Bienvenue sur le forum

Non....