Aller au contenu

Lazer

Administrateur
  • Compteur de contenus

    25 982
  • Inscription

  • Dernière visite

  • Jours gagnés

    1 277

Tout ce qui a été posté par Lazer

  1. Héhé.... en plus je crois que c'est la seconde fois en 24h que tu as un caractère caché qui traine
  2. Etrange, je n'ai pas ce problème.... et mes URL sur l'IPX800 semblent tout à fait identiques.
  3. 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.
  4. 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...
  5. Lazer

    Fibaro Intercom

    @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 :
  6. 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.
  7. 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)
  8. 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
  9. Lazer

    Bonjour.

    Bienvenue sur le forum
  10. 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.
  11. Lazer

    HC3 - modificationTime d'un module

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

    HC3 - modificationTime d'un module

    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")
  13. 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...
  14. Sorry I have no idea, I have never seen this error
  15. Lazer

    Sauvegarde automatique

    Oui ici (le script pour HC2 est à la fin) : Et.... c'est stable depuis des années
  16. 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....
  17. 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 }
  18. 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.
  19. 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.
  20. 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.
  21. Je viens de comprendre, upsAlarmBatteryBad est un TRAP, donc une trame spécifique (comme une notification push) envoyée vers un serveur capable de collecter les Traps SNMP et de les traiter (donc pas la box Fibaro). Typiquement Nagios, ou les outils dans ce genre là. http://pqsoftware.eaton.com/manual/mib/fra/mibagent.pdf Donc pas exploitable dans un cadre domotique.
  22. Cette entrée upsAlarmBatteryBad n'est pas présente sur mon onduleur Tout ce que je trouve c'est : UPS-MIB::upsAlarmsPresent.0 = Gauge32: 0 C'est un compteur, et d'après la MIB : "The present number of active alarm conditions." => Donc moi je n'ai pas d'erreur, OK super. Mais pour l'instant je n'en sais pas plus...
  23. Il faudrait trouver l'entrée dans l'arbre SNMP qui nous informe sur le défaut de batterie.... si cette entrée existe, ce qui n'est même pas sûr. Après ça sera simple d'émettre une notification ou mettre à jour n'importe quelle variable.
  24. Pour autant que je sache, il est impossible de modifier le type d'un module. Il faut le choisir lors de la création (ce que tu as fait). Il existe une astuce lorsque le type qu'on veut utiliser n'est pas disponible dans la liste déroulante lors de la création d'un QuickApp. Il faut choisir un type quelconque (approchant si possible), exporter le fichier fqa, modifier le type à la main dans un éditeur de texte, puis réimporter le fichier.
  25. Lazer

    Support Gea

    Non tu en as 1 seul, il faut juste regarder le bon C'est celui qui est dans "properties". Donc : Il prend la valeur true/false, ce qui est standard sur HC3. (sur HC2, les capteurs binaires prenaient les valeurs "0" et "1") Bref, dans ta condition, tu mets true à la place du 1. Ou alors encore plus simple, tu peux utiliser l'écriture abrégée : GEA.add({id["Garage_DetMouv"], {"Time", "Sunset-5", "Sunrise+5"}}, -1, "", {"turnOn", id["Eclairage_Allee"]})
×
×
  • Créer...