Barelle

Avec le swagger en utilisant l'API "/devices/addInterface" : - L'ajout de l'interface "energy" ajoute les propriétés "energy", "saveToEnergyPanel", "showEnergy" et "storeEnergyData". - Mais cela ne prend toujours pas en compte l'ajout de l'interface "virtualEnergyConsumption". Par contre avec l'api callAction cela fonctionne. et une fois l'interface "virtualEnergyConsumption" ajoutée, on obtient bien le choix dans l'interface de la Consommation théorique.

Toujours avec le swagger en utilisant l'API "/devices/addInterface" : { "devicesId": [ 261 ], "interfaces": [ "virtualEnergyConsumption" ] } J'obtiens un code 204, mais l'interface n'est toujours pas ajoutée.

En rajoutant l'interface "power" dans le QuickApp parent, cela ne change rien (sans avoir redémarré la HC3). Avec le swagger, un PUT de : { "id": 261, "name": "Ellipse PRO 1200", "roomID": 220, "interfaces": [ "power", "quickAppChild", "virtualEnergyConsumption" ] } permet d'obtenir un code 500 : Error: Internal Server Error

Tout est possible… Sauf qu'il a déjà l'interface "power" : { "id": 261, "name": "UPS VA/W", "roomID": 220, "view": [ { "assetsPath": "/dynamic-plugins/com.fibaro.multilevelSensor/assets", "jsPath": "/dynamic-plugins/com.fibaro.multilevelSensor", "name": "com.fibaro.multilevelSensor", "translatesPath": "/assets/i18n", "type": "ts" }, { "assetsPath": "/dynamic-plugins/power/assets", "jsPath": "/dynamic-plugins/power", "name": "power", "translatesPath": "/dynamic-plugins/power/i18n", "type": "ts" } ], "type": "com.fibaro.powerSensor", "baseType": "com.fibaro.multilevelSensor", "enabled": true, "visible": true, "isPlugin": true, "parentId": 260, "viewXml": false, "configXml": false, "interfaces": [ "power", "quickAppChild" ], "properties": { "categories": [ "other" ], "dead": false, "deadReason": "", "deviceControlType": 1, "deviceIcon": 1048, "deviceRole": "Other", "log": "", "logTemp": "", "manufacturer": "", "model": "", "power": 106, "quickAppVariables": [ { "name": "internalName", "value": "power" } ], "saveLogs": true, "showEnergy": true, "supportedDeviceRoles": [ "Other" ], "unit": "VA", "useEmbeddedView": true, "userDescription": "", "value": 159 }, "actions": {}, "created": 1645412537, "modified": 1645412537, "sortOrder": 72 }

Effectivement… Il serait toujours possible de convertir les puissances (consommée par l'onduleur et restituée par l'onduleur) en énergie cela supposerait d'intégrer les consommations sur une certaine période, ce qui conduira à une approximation qui n'a que peu de chance de gagner en précision par rapport au calcul réalisé par Fibaro et mentionné par @Lazer

Avec la variable debug du QA à false, ce devrait être moins verbeux. Sinon, si cela te gêne, tu peux toujours mettre les lignes en commentaires...

La variable varUPS est affichée dans la console ou encore à l'adresse http://<ip HC3>/logs Dans la fonction processData, pourrais-tu remplacer la ligne : if (varUps["ups.status"] and (string.sub(varUps["ups.status"], 1, 3) ~= "OL ")) then -- values "OL CHRG", "OL DISCHRG" Par la ligne : if (varUps["ups.status"] and (string.find(varUps["ups.status"], "OL") == nil)) then -- values "OL CHRG", "OL DISCHRG", "FSD OL" Et cela devrait être bon.

