MAM78 Posté(e) le 1 novembre 2021 Signaler Posté(e) le 1 novembre 2021 Je viens de commencer à le configurer mais je butte sur la création du ChildDevice. J'obtiens l'erreur suivante : [01.11.2021] [21:10:22] [ERROR] [QA_EATON_97]: ./quickApp.lua:156: attempt to index a nil value (local 'child') [01.11.2021] [21:10:22] [ERROR] [QA_EATON_97]: Error : child creation failed Le problème semble lié au fait que le Child est de type "com.fibaro.binarylSensor". Aurais-tu une idée de la cause et comment corriger ? L'erreur est générée dans le fichier tools, dans la fonction : function tools:createChild(param) au niveau de la ligne : -- Create child device local child = self:createChildDevice({ name = childName, type = childType, initialProperties = childProperties, }, childClass ) J'ai pourtant ajouté dans le fichier main les lignes suivantes : [13] = { name = "upsmgEnvironmentInput1State", oid = "MG-SNMP-UPS-MIB::upsmgEnvironmentInput1State.0", message = function(a) return QuickApp.upsmgEnvironmentInput1States[a or 1].emoji .. " Batterie " .. QuickApp.upsmgEnvironmentInput1States[a or 1].text end, child = {type = "com.fibaro.binarylSensor", name = "Porte Baie Informatique", property = "value", value = function(a) if a=="closed" then return false elseif a=="open" then return true else return false end end}, notification = {"push", "email", "sms"}, }, J'ai bien ajouté également ça : QuickApp.upsmgEnvironmentInput1States = { [1] = { value = "closed", emoji = "F", text = "Fermé"}, [2] = { value = "open", emoji = "O", text = "Ouvert"} } Mais aussi complété le tableau suivant : -- Setup classes for child devices self:initChildDevices({ ["com.fibaro.temperatureSensor"] = MyChild, ["com.fibaro.humiditySensor"] = MyChild, ["com.fibaro.multilevelSensor"] = MyChild, ["com.fibaro.binarylSensor"] = MyChildInput, }) Et finalement également ajouté ça : ---------------------------------------------------------------------------------------------------- -- QuickApp Child device - MyChildInput ---------------------------------------------------------------------------------------------------- class 'MyChildInput' (QuickAppChild) -- -- Constructor -- function MyChildInput:__init(device) QuickAppChild.__init(self, device) self:trace("QuickApp Eaton UPS - Initialization - Child device #",self.id , " (" , self.name,")") tools.log(self, "", 0) end Dans le fichier SNMP, j'ai ajouté les lignes suivantes : ["MG-SNMP-UPS-MIB::upsmgEnvironmentInput1State"] = ".1.3.6.1.4.1.705.1.8.7.1.9", ["MG-SNMP-UPS-MIB::upsmgEnvironmentInput2State"] = ".1.3.6.1.4.1.705.1.8.7.1.10",
Lazer Posté(e) le 1 novembre 2021 Auteur Signaler Posté(e) le 1 novembre 2021 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....
MAM78 Posté(e) le 1 novembre 2021 Signaler Posté(e) le 1 novembre 2021 Très bien, comme dit le proverbe, aide-toi, le ciel t’aidera
MAM78 Posté(e) le 1 novembre 2021 Signaler Posté(e) le 1 novembre 2021 la honte, c'était juste un p.... de caractère qui c'était inséré dans le type de child "com.fibaro.binarylSensor"
MAM78 Posté(e) le 2 novembre 2021 Signaler Posté(e) le 2 novembre 2021 J'ai enfin réussi à faire fonctionner les 2 capteurs (contacts secs) de la sonde EMP d'environnement raccordable à l'onduleur. Il s'agit d'un module optionnel qui se raccord par cable réseau. En fait c'est ultra simple quand on comprend comment fonctionne le QuickApp Dans le main, ajouter le code suivant : voici les device [13] et [14] que j'ai ajouté pour rendre cela fonctionnel : nota : Les 2 premières [12] et [13] correspondent à la sonde de température et d'humidité. Il convient d'adapter la numérotation des devices en fonction de ceux qui sont déjà instanciés dans votre QA. Vous pouvez modifier les valeurs emoji F et O par ceux de votre choix (l'éditeur du forum n'accepte pas les emojis autres que ceux proposés) moi j'ai choisi les cadenas Fermé et Ouvert. Vous pouvez également changer le type de device "com.fibaro.doorSensor" par d'autres types. Idem pour leur nommage. [11] = { name = "upsmgEnvironAmbientTemp", oid = "MG-SNMP-UPS-MIB::upsmgEnvironAmbientTemp.0", child = {type = "com.fibaro.temperatureSensor", name = "Température", property = "value", value = function(a) return a / 10 end}, }, [12] = { name = "upsmgEnvironAmbientHumidity", oid = "MG-SNMP-UPS-MIB::upsmgEnvironAmbientHumidity.0", child = {type = "com.fibaro.humiditySensor", name = "Humidité", property = "value", value = function(a) return a / 10 end, unit = ""}, }, [13] = { name = "upsmgEnvironmentInput1State", oid = "MG-SNMP-UPS-MIB::upsmgEnvironmentInput1State", message = function(a) return QuickApp.upsmgEnvironmentInput1States[a or 1].emoji .. " Porte Baie Info 1 " .. QuickApp.upsmgEnvironmentInputStates[a or 1].text end, child = {type = "com.fibaro.doorSensor", name = "Porte Baie Info 1", property = "value", value = function(a) if a==1 then return false elseif a==2 then return true else return false end end}, notification = {"push", "email", "sms"}, }, [14] = { name = "upsmgEnvironmentInput2State", oid = "MG-SNMP-UPS-MIB::upsmgEnvironmentInput2State", message = function(a) return QuickApp.upsmgEnvironmentInput1States[a or 1].emoji .. " Porte Baie Info 2 " .. QuickApp.upsmgEnvironmentInputStates[a or 1].text end, child = {type = "com.fibaro.doorSensor", name = "Porte Baie Info 2", property = "value", value = function(a) if a==1 then return false elseif a==2 then return true else return false end end}, notification = {"push", "email", "sms"}, }, } QuickApp.upsmgEnvironmentInputStates = { [1] = { value = "closed", emoji = "F", text = "Fermé"}, [2] = { value = "open", emoji = "O", text = "Ouvert"} } Toujours dans le fichier main : Ajouter dans le tableau initChildDevices, l'entrée suivante : ["com.fibaro.doorSensor"] = MyChild, A adapter selon le type choisi précédemment. -- Setup classes for child devices self:initChildDevices({ ["com.fibaro.temperatureSensor"] = MyChild, ["com.fibaro.humiditySensor"] = MyChild, ["com.fibaro.multilevelSensor"] = MyChild, ["com.fibaro.powerSensor"] = MyChild, ["com.fibaro.doorSensor"] = MyChild, }) Dans le fichier SNMP : Ajouté dans le tableau SNMP.MIB les lignes suivantes : ["MG-SNMP-UPS-MIB::upsmgEnvironAmbientTemp"] = ".1.3.6.1.4.1.705.1.8.1", ["MG-SNMP-UPS-MIB::upsmgEnvironAmbientHumidity"] = ".1.3.6.1.4.1.705.1.8.2", ["MG-SNMP-UPS-MIB::upsmgEnvironmentInput1State"] = ".1.3.6.1.4.1.705.1.8.7.1.9.1", ["MG-SNMP-UPS-MIB::upsmgEnvironmentInput2State"] = ".1.3.6.1.4.1.705.1.8.7.1.10.1", Il reste plus qu'à cliquer sur le bouton pour générer le child devices 1
MAM78 Posté(e) le 2 novembre 2021 Signaler Posté(e) le 2 novembre 2021 (modifié) J'ai remarqué dans le QuickApp:loop() que tu avais mis en place un test pour detecter un changement de statut de l'UPS output et lancer plus rapidement une actualisation des mesures. Cf. : SNMP:get("UPS-MIB::upsOutputSource.0", { Compte-tenue que la racine de la MIB pour la sonde d'ambiance est différente (MG-SNMP-UPS-MIB:: vs UPS-MIB::). Est-ce que selon toi, il faudrait adapter le code du QuickApp:loop() pour le faire également le test avec cette racine de MBI (MG-SNMP-UPS-MIB:: vs IOD : 1.3.6.1.4.1.705.1.8) Ceci afin de ne pas avoir à attendre une minute, mais avoir une actualisation plus rapide dès lors que l'un des 2 éléments change ? Du genre : SNMP:get("MG-SNMP-UPS-MIB::upsmgEnviron.0", { Modifié le 2 novembre 2021 par MAM78
Lazer Posté(e) le 2 novembre 2021 Auteur Signaler Posté(e) le 2 novembre 2021 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.
MAM78 Posté(e) le 2 novembre 2021 Signaler Posté(e) le 2 novembre 2021 (modifié) J'ai essayé, mais sans réussite. Je supposait que ton test sur UPS-MIB::upsOutputSource vérifiait si l'une des entrées sous-jacente était modifiée et donc lancer un check complet l'ensemble de points de mesures. Laisse tomber, l'actualisation toute les minutes est suffisante. Rien de critique, mes cas d'usage : une porte de baie info restée ouverte m'alerté si quelqu'un venait à trifouiller dans ma baie. Il faudra qu'il fasse vite pour ne pas être détecté Tu aurais une idée de composant à contact sec pour détecter un ou des ventilateurs qui ne tourneraient plus ? Modifié le 2 novembre 2021 par MAM78
Lazer Posté(e) le 2 novembre 2021 Auteur Signaler Posté(e) le 2 novembre 2021 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...
MAM78 Posté(e) le 2 novembre 2021 Signaler Posté(e) le 2 novembre 2021 Merci pour la piste du tachymètre, mais il va me falloir trouver maintenant un composant de type contact sec qui aura en entrée une intensité (intensité 0 = Le ventilateur ne tourne pas et >0 = Le ventilateur tourne) et en sortie Ouvert ou Fermé.
mprinfo Posté(e) le 23 décembre 2021 Signaler Posté(e) le 23 décembre 2021 J'avais pas vu mais il y a une mise a jour qui date déjà depuis un moment pour les 5P http://powerquality.eaton.fr/support/software-drivers/downloads/5p-ups-firmware.asp?cx=80 1
Lazer Posté(e) le 23 décembre 2021 Auteur Signaler Posté(e) le 23 décembre 2021 (modifié) Tiens, étonnant ça. C'est une mise à jour pour l'onduleur ? Et pas pour la carte de management réseau ? Du coup tu fais comment la mise à jour, via le port série ? EDIT : oui c'est ça, comme indiqué dans le document tu liens, la mise à jour se fait via série ou USB directement sur l'onduleur. Merci pour l'info, je ferai la mise à jour... peut être... on verra... (aujourd'hui j'ai bricolé au garage et j'ai fais la mise à jour... d'une batterie ! d'outil Festool. Tout se met à jour maintenant... de plus en plus fou....) Modifié le 23 décembre 2021 par Lazer 2
jjacques68 Posté(e) le 23 décembre 2021 Signaler Posté(e) le 23 décembre 2021 @mprinfo, c'est ok cette mise à jour ?
mprinfo Posté(e) le 23 décembre 2021 Signaler Posté(e) le 23 décembre 2021 @jjacques68 oui aucun soucis via la câble usb
jjacques68 Posté(e) le 24 décembre 2021 Signaler Posté(e) le 24 décembre 2021 oah trop compliqué, ils disent de retirer la carte réseau pour ceux qui en ont une. c'est mon cas, je laisse tombé
mprinfo Posté(e) le 24 décembre 2021 Signaler Posté(e) le 24 décembre 2021 J'ai rien retiré j'ai aussi une carte réseau Tu installes setups-win-2_5_0872.exe il faut bien sur branché l'onduleur en USB tu copies eaton_5p_lvhv11_e0_v03_16_0032_tl00.sta dans le dossier ou il doit y avoir le firmware je sais plus ou mais il est indiqué lorsque tu ouvres le logiciel Ensuite tu éteints ton onduleur et tu l’allumes ton onduleurs Envoyé de mon BLA-L29 en utilisant Tapatalk
Christb Posté(e) le 17 janvier 2022 Signaler Posté(e) le 17 janvier 2022 Bonjour, j'avais installé la version 3.0.1 de Lazer et maintenant la version 3.1 mais dans les 2 cas, j'ai régulièrement une erreur comme ci-dessous (avec les deux versions) : [17.01.2022] [12:50:41] [DEBUG] [QA_EATON_398]: Total memory in use by Lua : 1644.01 KB [17.01.2022] [12:55:42] [DEBUG] [QA_EATON_398]: Total memory in use by Lua : 1251.56 KB [17.01.2022] [12:57:48] [TRACE] [QA_EATON_398]: Child #401 Tension value changed to 231 [17.01.2022] [12:58:48] [TRACE] [QA_EATON_398]: Child #401 Tension value changed to 230 [17.01.2022] [12:59:48] [TRACE] [QA_EATON_398]: Child #401 Tension value changed to 231 [17.01.2022] [13:00:20] [ERROR] [QA_EATON_398]: Error : SNMP get failed : Receive failed : Operation canceled [17.01.2022] [13:00:42] [DEBUG] [QA_EATON_398]: Total memory in use by Lua : 982.18 KB Ces erreurs régulières ne semblent pas empêcher le QA et ses enfants de fonctionner. N'étant pas très familier avec la programmation des QA je n'arrive pas à savoir d'où vient cette erreur : le QA ou l'onduleur?
Lazer Posté(e) le 17 janvier 2022 Auteur Signaler Posté(e) le 17 janvier 2022 Problème de communication avec l'onduleur... ça peut venir d'une lenteur au niveau du réseau lui-même, de la carte contrôleur SNMP de l'onduleur, voire de la HC3. Il n'y a rien qu'on puisse faire, mais l'erreur n'est pas gênante et non bloquante, le QuickApp est prévu pour gérer ce cas de figure et ne pas planter. Pour preuve, il continue son fonctionnement normal. J'aurais pu faire le choix de cacher cette erreur et ne pas l'afficher, mais je préfère la laisser, au moins on voit ce qui se passe (ou ne passe pas en l'occurrence). 1
Christb Posté(e) le 17 janvier 2022 Signaler Posté(e) le 17 janvier 2022 Il y a 6 heures, Lazer a dit : Problème de communication avec l'onduleur... ça peut venir d'une lenteur au niveau du réseau lui-même, de la carte contrôleur SNMP de l'onduleur, voire de la HC3. Il n'y a rien qu'on puisse faire, mais l'erreur n'est pas gênante et non bloquante, le QuickApp est prévu pour gérer ce cas de figure et ne pas planter. Pour preuve, il continue son fonctionnement normal. J'aurais pu faire le choix de cacher cette erreur et ne pas l'afficher, mais je préfère la laisser, au moins on voit ce qui se passe (ou ne passe pas en l'occurrence). Merci de votre rapide réponse, je viens d'avoir une nouvelle série d'erreurs comme ci-dessous : [17.01.2022] [20:32:02] [TRACE] [QA_EATON_398]: Child #401 Tension value changed to 232 [17.01.2022] [20:33:02] [TRACE] [QA_EATON_398]: Child #401 Tension value changed to 233 [17.01.2022] [20:34:02] [TRACE] [QA_EATON_398]: Child #401 Tension value changed to 232 [17.01.2022] [20:35:02] [ERROR] [QA_EATON_398]: SNMP:sequence() : Fetch Response failed : Request ID 244810251 differs from 244810252 [17.01.2022] [20:35:02] [ERROR] [QA_EATON_398]: SNMP:sequence() : Fetch Response failed : Request ID 244810252 differs from 244810253 [17.01.2022] [20:35:02] [ERROR] [QA_EATON_398]: SNMP:sequence() : Fetch Response failed : Request ID 244810253 differs from 244810254 [17.01.2022] [20:35:02] [ERROR] [QA_EATON_398]: SNMP:sequence() : Fetch Response failed : Request ID 244810254 differs from 244810255 [17.01.2022] [20:35:02] [ERROR] [QA_EATON_398]: SNMP:sequence() : Fetch Response failed : Request ID 244810255 differs from 244810256 [17.01.2022] [20:35:02] [ERROR] [QA_EATON_398]: SNMP:sequence() : Fetch Response failed : Request ID 244810256 differs from 244810257 [17.01.2022] [20:35:02] [ERROR] [QA_EATON_398]: SNMP:sequence() : Fetch Response failed : Request ID 244810257 differs from 244810258 [17.01.2022] [20:35:02] [ERROR] [QA_EATON_398]: SNMP:sequence() : Fetch Response failed : Request ID 244810258 differs from 244810259 [17.01.2022] [20:36:02] [TRACE] [QA_EATON_398]: Child #401 Tension value changed to 233 Est-ce aussi dû à une lenteur de réponse de l'UPS? Est-ce que cela pourrait venir de la box?
Lazer Posté(e) le 17 janvier 2022 Auteur Signaler Posté(e) le 17 janvier 2022 En effet c'est exactement ça, le QA reçoit la réponse avec 1 train de retard, si on regarde les ID de ton log, on voit qu'ils sont décalés. Quand le QA emet une trame SNMP pour interroger l'onduleur, il reçoit en fait la réponse de la trame précédente. C'est étonnant que ça se produise si souvent chez toi, chez moi ce n'est jamais arrivé ce cas de figure. Rien de grave de toute façon, ça n'empêche pas le QuickApp de fonctionner, au pire il a un peu de retard dans la mise à jour des valeurs affichées, le temps qu'il reçoive une réponse correcte de l'onduleur. Théoriquement, je pourrais prendre en compte ce décalage dans le code LUA du QA, mais vu la complexité, je préfère même pas me lancer....
Massalia Posté(e) le 24 octobre 2023 Signaler Posté(e) le 24 octobre 2023 @Lazer Salut Dis moi si je prends ces deux composants la j'ai bon ? Onduleur https://www.ldlc.com/fiche/PB00255170.html Carte https://www.ldlc.com/fiche/PB00264426.html Merci
Lazer Posté(e) le 24 octobre 2023 Auteur Signaler Posté(e) le 24 octobre 2023 ça a l'air d'être une toute nouvelle version de la carte de management réseau, j'espère qu'elle sera compatible. Mais normalement il n'y a pas de raison, vu qu'elle est compatible SNMP v1, qui est un protocole bien standardisé, utilisé par mon QuickApp.
Massalia Posté(e) le 24 octobre 2023 Signaler Posté(e) le 24 octobre 2023 (modifié) Oui mais la tienne n'y est plus Et le fait d'en prendre un rackable, pas de souci ? Modifié le 24 octobre 2023 par Massalia
Messages recommandés