When connection is lost, it does not try to reconnect

[gawindx]

When connection is lost, it does not try to reconnect

[gawindx]

The reconnection is done correctly on my side.
Did you check the "Reconnect" box in the settings?

[gawindx]

Clarification :
The reconnection is tested for a certain time (I no longer have it in mind) and, beyond this period, it no longer takes place.
It must then be restarted manually.

[softlion]

It would be nice to have a windows notification when the connection can not be restored after a specific amount of time.

I have an issue with my raspberryPI and its nut server which seems to crash after some time.

Which nut server for PI are you suggesting ?

[gawindx]

your idea of a notification is not without interest, I will see what I can do.

concerning the nut server, I have no particular suggestion, my server is under fedora.
On the other hand, if your pi uses systemd, maybe you can modify the service to restart it in the event of a crash, or create a timer to restart it automatically at regular intervals - for example, if it generally crashes after a few hours of operation, set up a timer which restarts it every hour.

this is not an ultimate solution but it would allow it to work all the time and the restart time would not be long enough for winnut to completely lose the connection.

[softlion]

my server is under fedora.

Yes it's a linux. But what package (apt get) are you using for the nut server ?

I will try your other suggestions.

[gawindx]

if you use apt-get, that means your pi is running debian (raspbian?)

I'm using fedora which is another distribution chiche si bases on CentOs, so I'm not using the same type of package at all (dnf instead of apt-get).

so I can't help you on this point.
you should check the nut server log to try to understand what's going on.

I remember having a version of fedora which lost the usb, and therefore the connection to the UPS, and I had overcome this problem by setting up a script which monitored the event in the logs and which relaunched at the times the USB then the nut server.

maybe you have a similar problem.

what is certain is that if raspbian / debian uses systemd (replacing init.rc) you must be able to set up a service, or modify the nut server service, to restart it either automatically or regularly.

[gawindx]

Did you find the solution for your Nut restart problem or do you need help?

[softlion]

I did not have a chance to check it again. Will do that tonight.

[softlion]

The pi stops responding completely after some time. I upgraded the OS. Lets see how many hours it can stay alive alone.

[softlion]

Tu es fr je crois :)
Le client n'affiche ni la tension d'entrée ni la fréquence d'entrée.
Et une fois qu'il est déco il se reco plus jamais tout seul.
Apres avoir relancé le pi j'ai du relancer l'app. Ok not a big deal mais bon.

Le souci c'est que je met mon pc en veille prolongée. Apres sortie de veille la carte réseau met quelques secondes à se rétablir. Secondes pendant lesquels aucun appel réseau ne réussit.

Tu devais mettre un circuit breaker (cf le pattern circuit breaker).

[gawindx]

Effectivement, je suis fr mais par principe je préfère utiliser la langue de Shakespeare pour une meilleure compréhension générale.

Dans ton cas, je vois plusieurs problèmes :

1. Le non affichage des valeurs

Soit c'est un nouveau problème auquel cas quelque chose ne se passe pas bien dans la connexion (avec les logs en debug cela devrait donner quelques infos à ce sujet).

Si c'était déjà le cas avant, il faudrait savoir si le pilote Nut pour ton onduleur retourne les bonnes valeurs et si oui si elles sont correctement traitées par WinNUT :

• Dans WinNUT, Fichier -> Variable de l'UPS. ça te listera toutes les valeurs récupérée par WinNUT
• Depuis une console sur ton pi, lance la commande suivante upsc nom_de_l_ups. Cela devrait te retourner toutes les valeurs que Nut gère pour ton onduleur.

Normalement, le résultat de ces 2 tests doit concorder, sinon cela veux dire que pour x raisons je traite mal une donnée.
Au passage, le champ driver.version devrait t'idiquer la version de nut, qui doit 2.7.4 (derniére version stable datant de 2016).
Et il me semble que le champ driver.version.internal te donne la version du pilote utilisé par Nut (en tout cas c'est mon cas).

2. Le redémarrage du pi

Lorsque WinNut perd la connexion, il rentre dans un cycle de reconnexion automatique (sous réserve que la case correspondante soit bien cochée dans les préférences). A partir de ce moment, il va essayer de se reconnecter toutes les 30 secondes et ce pendant 30 tentatives (soit 15 min).
Ce délai est normalement largement suffisant pour permette à Nut de répondre de nouveau.

Il faudrait identifier la raison du blocage du pi, à défaut mettre en place un système de contrôle de Nut sur ton pi.
Par exemple une tache cron exécutée toutes les x minutes (ou un service timer si systemd sur le pi) pour lancer un script qui tentera de récupérer des infos de la part de Nut et qui s'occupera de le tuer et le relancer si Nut ne répond pas.
ça c'est sous réserve que Nut ne fonctionne plus non plus en local sur le pi à ce moment sinon le problème ne vient peut être pas de Nut mais d'un service réseau sur le pi (pare-feu ou autres) ou du pi lui même.

Pour le script de test :

#!/bin/bash

RESULT_NUT=$(timeout 10 upsc nom_de_l_ups)
If [ $? <> 0 ]; then
cmd pour relancer nut:
systemd => systemctl restart nut-server
initrc => ???
fi

Pour expliquer rapidement, la commande timeout 10 va lancer la commande upsc pour 10 secondes (dans le cas ou elle bloque cela permet de ne pas bloquer le script) ; si le script nécessite plus de tritement par la suite, je le place dans une variable pour simplifier, mais ceci est optionnel.
On teste ensuite le code de sortie de la commande upsc retournée par timeout (si tout est ok elle doit être 0).

En tache cron (depuis root):
crontab -e
Ajout de la ligne (si tu ne connais pas vi, déplace le curseur sur la ligne ou tu veux ajouter ta commande, puis tape la touche Inser pour insérer ton texte).
*/5 * * * * le chemin du script de test
là c'est pour un lancement toutes les 5 min
Ensuite pour sauvegarder, tape :wq (: pour rentrer la commande dans vi, w pour write, q pour quit)

timer systemd :
Dans /etc/systemd/system, crée un nouveau fichier nommé par exemple verify-nut.timer
Insére le texte suivant :

[Unit]
Description=Verify and Restart Nut Server

[Timer]
OnBootSec=10min
OnUnitActiveSec=5min

[Install]
WantedBy=timers.target

Là encore, c'est pour un lancement toutes les 5 min mais à partir de 10 min au reboot

Toujours dans le même répertoire, crée un second fichier nommée comme le précédent mais avec l'extension '.service', donc dans notre cas : verify-nut.service
Et insére le texte suivant :

[Unit]
Description=Verify and Restart Nut Server
After=network.target

[Service]
WorkingDirectory=Chemin du répertoire ou est ton srcipt de test
ExecStart=Chemin du srcipt de test
Type=oneshot

Maintenant pour informer systemd de prendre en compte les changements :
systemctl daemon-reload

Ton timer sera alors en place et devrait s'occuper de tester et relancer automatiquement le serveur Nut quand il se plante (si c'est bien lui le problème).

