Lazer

@henri-allauch à priori c'est à partir de la Beta 5.153.120, donc on peut anticiper à partir de la Stable 5.160.xx @TitiXsi les APK des applications mobiles Fibaro sont disponibles sur leur site directement : http://android.fibaro.com/

J'ai créé un nouveau topic pour discuter de cette nouvelle nouvelle (non je ne bégaye pas) application mobile Yubi Home :

Yubii Home Nouvelle application mobile sortie en février 2024, à ne pas confondre avec "l'ancienne nouvelle" application mobile Fibaro Home Center sortie en décembre 2018, puis renommée Yubii Home Center. Pas évident de suivre, mais l'élément différenciant, c'est qu'ils ont retiré Center dans le nom de l'application A noter que Yubii Home Center supporte HC2 + HC3, tandis que Yubii Home ne supporte que la HC3 (et autres box récentes, déclinaisons Lite, etc...) Cette application introduit un nouveau mode d'affichage des QuickApps, il est possible de revenir à l'ancien à l'aide de la case à cocher "Use the new views in mobile application " dans les paramètres des QuickApps sur l'interface Web de la box : Application disponible sur les 2 plateformes Android et iOS : Google Play Store : https://play.google.com/store/apps/details?id=com.niceforyou.yubii Apple App Store : https://apps.apple.com/us/app/yubii-home/id6477485519

Si tu mets 3, c'est exactement comme si tu mets 0, puisque tu seras dans le mode de fonctionnement par cycle de 30s de GEA. Donc un déclenchement entre 0 et 30s maximum après la détection du mouvement. Voir les explications dans la doc de syntaxe. Mais j'y pense, les ID 172, 210, etc... je n'ai pas l'impression que ce soit des ID de détecteurs de mouvements, vu que dans tes lignes d'extinction de la lumière on retrouve les mêmes ID, donc je suppose que ce sont les ID des lampes. Dans ces conditions, si tu attends que la condition (la lampe est allumée) soit vraie pour effectuer l'action (allumer la lampe), tu risque d'attendre longtemps... éternellement même ! Le serpent qui se mort la queue... Bref, faut mettre les ID de tes détecteurs de mouvement à la place. EDIT : j'ai relu ta demande, tu veux juste que la lumière s'allume au coucher du soleil.. dans ce cas encore plus simple : GEA.add({"Time", "Sunset", "Sunset+1"}, 0, "", {"TurnOn", {172, 210, 267, 269}}, "Allumage des 4 lumières au coucher du soleil") Inspiration trouvée dans la doc de syntaxe, que tu devrais vraiment commencer par lire, il y a plein d'explication et surtout des tonnes d'exemples.

Génial, merci pour l'info. En revanche je ne vais pas faire la modification du QuickApp tout de suite, j'ai d'autres sujets sur le feu là, mais je garde ça sous le coude. Par ailleurs je vois que ce change n'est pas encore intégré à la branche principale du projet, avec un peu de chance ça le sera bientôt.

Bienvenue sur le forum

Bienvenue sur le forum

Comment tu as trouvé la configuration des ailettes horizontales et verticales ? Je n'ai rien vu de tel sur la page du projet : https://github.com/geoffdavis/esphome-mitsubishiheatpump

Ce qui m'embête toujours avec ce genre de produit, c'est que c'est totalement dépendant du cloud, et du compte Amazon en l'occurrence. Donc ça va être limité aux objets connectés officiellement supportés par Alexa, et de la présence d'Internet, puisque même si la HC3 est supportée au travers de 2 clouds (Amazon + Fibaro), la communication ne se fera pas en local. Quid des caméras supportées ? L'espoir, c'est la compatibilité Matter, puisque tout devrait fonctionne en local et avec un protocole unifié, mais bon, pour ça, faudrait que ce protocole décolle vraiment, pour l'instant ce n'est pas encore ça...

Dans tes 4 premières règles avec l'action TurnOn, la durée n'est pas bonne, puisque tu as mis "", or il faut mettre un nombre. Pour un allumage de lumière, normalement on veut de l'instantané, donc durée = -1. Exemple : GEA.add({172, {"Global", "alba_tramonto", "tramonto"} }, -1, "", {{"turnOn"}}) GEA.add({210, {"Global", "alba_tramonto", "tramonto"} }, -1, "", {{"turnOn"}}) GEA.add({267, {"Global", "alba_tramonto", "tramonto"} }, -1, "", {{"turnOn"}}) GEA.add({269, {"Global", "alba_tramonto", "tramonto"} }, -1, "", {{"turnOn"}}) Pour la documentation de référence de GEA, voir ce topic avec le lien vers la doc de syntaxe en première page :

Les betas testeurs, il faut faire remonter vos griefs à Fibaro via le forum officiel, avec la sortie de cette nouvelle application toute buguée, ils sont à l'écoute des retours utilisateurs en ce moment, il faut en profiter. Après, ça sera surement trop tard...

