Le serveur IPP minimaliste n’aime pas la forme de nos requêtes — un caprice connu des EcoTank.
La 1.0.5 qui vient de sortir envoie désormais les requêtes sous plusieurs variantes (dont celles que les Epson exigent) et choisit automatiquement celle qui marche.
Mets à jour l’intégration puis relance le bouton « Tester une imprimante » avec ton IP : si ça passe, ta découverte suivra. Si ça coince encore, colle-moi le message exact du bouton — il dit précisément ce que l’imprimante répond.
(Pour CUPS : ça ferait marcher la connexion mais très probablement sans les niveaux
d’encre — CUPS irait interroger ton Epson via le même IPP capricieux. Autant régler
le problème à la source )
@guim31 avec la version 1.0.5, tu fais un scan de toutes les machines sur tout le réseau ?
Car j’ai un paquet de mes machines (dont mon imprimante) qui sont scannées sur tous les ports ouverts j’ai l’impression (ce qui veut dire que j’ai plein de ports ouverts donc …).
Pour le scan, réponse précise : non, aucun scan de réseau ni de
ports. L’intégration fait exactement trois choses : elle écoute (via Gladys) les
annonces mDNS _ipp._tcp — du multicast passif, on ne sonde personne — ; elle se
connecte en IPP au port 631 des seules machines qui s’annoncent comme imprimantes
ou que tu as saisies dans la config ; et elle interroge tes imprimantes ajoutées
toutes les 15 secondes, toujours sur le port 631. Tout est dans le code, ouvert :
src/discovery.js et src/ipp/client.js sur le dépôt.
Ce que ton pare-feu voit probablement : les connexions répétées vers le port 631 de
ton imprimante (le suivi d’état, toutes les 15 s), que certains IDS étiquettent
« scan » à cause de la fréquence. Et si plusieurs de tes machines apparaissent,
vérifie si elles partagent une imprimante via CUPS : elles s’annoncent alors
elles-mêmes comme imprimantes IPP et sont sondées à ce titre — sur le seul port 631.
Par contre, si tes logs montrent réellement des connexions sur PLEIN de ports
différents, ça ne vient pas de cette intégration — et ça vaudrait le coup d’en
identifier la vraie source.
Re @Chris75 ! Claude a creusé, et ton observation précédente contient un indice précieux :
tu as vu passer « idle (media-empty) » — donc la chaîne de détection fonctionne, elle
attrape bien les changements d’état. Si « printing » n’apparaît pas, c’est que ton
imprimante ne le dit pas via IPP.
Et il y a une explication probable : sur pas mal de HP, l’état IPP reflète la file
d’impression IPP, pas le moteur physique. Si tu imprimes depuis un PC avec le pilote
HP, le travail part par un autre canal (port 9100) et la file IPP reste vide — donc
« idle », même pendant l’impression. Le « media-empty », lui, vient du capteur papier
et remonte quel que soit le canal — d’où le fait que tu voies l’un et pas l’autre.
Deux petits tests pour trancher, si tu veux bien :
Lance une impression longue et, PENDANT qu’elle sort, clique sur « Tester une
imprimante » avec ton IP : c’est une lecture en direct. Dis-moi ce qu’affiche
le bouton.
Imprime une page depuis ton téléphone (AirPrint/Mopria passent par IPP, eux)
et regarde si « printing » apparaît cette fois.
Si le test en direct dit « idle » pendant que le papier sort, c’est le firmware qui
ne publie pas l’état moteur via IPP — et là, aucune intégration ne peut l’inventer.
Si au contraire l’impression depuis le téléphone affiche « printing », on aura la
confirmation : l’état marchera pour tout ce qui imprime via AirPrint.
Salut @elfedagger ! Désolé j’étais passé à coté du message…!
Bonne nouvelle déjà : la connexion chiffrée fonctionne, ton ET-2810 est trouvée et son état remonte. Il ne reste « que » les cartouches.
J’ai trouvé une explication probable. Quand l’intégration interroge l’imprimante, elle envoie la liste précise des infos qu’elle veut (dont les niveaux d’encre). Certains firmwares Epson répondent poliment… en oubliant justement les niveaux quand on les demande explicitement, alors qu’ils les donnent quand on demande « tout » sans préciser. Oui, c’est absurde, mais c’est un grand classique chez eux.
Le correctif est publié dans la 1.0.8.
En attendant que tu l’installes, un petit test m’aiderait à confirmer : dans la page de l’intégration, bouton « Tester une imprimante » avec l’IP de ton Epson (192.168.1.51), et colle-moi le résultat ici.
Si tu vois tes cartouches listées (même avec des valeurs bizarres), c’est autre chose et je creuse.
Si tu vois « aucun consommable annoncé », c’est bien le scénario ci-dessus — et on saura si la prochaine version le règle, ou si ce modèle ne donne tout simplement pas ses niveaux en IPP (certains Epson ne les exposent que via leur appli maison, auquel cas je le documenterai honnêtement).
Au pire, tu mets à jour et tu me dis si ça fonctionne !!
j’ai ça comme retour avant ta mise à jour.
Imprimante OK : EPSON ET-2810 Series — état « idle » — aucun consommable annoncé (https://192.168.1.51:631/ipp/print)
j’ai le même retour avec la version 1.08.
Imprimante OK : EPSON ET-2810 Series — état « idle » — aucun consommable annoncé (https://192.168.1.51:631/ipp/print)
Merci pour les deux tests, c’est exactement ce qu’il me fallait ! Et le résultat est très instructif : même quand on demande à ton imprimante de TOUT nous dire, elle ne mentionne jamais ses cartouches… dans le format que je lisais.
Explication : il existe en fait deux façons standard pour une imprimante d’annoncer ses consommables en IPP. La plus courante (celle que je lisais), et une seconde, plus récente, que pas mal d’Epson utilisent à la place. Ton ET-2810 fait visiblement partie de la deuxième école — et moi je ne regardais que la première. C’est corrigé : la prochaine version lit les deux formats.
Bonus : j’ai aussi rendu le bouton « Tester une imprimante » plus bavard. S’il ne trouve toujours pas de cartouches, il dira maintenant précisément pourquoi :
« attributs non exploités : … » → l’imprimante annonce quelque chose que je ne sais pas encore lire, et la liste me dira exactement quoi ;
« aucun attribut de consommable dans la réponse IPP » → là, ce sera la preuve définitive que ton modèle réserve ses niveaux d’encre à l’appli Epson (et je regarderai alors une autre piste, le protocole SNMP, que les Epson supportent généralement).
Donc même dans le pire des cas, ton prochain test nous dira où aller.
J’ai ça avec la 1.09.
Imprimante OK : EPSON ET-2810 Series — état « idle » — aucun attribut de consommable dans la réponse IPP (https://192.168.1.51:631/ipp/print)
Ok. « Aucun attribut de consommable dans la réponse IPP », ça veut dire qu’on a épuisé les deux standards IPP : ton ET-2810 ne publie tout simplement pas ses niveaux d’encre par ce protocole. Ce n’est pas un bug, c’est son firmware.
Mais il reste une porte, et c’est la bonne : le SNMP. C’est le protocole que CUPS (le système d’impression de Linux et de macOS) utilise justement pour lire les niveaux d’encre, et les Epson le remplissent en général très correctement là où ils sont muets en IPP. J’ai donc ajouté ça à l’intégration.
Concrètement, à partir de la prochaine version : si une imprimante ne dit rien sur ses cartouches en IPP, l’intégration lui redemande poliment en SNMP. Et pour les curieux (et parce que la question du trafic réseau avait été soulevée à juste titre plus haut dans le fil), c’est volontairement très encadré :
uniquement vers l’imprimante qu’on interroge déjà, jamais vers autre chose ;
uniquement si l’IPP n’a rien donné — une imprimante dont les niveaux fonctionnent déjà (les HP du fil, par exemple) n’enverra jamais le moindre paquet SNMP ;
uniquement au moment de relever les niveaux, pas à chaque vérification d’état ;
et si l’imprimante ne répond pas, on la laisse tranquille pendant 30 minutes au lieu de réessayer en boucle.
Le bouton « Tester une imprimante » te dira maintenant d’où viennent les valeurs (« via SNMP »).
Un point à vérifier de ton côté si jamais ça ne marche toujours pas : dans les réglages réseau de ton Epson, le SNMP doit être activé (il l’est par défaut) et le nom de communauté laissé sur public.
Croisons les doigts, cette fois je suis plutôt confiant !
)