3. Pour la mise en veille prolongée

Il faudrait peut être que je modifie le démarrage pour qu'il force un cycle de reconnexion plutôt qu'une tentative de connexion directe qui, si elle échoue ne va pas plus loin.

Ta proposition de circuit breaker n'est pas mauvaise, c'est une notion que je ne connaissais pas mais vu l'architecture de WinNUT, je ne suis pas sûre qu'elle s'y prête bien.
Le cycle de reconnexion étant déjà là pour palier à ce genre de problème et la non connexion à Nut n'est pas un circuit bloquant pour WinNUT mais juste un état.

Je pense de toute façon reprendre l'ensemble du projet à 0 mais cette fois ci depuis un langage plus robuste et ne posant pas de problème de faux positifs comme AutoIt peux en poser.
Je me rends bien compte que AutoIt est associé à de nombreux MalWare et de ce fait identifié comme indésirable par la plupart des Antivirus.
Ce qui nécessiterai de ma part de soumettre une requête à chaque éditeur à chaque fois qu'une mise à jour est faite sur WinNNUT pour éviter d'être black listé et je pense que j'ai mieux à faire.

[softlion]

1. effectivement infos non dispos

pi@pihome:~ $ upsc eaton800
battery.charge: 100
battery.charge.low: 20
battery.runtime: 937
battery.type: PbAc
device.mfr: EATON
device.model: Protection Station 800
device.serial: XX1X11111
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.synchronous: no
driver.version: 2.7.4
driver.version.data: MGE HID 1.39
driver.version.internal: 0.41
input.transfer.high: 264
input.transfer.low: 184
outlet.1.desc: PowerShare Outlet 1
outlet.1.id: 2
outlet.1.status: on
outlet.1.switchable: no
outlet.2.desc: PowerShare Outlet 2
outlet.2.id: 3
outlet.2.status: on
outlet.2.switchable: yes
outlet.desc: Main Outlet
outlet.id: 1
outlet.power: 25
outlet.switchable: no
output.frequency.nominal: 50
output.voltage: 230.0
output.voltage.nominal: 230
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.firmware: 1.13
ups.load: 17
ups.mfr: EATON
ups.model: Protection Station 800
ups.power.nominal: 800
ups.productid: ffff
ups.serial: AN2E49008
ups.status: OL
ups.timer.shutdown: -1
ups.timer.start: -1
ups.vendorid: 0463

2. Ah tu vas le réécrire ?

Dans ce cas n'oublie pas de donner accès aux variables de l'ups sous forme d'une zone texte facilement copiable. Idem pour toute la configuration. Comme vscode le fait par ex.

Merci pour les autres infos, je test!

[gawindx]

Je suis plutôt surpris qu'il ne fournisse pas ces infos qui me semble essentielle.
Pour la fréquence, il y'a normalement un paramètres pour la fixer dans les préférences (pas sur que ça marche bien vu que je n'ai qu'un seul onduleur et qu'il me fournis toute ces infos). Ce paramètre et là depuis peu de temps.
Je réfléchissais à faire de même pour la tension d'entrée mais je pense que cela ne sera pas du luxe...

Par contre ça ne fera que de mettre l'aiguille sur une valeur théorique, c'est donc juste "pour faire joli".

Et oui, je vais le réécrire complètement, je pense partir sur Visual Basic dans le sens ou je suis une quiche en C++.
Avec Visual Studio, ça devrait le faire quand même.

Par contre je vois pas trop ce que tu veux dire par :

Dans ce cas n'oublie pas de donner accès aux variables de l'ups sous forme d'une zone texte facilement copiable. Idem pour toute la configuration.

[gawindx]

ca y'est, je l'ai
tu veux dire que la fentre 'Varible de l'UPS' existante devra permettre de récupérer facilement sous format texte les valeurs, comme la commande upsc

Pour la config, elle sera surement en base de registre, mais rien n'empeche de créer une fonction pour sortir tout ça en texte pour les logs en cas de bugs.

[gawindx]

