Lazer

Souci...de quoi ?

Peut être, je ne sais pas du tout en fait. Mais je pense plutôt à une modification de la syntaxe du YAML comme je l'ai évoqué dans mon message précédent, as-tu essayé les modifications comme je l'ai suggéré ?

Aucun intérêt le POE sur cet appareil, qui se doit d'être indépendant, connecté directement au compteur dans le tableau électrique. Par contre peur être qu'ils ont prévu le même type de bloc d'alimentation que sur l'IPX800 v5 sur l'EDRT3 dont la conception est quasi finalisée.

Je pense que c'est possible, en revanche ta syntaxe n'est pas bonne, le Slepp n'est pas après les ID, mais avant, il est même avant le nom de l'action à appeler ("Close" je suppose)

Bienvenue sur le forum

Bonne idée

ça a peut être changé.... Je viens de regarder le fichier exemple de la page 1 contient à la fois ota, et à la fois platform, sauf que le platform est dans climate. La doc en ligne te donne les valeurs possibles pour le paramètre platform dans ota : esphome ou http_request... à tester. Sinon, tu peux essayer de virer complètement ota, tu ne pourras pas faire les mises à jour à distance par Wi-Fi, mais ce n'est pas nécessaire, au pire tu devras rebrancher le module en USB sur le PC (c'est d'ailleurs pour ça que j'avais anticipé, dans mon tuto, avec la "rallonge" permettant de déporter le module ESP de la carte mère du split pour le débrancher facilement)

Ah ça avance Là tu dois juste avoir un petit problème d'erreur de syntaxe dans ton fichier de configuration et/ou le fichier de mots de passes.

C'est exactement le même microcontrôleur que j'ai commandé, donc ça devrait être bon. Dans ton fichier YAML, tu n'as pas une référence à esp8266 qui traine ? Si le test.yaml passe, je ne vois pas pourquoi ça ne passerait pas ensuite...

Ouh là là, c'est du chinois tout ça Tu as dû avoir quelque chose qui s'est mal passé durant l'installation de la suite de compilation ESPHome. Essaye de tout effacer et reprendre au début, car là je n'ai aucune idée du problème. EDIT : c'est normal le KeyError: 'esp8266' tout en bas ? C'est de l'ESP32 qu'on utilise normalement... tu n'aurais pas juste une couille dans ton fichier de config YAML ?

Moi aussi... espérons à une indisponibilité passagère de l'API RTE...

Voilà, nouveau topic dédié pour le projet de @Sakkhho

Ah c'est ça le terme technique, merci j'ai appris un mot aujourd'hui (que j'aurai oublié dans 1 heure ) @Sakkhho je vais scinder le topic pour que tu aies ton topic à toi, car ça commence à prendre de l'ampleur et ça n'est pas lié à mon installation, sujet du topic.

Ah oui d'accord, c'est le lien que tu avais donné. Mais de ce que je vois, c'est pas pour les toit plat, mais pour les toitures arrondies, qu'on trouve sur certains entrepôts. Niveau rendement ça être bien merdique, car les panneaux ne sont jamais correctement orientés par rapport au soleil. Et j'ai des doutes sur la durée de vie. Ton problème, ce n'est pas la forme du panneau, mais de trouver un moyen de fixer la structure en dessous. C'est pout ça que je te demandais, si sur ton toit terrasse tu as un rebord (généralement c'est le cas), et surtout qu'il est suffisamment haut, alors venir fixer la structure dessus. Ainsi, elle serait comme en lévitation au dessus du toit plat, sans jamais venir s'appuyer dessus. Après, tu comptes poser toit même ou faire poser ? Car si tu fais poser, ce sont les artisans qui vont te proposer des solutions qu'ils connaissent.

