Bonjour,

Y a-t-il un moyen de déterminer, en ligne de commande, si une imprimante
est allumée ou pas ?
(J'ai regardé sans succès lpadmin, lpstat et cupsctl.)

Merci pour vos pistes !
Seb.

Peut-être une c? mais juste un ping ne suffirait-il pas ?
Ou alors une simple tentative sur un des ports de service de l?imprimante (LPD, IPP, ?) ?
[..]

Le lundi 30 septembre 2019 à 14:03 +0200, Pierre Malard a écrit :
> Ou alors une simple tentative sur un des ports de service de
> l?imprimante (LPD, IPP, ?) ?

vivi, mais quelque chose qui ne rallume pas l'imprimante en veille, non
?

D'ailleurs en écrivant ça me rappelle que les imprimantes réseau ont
maintenant toutes un serveur http à ma connaissance.

Un ping me parait assez adapté pour quelque chose de très minimaliste.
Et je me demande a quel point un bon vieux wakeonlan ne fonctionnerait
pas en cas de besoin.

Sinon il y a souvent un hplip ou équivalent qui fonctionne pour un
constructeur donné.

Voilà en vrac mes 4,85 secondes de réflexions.

Bonjour,

> Peut-être une c? mais juste un ping ne suffirait-il pas ?

Ah, j'aurais dû préciser que l'imprimante est connectée en USB.

Pour détailler un peu: il y a une dizaine de jours j'avais envoyé un mail
sur cette liste parce que le comportement du spooler d'impression semble
avoir changé entre Debian 9 et Debian 10. Au lieu de réessayer d'imprimer
jusqu'à ce que l'imprimante soit allumée, il abandonne au premier échec.
Résultat, si je lance une impression avant d'allumer mon imprimante, je
suis obligé de passer ensuite par l'interface web de CUPS pour débloquer
le job. (Et je ne peux pas laisser l'imprimante allumée en permanence,
parce qu'elle passe en mode soufflerie pendant une minute toutes les dix
minutes.) Comme je n'ai pas trouvé comment régler le spooler (ce qui
serait la bonne solution) et comme mon message n'avait pas inspiré la
liste (aucune répnse), j'ai pensé à la solution de contournement
« détecter si l'imprimante est allumée » pour qu'un script temporise
l'envoi du fichier à CUPS jusqu'à ce qu'il ait le feu vert du système.

Je note donc qu'une idée serait de connecter l'imprimante en Ethernet. Ce
n'est pas si commode car elle n'a pas carte réseau, il faudrait que je
trouver un boîtier externe pour la conversion Ethernet/USB. Peut-on faire
plus simple, et idéalement régler le système plutôt que trafiquer le
hardware ?

Merci !
Seb.

Le 01/10/2019 à 11:42, Seb a écrit :
> Bonjour,

Bonjour

[...] Peut-on
> faire plus simple, et idéalement régler le système plutôt que trafiquer
> le hardware ?

Dans la configuration CUPS de ton imprimante as tu bien ErrorPolicy
retry-job ?

>> [...] Peut-on faire plus simple, et idéalement régler le système plutôt
>> que trafiquer le hardware ?
> Dans la configuration CUPS de ton imprimante as tu bien ErrorPolicy
> retry-job ?

Oui:

~>sudo grep ErrorPolicy /etc/cups/printers.conf
ErrorPolicy retry-job

Seb.

Bonjour à tous,
Salut Seb,

Une idée me vient en quelques secondes, tu ne pourrait pas "connaître"
l'état de ton imprimante via SNMP par exemple et ainsi "retarder"
l'impression depuis la configuration de l'impression pilote, ppd. Afin de
scripter le réveil, la vérification puis l'impression, "simplement" en
lançant une impression "standard" (CTRL+P).

Certains GET ou WALK SNMP don't meme "capables" de réveiller voire
redémarrer une imprimante.

Quel est ton modèle et as-tu déjà récupéré laMib SNMP ?

Cordialement,
Gwennhaël.

Le mar. 1 oct. 2019 à 12:56, Seb <seb> a écrit :
[..]

Le 01/10/2019 à 12:56, Seb a écrit :
> Oui:
> ~>sudo grep ErrorPolicy /etc/cups/printers.conf
> ErrorPolicy retry-job

Cela ne veut rien dire ! Si tu as plus d'une imprimante définie comment
sais tu que ce paramètre s'applique bien à ce modèle ?

Bonjour,

> Cela ne veut rien dire ! Si tu as plus d'une imprimante définie comment
> sais tu que ce paramètre s'applique bien à ce modèle ?

OK, je précise qu'il y a une seule imprimante branchée et que j'ai vérifié
que la même information était bien cliquée sur l'interface web de CUPS.

> Une idée me vient en quelques secondes, tu ne pourrait pas "connaître"
> l'état de ton imprimante via SNMP par exemple

Hou, ça fait longtemps que je n'ai pas regardé SNMP. Si ça marche avec une
imprimante branchée en USB, je ne sais pas faire.

> et ainsi "retarder" l'impression depuis la configuration de l'impression
> pilote, ppd.

Oui, c'est en gros ce que je proposais il me semble. Comme j'imprime
pratiquement toujours via un script maison (qui redistribue le travail
ensuite aux différents outils en fonction du type de fichier), retarder ne
pose pas de problème *si* on sait déterminer si l'imprimante est allumée
ou pas.

> Certains GET ou WALK SNMP don't meme "capables" de réveiller voire
> redémarrer une imprimante. Quel est ton modèle et as-tu déjà récupéré la
> Mib SNMP ?

C'est une imprimante HP assez ancienne, gros format (4250 laserjet), que
l'on n'allume qu'avec un commutateur physique. (Je serais très preneur
d'une commande pour l'arrêter sans toucher à ce bouton :-)

Seb.

Le 01/10/2019 à 11:42, Seb a écrit :
> Pour détailler un peu: il y a une dizaine de jours j'avais envoyé un
> mail sur cette liste parce que le comportement du spooler d'impression
> semble avoir changé entre Debian 9 et Debian 10. Au lieu de réessayer
> d'imprimer jusqu'à ce que l'imprimante soit allumée, il abandonne au
> premier échec. Résultat, si je lance une impression avant d'allumer mon
> imprimante, je suis obligé de passer ensuite par l'interface web de CUPS
> pour débloquer le job. (Et je ne peux pas laisser l'imprimante allumée

Bonjour, peut-etre pourrais-tu trouver de l'aide sur
<https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture>

On Tuesday 01 October 2019 12:56:18 Seb wrote:
> ~>sudo grep ErrorPolicy /etc/cups/printers.conf
> ErrorPolicy retry-job

Mon imprimante est en WiFi.

J'ai sans doute mal compris la ligne ci-dessous,
excuses sinon.

Imprimante allumée ou pas,
# grep ErrorPolicy /etc/cups/printers.conf
je reçois cette réponse :
ErrorPolicy retry-job
ErrorPolicy stop-printer

Bonne journée.