Je cherche... Pourrais-tu me confirmer que : La version de DSM de ton NAS est bien supérieure à 5 ; Ton onduleur a bien subi une coupure du secteur sans redémarrage du NAS ; Dans la variable varUPS la valeur du champ status est bien à "FSD OL". Merci. PS : tu peux également m'envoyer l'intégralité de la variable "varUPS" (sous forme de texte, une copie d'écran étant peu exploitable).

Merci... Le fichier .lua est le source lua du QA. Si le FQA a été importé, il est inutile.

Bonjour, Après une rapide recherche, j'ai trouvé ceci, pour un trou de 18mm, sur un site que je ne connaissais pas... De rien, bonne journée.

Il faut lire, c'est ce que j'ai écrit au dessus

Même réponse... Cela devrait plutôt être quelque chose comme cela : -[[ %% properties 772 value %% globals --]] local door = 772 local light = 459 -- Spots hall local startSource = fibaro:getSourceTrigger(); local heure = string.format(os.date("%H"), "%2d")..string.format(os.date("%M"), "%2d") local enAlerte = (tonumber(fibaro:getValue(door, "value")) > 0) local heureValable = fibaro:getGlobalValue("Jour-Nuit")== ("Jour") -- à partir de 6h30 local heureValable1 = fibaro:getGlobalValue("Jour-Nuit")== ("Matin") -- à partir de 9h00 local heureValable2 = fibaro:getGlobalValue("Jour-Nuit")== ("Midi") -- à partir de 12h00 local heureValable3 = fibaro:getGlobalValue("Jour-Nuit")== ("Après-midi") -- à partir de 14h30 local heureValable4 = fibaro:getGlobalValue("Jour-Nuit")== ("Soir") -- à partir de 17h00 local heureValable5 = fibaro:getGlobalValue("Jour-Nuit")== ("Soirée") -- à partir de 21h00 local heureValable6 = fibaro:getGlobalValue("Jour-Nuit")== ("Nuit") -- à partir de 23h59 if enAlerte and heureValable then fibaro:call(459, "setValue", "40") -- Spots Hall fibaro:sleep(2*1000); fibaro:call(592, "turnOn") -- Plante 1 fibaro:call(593, "turnOn") -- Plante 2 fibaro:debug("Porte ouverte") elseif enAlerte and heureValable4 then if tonumber(fibaro:getValue(459, "value")) > 0 then fibaro:debug("lumière déjà allumée") fibaro:killScenes(427) else fibaro:call(light, "setValue", "30"); -- Spots Hall fibaro:sleep(15*1000); fibaro:call(light, "turnOff") -- Spot Hall fibaro:debug("Porte ouverte matin") end fibaro:debug("Fin de script") fibaro:sleep(60*1000); else fibaro:call(592, "turnOff") -- Plante 1 fibaro:call(593, "turnOff") -- Plante 2 fibaro:sleep(2*1000); fibaro:call(459, "turnOff") -- Spot Hall fibaro:debug("Porte fermée") end

Structure la présentation de ton code et tu verras tout de suite que le elseif de ta ligne 44 qui suit un else n'a aucun sens...

La syntaxe du if then else n'est pas : if fibaro:getGlobalValue("TV")== ("On") then fibaro:call(56, "pressButton", "1") fibaro:debug("TV extinction") else fibaro:debug("TV déjà éteinte") fibaro:debug("Porte ouverte Jour") end elseif enAlerte and heureValable1 -- Matin -- then mais ta scène devrait plutôt avoir la structure suivante : if enAlerte and heureValable then -- Jour -- -- traitement pour le jour elseif enAlerte and heureValable1 then -- Matin -- -- traitement pour le matin elseif enAlerte and heureValable2 then -- Midi -- -- traitement pour le midi elseif enAlerte and heureValable4 then -- Soir -- -- traitement pour le soir elseif enAlerte and heureValable5 then -- Soirée -- traitement pour la soirée elseif enAlerte and heureValable6 then -- Nuit -- -- traitement pour la nuit else fibaro:debug('Global "Jour-nuit", valeur inconnue"); end Remarque : Si la scène est en erreur, il serait normal de mentionner le message d'erreur. N'hésite pas à utiliser l'insertion de code "</>" (en sélectionnant LUA), cela rend les messages plus lisibles. Enfin, une présentation du code avec les bons décalages (indentation en jargon globish) facilite la compréhension, et la détection des erreurs de syntaxe.

math.random(-30, 30) cf. http://lua-users.org/wiki/MathLibraryTutorial

Sans doute l'opportunité de découvrir une autre approche de la gestion des flux dans une approche plus XXIe siècle.

Le sujet du topic n'est pas GEA... Je répondais à @jjacques68 pour une application externe. Même si je préfère le LUA au Javascript, il n'empêche que, pour des fonctions simples, Node-RED est bien commode et d'une rare puissance

C'est facile à réaliser avec Node-Red :

Yes, off course, when the variable if locally declared, its scope is known only after its declaration.

Je crains que tu ne confonde deux aspects : 1) Lua n'impose pas syntactiquement parlant de déclarer une fonction avant son emploi, le fait que cette variable appartienne ou non à la classe QuickApp n'y change rien. 2) La référence que tu fais à onInit, est relative à l'exécution du programme qui ne commence qu'après sa "compilation", donc une fois que l'ensemble du programme a été lu et donc les différentes variables déclarées connues. Le test de @jang ne fait référence qu'à la vitesse d'exécution selon la portée de la variable. function QuickApp:onInit() f1("toto"); end function f1(a) return f2(a); end -- f1 function f2(a) print(a); end Désolé, mais ça marche, mon avis se limite à cette considération langagière... https://www.lua.org/pil/4.2.html