Si tu veux tester la V2 ( elle est encore en beta mais commence à être pas mal abouti), tu peux la trouver ici.

Par contre, je serais pas dispo la semaine prochaine donc tu peux me faire un retour mais je ne pourrais pas trop le traiter avant la semaine suivante.

[gawindx]

I think that with V2, this problem is no longer relevant

I close the issue, it will have to be reopened if necessary

je pense qu'avec la V2, ce probleme n'est plus d'actualite

je ferme l'issue, il faudra la rouvrir si necessaire

[softlion]

Ok. J'ai toujours le probleme avec l'app v1. Je teste la V2 maintenant que le PI est stable.

[gawindx]

Ah, je pensais que tu avais déjà testé la v2
Je réouvre en attendant ton retour

[gawindx]

Tu feras attention avec l’import automatique du fichier de config, je pense qu’il y’a un problème en raison des droits d’accès au répertoire « Program files »
Il me semble que dans ce cas de figure, le programme n’arrive pas à renommer le fichier ini, il faut dans ce cas :

• Fermer WinNUT
• effacer le fichier ini
• Redémarrer WinNUT

Autre solution, ne pas utiliser l’import automatique et redéfinir manuellement les paramètres

[softlion]

Il ne m'a pas proposé l'option d'import auto. Je fais la manip.

[softlion]

D'ailleurs il ne m'a pas importé les réglages.

[softlion]

On ne sais pas s'il arrive à joindre le serveur ou pas :( Il n'y a pas d'indicateur "connecté" ou "erreur connexion".

[gawindx]

Justement, l’import est automatique
Il suffit de déposer le fichier ini dans le répertoire d’install

Mais comme j’ai développé la fonction dans le répertoire de debug, je n’avais pas ce problème de droit

[gawindx]

Mais ça fait partie des petites choses à améliorer pour la version finale

La dernière version beta est ici : https://github.com/gawindx/WinNUT-Client/releases/download/v2.0.3.0-dev/WinNUT-Setup.msi

[softlion]

J'ai pas trouvé de fichier .ini dans C:\Program Files (x86)\WinNUT-client

J'ai vérifié IP et port. J'ai telnet et ca marche. Mais WinNut ne le détecte pas.

[gawindx]

Je me suis mal expliqué, et c’est aussi pour ça qu’il faut que je revoie la fonction (et encore, c’est une fonction appelé à disparaître car ne servant qu’a simplifier la transition entre la v1 et la v2)

Il suffit de récupérer le fichier ini de la v1 et de la mettre dans le répertoire de la v2
Au premier lancement il est lu puis renommé ( pour ne pas être relu à chaque lancement) - sauf qu’avec les droits d’accès du Program files, le fichier n’est pas renommé et cela bloque WinNUT

Si tu n’as pas conservé ton ancien fichier ini, le plus simple est de refaire la config manuellement.

[softlion]

voila le résultat.
Je ne savais pas qu'il fallait changer les valeurs dans "calibrage" sinon ca donne l'impression de pas marcher du tout.
faudrait un indicateur "non connecté" et "erreur connexion".

Pourquoi la charge batteries est marquée comme étant à 20% ?

[gawindx]

L’option de calibrage a toujours été présente, et les valeurs par défaut te laisse normalement apparaître des graph suffisamment précis pour voir les fluctuations.
Concernant les retours d’infos, ils sont présent dans le menu déroulant, comme pour la V1 (en tou cas pour la connexion et l’erreur de connexion ou sa perte) et l’état non connecté en lui même est représenté par l’absence de valeur aussi bien au niveau des graphs que des infos dans le panneau latéral.

Par contre pour la valeur de 20%, je te rejoins sur ce point, pas très logique.

Tu peux me donner les valeurs indiqués dans la fenêtre « variable UPS »? (Il y’a maintenant un bouton pour effectuer un copier coller direct dans le presse papiers)
On comparera avec les valeurs que tu avais avec la v1.8 parce que je suis assez étonné de ne pas voir les infos fabricant et autre dans le panneau lateral sur y’a capture alors qu’elles sont présentes dans les infos que tu m’avais fournies précédemment.

[gawindx]

Ce qui est aussi très surprenant c’est que, entre tes infos de la v1.8 et maintenant, on a l’impression que toutes les valeurs par défaut sont forcées dans ton cas.
On a l’impression que tu est bien connecté mais qu’aucune valeur ne remonte correctement (dans les logs, les lignes « Apply fallback Value »)

As tu un mot de passe ou une config particulière sur ton serveur nut?

[softlion]

Salut :)

les valeurs par défaut

Elles étaient toutes à 0. D'ou le souci je pense.
Je n'ai pas importé de .INI

Je ne peux pas ouvrir la fenetre "variable de l'UPS", ca fait planter l'app.

Je n'ai aucun mot de passe ni conf particulière sur le serveur NUT.

Sinon les graphes sont plus jolis.

[gawindx]

Bizarre la fenêtre UPS qui plante, j’ai réglé ce problème avec cette version.

Tu as quelque chose de particulier dans les logs quand ça se produit?

Pour les valeurs par défaut, je ne parlais pas de celle du calibrage, mais de celle appliquée dans le cas la donnée à interrogée ne retourne pas une valeur correcte
exemple : la donnée battery.charge ne retourne pas une valeur correcte - ou non fournie - donc on applique une valeur Fallback pour pouvoir traiter le reste des données. Le but étant de continuer le traitement et essayer de déterminer les données manquantes en fonction des autres données.

Dans ton cas, la valeur « Fallback » est appliquée à chaque fois et ça, ce n’est pas normal.