Je ne comprend pourquoi ça fait plusieurs messages que tu parles de panneaux souples ? Ce n'est pas du tout adapté à l'installation fixe sur bâtiment, ces panneaux très particuliers sont prévus pour les toits des fourgons aménagés, afin d'épouser la forme du capot. Sur un bâtiment, tu vas avoir une prise au vent démentielle, et en plus c'est plus fragile, ça ne tiendra jamais dans la durée. C'est du panneau rigide uniquement qu'il te faut utiliser, la question est de trouver un système de fixation sur ton toit-terrasse. Pas possible de fabriquer une structure qui viendrait se fixer sur les rebords verticaux ? Ainsi tu ne toucherais pas à la partie horizontale du toit. Techniquement il est possible de déporter des micro-onduleurs, bien que ça ne soit pas prévu pour.... il faut utiliser des rallonges de câbles DC avec connecteurs MC4. Pourquoi tu ne veux pas d'onduleur central ? C'est à mon avis une solution préférable par rapport à des micro-onduleurs déportés (ce qui va à l'encontre même du principe des MO)

Ah, tu aurais dû mettre le log complet dès le début, car là je pense que tu as le soucis déjà mentionné sur le topic, il fait allonger le Timeout de redémarrage.

Pas de VMC chez moi.

J'ai un modèle de chez Delonghi, acheté au Casto Merlin du coin, qui fait super bien le job. Il a l'avantage de se souvenir du dernier état de fonctionnement (marche/arrêt), donc domotisé avec un simple Wall Plug, il redémarre instantanément. J'ai simplement réglé le taux d'humidité super bas sur le panneau de contrôle pour qu'il fonctionne quoi qu'il arrive, et c'est la domotique qui gère. Attention, c'est un compresseur, ça fait pas mal de bruit, je le lance quand on est absent ou la nuit, mais faut pas rester dans la pièce... Avec la mesure de consommation de la prise, je peux détecter quand il s'arrête, car le réservoir est plein d'eau ! Alors une petite notif avec GEA pour penser à aller le vider. C'est un vieux modèle, qui n'est plus commercialisé, je ne sais pas si les nouveaux modèles savent encore conserver leur état de fonctionnement.

ça me fait penser que j'ai eu exactement le même problème quand j'utilisais GEA sur HC2, j'avais alors commenté la ligne ne me disant que je solutionnerai ce problème plus tard, entre temps j'ai migré sur HC3, et je viens de vérifier à l'instant, ma règle est toujours commenté Je pense qu'il y a moyen de s'en sortir avec NotStart et RestartTask, ou bien avec Depend. Quelques pistes à creuser... Attention Jojo avec le JSON modified, ça correspond au timestamp de modification du QuickApps, pas à son démarrage. Il peut avoir redémarré 100x depuis la dernière modification... par exemple après un plantage, un reboot, une sauvegarde, etc...

Le message est clair : No client connected to API. Rebooting Puis juste après : Forcing a reboot Ce n'est donc pas un problème de stabilité, mais au contraire, le watchdog qui entre en jeu, un mécanisme pour s'assurer de la stabilité du programme qui tourne. Je traduis : s'il n'y a pas de connexion à l'API depuis le réseau, c'est louche, peut-être qu'il y a un souci quelque part (un processus qui aurait crashé par exemple), donc par sécurité on force le reboote pour tout redémarrer proprement. Maintenant la question, c'est : pourquoi tu n'utilises pas l'API ? Si tu utilises un autre mode de connexion, tel que MQTT, ou les URL HTTP, alors il faut désactiver l'API. Pour cela il te faudra modifier le fichier de configuration YAML. Attention cependant, si l'API est désactivée, tu perdras les fonctionnalités de journalisation et debuggage à distance. Mais si tu ne les utilises pas, tu peux t'en passer.

Plusieurs pistes, en fait ça dépend de tes besoins : - tu peux ajouter des règles pour changer le mode / température du thermostat s'il est dans le mode précédent depuis 2 h (soit une durée de 2*60*60 secondes) - dans tes règles existantes, tu peux aussi positionner une variable cache lors du changement de mode du thermostat, afin que GEA sache que c'est lui-même qui a mis le thermostat dans ce mode, et puis une autre règles comme pour ma suggestion précédente, au bout de 2h revenir à un autre mode si la variable cache a la valeur qui va bien (ainsi, contrairement à la première suggestion, ces nouvelles règles GEA ne réagiront que si c'est GEA lui même qui a changé le mode de thermostat, mais pas l'utilisateur directement) - utiliser la durée dans l'action Climate en mode Manual, et ne pas utiliser les actions/conditions de thermostat (vu que le panneau de climat, lorsque modifié, va agir directement sur le(s) thermostat(s) de la zone)

Oui : poster sur le sujet du Support GEA

Ah non, attention, comme d'habitude, tout est dans le : Donc potentiellement de grands changements que l'on découvrira à l'occasion

Firmware 5.163.59 BETA 17/10/2024 Thank you for using our gateway! Be sure to update to the latest version to enjoy new features and improvements. Make sure that you are using the newest version of the mobile application for the best experience. New features: Nice Added a feature for synchronous movement of blinds and shutters using Bidirectional radio protocol when used in group actions. Bug Fixes: Access Fixes in the UI for configuring rights for advanced user. Devices Fixed status presentation on Door Locks icons in some cases. Fixed current override status presentation for thermostats control dialog. Fixed issue with automatic change of device icon based on selected role for some device types. History Lack of icon for some events from FGT-001. Gateway Connection Fixed issue with connecting a new Slave hub that occurred in 5.162 Beta. Fixed issue with accessing backups on the Slave hub in rare cases. Other Small UI/UX fixes. QuickApps Fixed issue with icons handling for some devices types like Weather provider. Z-Wave Fixed rare issue with starting the Z-Wave service when controller Node ID is different than 1. Solved issue with mesh network reconfiguration not working. Fixed issue with not hiding automatically console log after finishing adding or removing process. Known issues: Z-Wave Engine 3.0 Some Z-Wave devices are not fully compatible with the new version of Z-Wave engine. * - Does not apply to HC3L (Home Center 3 Lite). ** - Applies only to Z-Wave 3.0 engine.

C'est tout de même étrange ta condition "Or" avec les 2 sous-conditions qui se complémentent : weekdays ou weekend, il y a obligatoirement une des 2 conditions qui est valide, donc la condition Or est toujours valide => donc inutile. Pourquoi ne pas la supprimer ? D'autant plus si ça rend GEA fou, car le comportement de ta 2nde règle ne me semble pas normal.