Aller au contenu
Barelle

Quick APP - UPS pour serveur DSM Synology

Recommended Posts

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

  • Like 1

Partager ce message


Lien à poster
Partager sur d’autres sites

oui c'est ce que j'ai fait. 

C'est parfait maintenant.

Merci pour tout ton travail!:16:

Partager ce message


Lien à poster
Partager sur d’autres sites

Bonjour à tous.

Aller, pour utiliser d'une manière plus avancée la QA,

Barelle, tu as un child en tant que Power Sensor (Génial!),

par contre, maintenant que Fibaro a fait de belles pages sur la consommation, il y a quelque chose de spécial à faire pour que le Power Sensor de la QA apparaisse?

Merci

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Les modules qui remontent une puissance (power, en Watts) ne sont pas gérés par le panneau d'énergie.

 

Comme son nom l'indique justement, il ne présente que les données issues des capteurs qui remontent une énergie (energy, en kWh)

 

Ce que tu peux faire à partir d'un module qui remonte la puissance, c'est d'activer l'option virtualEnergyConsumption, il y a une case à cocher pour cela dans les propriétés du module.

La box va automatiquement calculer l'énergie en kWh à partir de la consommation instantanée en W, et donc le module devrait être géré par le panneau d'énergie.

  • Like 1

Partager ce message


Lien à poster
Partager sur d’autres sites

Ha, j avais pas fait le distinguo entre la puissance et l énergie,  mais c est logique.

Barelle, tu penses qu il y a quelque chose à faire ?

Ou "au pire" intégrer la partie virtualEnergyConsumption?

 

Merci :)

Partager ce message


Lien à poster
Partager sur d’autres sites

Voilà une capture d'écran : Barelle ne pourra pas cliquer à ta place ;)

 

 

image.thumb.png.380bc1b7daeeb685bd4e6f2db57ad6c0.png

  • Like 2

Partager ce message


Lien à poster
Partager sur d’autres sites

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

 

Partager ce message


Lien à poster
Partager sur d’autres sites

ok Barelle, je comprends que ça n'apporterait pas beaucoup plus 

Mais soit je suis une truffe, soit j'ai loupé quelque chose.

Car j'ai pas l'option virtualEnergyConsumption .. D'où ma demande s'il y avait une adaptation de dev à faire...

Ma capture d'écran:

image.thumb.png.37471263cd4c7d1af02fd62d29ba7618.png

 

Dites moi que je suis pas encore fou..!!!

 

Modifié par Overkill

Partager ce message


Lien à poster
Partager sur d’autres sites

J'ai l'impression que c'est une limitation actuelle de la box... je n'ai pas non plus cette option sur les powerSensors, alors que je l'ai que les autres types de modules (sur ma capture d'écran d'hier, c'était un binary switch, à laquelle j'ai ajouté l'interface "power")

 

Barelle, plutôt que de créer un child dédié pour la mesure de puissance, est-ce que tu ne pourrais pas l'ajouter en tant qu'interface power sur un module existant (parent ou enfant) ? Si le type est différent, je pense que la HC3 laissera l'utilisateur activer l'option virtualenergyconsumtion.

 

Autre piste, forcer l'ajout du virtualEnergyConsumption via l'API sur le child en question, je pense que ça peut marcher (auquel car ça serait juste une limitation de la page Web, mais pas de la box, ce ne serait pas la 1ère fois que Fibaro nous fait le coup)

 

Modifié par Lazer

Partager ce message


Lien à poster
Partager sur d’autres sites

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
}

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Oui ça c'est normal.

 

Relis bien mon message, ce n'est pas ce que je demandais ;)

=> Soit mettre le power sur un child existant d'un autre type, soit ajouter virtualEnergyConsumption sur ce child de type powerSensor

Partager ce message


Lien à poster
Partager sur d’autres sites

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

Partager ce message


Lien à poster
Partager sur d’autres sites

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.

Partager ce message


Lien à poster
Partager sur d’autres sites

Pour ajouter une interface, tu ne peux pas le faire injectant un paramètre dans le JSON d'un module.

Car il ne s'agit pas que d'ajouter un nouvel élément à la table interfaces du module, cela va également créer des nouvelles propriétés dans le module, qui dépendent de l'interface ajoutée.

 

=> il faut appeler la méthode addInterfaces du QuickApp (avec l'ID du parent ou d'un enfant, peu importe ça fonctionne pour les 2)

 

Tu peux regarder comment je fais en LUA dans ma librairie tools que tu trouveras dans tous mes QuickApps du forum.

 

Ou alors directement via une méthode GET en passant par callAction :

/api/callAction?deviceID=123&name=addInterfaces&arg1=%5B%22power%22%5D
/api/callAction?deviceID=123&name=addInterfaces&arg1=%5B%22virtualEnergyConsumption%22%5D

 

 

