Lazer

Non attention, là c'est le topic original de GEA pour HC2. Pour la HC3, c'est par ici : Tu y trouveras les explications de mise en oeuvre et le lien avec la doc de syntaxe. C'est l'action "Protection" que tu devras utiliser pour ton usage.

Si c'est faisable via le GUI, c'est forcément faisable en LUA. Pour GEA, commence par regarder la doc de syntaxe pour comprendre la logique de base. Pour le reste, ça se passe sur le topic du Support GEA (des centaines de pages de bonheur )

Non ce paramètre n'est pas au même endroit que les autres paramètres, il est dans l'onglet Avancé du module : Protection locale : les interrupteurs connectés au module Protection à distance : les commandes radio Z-Wave

Idée qui me semble la plus efficace : bloquer la commande locale des volets. Normalement tu as ce paramètre dans les propriétés de ton module, à vérifier. Si OK, alors il suffira de créer 2 règles dans GEA qui activent et désactivent la commande locale en fonction de l'état de la fenêtre.... ça peut aussi se coder en LUA dans un QA ou une Scène, mais ça te fera plus de boulot.

Mauvais site

Malheureusement pour les scènes uniquement, ça n'a jamais existé dans les QuickApps.

Non pas encore changé le profil, car pour l'instant je n'ai pas encore installé les micro-onduleurs Enphase sur l'AC-Out secouru du Victron (en AC Coupling).... et surtout, je n'ai pas encore branché la maison dessus. En effet, pour l'instant, mon câblage, encore temporaire, ne permet pas de fonctionner en autonomie. Je ferai ça cet été dès que j'aurai un moment seul à la maison pour une journée entière, car il faut que je recâble le tableau principal avec l'inverseur de source et tout et tout (comme sur le schéma), directement en sortie du disjoncteur de branchement Enedis.

Victron et Enphase : communication par Modbus Depuis la mise à jour 3.60 de Venus OS de début juin 2025, on apprend que Victron supporte maintenant la communication avec Enphase via Modbus SunSpec : Ce qui signifie que Enphase a enfin ajouté le support du Modbus à leur passerelle Effectivement, tout cela est maintenant officiellement documenté par Enphase dans le PDF suivant, qui date de janvier 2025 : AC-coupling with Victron battery inverters using Modbus TCP/IP J'ai donc demandé l'activation au support Enphase. 15 jours plus tard (c'est aujourd'hui), le support me répond que Modbus a été activé sur ma passerelle Envoy-S Metered Et je confirme que ça fonctionne Je peux interroger l'Envoy directement avec Modbus Doctor sur le port TCP 502. On a accès aux données de chaque MO indépendamment. L'Envoy est maintenant reconnue par le Cerbo GX en tant que "Convertisseur PV", qui affiche les données de production sur le tableau de bord (et ça remonte également dans VRM) Dans la vue des appareils, l'Envoy apparait bien : (seulement 46W de production, c'est normal il fait bientôt nuit) Et la vue détaillée : Le Victron n'affiche pas le détail de chaque MO, mais on s'en fout, c'est la production globale qui nous intéresse. Quelques remarques : Je peux en retour interroger le Victron via Modbus (ce que je fais déjà via domotique), et j'ai accès autant aux données du Multiplus, de la batterie Pylontech, etc, mais aussi de la passerelle Enphase Envoy, ce qui est marrant car elle est elle-même interrogée par le CerboGX par Modbus On constate sur le 1er screenshot que j'ai aussi un compteur VM-3P75CT qui fourni la même information, car j'avais spécifiquement installé celui-ci sur la phase de mon installation Enphase pour remonter les statistiques.... Du coup l'information est maintenant redondante et cet appareil ne sert plus à rien dans mon installation... si j'aurais su j'aurais pu économiser quelques euros ! Le point intéressant, c'est que la mesure du VM-3P75CT est complètement foireuse (forte variation) lorsque la prod solaire est faible, en début/fin de journée. Donc je vais le virer, et j'aurais l'information remontée avec précision par l'Envoy via Modbus. Nickel tout ça Comme le précise Enphase dans la doc, c'est de la lecture seule, donc on peut interroger, mais pas piloter. En cas de fonctionnement off-grid, si les MO Enphase sont connectés sur la sortie AC Out secourue, et que la batterie est pleine, alors ça fonctionne comme avant : par variation de fréquence, ce qui fonctionne depuis des années (d'ailleurs ça reste la grande différence d'intégration avec un Fronius, pour qui le pilotage se fait en bidirectionnel via Modbus) : En effet, pour rappel, en cas de fonctionnement off-grid, donc déconnecté du réseau, il faut impérativement ralentir puis arrêter complètement la production solaire quand la batterie est pleine, sinon... BOUM

C'est comme si nos 2 box se sauvegardaient ensemble, main dans la main

OK, alors ce n'est pas possible à ma connaissance. Si tu veux paramétrer des trucs, c'est dans les variables du QA qu'il faut le faire, pas directement dans le code LUA.

