[Plugin Tiers][Sujet Principal] Nut-free

[Anonyme]

Contenu supprimé à la demande de son auteur

[stef74]

J'en ai pas l’intention.

Pour diverses raisons:
- Je suis toujours dans le partage des informations et connaissances.
- il peut toujours être amélioré et alléger en code. Je suis pas un expert du html ni du php.
- pour moi c'est plus pour apprendre, tout en étant utile.

Stef.

[Anonyme]

Contenu supprimé à la demande de son auteur

[stef74]

No soucie.

[fdp2]

Pas de soucis non plus. Au pire, mets la valeur "ups" par défaut et ca réglera le pb!
Justement, le nas est bien configuré pour redémarrer en cas de coupure de courant, mais si il est éteint par jeedom, ca ne marche pas. Car pour lui il n'y a pas eu de coupure.

Cela fonctionnera. C'est expliqué dans la doc du NAS. En fait sur batterie faible le nas n'est pas eteint, mais il arrête tous les services et demonte les disques afin que la coupure de courant soit sans risque. Ainsi il tiendra compte du redémarrage sur coupure de courant. Pour ton nuc cherche les option d'alimentation dans le bios. Un option doit te premettre de démarrer automatiquement lors de la mise soustension. En tout cas c'est le cas pour mon brix.

Envoyé de mon SM-G900F en utilisant Tapatalk

[fwehrle]

Pas de soucis non plus. Au pire, mets la valeur "ups" par défaut et ca réglera le pb!
Justement, le nas est bien configuré pour redémarrer en cas de coupure de courant, mais si il est éteint par jeedom, ca ne marche pas. Car pour lui il n'y a pas eu de coupure.

Cela fonctionnera. C'est expliqué dans la doc du NAS. En fait sur batterie faible le nas n'est pas eteint, mais il arrête tous les services et demonte les disques afin que la coupure de courant soit sans risque. Ainsi il tiendra compte du redémarrage sur coupure de courant. Pour ton nuc cherche les option d'alimentation dans le bios. Un option doit te premettre de démarrer automatiquement lors de la mise soustension. En tout cas c'est le cas pour mon brix.

Envoyé de mon SM-G900F en utilisant Tapatalk

Tu veux dire que si jeedom envoie une commande SSH shutdown au NAS, c'est parce qu'il détecte qu'il est sur batterie qu'il se met en veille (plutot que de s'éteindre)? Bon à savoir ca... Je pensais que c'était seulement quand c'était le NAS qui s'éteingnait de lui-même à cause d'un niveau de batterie trop bas (paramétré dans la gestion de l'alimentation du NAS).
Du coup, sur le NUC, si j'ai un scenario qui dit a jeedom (et donc au NUC) de s'eteindre, c'est juste l'option dans le bios qui va faire qu'il se rallumera tout seul sur reprise du courant?

[fdp2]

Tu veux dire que si jeedom envoie une commande SSH shutdown au NAS, c'est parce qu'il détecte qu'il est sur batterie qu'il se met en veille (plutot que de s'éteindre)? Bon à savoir ca... Je pensais que c'était seulement quand c'était le NAS qui s'éteingnait de lui-même à cause d'un niveau de batterie trop bas (paramétré dans la gestion de l'alimentation du NAS).
Du coup, sur le NUC, si j'ai un scenario qui dit a jeedom (et donc au NUC) de s'eteindre, c'est juste l'option dans le bios qui va faire qu'il se rallumera tout seul sur reprise du courant?

Ah non, désolé, je ne pensais pas que tu étaignais ton NAS via une commande SSH. Dans ce cas, il est effectivement eteint, et ne redémarera pas avec l'option restart after power failure
Mon explication ne vaut que si ton synology est directement relié à l'onduleur, ou a un serveur nut (par exemple un autre synology) et qu'il gère lui même sa mise en sécurité. ça me parrait d'ailleurs être un meileure option qu'un shutdown SSH.

Si tu souhaite malgré tout que jeedom pilote l'extinction de ton NAS, alors il devrat aussi piloter sa remise en route viw WOL par exemple. Mais attention, tous les synology ne supportent pas le WOL : https://www.synology.com/fr-fr/knowledg ... ake_on_LAN

Concernant le redémarrage du NUC, c'est bien ça : Si une option du BIOS te permet de l'allumer des la mise sous tension, alors il redémareras des que le courant reviendra, quelle que soit la façon dont il a été éteint. A vérifier que cette option existe sur ton NUC, cela dépend du matériel, mais c'est paramétré ainsi sur mon BRIX Gigabyte et cela fonctionne parfaitement.

[fwehrle]