Ah mais très clairement, NICE (tout comme Fibaro en fait), n'a jamais eu l'intension d'aller vers un usage plus avancé. Chez Nice, ils se positionnement comme un concurrent à Somfy, et de ce coté là, la HC3 est 1 million de fois plus évolué que la box proposée par Somfy. Ils vendent des automatismes, des système intégrés, et leur cible c'est plus les intégrateurs que les clients finaux que nous sommes. Pour revenir à la HC3, je pense que son seul vrai concurrent c'est la box Homey. Je considère que Home Assistant n'est pas du tout un concurrent, c'est juste un autre marché. Il n'y a même pas de débat à mon sens.

Hum, je ne me souviens plus bien comment j'ai trouvé la syntaxe de la fonction, mais par contre je me souviens avoir chercher longtemps... Merci pour ta trouvaille, je n'ai même pas creusé aussi loin.

Je pense que tu es le premier à rencontrer ce problème, mais effectivement, à la lumière de cette discussion je me disais que ce n'était peut être pas si clair, et qu'il fallait ajouter une remarque à ce sujet dans le tuto... Je vais donc le faire.

Encore une fois, souvenez vous de la nouvelle ancienne application Yubii Home Center (celle qui venait en remplacement de la vieille application Fibaro), elle était complètement inutilisable pendant au moins 1 an, puis il a fallu encore 1 année supplémentaire pour la rendre à peu près agréable (les modules manquants, les QA qui ne s'ouvraient pas toujours, les icônes avec un point d'interrogation) Souvenez vous... C'est du Fibaro quoi, l'histoire se répète à chaque fois, ils sortent un nouveau produit, c'est ultra buggué et inutilisable, et quelques années après, quand c'est enfin super stable, ils arrêtent le développement du produit. Rien de nouveau, faut juste être patient pragmatique et utiliser l'ancienne application, ça ne pose aucun problème.

Le reboot est normal, car dans le YAML, l'API native est activée, donc il s'attend à une connexion. Dans ton cas, tant que tu ne connectes pas le QuickApp sur ton module (ce que tu peux faire même sans être connecté au port CN105), le module rebootera à intervalle régulier avec le message "No client connected to API. Rebooting..." C'est une sorte de watchdog intégré, les développeurs d'ESPHome ont pensé à tout

En fait, pour le coup, il ne fallait pas avoir de logique, parce que.... : Tu ne mets aucune étiquette, tu mets juste la ligne telle quelle, avec EAST. C'est un hack dans le QA lui-même, la téléinfo est gérée d'une façon assez particulière, différemment de toutes les autres pins. La fonction dédiée dans le code LUA va détecter le bon type de champ à utiliser, et faire la somme de tous les index (car il sait aussi prendre en compte les abonnements EJP, quelqu'un l'avait demandé ici) Donc c'est générique, facile, mais ça ne fait pas dans le détail. Comme dit, le module enfant téléinfo aura comme énergie la somme de tous les index. Et si j'ai fait ça, la raison c'est lié à la box Fibaro, à son panneau d'énergie, car le module enfant téléinfo peut être utilisé directement dedans, afin de voir la conso journalière, directement dans l'appli (sans distinction des tranches horaires) ça m'a l'air pas mal du tout ça. Effectivement avec DIndex c'est mieux pour récupérer les données. Oui, oui, et oui normalement (avec pin = EAST comme répété plus haut)

