Lazer

Parce que l'IPX800 est au garage, qui est loin, très loin de la cave. Le FGR était la solution la plus simple (comme tout module Z-Wave, ça évite de tirer des câbles) Le seul câble que j'ai tiré, c'est l'alimentation électrique (fallait bien, il n'y avait pas de courant de ce coté-ci de la cave... j'en ai profité pour ajouter 2 prises de courant). Ah et aussi le câble de comptage des impulsions, un peu obligé pour le coup, vu qu'aucun module Z-Wave n'existe pour faire du comptage d'impulsion (c'est quand même étonnant qu'aucun fabricant ne s'y soit intéressé).... du coup il est branché sur l'EcoDevice, qui lui est bien dans la maison, à quelques mètres. (petite précision, avant de me brancher sur l'EDRT2, j'ai utilisé pendant des années une carte Piface sur un Raspberry PI 1.... qui a pris sa retraite bien méritée cette année.... et ça fait 1 truc de moins à maintenir) Ma gestion de l'arrosage chez moi est on ne peut plus simple, il n'y a rien d'automatisé. J'allume manuellement, je coupe manuellement, sauf si j'oublie, auquel cas GEA coupe tout seul. Du coup mon scénario GEA est ultra basique, c'est une règle la plus simple du monde, qui coupe l'arrosage au bout de 10 minutes. Le mieux c'était l'été 2021, j'ai juste pas eu besoin d'arroser pour conserver une herbe verte pendant tout juillet/août, c'était juste incroyable... mieux que la domotique, la météo pourrie

J'avais le même départ que toi. J'ai conservé cette vanne d'arrêt mécanique (on l'aperçoit tout en bas de la photo), et j'ai ajouté en aval une vanne motorisée (ce n'est pas une électrovanne) et le compteur d'eau Gioanola bien connu des domotiseurs en herbe : La vanne mororisée est pilotée par un module Fibaro FGR pour volet roulant. L'avantage, contrairement à une électrovannne, c'est que ça consomme 0 Watts. La consommation est de 5 ou 10W pendant la manœuvre qui dure 12 secondes, donc autant dire rien du tout. Le compteur est branché sur une entrée numérique d'un EDRT2, qui compte, et remonte les infos dans la HC3, avec mon QA que tu connais. Cela fonctionnerait pareil avec l'IPX800 v4. Après y'a plus qu'à écrire ses propres scénarios (GEA pour ma part)

C'est rien ça, tu es dans les variations normale de la consommation de RAM pour un QA. Mon QA pour l'EDRT2 dépasse régulièrement les 2 Mo, puis redescend vers les 700 ko, et ça oscille en permanence. C'est le Garbage collector qui fait son job, "quand il en a envie". Le message "LUA memory usage is increasing" provient de ma librairie tools, je l'ai mal réglé car il a tendance à avertir un peu trop vite alors qu'en fait tout va bien. Pour info dans la version précédente du QA événements, j'étais monté à 180 Mo de RAM utilisée... Joli record, la HC3 a décidé que c'était trop, elle a tué le process, et ne l'a pas redémarré (alors que le watchdog intégré est censé redémarrer les QA plantés). La morale de l'histoire, on a une marge de manœuvre énorme, et la HC3 réagit très bien en cas d'abus.

Bienvenue sur le forum

Je vais très peu sur l'interface de l'IPX800v4, mais oui j'ai des lenteurs. A priori les ressources sont trop limitées... l'IPX800v5 est censé être plus rapide (pas encore testé)

Héhé.... en plus je crois que c'est la seconde fois en 24h que tu as un caractère caché qui traine

Etrange, je n'ai pas ce problème.... et mes URL sur l'IPX800 semblent tout à fait identiques.