Ok. C'est bien ce que je pensais aussi...
Merci pour les explications.
Du coup, j'ai plus qu'a voir dans le bios du NUC (j'attends le SSD pour installer jeedom) en espérant que l'option y soit.
Et pour le syno, je le laisse gérer tout seul (l'UPS est branché dessus).

EDIT : Y'a quand même un loup.
Si Jeedom/NUC s'éteind tout seul quand la batterie est faible, il y a 2 scénarios :
- l'onduleur s'éteind qq minutes plus tard, il y a donc coupure de courant et le NUC se rallume tout seul à la reprise.
- le courant revient AVANT que l'onduleur ne se coupe. Il n'y a pas de coupure de courant, et le NUC ne se rallume jamais!

Une idée pour palier à ça?

[PatrickBB29]

Bonjour,
voici ma contribution pour un onduleur APC Back-UPS RS 900G connecté en usb à un NAS Synology DS213+
La commande passée en SSH sur la box jeedom est :
upsc ups@adresse_locale_du_nas

Le retour est :

Code : Tout sélectionner

Init SSL without certificate database
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.date: 2001/09/25
battery.mfr.date: 2012/09/29
battery.runtime: 11330
battery.runtime.low: 120
battery.type: PbAc
battery.voltage: 27.4
battery.voltage.nominal: 24.0
device.mfr: American Power Conversion
device.model: Back-UPS RS 900G
device.serial: 3B1239X25286
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 5
driver.parameter.port: auto
driver.version: DSM6-1-14872-161104
driver.version.data: APC HID 0.95
driver.version.internal: 0.38
input.sensitivity: medium
input.transfer.high: 294
input.transfer.low: 176
input.voltage: 237.0
input.voltage.nominal: 230
ups.beeper.status: disabled
ups.delay.shutdown: 20
ups.firmware: 879.L4 .I
ups.firmware.aux: L4
ups.load: 6
ups.mfr: American Power Conversion
ups.mfr.date: 2012/09/29
ups.model: Back-UPS RS 900G
ups.productid: 0002
ups.realpower.nominal: 540
ups.serial: 3B1239X25286
ups.status: OL
ups.test.result: No test initiated
ups.timer.reboot: 0
ups.timer.shutdown: -1
ups.vendorid: 051d

En image dans le dashboard ça donne ça :


Comment peut-on configurer l'objet UPS du plugin pour afficher d'autres infos ou changer le formatage des données (temps restant sur batterie en hh:mm:ss par exemple) ?

Merci pour le travail fourni.

[stef74]

Bonsoir,

A aujourd'hui le seul moyen est de modifier le code du plugin pour ajouter des infos et modifier l'affichage du temps.

Dans la prochaine version:
- les paramètres non gérés seront supprimés de l'affichage.
- le plugin va être en partie ré-écrit pour minimiser le nombre de lignes de codes.

Passer le temps de s à hs risque de ne plus pouvoir être historisé.

Stef.

[mjeanne]

Comment peut-on configurer l'objet UPS du plugin pour afficher d'autres infos ou changer le formatage des données (temps restant sur batterie en hh:mm:ss par exemple) ?

Bonjour,

ma première idée serait de créé un virtuel en important l'objet nut, puis vous modifiez le type 'numeric' en 'autre' et vous remplacez la valeur par 'formatTime(floor(#[votre_ups][Temps restant sur batterie]#/60))'

Mais une chaine de texte n'est plus exploitable en scénario, ni historisable

[fwehrle]

Bonsoir,

Passer le temps de s à hs risque de ne plus pouvoir être historisé.

Stef.

L'infos ne doit effectivement pas être modifiée. Mais rien n'empêche de modifier l'affichage du widget pour formater la données avec quelques lignes de JS.

[PatrickBB29]

Bonsoir,
Merci pour les réponses, effectivement l'idée est surtout de modifier l'affichage du widget indépendamment de la récupération et de l'historisation des données.

Patrick

[fwehrle]

Il y a trois valeurs pour le moment. Cela depend des onduleurs.

OL ou OL CHRG et OB DISCHRG..

Bonjour,

dans le code source de Nut, les textes sont indépendants, et il y en plus que 3:
OL : Sur secteur
OB: sur batterie
LB: batteries faibles (low bat)
RB: je sais pas ce que cela signifie. Peut-être 'replace bat'
CHRG: charge des batteries en augmentation
DISCHRG: décharge des batteries
OVER: Surtension
OFF: onduleur éteint
CAL: calibrage/test
etc...

Théoriquement, on pourrait avoir "OL DISCHRG", même si j'ai jamais vu, si la batterie était en fin de vie et se décharge bien qu'étant sur secteur.

Stef : tu as finalement intégrer tous ces codes? Parce que je viens de voir passer un OL OVER il y a quelques minutes. Cool (pour les modes, pas pour la surtension...)

[stef74]

Salut,

Non pas encore.

Je manque de temps...


Stef.

[fwehrle]

Pas grave. Mais comme j'en ai trouvé un qui n'était apparemment pas dans ta liste, je me posais la question. Tu as géré quels modes au final?
D'ailleurs, je dis peut-être une bêtise, mais pourquoi tu ne récupère pas tout simplement directement les modes envoyés par l'ups?


Envoyé de mon Nexus 6P en utilisant Tapatalk

[stef74]

J'utilises direct le message de l'ups.
Mode = UPS.STATUS.

Suivant le résultat, je modifie l'icone.
J'ajouterais différentes couleurs et alertes sur certains mode. Mais je dois me renseigner sur tous les modes qui existent car je ne les connais pas.

Stef.

[mjeanne]

J'ajouterais différentes couleurs et alertes sur certains mode. Mais je dois me renseigner sur tous les modes qui existent car je ne les connais pas.

Bonjour,

ceux que j'ai indiqué viennent des sources de NUT, mais il ne sont pas fixés. Chaque marque d'onduleur semble pouvoir créer ses propres codes d'informations.
Le plus "propre" serait d'identifier et séparer les codes en 2 variables en plus du status: l'état 'électrique' de l'onduleur: OL/OB/OFF/LB/RB/BYPASS et les infos complémentaires (optionnelles et dépendantes des marques): OVER (surcharge), BOOST (sous-tension), CHRG (en charge), DISCHRG (en décharge), CAL (calibrage), TRIM (surtension), NOBAT (oublié de mettre la batterie !)...
ça rajoute de la programmation, mais ça doit pouvoir se faire via une regex...

'RB', c'est bien 'replace batteries', qui indique une défaillance de la batterie.
'BYPASS', c'est sur certains onduleurs, on 'déconnecte' l'onduleur, la sortie est alors directement reliée à l'entrée et non filtrée (le temps d'un remplacement de batterie, par exemple).

Se limiter aux codes d'APC, qui est l'un des leader, c'est déjà bien, ça couvre la majorité des codes. Il suffit d’intégrer un code 'inconnu' pour les autres
extrait du code d'apc:

Code : Tout sélectionner

#define STATUS_CAL		1       /* calibration */
#define STATUS_TRIM		2       /* SmartTrim */
#define STATUS_BOOST		4       /* SmartBoost */
#define STATUS_OL		8       /* on line */
#define STATUS_OB		16      /* on battery */
#define STATUS_OVER		32      /* overload */
#define STATUS_LB		64      /* low battery */
#define STATUS_RB		128     /* replace battery */
#define STATUS_BYPASS		256	/* on bypass */
#define STATUS_OFF		512	/* ups is off */
#define STATUS_CHRG		1024	/* charging */
#define STATUS_DISCHRG		2048	/* discharging */

Les dev de NUT ont de toute façon limité les codes, voici leur liste, mais qui ne donne pas d'info sur la chaine de caractères qui correspond:

Code : Tout sélectionner

/* boolean status values from UPS */
extern info_lkp_t online_info[];
extern info_lkp_t discharging_info[];
extern info_lkp_t charging_info[];
extern info_lkp_t lowbatt_info[];
extern info_lkp_t overload_info[];
extern info_lkp_t replacebatt_info[];
extern info_lkp_t trim_info[];
extern info_lkp_t boost_info[];
extern info_lkp_t bypass_auto_info[];
extern info_lkp_t bypass_manual_info[];
extern info_lkp_t off_info[];
extern info_lkp_t calibration_info[];
extern info_lkp_t nobattery_info[];
extern info_lkp_t fanfail_info[];
extern info_lkp_t shutdownimm_info[];
extern info_lkp_t overheat_info[];
extern info_lkp_t awaitingpower_info[];
extern info_lkp_t commfault_info[];
extern info_lkp_t timelimitexpired_info[];
extern info_lkp_t battvoltlo_info[];
extern info_lkp_t battvolthi_info[];
extern info_lkp_t chargerfail_info[];
extern info_lkp_t emergency_stop_info[];
extern info_lkp_t fullycharged_info[];
extern info_lkp_t depleted_info[];

On voit que les codes d'APC couvrent déjà bien le sujet

[stef74]

Ok, je regarderais quand j'aurais le temps.

Mais dans le plugin, je penses que ca sera surtout pour gérer les icones/couleur et des messages d'alertes.


Stef.

[fwehrle]

Ah mais si c'est juste pour les icônes et les couleurs, c'est pas important. Cest même mieux de ne pas regerer les codes dans le plugin. Si tout les codes sont passés au scénarios, ça me suffit largement. Je vais gérer la séparation du statut électrique avec un bête "matches".

D'ailleurs, je vois que OVER est une surcharge. Faudra que je vérifie ce qui a bien pu provoquer ça sur le mien alors, parce qu'il est chargé qu'à 14% normalement. Et la porte du garage ne le fait monter qu'à 25.



Envoyé de mon Nexus 6P en utilisant Tapatalk