Lazer

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

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.