Je ne comprends pas bien comment tu pourrais avoir une erreur en ligne 27 du fichier GCE dans ton QuickApp, car c'est le début du fichier, là où il y a des déclarations de variables... aucun test n'est effectué à ce niveau là qui pourrait aboutir à une erreur de comparaison d'un nombre avec nil => tu es certains que tu n'as pas modifié les fichiers, même par erreur ? Dans ce cas, commence par essayer de reprendre les fichiers LUA dispos en 1ère page, normalement tu ne dois customiser que le fichier CONFIG. En plus là, tu utilises vraiment les fonctions de base du QA, la gestion des capteurs binaires, ça fonctionne depuis la toute première version du QA. Entre temps j'ai une version un peu plus avancée chez moi, mais ça ne corrige que des bugs liés à la mise en production de mon EDRT2 (mesure d'énergie, etc), je n'ai pas touché au reste.

De mémoire j'utilise upsOutputSource pour détecter si on a basculé sur batterie, et dans ce cas actualiser plus souvent. Le reste du temps c'est inutile, donc intervalle allongé afin de ne pas consommer de ressource inutilement. Il faudrait modifier la boucle plus en profondeur.... donc se replonger dans le code LUA... Normalement pour les ventilateurs on utilise des modèles avec tachymètre intégré (4 fils je crois je ne sais plus), c'est ce que font les cartes mères de PC par exemple. En dehors de ça, je ne me suis jamais posé la question...

@shooty77 @Manech Vous voulez bien arrêter de citer systématiquement le message précédent le votre ? C'est totalement illisible votre discussion là.... un peu de respect pour les lecteurs SVP, en plus ces mêmes lecteurs auraient été susceptibles de vous aider.... Merci pour tout le monde, et pour vous même compris du coup. Rappel :