Tu as bien donné le bon nom pour l’UPS ? (Ça pourrait à la fois expliquer ce phénomène et le problème de la fenêtre UPS qui crashe - ca reste quand même un cas de figure que je n’ai pas envisagé donc à ajouter dans la Todo list)

[softlion]

J'ai mis un truc au hasard pour le nom de l'UPS :) Faut mettre quoi ?

[softlion]

Quand ca plante il n'y a aucun message, et aucun log.

[softlion]

Bon alors j'ai mis le nom de l'UPS comme c'est déclaré dans le serveur NUT. Ca marche mieux:

eaton800 (EATON/Protection Station 800/1.13)
battery.charge (Battery charge (percent of full)) : 100
battery.charge.low (Remaining battery level when UPS switches to LB (percent)) : 20
battery.runtime (Battery runtime (seconds)) : 671
battery.type (Battery chemistry) : PbAc
device.mfr (Description unavailable) : EATON
device.model (Description unavailable) : Protection
device.serial (Description unavailable) : AN2E49008
device.type (Description unavailable) : ups
driver.name (Driver name) : usbhid-ups
driver.parameter.pollfreq (Description unavailable) : 30
driver.parameter.pollinterval (Description unavailable) : 2
driver.parameter.port (Description unavailable) : auto
driver.parameter.synchronous (Description unavailable) : no
driver.version (Driver version - NUT release) : 2.7.4
driver.version.data (Description unavailable) : MGE
driver.version.internal (Internal driver version) : 0.41
input.transfer.high (High voltage transfer point (V)) : 264
input.transfer.low (Low voltage transfer point (V)) : 184
outlet.1.desc (Outlet description) : PowerShare
outlet.1.id (Outlet system identifier) : 2
outlet.1.status (Outlet switch status) : on
outlet.1.switchable (Outlet switch ability) : no
outlet.2.desc (Outlet description) : PowerShare
outlet.2.id (Outlet system identifier) : 3
outlet.2.status (Outlet switch status) : on
outlet.2.switchable (Outlet switch ability) : yes
outlet.desc (Outlet description) : Main
outlet.id (Outlet system identifier) : 1
outlet.power (Description unavailable) : 25
outlet.switchable (Outlet switch ability) : no
output.frequency.nominal (Nominal output frequency (Hz)) : 50
output.voltage (Output voltage (V)) : 230.0
output.voltage.nominal (Nominal output voltage (V)) : 230
ups.beeper.status (UPS beeper status) : enabled
ups.delay.shutdown (Interval to wait after shutdown with delay command (seconds)) : 20
ups.delay.start (Interval to wait before (re)starting the load (seconds)) : 30
ups.firmware (UPS firmware) : 1.13
ups.load (Load on UPS (percent of full)) : 23
ups.mfr (UPS manufacturer) : EATON
ups.model (UPS model) : Protection
ups.power.nominal (UPS power rating (VA)) : 800
ups.productid (Product ID for USB devices) : ffff
ups.serial (UPS serial number) : AN2E49008
ups.status (UPS status) : OL
ups.timer.shutdown (Time before the load will be shutdown (seconds)) : -1
ups.timer.start (Time before the load will be started (seconds)) : -1
ups.vendorid (Vendor ID for USB devices) : 0463

[softlion]

Du coup j'ai remis 0 partout dans les pref et ca marche mieux:

[softlion]

Je vois pas l'intéret de la FREQ d'entrée ?

[gawindx]

voila, j'allais te donner l'info mais tu m'as devancé.

Effectivement, c'est mieux.
Par contre, ça veux dire que je ne gère pas correctement ce cas de figure, ni pour la connexion, ni pour la fenêtre des variables.

Pour les tensions d'entrée, de sortie et la fréquence d'entrée, tu n'est pas obligé de mettre le mini à 0, ca te permettra de mieux cibler la plage de valeur que tu veux observer sur le graph.
Pareil pour la tension de batterie, elle est de 12V un mini/maxi entre 8 et 16 est largement suffisant.

Pour la fréquence d'entrée, j'ai récupérer l'idée sur un fork, à priori celui qui avait ajouté cette partie avait un onduleur qui ne retournait pas de valeur pour la fréquence ; en fait, le choix 50/60 permet de régler la valeur Fallback (histoire de ne pas avoir un graph avec l'aiguille au mini)

[gawindx]

La nouvelle version devrait pas tarder à être prête (d’ici moins d’une semaine et probablement avant).

Elle prendra en compte (entre autres) la détection du mauvais nom d’onduleur et le retrait de l’import automatique pour une fonction manuelle.

[gawindx]

Version libérée, les différents problèmes évoqués ont été traitées ainsi que pas mal de chose...
Je te laisse découvrir

[softlion]

Ca a l'air de bien marcher la connexion. L'icone est très sympa.
Par contre quand on veux déplacer la fenetre ca rame à mort.
Bon sinon le calibrage est pas censé etre automatique ?
Version 2.0.4.0

[gawindx]

J’ai pas remarqué de lenteur particulière, mais j’ai un pc qui tourne plutôt bien, donc je ne suis pas forcément objectif sur ce point.
Si tu pouvais me décrire plus précisément le comportement de la fenêtre pendant le déplacement.

Pour le calibrage automatique, ce n’est pas encore le cas, mais le projet est dans les cartons.
Pour l’instant je cherche à surtout à obtenir une version stable qui reprend au minimum ce qui marchait sur la version AutoIT.
Sur ce point, je pense que l’objectif est atteint et que je vais pouvoir passer à la réalisation des fonctionnalités qui, a mon sens, sont manquantes.

