When connection is lost, it does not try to reconnect

[softlion]

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]

1)

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.