The minimalist IPP server doesn’t like the shape of our requests — a known quirk of the EcoTank.
The newly released 1.0.5 now sends requests in several variants (including those required by Epson) and automatically chooses the one that works.
Update the integration and then click the « Test a printer » button with your IP: if it works, your discovery will follow. If it still doesn’t work, paste me the exact message from the button — it tells exactly what the printer responds.
(For CUPS: this would make the connection work but very likely without ink levels — CUPS would query your Epson via the same finicky IPP. Might as well fix the problem at the source )
@guim31 with version 1.0.5, do you scan all machines across the entire network?
Because I have a bunch of my machines (including my printer) that seem to be scanned on all open ports (which means I have a lot of open ports, so …).
For the scan, precise answer: no, no network or port scanning.
The integration does exactly three things: it listens (via Gladys) for mDNS
announcements _ipp._tcp — passive multicast, no one is probed —; it connects in IPP
to port 631 of only the machines that announce themselves as printers or that you
have entered in the config; and it queries your added printers every 15 seconds,
always on port 631. Everything is in the code, open:
src/discovery.js and src/ipp/client.js in the repository.
What your firewall probably sees: repeated connections to port 631 of your
printer (status tracking, every 15 seconds), which some IDS label as « scan »
due to the frequency. And if several of your machines appear, check if they share a
printer via CUPS: they then announce themselves as IPP printers and are probed
for this purpose — only on port 631.
However, if your logs actually show connections on A LOT of different ports,
this does not come from this integration — and it would be worth identifying the
real source.
I’ll send you my logs in a private message because it’s through the integration logs that I saw all this scanning, nothing from my firewall or my network install.
Re @Chris75! Claude has dug deeper, and your previous observation contains a valuable clue:
you saw « idle (media-empty) » pass by — so the detection chain works, it
catches state changes correctly. If « printing » does not appear, it’s because your
printer does not report it via IPP.
And there is a likely explanation: on many HP printers, the IPP status reflects the
IPP print queue, not the physical engine. If you print from a PC with the HP
driver, the job goes through another channel (port 9100) and the IPP queue remains
empty — so « idle », even during printing. The « media-empty », on the other hand,
comes from the paper sensor and is reported regardless of the channel — hence why
you see one and not the other.
Two small tests to settle the matter, if you don’t mind:
Start a long print job and, WHILE it is printing, click on « Test a
printer » with your IP: it’s a live readout. Tell me what the button displays.
Print a page from your phone (AirPrint/Mopria use IPP) and see if « printing »
appears this time.
If the live test says « idle » while the paper is coming out, it’s the firmware that
does not publish the engine status via IPP — and in that case, no integration can
invent it. If, on the other hand, printing from your phone displays « printing »,
we will have confirmation: the status will work for everything printed via AirPrint.
Good news already: the encrypted connection works, your ET-2810 is found and its status is reported. Only the cartridges remain.
I found a probable explanation. When the integration queries the printer, it sends the precise list of information it wants (including ink levels). Some Epson firmwares respond politely… by forgetting the levels when explicitly requested, while they provide them when you ask for « everything » without specifying. Yes, it’s absurd, but it’s a classic with them.
The fix is published in version 1.0.8.
While you wait to install it, a small test would help me confirm: in the integration page, click the « Test a printer » button with the IP of your Epson (192.168.1.51), and paste the result here.
If you see your cartridges listed (even with weird values), it’s something else and I’ll dig deeper.
If you see « no consumables announced », it’s indeed the scenario above — and we’ll know if the next version fixes it, or if this model simply doesn’t provide its levels in IPP (some Epson only expose them via their proprietary app, in which case I’ll document it honestly).
Worst case, you update and let me know if it works!!
I got this response before your update.
Printer OK: EPSON ET-2810 Series — status « idle » — no consumables announced (https://192.168.1.51:631/ipp/print)
I have the same response with version 1.08.
Printer OK: EPSON ET-2810 Series — status « idle » — no consumables announced (https://192.168.1.51:631/ipp/print)
Thanks for the two tests, that’s exactly what I needed! And the result is very instructive: even when you ask your printer to tell us EVERYTHING, it never mentions its cartridges… in the format I was reading.
Explanation: there are actually two standard ways for a printer to announce its consumables in IPP. The most common one (the one I was reading), and a second, more recent one that many Epson printers use instead. Your ET-2810 is clearly part of the second school — and I was only looking at the first. It’s fixed: the next version will read both formats.
Bonus: I also made the “Test a printer” button more talkative. If it still doesn’t find any cartridges, it will now tell you precisely why:
« unused attributes: … » → the printer is announcing something I don’t know how to read yet, and the list will tell me exactly what;
« no consumable attributes in the IPP response » → in that case, it will be the definitive proof that your model reserves its ink levels for the Epson app (and I will then look into another lead, the SNMP protocol, which Epson printers generally support).
So even in the worst-case scenario, your next test will tell us where to go.
I have this with version 1.09.
Printer OK: EPSON ET-2810 Series — status « idle » — no consumable attributes in the IPP response (https://192.168.1.51:631/ipp/print)
Ok. « No consumable attribute in the IPP response », this means we’ve exhausted the two IPP standards: your ET-2810 simply doesn’t publish its ink levels via this protocol. It’s not a bug, it’s its firmware.
But there’s still a way, and it’s the right one: SNMP. This is the protocol that CUPS (the printing system for Linux and macOS) uses precisely to read ink levels, and Epson usually fills this in very correctly where they are silent in IPP. So I’ve added that to the integration.
Concretely, from the next version: if a printer says nothing about its cartridges in IPP, the integration will politely ask again via SNMP. And for the curious (and because the question of network traffic was raised quite rightly earlier in the thread), it’s deliberately very restricted:
only to the printer we’re already querying, never to anything else;
only if IPP didn’t return anything — a printer whose levels already work (like the HP printers in the thread, for example) will never send a single SNMP packet;
only at the time of reading the levels, not with every status check;
and if the printer doesn’t respond, we leave it alone for 30 minutes instead of retrying in a loop.
The « Test a printer » button will now tell you where the values come from (« via SNMP »).
One thing to check on your side if it still doesn’t work: in your Epson’s network settings, SNMP must be enabled (it is by default) and the community name left on public.
I got this as a printer OK: EPSON ET-2810 Series — status « idle » — Black Ink Bottle: unknown (-2), Cyan Ink Bottle: unknown (-2), Magenta Ink Bottle: unknown (-2), Yellow Ink Bottle: unknown (-2) (via SNMP) (https://192.168.1.51:631/ipp/print)etour.
My printer still only has text functionality
)