Le calibrage automatique en fait partie, tout comme une fonctionnalités de log plus aboutie et s’appuyant sur une base sqlite, ce qui permettra au passage de stocker les différentes valeurs récupérée pour pouvoir générer des graphs.
Dans les autres évolutions envisagées, je pense pousser le développement pour permettre de configurer les paramètres Nut de l’onduleur directement depuis WinNUT et pourquoi pas la possibilité d’exécuter des script personnalisés lors de l’extinction.

Mais tout ça me prendra un certains temps à développer donc il ne faudra pas être pressés, mais ça viendra.

Edit : le fait que toutes les valeurs soient à zéro n’est pas normal, il faudra que je reprenne cette partie du code pour empêcher cette possibilité, quitte à réappliquer les valeurs par défaut si nécessaire.

[softlion]

Si tu pouvais me décrire plus précisément le comportement de la fenêtre pendant le déplacement.

Alors j'attrape la barre de titre avec la souris et je déplace la fenetre.
Attendu: que ca se déplace de facon fluide
Résultat: ca fait des petits bonds. Et si le PC est chargé, ca fait des gros bonds.
J'ai réglé "niveau de journalisation: erreur" au lieu de "debug" (c'était debug par défaut ?) et ca va un peu mieux mais c'est pas encore le top.

Et sinon j'ai un gros PC :)
i7 6700K 4GHz 32G Ram et stockage NVMe.

2. Cette dernière version affiche les notifications de déconnexion/reconnexion dans Windows.

Personnellement, j'utilise toujours "mettre en veille prolongée" quand j'éteint windows.
Donc ce matin je rallume windows, ca restaure de veille prolongée.
Il faut quelques secondes à Windows pour récupérer son accès réseau (DHCP).
Et voici le résultat:

Je pense qu'il serait mieux que tu fasses le 1er essai de reconnexion de facon silencieuse. Ou alors uniquement si tu détectes la sortie de veille prolongée. Parce que les notifications inutiles c'est pénible.

[gawindx]

Je prend note de tes remarques.
Concernant le lag de la fenêtre, je ne me l'explique vraiment pas, tu as une config proche de la mienne, la différence étant que je travaille sur ssd plutôt que NVMe(trop cher) et que je n'ai que 16Go de Ram.
Au niveau carte vidéo, je n'ai qu'une 960 donc c'est pas la dernière bête de course et je la charge déjà pas mal en double écran.
Donc au vue de ta config, je devrais ressentir des lags similaires au tiens.
Un problème de pilote vidéo pas à jour peut être ?
Au niveau des interfaces, le double buffer est activée pour justement palier à ce genre de problème, WinNut est donc compilé avec cette option, c'est pour ça que j'aurais tendance à penser que cela vient de ta machine, mais je peux me tromper.
Par contre, cela m'a permis de voir que le double buffer n'est activée que pour la fenêtre principale => c'est corrigé et activé pour toutes les fenêtres (pas indispensable pour les fenêtres "statiques" mais...) ; par contre, cela ne sera présent que pour la prochaine version.

Je modifierais les notif pour qu'elles soient moins intrusives dans certains cas de figure.
JE te préviendrais quand l'exe sera dispo dans la branche dev

[softlion]

Salut salut :)
Mon pc est à jour.
Avec même la dernière version de Windows
Et j’ai une 970.
Sinon les nvme sont abordables ... chez crucial.fr !
Je peux pas plus t’aider sur le lag.

[gawindx]

Petite question qui me vient, qu'as tu comme valeur dans l'onglet connexion, pour la valeur Intervalle?
La valeur est en ms et doit etre par défaut de 5000, mais il semble que dans le cas du "bug" qui prvoque une mise à zero de toutes les valeurs (que je n'ai pas encore identifié n'ayant pas réussi à le reproduire) la valeur devienent elle aussi 0.
Il est possible dans ce cas que tu ait réglé une valeur trop basse et que, du fait, WinNut se connecte trop fréquemment au serveur NUT.
Ce comportement pourrait expliquer les lags que tu rencontres.

[softlion]

Alors j'avoue que j'ouvre l'App une fois par mois.
Les valeurs et graphiques sont jolis mais ne servent
A rien en day to day.
Sauf peut etre a vérifier que la batterie ne baisse pas
Alors que l'UPC est connecté.
Ce qui voudrais dire qu'il est temps de la changer :)

Donc je l'ai pas réouvert et je sais pas :)
De toute façon il notifie a chaque fois que je sort
De veille qu'il s'est bien reconnecté.
Du coup je sais que tout fonctionne.

Et pour info le raspberry pi ne plante plus depuis
Qu'il y a eu la grosse mise a jour d'os d'il y a
Quelques mois.

[gawindx]

Pour être franc, tu m’aides pas beaucoup la.
J’ai eu plusieurs retour ou j’ai put constater que les valeurs des préférences se sont retrouvées réinitialisées, non pas aux valeurs par défaut, mais carrément à 0 (pour l’instant je n’ai pas réussi ni à reproduire ni à corriger ce problème).

Je me demandais simplement si, comme il me semble que tu as rencontré ce problème, tu as une valeur correcte de configuré au niveau de la valeur de rafraîchissement.

La valeur est en millisecondes, et à 5000 par défaut.
Si tu as une valeur trop faible de configuré ici, WinNUT va interroger trop régulièrement le serveur NUT et cela pourrait expliquer les lags que tu rencontre dans le sens où, lorsque les valeurs sont récupérées, la partie GUI est elle aussi mises à jour.

