Lazer

Si tu reprends l'extrait de code de @chrisalex du 20 avril 2021 ça te donne une base de départ.

Effectivement, merci @jojo tu as l'oeil Aller @Cram19 on ferme ici et on recommence une présentation correcte

Bienvenue sur le forum

Je t'ai conseillé l'API de EDF, c'est pas pour rien... car l'API de RTE n'est pas publique, il faut passer par une authentification OAuth 2.0 avec un Token. Donc déjà essaye d'écrire un VD en LUA avec l'API de EDF qui est franchement très simple, et si tu y arrives, tu verras pour attaquer l'API RTE... ce que tu ne pourras pas faire avec un VD car il est impossible de manipuler les headers de la requête HTTP nécessaires pour OAuth 2.0. Donc il faut passer par une scène, c'est d'une lourdeur incroyable. Bref, on en revient toujours au même : utilise l'API de chez EDF.

Pas tout à fait, je continue à penser que Z-Wave >> tous les autres protocoles domotiques. Mais pour le choix de la box / moteur de scénario, là c'est question de préférence personnelle. Il est probable que je partirais sur Home Assistant si je devais faire une toute nouvelle installation.... mais avant d'en être certain, il faudrait d'abord que je le teste, dans une VM ça ne coute rien. Je n'avais pas du tout accroché à Jeedom malgré 2 tentatives, et tout le bien, que dis-je, les critiques dithyrambiques que j'ai entendues ça et là, donc rien ne dit que j'accrocherai plus à HA. Faut tester pour savoir. Encore une fois, c'est un choix personnel plus que purement technique. J'ai le sentiment que la prise en main est plus complexe qu'une box Home Center, mais qu'une fois ce stade dépassé, on peut faire plus de choses, ou du moins plus facilement, grâce à la communauté (qui a disparu chez Fibaro.... du coup obligé de coder en LUA si on veut faire une intégration qui n'a pas déjà été faite par un autre) Quant aux modules Z-Wave, et à Shelly, je sais pas. Ils ont repris Qubino, donc j'imagine que c'est la même ingénierie derrière. La partie matérielle des modules Qubino était plutôt OK, mais la partie logicielle c'était plutôt assez moyen (pour le dire gentiment). Espérons qu'ils se soient amélioré sur ce point. Dans le doute, Fibaro c'est toujours une valeur sure, mais bon... ça se paye.

Ils sont tous les deux en 2.4 GHz, mais ce sont des protocoles complètement différents, donc seuls les appareils Wi-Fi utilisent les AP. Les appareils Zibgee communiquent entre eux (binding, c'est comme l'association directe), ou avec le contrôleur (clé USB si c'est Home Assistant derrière, ou chipset intégré dans la HC3) C'est comme en 868 MHz, on avait le Z-Wave, EnOcean, X3D, IO HomeControl, et quelques autres protocoles qui communiquaient (communiquent au présent, ils n'ont pas encore disparu...) Ou 433 MHz, là c'est la méga-foire, d'ailleurs tout le monde l'a abandonné tellement c'était saturé. @Sakkhho je sais : tu attends quelques années que je migre sur HA et que je porte GEA sauf si quelqu'un d'autre s'y colle...

Ben oui normal, @jojo et @flacon030 font du hors sujet Pour la HC2 désolé je ne sais pas te dire, mais @Nico et @Sakkhho ont semble-t-il réussi à générer le nouveau token.

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