Ce sont les Custom Events, on en parle un peu ici : Et je constate que toi même tu les utilises déjà : C'est une fonctionnalité assez peu utilisée, ce qui est étonnant c'est qu'un QuickApp peut tout à fait émettre des Custom Events, un autre QuickApps peut les intercepter pour les traiter (ça agit alors comme un déclencheur), pourtant ils n'apparaitront jamais dans l'onglet de ta capture d'écran. De là à dire que cet onglet ne sert à rien, il n'y a qu'un pas... C'est différent des variables globales (ou variables de QuickApps). Les Variables servent à mémoriser une valeur. On peut éventuellement déclencher (trigger) une action lors du changement de valeur d'une variable, mais ce n'est pas l'usage premier. Les Custom Events, c'est juste un événement, ponctuel, qui ne sert qu'à déclencher une action. Rien d'autre.

Je n'ai pas compris la question. Tu veux créer des notifications ? ça c'est facile et possible depuis toujours, il faut utiliser notificationService : https://manuals.fibaro.com/home-center-3-lua-scenes/ Ou tu veux ajouter des lignes dans l'onglet Notification de ta capture d'écran ? Ce qui à ma connaissance n'est pas possible, il faut se contenter des choix déjà proposés, et qui correspondent au type de QuickApp créé (binarySwitch, etc...). Dans ta capture d'écran, on ne vois que le statut Indisponible qui correspond à la propriété dead, que tous les QuckApps doivent normalement déjà avoir.

Pour info je viens de tester sur mon NAS et la commande tee -a qui crée bien le fichier s'il n'existe pas.

Tu es sûr que tu utilises bien des tirets "-" et pas un caractère à la con remplacé automatiquement lors de la saisie ou d'un copier-coller ? Car Word par exemple est le spécialiste pour remplacer le tiret simple par un tiret allongé. En France, on dit souvent le "tiret du 6", car il se trouve sur la touche 6 de nos claviers Azerty, mais pas sûr que ça soit pareil en Belgique.

Ah trouvé, j'en étais sûr, il est revenu, t'es mal @jojo

Oui; normalement pas de souci. Après, il faudrait vérifier un truc quand même, dans les process qui tournent : admin@DiskStation:~$ ps -ef | grep -i "chat noir"

Pas de souci, c'est comme chez moi, il faut que tu regardes la ligne "." qui correspond au répertoire courant de ton chemin, donc /volume1 : @SynoMain:~$ ls -la /volume1/ total 4 drwxr-xr-x 1 root root 526 Jun 23 09:22 . Je n'ai pas employé les mêmes arguments pour la commande ls, d'où la différence de résultat.

Non, justement j'avais ce doute aussi, j'avais vérifié et ça ne pose pas de souci, exemple chez moi, seul root a les droits en écriture sur le point de montage /volume1 : admin@DiskStation:~$ ls -ld /volume1 drwxr-xr-x 1 root root 614 May 19 11:40 /volume1

Pas de raison que ça change quelque soit l'utilisateur, car les droits sont rwx (read write execute) sur tous les fichiers et répertoires pour l'ensemble des utilisateurs (owner, group, et other) Permissions UNIX : https://fr.wikipedia.org/wiki/Permissions_UNIX

Très étrange, tout m'a l'air OK. Le SSH n'est pas utilisé, l'exécution du script se passe en local sur le NAS.

Vérifie les droits et propriétaire aussi : ls -la /volume1/ScriptsUnix/ Chez moi le script tourne avec le compte admin, comme dans le tuto en 1ère page. Et je n'ai pas mis de double-quotes autour des chemins, c'est inutile car il n'y a pas d'espace, mais leur présence ne devrait rien changer.

Ton répertoire /volume1/ScriptsUnix existe bien ?

Nouvelle version 3.23 en première page et mise à jour du tuto. Ajout d'une variable WAIT_AFTER_BACKUP permettant d'attendre avant le téléchargement du fichier, ce qui permet d'éviter l'erreur 404. La valeur par défaut de 60 secondes devrait contenir à la majorité des box, il faut augmenter la valeur si nécessaire.

Moi je n'aime pas l'arrêt propre, car quand le courant revient, bah.... la box ne redémarre pas ! J'ai le même problème avec mon serveur, contrairement à beaucoup, je me suis toujours refusé à programmé un arrêt propre, enfin surtout automatique, du serveur avant épuisement de la batterie de l'onduleur, car dans ce cas le serveur ne redémarre jamais, ce qui en cas d'absence est un vrai problème. Je préfère avoir au pire une coupure violente une fois de temps en temps, autant de la box domotique que tu serveur, puis que tout redémarre automatiquement quand le courant revient (et que l'onduleur commence à réalimenter sa sortie) Après, j'ai assez peu de coupure de courant chez moi, en moyenne 1 fois par an, et la grande majorité du temps c'est quelques secondes, donc finalement les cas d'épuisement de la batterie et de coupure violente des équipements sont très très rares. Si ça arrivait tous les 2 mois, il est probable que je raisonnerais différemment (en fait ça fait longtemps que j'aurais trouvé une meilleure solution... plus gros onduleur, ou mieux solution type onduleur autonome pour alimenter toute la maison avec batterie + panneaux solaires)