Si c’est ça, il n’y a pas de bug à ce niveau mais il faudra que je change la valeur mini autorisé (c’est de toute façon prévu) et que j’identifie la raison de cette remise à zéro des valeurs.
Si ce n’est pas ça, on pourra considérer qu’il y’a un bug dans l’interface qui génère ces lags , le problème sera de l’identifier pour le résoudre.

[FileCity]

Les problèmes de connexion peuvent aussi provenir d'une switch/carte réseau, de firewall, etc...
Je ne crois pas que WinNUT soit nécessairement la cause à première vue.
Par contre, pour le délais de 'pool' en millisecondes, je crois qu'il devrait être mis en secondes, pour refléter les même mesures d'entrées sur le serveur NUT, pour homogénéiser le tout, pour éviter les erreurs. Je ne crois pas que d'entrer ce délais à la milliseconde près soit nécessaire, à mon humble avis. Le 0 devrait ne pas être permis.
5 secondes est le défaut de NUT, et 1 seconde en alerte est aussi par défaut.
Certains UPS ont aussi des comportements curieux, si un UPS semble erratique, le forum de NUT est très utile car le problème se règle plus souvent avec la config sur le serveur. Certains settings peuvent être ajustés.

[gawindx]

Pour les problèmes de connexion, je crois que c’est résolu (j’ai pas relu tout le fil de la discussion mais il me semble que c’est le cas).

Pour ce qui est de l’unité de temps pour l’intervalle, je te rejoins car je me rend bien compte que cela est ambigu (d’autant que j’ai bien précisé l’unité dans le popup au survol du champ mais que je n’ai pensé que cela serait tout aussi simple de l’ajouter dans le libellé du champ).

Il faudra de toute façon que je mette en place un wiki qui expliquera mieux le fonctionnement général et que je donne aussi quelques trucs et astuces pour aider à identifier si ce genre de problèmes vient de l’appli ou du réseau ( dans ce cas, un simple telnet sur l’ip/port du serveur Nut permet déjà de savoir si le réseau est en cause ou non).

En l’occurrence, pour le cas présent, @softlion rencontre un bug sur l’affichage de la GUI en elle même (elle saccade au déplacement ce que je ne rencontre pas sur mon installation alors que l’on a tous 2 des pc avec une config proche ce qui semblerait exclure un problème de performances graphiques ou autres) et je suspecte un rafraîchissement trop fréquent causant ce lag (a chaque fois que les valeurs sont mises à jours, les composant graph sont rafraîchis car ils sont directement liés aux valeurs correspondante) ; je trouve juste que cette explication pourrait bien correspondre aux symptômes étant donné qu’hormis ce détail, il n’a rien relevé d’anormal dans les logs.

[gawindx]

Petite précision, le zéro n’est normalement pas permis car les valeurs sont valides lors de la saisie mais il arrive, sans que j’ai réussi à le reproduire et retracer ce qui se passe, que les paramètres soit écrases et mis à zéro.
Quand cela arrive, les paramètres sont lus et utilisés lors du démarrage ou de la connexion (je devrais peut être rajouter quelques sécurités à ce niveau mais j’ai peur que ça devienne une usine à gaz ensuite).
C’est à ce moment qu’une valeur anormale est utilisée et pourrait causer ce genre de problèmes.

[softlion]

La valeur est en millisecondes, et à 5000 par défaut.

Aha c'est pas indiqué que c'est des millisecondeS.
Il y avait 10 dans la boite.
Ca a réglé le souci de fenetre lente

[FileCity]

