cévhé a écrit 414 commentaires

Faut se mettre en orbite géostationnaire sinon ça va vite faire des nœuds dans le fil.

Lapin compris non plus :-(

Dans mon collège, je recycle des DELL 3060 de 2018 (4Go - SSD - distribution NIRD basée sur MINT) Mis à côté d'un poste de la dernière dotation (W11) ils n'ont pas à pâlir : démarrage tout aussi rapide (25s), ouverture de session plus rapide (5s). Les lancements des applications FF et LO un peu plus lentes mais pas de beaucoup (pas mesurées)

Et si la solution d'acétate de calcium ainsi produite s'évapore avant d'avoir complètement égoutté, il reste des trace d'acétate de calcium au lieu de carbonate de calcium.

Est-ce mieux ? ;-)

Les deux LV que j'ai eu à démonter (réparabilité pas forcément au top mais c'est un autre problème) avaient tous les deux la résistance et la pompe de circulation imbriquée. et vue la taille de la résistance chauffante il est illusoire d'espérer de l'eau chaude avant un certain nombre de tours complets de l'eau.

Calcul d'ordre de grandeur,
la capacité calo de l'eau est 4180 J.kg⁻¹.K⁻¹, pour 10 L et 45 K ça fait 1,8 MJ
Avec une résistance de 2 kW c'est un peu moins de 1ks à attendre que ça chauffe, un petit quart d'heure où la machine tourne déjà mais avec une eau d'abord froide et qui chauffe progressivement.

J'en ai déjà avec une entrée « eau chaude sanitaire » mais pour que ce soit rentable financièrement (le sur-coût n'est pas négligeable) il parait qu'il faut que l'eau chaude soit gratuite ou presque : par exemple avec un chauffe-eau solaire.

Autant je peux comprendre les arguments de séchage/condensation pour l'ouverture de la porte, la dégradation due à la vapeur chaude aussi mais le label énergétique ?

En quoi ouvrir la porte quand tout est fini va changer quoi que ce soit à la consommation ?

Une autre possibilité serait qu'elles contiennent des anions susceptibles de se lier aux ions calcium pour former un composé stable

Tout à fait possible, ça s’appelle un complexant et, en tout cas dans les lessives pour le linge, on utilise de l'EDTA
Ce n'est pas la même chose qu'une résine échangeuse d'ions mais le but est le même : se débarasser des ions Ca²⁺

merci

Le serveur peut-il fonctionner s'il est derrière un proxy ?

ça repart mais j'ai ajouté * à la fin de la règle udev :

ENV{DEVLINKS}=="*usb-EPSON_EPSON_EPSON_695Wi_695WT-mouse*"

Finalement cela n'a pas survecu au redémarrage : ça ne fonctionne plus. J'ai ajouté echo "$(date)- start" >> /tmp/foobar.log au script pour constater qu'il n'est plus lancé par le branchement du VPI…

Par curiosité, quelle est la différence ou intérêt ?

Solution provisoire et mise en test

Un fichier /etc/udev/rules.d/90-usbepson.rules :

ACTION=="add|remove", SUBSYSTEM=="input", ENV{DEVLINKS}=="*usb-EPSON_EPSON_EPSON_695Wi_695WT-mouse", RUN+="/usr/local/bin/map-epson2.sh"

un script /usr/local/bin/map-epson2.sh :

!/bin/sh

USER_NAME=$(loginctl list-sessions | awk '$6=="active" {print $3}')
DISPLAY_VALUE=":0.0"

su - "$USER_NAME" -c "export DISPLAY=$DISPLAY_VALUE;  sh -c \"xinput | grep EPSON | grep -oP '(?<=id=)[0-9]+' | xargs -I % xinput map-to-output % DP-2 \""

Ça semble fonctionner comme souhaité, du moins quand on branche le VPI avec une session ouverte. Reste à voir les cas où le VPI est déjà allumé et branché et le changement d'utilisateur…

Question peut-être bête : est ce que

loginctl list-sessions | awk '$6=="active" {print $3}' 

est quelque chose de sûr ? Ça à l'air de renvoyer l'id de l'utilisateur connecté mais il y a peut-être un problème caché…

Dans un des précédents messages, tu évoques un périphérique /dev/vpi

Mea culpa, c'était un raccourci parce que je n'avais pas le nom complet sous les yeux.

On connait déjà l'utilisateur.

J'ai peut-être mal compris mais en fait non, on ne le connais pas. J'ai fait des tests avec un utilisateur connu mais à priori on ne le connaît pas : c'est un utilisateur lambda du domaine.

pour trouver l'utilisateur qui a ouvert la première session :

C'est plutôt le dernier, ou plutôt celui qui a une session graphique ouverte au moment où le script est lancé.
Il peut y avoir plusieurs utilisateurs qui se sont succédé et qui n'ont pas forcémentfermé leur session.

Le nom du fichier (ici dev-sdb1.device) doit correspondre à un des fichiers de périphérique créé quand tu allumes l'appareil.

/usr/lib/systemd/user/dev-sdb1.device

Les périphériques créés sont :

