Aller au contenu

Messages recommandés

Posté(e)

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",
Posté(e)

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....

Posté(e)

la honte, c'était juste un p.... de caractère qui c'était inséré dans le type de child "com.fibaro.binarylSensor" :15:

Posté(e)

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 ;)

 

  • Like 1
Posté(e) (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é par MAM78
Posté(e)

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.

Posté(e) (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é par MAM78
Posté(e)

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...

Posté(e)

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é.

  • 1 mois après...
Posté(e) (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é par Lazer
  • Like 2
Posté(e)

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

  • 4 semaines après...
Posté(e)

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?

Posté(e)

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).

  • Like 1
Posté(e)
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?

Posté(e)

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....

  • 3 mois après...
  • 3 mois après...
  • 1 an après...
Posté(e)

@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

Posté(e)

ç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.

Posté(e) (modifié)

:angry: Oui mais la tienne n'y est plus 

 

Et le fait d'en prendre un rackable, pas de souci ?

Modifié par Massalia
×
×
  • Créer...