Remarque de fond sur la gestion de modules :

  • Je n'aime pas la technique consistant à créer autant d'enfants que d'informations à remonter. Ex : un enfant de type binarySwitch, un autre de type powerMeter, un autre de type energyMeter, et un autre de type battery... ça surcharge l'interface, et remplie la DB de nombreux modules inutiles.
  • Je préfère sélectionner soigneusement le type de mon module (par exemple binarySwitch), et lui ajouter les interfaces nécessaires, donc dans cet exemple : power, energy (ou virtualEnergyConsumption), et battery => On a 1 seul module dans l'interface, c'est propre, concis, et toutes les informations utiles sont bien présentes.

Fibaro a inventé ce concept d'interface sur la HC2, il nous permet depuis la HC3 de l'appliquer aux QuickApps, autant en profiter.

Partager ce message


Lien à poster
Partager sur d’autres sites

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.

Partager ce message


Lien à poster
Partager sur d’autres sites

Je dirais que c'est normal, d'après ma compréhension de la logique Fibaro, un module peut avoir soit l'interface energy, soit virtualEnergyConsumption, mais pas les deux.

- energy : l'énergie est mise à jour manuellement (par lecture de la valeur d'un compteur électrique, d'un onduleur, etc)

- virtualEnergyConsumption : justement là on n'a aucun moyen de connaitre l'énergie, donc on laisse la HC3 le calculer (ça n'est possible que si on met à jour la propriété power (ce qui implique que le module doive impérativement posséder l'interface power)

 

Modifié par Lazer

Partager ce message


Lien à poster
Partager sur d’autres sites

Désolé de te contredire, j'ai bien :

  "interfaces": [
    "energy",
    "power",
    "quickAppChild",
    "virtualEnergyConsumption"
  ],

 

L'ajout de l'interface "virtualEnergyConsumption" a ajouté également l'interface "energy" et les propriétés "energy", "lastEnergyCalculationTimestamp", "saveToEnergyPanel", "showEnergy" et "storeEnergyData".

 

L'existence d'une interface "energy" n'a pas empêché l'ajout de l'interface "virtualEnergyConsumption".

 

Par contre je ne m'explique pas le non-fonctionnement de l'API "addInterface" par le swagger.

Partager ce message


Lien à poster
Partager sur d’autres sites

OK d'accord.

Alors energy + power sont donc 2 prérequis pour voir virtualEnergyConsumption

 

Donc si je rectifie ce que j'ai écris, ça donne :

La propriété energy peut être mise à jour manuellement (par lecture de la valeur d'un compteur électrique, d'un onduleur, etc), ou bien calculée par la HC3 grâce à l'ajout de l'interface virtualEnergyConsumption

 

Pour l'API, essaye avec un s à la fin : "addInterfaces"

Partager ce message


Lien à poster
Partager sur d’autres sites

J'abonde dans ton sens, surtout que l'on voit apparaître la propriété "lastEnergyCalculationTimestamp".

 

Le swagger envoie l'ordre : curl -X POST "http://192.168.0.83/api/devices/addInterface" -H  "accept: */*" -H  "Content-Type: application/json" -H  "X-Fibaro-Version: 2" -H  "Accept-language: fr" -H  "Authorization: Basic  xxxxxxxxxxxxxxxxxxxxxxxx" -d "{\"devicesId\":[261],\"interfaces\":[\"virtualEnergyConsumption\"]}"

 

Cela a bien fonctionné pour l'ajout d'une interface "energy", mais pas pour "virtualEnergyConsumption". Sans doute un des nombreux bugs du swagger.

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Possible, je n'utilise le swagger que pour consulter la syntaxe, je ne réalise jamais les requêtes avec.

Je fais mes requêtes avec curl directement (depuis une VM Linux, par habitude puisque maintenant c'est en natif dans Windows), ou bien directement dans le navigateur, ou en LUA...

Partager ce message


Lien à poster
Partager sur d’autres sites

Passions est un bien grand mot, tout au plus s'agissait-il d'un échange de points de vue sur quelques détails d'ordre technique.

Partager ce message


Lien à poster
Partager sur d’autres sites
On 4/25/2021 at 9:13 PM, Kana-chan said:

good morning,

 

So, the best thing is that I give you the QA.

 

That's it...:D

Back_UPS_900.fqa

Salut,

 

j'ai un APC Back-UPS XS 700U, ce fichier/QA fonctionnera-t-il pour moi ?

 

Cordialement,

Partager ce message


Lien à poster
Partager sur d’autres sites
Le 13/12/2022 à 21:51, Kana-chan a dit :

Bonsoir,

Est-ce que vous le connecter au NAS par l'intermédiaire d'un câble USB ?

@Kana-chan désolé, j'ai oublié de le mentionner, oui, il est connecté via USB.

Modifié par Merlin

Partager ce message


Lien à poster
Partager sur d’autres sites

×