@Lazer https://stackoverflow.com/questions/6067369/forward-define-a-function-in-lua <edit> Pour illustrer, to QA Synology Surveillance Station appelle la fonction loop déclarée après onInit... </edit>

En lua la seconde forme est inutile, on peut déclarer dans l'ordre que l'on veut. La notion historique de FORWARD du Pascal n'est pas nécessaire.

Je confirme, passage de 13,2 % de CPU User à 4 %.

J'utilise une variable globale "EcoDevices" pour mémoriser les index, à titre d'exemple chez moi j'ai : {"firstUpdate":1607336057,"teleinfo1":{"HCdayTotalIndex":19334989,"BASEhourTotalIndex":19885426,"HChourTotalIndex":19346744,"dayTotalIndex":19858838,"HPhourTotalIndex":30877214,"HPIndex":30877831,"abonnement":"BASE","lastTotalIndex":19886192,"HCmonthTotalIndex":19279930,"HCIndex":19346744,"BASEyearTotalIndex":19346746,"hourTotalIndex":19885426,"yearTotalIndex":19346746,"BASEdayTotalIndex":19858838,"consoActuelleWh":15,"HPmonthTotalIndex":30766412,"HPyearTotalIndex":28136471,"periode":"TH..","monthTotalIndex":19346746,"HPdayTotalIndex":30875101,"HCyearTotalIndex":17809978,"puissanceApparente":1160,"BASEmonthTotalIndex":19346746,"BASEIndex":19886192},"compteur2":{"monthIndex":670453288,"lastIndex":670603492,"dayIndex":670594573,"consoActuelle":0,"hourIndex":670603491,"yearIndex":670068238},"lastUpdate":1624650395,"compteur1":{"monthIndex":631288772,"lastIndex":631380432,"dayIndex":631376499,"consoActuelle":0,"hourIndex":631380432,"yearIndex":631288772},"teleinfo2":{"puissanceApparente":0,"yearTotalIndex":0,"consoActuelleWh":0,"dayTotalIndex":0,"periode":0,"monthTotalIndex":0,"BASEIndex":0,"abonnement":"BASE","lastTotalIndex":0,"hourTotalIndex":0}} Sachant que j'ai commencé avec un abonnement HPHC et que je suis, depuis, passé à un abonnement BASE.

Avez-vous remarqué que dans cette version, il semble possible d'entrer en mode édition (dans l'onglet Modifier et prévisualiser) pour un child ?