Oui, il faudrait modifier la boucle pour interroger plus souvent pour l'état des capteurs, mais attention quand même, c'est loin d'être une solution idéale : - ce polling régulier et fréquent est peu efficient et va consommer plus de ressource (CPU et RAM sur la HC3) (ainsi que réseau mais c'est négligeable à mon avis) - ça restera un polling, donc avec un retard d'un certain nombre de seconde. Il ne faut pas avoir d'application critique nécessitant une réaction instantanée sur ces 2 contacts sec. Toi tu as une idée d'application (contact de porte), à voir si le jeu en vaut la chandelle. Perso je n'ai pas usage (pour l'instant) de ces 2 contacts, seules les informations de température/humidité m'intéressaient, donc je n'ai pas creusé plus loin.

Désolé j'avais mal compris, car je n'avais pas vu que la station peut envoyer ses données dans le cloud via sa connexion Wi-Fi. Dans ce cas en effet, il doit être possible de récupérer directement ces informations. C'est exactement de cette façon que ça se passe avec Netatmo, la station envoie les données sur le cloud, et on les récupère directement depuis un QuickApp sur la HC3, sans passer par Jeedom. Cela dit, la discussion sur le forum Jeedom que tu as pointé n'est pas très engageante.... l'API a l'air mal documentée (le PDF n'est plus accessible), limitée (bon, celle de Netatmo aussi, et c'est bien normal pour éviter les abus) A voir si tu arrives à t'en sortir avec les infos partagées sur le forum Jeedom. Mais j'ai le sentiment que récupérer les infos sur le cloud de Lacrosse va te demander encore plus de travail que ce que je pensais initialement (à savoir récupérer les infos depuis Jeedom)

Pour faire une requête http depuis la HC3 : Idéalement dans des QuickApp, chacun avec le bon type (capteur de température, humidité, etc) Mais je te conseille quand même de retrouver le tuto pour faire communiquer Jeedom avec Fibaro, ça t'évitera de réinventer la roue, surtout que tu ne sembles pas très à l'aise en LUA. Je pense que ça sera plus optimisé. Car la solution avec net.HTTPClient sera du polling régulier, pas très efficient. L'idéal, c'est que Jeedom envoie (push) la valeur vers la HC3 dès lors que la valeur change, ça présente 2 avantages : - pas de trafic inutile - la valeur est mise à jours instantanément, sans retard

Bienvenue sur le forum

Ouais bien ça c'est pour Jeedom, après comme je te disais dans mon message précédent, il faut faire remonter les infos entre Jeedom et la HC3. Il existe déjà des choses à ce sujet, sur le forum, si tu fais une recherche ta vas le retrouver. Un peu de travail, ce n'est pas du plug and play là PS : je n'utilise pas Jeedom, donc en dehors de te guider sur les grandes lignes, je te pourrai pas t'apporter d'aide technique.

Ah mais attends, ça fonctionne fibaro:getModificationTime() ? Dans ce cas c'est la solution la plus simple non ?

Pas à ma connaissance. Si tu n'as pas besoin de la value, tu peux écrire ta ligne ainsi : local _, modificationTime = fibaro.get(DEVICE_ID, "value")

868 MHz OK, mais ce n'est pas du Z-Wave, donc jamais ça ne communiquera directement ensemble. Peut être en passant par un RFXcom ou un RFPlayer, il faut regarder leur liste de compatibilité. Puis brancher la clé en question sur une machine sachant le supporter, quels que Jeedom ou Home Assistant, que tu feras communiquer avec la HC3. Un peu de travail en perspective...

Sorry I have no idea, I have never seen this error

Oui ici (le script pour HC2 est à la fin) : Et.... c'est stable depuis des années

Ouh là là Je vais te laisser te débrouiller tout seul là, si je te disais que je m'en occuperai ultérieurement, c'est que je n'ai aucune envie de me plonger dans ce code LUA maintenant....

Non jamais car je ne les exploite pas. Tu en as besoin ? Je pourrais éventuellement l'ajouter plus tard... un jour quand j'aurai le temps, avec quelques bricoles que j'ai déjà sur ma toto-list pour ce QA. Apparemment il s'agit de upsmgEnvironmentInput1State et upsmgEnvironmentInput2State accessibles sur 1.3.6.1.4.1.705.1.8.7.1.9 et 1.3.6.1.4.1.705.1.8.7.1.10 respectivement : (j'écris ces infos ici même si ça ne parle à personne, juste parce que me servira de bloc note quand je m'y remettrai) upsmgEnvironmentInput1State OBJECT-TYPE SYNTAX INTEGER { closed(1), open(2) } ACCESS read-only STATUS mandatory DESCRIPTION "State of Input#1 : closed(1), open(2)." ::= { upsmgEnvironmentSensorEntry 9 } upsmgEnvironmentInput2State OBJECT-TYPE SYNTAX INTEGER { closed(1), open(2) } ACCESS read-only STATUS mandatory DESCRIPTION "State of Input#2 : closed(1), open(2)." ::= { upsmgEnvironmentSensorEntry 10 }

C'est mieux oui. Il te faudra utiliser le serveur SMTP de ton fournisseur d'accès à Internet. Je n'ai jamais testé les fonctions d'autotest de la batterie, mais je sais que l'onduleur fait certains tests tout seul, une fois de temps en temps, car je reçois une notification par email de bascule sur batterie pendant 1 seconde. De même que le Module Virtuel et le QuickApp qui relèvent également information, ce qui ne manque pas de me faire sursauter à chaque fois que je reçois cette notification.... qui est donc une fausse alerte.

Là je ne sais pas, j'ai fait une rapide recherche mais je ne trouve rien non plus au sujet de ces tests. Cela dit, je pense que tu fais fausse route, tu te prends la tête pour rien. L'objectif de ce QuickApp est de remonter l'état de l'onduleur (coupure secteur, fonctionnement sur batterie, etc), cela afin de pouvoir déclencher des scénarios que ne sait pas faire l'onduleur tout seul (extinction des équipements, notification par SMS ou par Push sur l'appli mobile, etc) L'administration de l'onduleur, en tant qu'équipement électronique, devrait être autonome. Tu peux configurer l'envoi d'emails sur l'onduleur, et c'est lui qui t'informera en direct en cas de problème technique (batterie à remplacer, ou toute autre chose). Cela indépendamment de la domotique.

Voilà, c'est bien pour cela que j'indique dans mon message précédent qu'il faut un gestionnaire externe, comme Nagios (le plus connu). On sort complètement du cadre domotique, c'est de la supervision informatique.