Ta seule et unique ligne de configuration pour lire la téléinformation doit être exactement comme celle donnée en première page (et dans l'exemple fourni lors du téléchargement du QA), soit : {device = {name = "Téléinfo", type = "Teleinfo", options = {VG = "TELEINFO_Tarif"}}, value = {command = "Get", argument = "TI", pin = "EAST"}}, Tout ce que tu peux changer, c'est la valeur de name (c'est le nom qui est donné au module enfant lors de la création, et en pratique ce n'est pas limitant car tu peux le changer après, directement dans les propriétés du module dans l'interface Web de la box) Là tu as voulu jouer à l'apprenti sorcier, donc forcément, ça ne marche pas Pourquoi il n'y a pas de message d'erreur, je ne sais pas... j'essaye toujours de mettre un maximum de tests dans mes QuickApps pour parer à tous les cas de figure, mais il y a toujours un utilisateur très inventif qui arrive à trouver une faille dans le bousin. Bravo Le QA n'est pas prévu pour aller récupérer les différents index.... je ne l'ai pas prévu car je ne vois pas trop l'intérêt à vrai dire. Si tu veux quand même le faire, une astuce serait de mapper les index de la téléinfo sur des sous-postes regroupés au sein d'un poste dédié à la téléinfo (à configurer sur l'EcoDevice directement) puis de créer autant de ligne que nécessaire dans la config du QA pour aller lire chacun des sous-postes. Exemple de ce que je fais pour mon chauffe-eau : {device = {name = "Chauffe-eau", type = "EnergyMeter"}, value = {command = "Get", argument = "C", pin = "C2"}}, Bon là c'est un compteur (C), mais tu peux aller chercher, par exemple, le sous-poste 1 du poste 2 avec "P2_SSP1" Je te renvoie vers la doc de l'API EDRT2 fournie par GCE : https://wiki.gce-electronics.com/index.php?title=API_EDRT

When I click on Heat or Cool in S1, then S2 reflects the change. Whereas if I choose another value (Auto or Off) then S2 displays Choose.

Désolé j'ai oublié de répondre à la seconde question. Bien sûr, tu peux faire toute la config avec l'ESP32 attaché et alimenté en USB par le PC. De toute façon lors de la première compilation du programme, pour l'envoyer sur l'ESP32, il doit obligatoirement être connecté en USB au PC, et c'est bien par ce port qu'il va tirer son alimentation (en 5V)

C'est bien pour cela que je t'ai suggéré de regarder aussi le panneau d'événements de la box lorsque le problème se produit, pour dédouaner, ou non, les seuls QuickApps. Pour le QA GCE, là aussi je t'ai suggéré de continuer sur le topic GCE, afin de limiter les hors-sujets, et donc de regrouper les infos là où elle doivent être.

Sur la première page il y a la référence du connecteur officiel "PAP-05V-S", et le PDF des spécifications complètes en téléchargement, dont voici un extrait : Si tu as un pied à coulisse tu peux vérifier si ça correspond exactement à ton connecteur, notamment pour sa largeur qu'on n'arrive pas à deviner sur la photo. Pour la correspondance des couleurs c'est pas trop grave, l'important est de s'y retrouver. Mais normalement, avec une petite pointe, tu peux déclipser les contacts métalliques pour les sortir du boitier en plastique blanc, puis les réinsérer dans l'ordre désiré.

OK, je commence à y voir plus clair. Déjà tu as un problème intermittent avec ton QA qui se bloquent certaines nuits, ce n'est pas normal, et ce n'est pas lié à mon QA, je pense que le problème provient plutôt de la box, il faudra donc rester vigilant sur la prochaine occurrence de ce bug. Néanmoins ce bug est sans rapport avec la suite... Le QA interroge RTE à intervalle régulier jusqu'à 10h30, car bien que l'information de couleur du lendemain est généralement publiés à 7h du matin, l'information n'est légalement contractuelle qu'à 10h30. En faisant cela, au réveil on connait la couleur du lendemain, mais le QA s'assure jusqu'à 10h30 qu'elle ne va pas changer. (puis à 11h c'est au tour de EDF) Ce qui ne devrait pas poser de problème puisqu'en contrat Tempo, la téléinformation bascule d'horaire à 6h du matin, donc ça fait déjà 1 heure que la variable globale TELINFO_Tarif doit être à jour. Si. Donc là il y a un problème. J'avais un doute sur le fait que mon QA Tempo sachent bien prendre en compte le mode Historique de la téléinfo, que je n'ai pas pu tester vu que je suis en mode Standard, mais d'après le code source LUA ça devrait bien prendre en compte ton tarif HPJW, et le transformer en couleur exploitable : -- Recherche téléinformation PTEC en mode historique if string.find(vgTeleinfoTarif, "JB") then newTeleinfoTarif = "BLEU" elseif string.find(vgTeleinfoTarif, "JW") then newTeleinfoTarif = "BLANC" elseif string.find(vgTeleinfoTarif, "JR") then newTeleinfoTarif = "ROUGE" end Vu que le QA a détecté du BLEU, c'est que ta VG porte la valeur HPJB au lieu de HPJW, et c'est l'origine du problème. Normal car il donne priorité à la couleur de la Téléinformation, qui est censée être plus fiable que l'information provenant du Cloud. En effet, les serveurs cloud peuvent être bugués, tandis que la téléinfo est issue directement du compteur Linky, et c'est le seul qui fait foi dans la facturation de l'abonné. On voit clairement dans ton log le message Tarif téléinformation non trouvé dans la Variable Globale TELEINFO_Tarif : """" donc c'est cohérent. Oui Effectivement. Le bug provient de ta config. Je te laisse relire mon tuto sur le topic GCE, et continuer la discussion là bas, mais en synthèse, tu ne peux avoir qu'une seule ligne de configuration pour la Téléinfo. Là tu en a 6, c'est pas bon, d'ailleurs le QA GCE devrait t'envoyer au moins un avertissement.

C'était effectivement mon interrogation de départ, connecter Alexa sur mon ampli Yamaha. Après, je ne suis pas certain d'avoir envie d'entendre la musique de ma fille sur l'ampli du salon...

Oui clairement... (mon message précédent était sarcastique hein )