10ms devait même flooder le serveur NUT et expliquer la lenteur ( single thread app ), fort possible...
Je me remet au bon soins de gawindx pour remettre ces unités en secondes ( 5 par défaut à l'installation ) serait un excellent début.

[softlion]

Normal que ca me mette batterie basse ?
Ah et c'est pénible, ca perds ses valeurs.
J'avais bien mis 240V et non 100V ...

[softlion]

J'ai mis 240V partout.
mais toujours batterie basse. Et propriétés (noms etc) vides.

[softlion]

07/09/2020 15:15:58 17268  UPS_Network : Enter Retrieve_UPS_Data
07/09/2020 15:15:58 17268  UPS_Network : Enter GetUPSVar
07/09/2020 15:15:58 17268  UPS_Network : Apply Fallback Value when retrieving battery.charge
07/09/2020 15:15:58 17268  UPS_Network : Process Result With battery.charge : VAR eaton800 battery.charge "255"
07/09/2020 15:15:58 17268  UPS_Network : Enter GetUPSVar
07/09/2020 15:15:58 17268  UPS_Network : Apply Fallback Value when retrieving battery.voltage
07/09/2020 15:15:58 17268  UPS_Network : Process Result With battery.voltage : VAR eaton800 battery.voltage "12"
07/09/2020 15:15:58 17268  UPS_Network : Enter GetUPSVar
07/09/2020 15:15:58 17268  UPS_Network : Apply Fallback Value when retrieving battery.runtime
07/09/2020 15:15:58 17268  UPS_Network : Process Result With battery.runtime : VAR eaton800 battery.runtime "86400"
07/09/2020 15:15:58 17268  UPS_Network : Enter GetUPSVar
07/09/2020 15:15:58 17268  UPS_Network : Apply Fallback Value when retrieving battery.capacity
07/09/2020 15:15:58 17268  UPS_Network : Process Result With battery.capacity : VAR eaton800 battery.capacity "7"
07/09/2020 15:15:58 17268  UPS_Network : Enter GetUPSVar
07/09/2020 15:15:58 17268  UPS_Network : Apply Fallback Value when retrieving input.frequency
07/09/2020 15:15:58 17268  UPS_Network : Process Result With input.frequency : VAR eaton800 input.frequency "50"
07/09/2020 15:15:58 17268  UPS_Network : Enter GetUPSVar
07/09/2020 15:15:58 17268  UPS_Network : Apply Fallback Value when retrieving input.voltage
07/09/2020 15:15:58 17268  UPS_Network : Process Result With input.voltage : VAR eaton800 input.voltage "220"
07/09/2020 15:15:58 17268  UPS_Network : Enter GetUPSVar
07/09/2020 15:15:58 17268  UPS_Network : Apply Fallback Value when retrieving output.voltage
07/09/2020 15:15:58 17268  UPS_Network : Process Result With output.voltage : VAR eaton800 output.voltage "220"
07/09/2020 15:15:58 17268  UPS_Network : Enter GetUPSVar
07/09/2020 15:15:58 17268  UPS_Network : Apply Fallback Value when retrieving ups.load
07/09/2020 15:15:58 17268  UPS_Network : Process Result With ups.load : VAR eaton800 ups.load "100"
07/09/2020 15:15:58 17268  UPS_Network : Enter GetUPSVar
07/09/2020 15:15:58 17268  UPS_Network : Apply Fallback Value when retrieving ups.status
07/09/2020 15:15:58 17268  UPS_Network : Process Result With ups.status : VAR eaton800 ups.status "OL"
07/09/2020 15:15:58 17268  UPS_Network : Enter GetUPSVar
07/09/2020 15:15:58 17268  UPS_Network : Apply Fallback Value when retrieving ups.realpower.nominal
07/09/2020 15:15:58 17268  UPS_Network : Process Result With ups.realpower.nominal : VAR eaton800 ups.realpower.nominal "0"
07/09/2020 15:15:58 17268  UPS_Network : Enter GetUPSVar
07/09/2020 15:15:58 17268  UPS_Network : Apply Fallback Value when retrieving ups.current.nominal
07/09/2020 15:15:58 17268  UPS_Network : Process Result With ups.current.nominal : VAR eaton800 ups.current.nominal "1"

[softlion]

Aha je peux pas mettre 255 dans battery charge lol.

[FileCity]

C'est un UPS Eaton. Il y a de l'info sur le forum de NUT.
En général j'utilise des UPS de APC, j'ai peu de problèmes avec ceux-ci.
Certains UPS ont de drôles de comportement parfois et il faut 'tweaker' les settings sur les config du serveur directement en premier. Quand le comportement sera stable et prévisible, ensuite regarde du côté de WinNUT.

[FileCity]

Aussi, mettre la gauge de 'Tension de Batterie' entre 9 et 15 me semble aussi plus sensé.
Les UPS chargent souvent les piles près de 13.5v ( 2.25v par cellule / 13.5v par pile ).
12v étant la tension nominale après une certaine décharge. À 10.5v la pile est considérée déchargée.

[softlion]

Le coup de la charge de batterie c'est pas un pb du serveur nut, c'est un probleme de winnut.
Le eaton renvoie la valeur entre 0 et 255.
Mais winnut bloque entre 0 et 100.
Du coup il voit 20% de charge alors qu'il y en a 100% !!

[FileCity]

En fait il faudrait voir et comparer avec d'autres UPS.
Mon APC va de 0 a 100.
WinNUT est 'probablement codé' pour des valeurs de 0 a 100, je n'ai pas vérifié le code.
Si ton UPS donne des valeurs de 0 a 255, il aurait besoin d'une échelle spécifique.
WinNUT pourrait en tenir compte, voir avec gawindx pour une prochaine version.
Si un user entre de 0 à 100 et inférieur ou égal a 100 = on fonctionne avec ça.
Si un user entre de 0 à 255 et inférieur ou égal a 255 = on prends la valeur, on divise par 2.55, on oublie le reste de la division et on garde la base et on fonctionne avec. On oeut donc la ramener de 0 à 100 en interne sans trop change le code.
Il faut simplement comparer si le chiffre entré et plus haut que 100 et avertir l'utilisateur pour éviter les erreurs d'entrées.
Ceci réglerait le problème du côté de WinNUT pour des UPS avec valeurs de 0 à 255.

[FileCity]

@gawindx,
Je crois qu'il faudrait créer une liste de features demandés et te laisser trier les priorités. La priorité sera gérée par toi, le code t'appartient.
Je suis nouveau dans GitHub alors je ne sais pas. Je travaille sur d'autres systèmes...
De cette façon les gens pourraient voir la liste et attendre les prochaines versions... Ceci évitera des discussions comme la présente, qui s'écarte du sujet...
Devrions nous (ou tu) créer des 'issues' pour chaque demande ou problème qui passe ?
Je veux bien donner mon aide mais je ne suis qu'un client de ce projet et je ne veux pas prendre la place d'autres personnes, je crois que tu comprends l'idée... J'aimerais ton avis sur le sujet...

[gawindx]

Entièrement d'accord pour la liste de features car effectivement ce fil s'écarte du sujet et mélange plusieurs problématiques.
Je vais réfléchir à la meilleures façons de mettre ça en place.

Concernant le problème de la charge :

• la charge est exprimé en pourcentage dans WinNut, il est donc normal qu'une valeur supérieur à 100 ne passe pas.
• Une valeur de 255 retournée par Nut, d’après ce que j'ai put lire à différent endroit, exprime soit une valeur non gérée par le driver NUT utilisée, soit une valeur ayant 256 palier.
  Dans ce cas de figure, il ne m'est pas possible de gérer toutes les versions ou onduleur existant et il m'a donc fallu faire un choix dans le traitement.

Ce choix est que, lorsque la valeur de charge est de 255 et en fonction des autres valeurs obtenues (tension de batterie entre autres, je n'ai plus la formule en tête) on essaie d'estimer la charge batterie actuelle.
Le problème étant que dans le cas d'un pilote mal fichus ou d'une config nut mal faite, je ne peux pas inventer des valeurs qui sont "exotiques"

@softlion, si tu regarde ce que tu as posté il y'a un mois (#16 (comment)), tu verras qu'à ce moment tu avais des valeurs cohérentes et que les informations que WinNUT pouvait récupérer auprès du serveur sont correctes (battery.charge = 100).

Et si on considère que :

• je n'ai pas modifié la classe gérant la connexion
• Qu’aujourd’hui WinNUT n'arrive même plus à savoir quel est le type de l'onduleur
  J'aurais tendance à penser que soit il y'a bug, soit il y'a un paramètre de connexion qui est mauvais depuis cette précédente capture.

@softlion et @FileCity :
PS et pour info, tout comme j'estime la valeur de la charge batterie dans certains, la valeur de runtime est elle aussi calculée lorsque la valeur qu'obtiens WinNUT est incohérente (86400 par exemple, à moins d'avoir un onduleur de la taille d'un local technique mais ça doit rester assez rare, et on utilisera pas WinNUT dans ce cas).
Et dans le cas ou on estime la valeur de runtime restant, la valeur de la charge batterie est prises en compte si j'ai bonne mémoire.
Donc, dans le cas de certains onduleur mal géré ou configuré, les informations affichées peuvent être des estimations qui s’appuient sur les lois de la physique et de l'Electricité (si je me suis pas planté lors de mon raisonnement sur ce point) mais qui dans certains cas peuvent aboutir à un grand n'importe quoi dans le sens ou on estime une valeur en se basant sur des estimations, cela peux donc amener à une marge d'erreur assez importante.

ça fait partie des points qui justifie le fait que je doive mettre en place un wiki pour informer de ces particularités en plus d'expliquer clairement le fonctionnement du soft.

[softlion]

Tu as raison.
Le driver nut du serveur nut est simplement déconnecté.
winnut ne le détecte donc pas ?

Il semble y avoir un bug dans ce serveur nut qui n'arrive plus à se connecter à l'eaton.
Par contre windows y arrive très bien avec l'app windows fournie par Eaton.

J'ai mis à jour le firmware de l'eaton et rebooté le pi.
Ca refonctionne.
On va voir pour combien de temps.

[softlion]

[gawindx]

Non, il semble que WinNUT ne le détecte pas, mais c’est un cas de figure que je n’ai pas encore étudié donc Nut l’indique probablement mais je ne l’interprète pas correctement.

Pour ton problème de déconnexion je ne pense pas que ça vienne de Nut mais plutôt un problème du pi.

j’ai personnellement eu le cas d’une version (Fedora il me semble mais c’était peut être une ubuntu server) qui plantait le port usb à intervalle régulière.
J’avais du mettre en place un script pour « casser » et remettre en route le bus usb en cause.
Ce problème a disparu sur une upgrade suivante et je ne pense pas que j’ai encore le script dans un coin, je regarderais quand même si jamais je le retrouve et que ça peut t’aider.

[FileCity]

Je ne sais pas si d’augmenter le délais de rafraîchissement pourrait être bénéfique ?
pollinterval = 5 dans UPS.CONF, le défaut est de 2.
5 secondes au lieu de 2 pourrait éviter de demander les données trop souvent au UPS et éviter de le 'flooder'.
Je crois que d’essayer ceci sur le UPS EATON serait un début.
Aussi peut-être valider si NUT tourne avec un user autre que root, si le user à les bons accès pour les ports USB.
Je ne sais pas si mon commentaire est pertinent mais bon... à suivre...

[gawindx]

Petit retour sur cette issue :

• Pour ce qui est de la connexion au serveur NUT alors que l'onduleur n'est pas connecté, cela ne devrait plus se produire avec la dernière version
• De même pour le problème de chargement des valeurs mal initialisées

Je pense que c'était les derniers problèmes encore non résolus sur ce post, je vais donc le fermer si tu n'y vois pas d'inconvénients.

[softlion]

Fais ce que tu veux j’ai abandonné le raspberry pi n’est pas stable c’est de la grosse merde en fait. Plus jamais pour ma part de raspberry. B. Le sam. 6 févr. 2021 à 18:17, Decaux Nicolas <[email protected]> a écrit :

Petit retour sur cette issue : - Pour ce qui est de la connection au serveur NUT alors que l'onduleur n'est pas connecté, cela ne devrait plus se produire vaec la derniére version - De même pour le problème de chargement des valeurs mal initialisées Je pense que c'était les derniers problèmes encore non résolus sur ce post, je vais donc le fermer si tu n'y vois pas d'inconvénients. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#16 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABOSJGZKFSLKYUMOGKUAHDS5V2T7ANCNFSM4NZVFN6Q> .

-- Benjamin Mayrargue Vapolia.fr [phone] vapolia.fr <http://www.vapolia.fr>/ Skype/WhatsApp/Slack/Discord/Zoom/Teams/Meets/...

[FileCity]

Pour ma part, c'est OK.
Merci.