/dev/input/by-id/usb-EPSON_EPSON_EPSON_695Wi_695WT-event-if02
/dev/input/by-id/usb-EPSON_EPSON_EPSON_695Wi_695WT-if02-event-mouse
/dev/input/by-id/usb-EPSON_EPSON_EPSON_695Wi_695WT-if02-mouse
/dev/input/by-id/usb-EPSON_EPSON_EPSON_695Wi_695WT-if01-event-mouse
/dev/input/by-id/usb-EPSON_EPSON_EPSON_695Wi_695WT-if01-mouse
/dev/input/by-id/usb-EPSON_EPSON_EPSON_695Wi_695WT-event-mouse
/dev/input/by-id/usb-EPSON_EPSON_EPSON_695Wi_695WT-mouse
/dev/input/by-path/pci-0000:00:15.0-usb-0:4.3:1.2-event
/dev/input/by-path/pci-0000:00:15.0-usb-0:4.3:1.2-event-mouse
/dev/input/by-path/pci-0000:00:15.0-usb-0:4.3:1.2-mouse
/dev/input/by-path/pci-0000:00:15.0-usb-0:4.3:1.1-event-mouse
/dev/input/by-path/pci-0000:00:15.0-usb-0:4.3:1.1-mouse
/dev/input/by-path/pci-0000:00:15.0-usb-0:4.3:1.0-event-mouse
/dev/input/by-path/pci-0000:00:15.0-usb-0:4.3:1.0-mouse

donc pour moi, si je suis bien, ce serait un fichier : /usr/lib/systemd/user/dev-usb-EPSON_EPSON_EPSON_695Wi_695WT-mouse.device ?

Est-ce résolu ?

Pas tout à fait de cette manière et je pense que j'ai dans mes essais précédents accumulé les erreurs de syntaxe que j'ai eu du mal à débugger. J'ai posté plus bas une ébauche partiellement fonctionnelle, solution que je pensais avoir déjà explorée.

Mais merci à tous ceux qui se sont déjà penché sur le problème…

Je progresse (enfin j'espère)

N'ayant pas de VPI à la maison, je me suis rabattu sur ce que j'avais, plus simple et finalement plus accessible. J'arrive à quelque chose qui fonctionne. J'ai utilisé comme périphérique USB une tablette graphique wacom et simplement xeyes comme programme à lancer.

fichier ̀ /etc/udev/rules.d/90-usb-test.rules` :

ACTION=="add|remove", SUBSYSTEM=="input", ENV{DEVLINKS}=="*Wacom_Co*-event-mouse", RUN+="/usr/local/bin/usb-test.sh"

Et dans le script /usr/local/bin/usb-test.sh :

#!/bin/sh

# valeurs pour mon portable perso
USER_NAME="christian"
DISPLAY_VALUE=":0"

su - "$USER_NAME" -c "DISPLAY=$DISPLAY_VALUE /usr/bin/xeyes" &

Constats :
- xeyes est bien lancé à chaque branchement - débranchement de la tablette
- ça marche même sans export et sans préciser le fichier .Xauthority

Demain j'essaye de remplacer d'abord la chaîne caractéristique de la tablette par une du VPI epson
Ensuite de remplacer xeyes par la longue ligne xinput | grep EPSON | grep -oP '(?<=id=)[0-9]+' | xargs -I % xinput map-to-output % DP-2

Reste une partie pour laquelle je n'ai pas d'idée : l'utilisateur est codé pour le moment en dur. Comment faire pour remplacer USER_NAME="christian" par le nom de l'utilisateur qui est effectivement connecté à l'ordinateur ? (non prévisible : il s'agit des utilisateurs du domaine)

Je plussoie l’incitation aux commentaires récursifs.

sans que ça ne devienne très confus

« confus » c'est effectivement le mot qui m'est venu à l'esprit quand j'ai vu la sortie du truc ;-)

La moodlebox est toujours maintenue

Un fichier de périphérique est-il créé au branchement ?

il y a effectivement 7 (!) entrées qui sont crées dans /dev/input/by-id/ du type usb-EPSON_EPSON_EPSON_695Wi_695WT-event-mouse` et qui disparaissent à la déconnexion

Il y a moyen d'en faire quelque-chose ?

J'ai essayé ceci, suggéré par ailleurs (mais qui ne marche pas mieux :-( )

/etc/udev/rules.d/91-vpi-epson.rules :

SUBSYSTEM=="usb", ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="0907", OWNER="${USER}", GROUP="${USER}", MODE="0664"
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="0907", TAG+="systemd", ENV{SYSTEMD_ALIAS}="/dev/vpi"
ACTION=="remove", SUBSYSTEM=="usb", ENV{PRODUCT}=="04b8/0907/*", TAG+="systemd"

/etc/systemd/user/epson-vpi.service :

[Unit]
Description=VPI Epson
Requisite=dev-vpi.device
After=dev-vpi.device
StartLimitIntervalSec=1m
StartLimitBurst=5

[Service]
Type=simple
ExecStart=/usr/local/bin/map-epson.sh
Restart=on-failure
RestartSec=1

[Install]
WantedBy=dev-vpi.device

et le script :

#!/bin/sh
xinput | grep EPSON | grep -oP '(?<=id=)[0-9]+' | xargs -I % xinput map-to-output % DP-2
logger -t epson 'epson détecté...'

Le service est activé par par systemctl --user enable epson-vpi.service

En branchant le VPI, je vois bien que le script est lancé
Mais le stylet n'est pas aligné !! alors que si l’utilisateur lance la commande directement, ça fonctionne et le stylet est aligné.

Pourtant dans ce cas, su n'est pas nécessaire, c'est bien l'utilisateur qui exécute le script.