Yes, you fixed it! The Printer Message is updated now: it clears after I insert the tray again.
Yes, you fixed it! The Printer Message is updated now: it clears after I insert the tray again.
That closes every point you raised. Thank you — genuinely.
For the record, what your reports actually fixed: the waste bottle read upside down and rang a false alarm, empty manual feed slots kept the paper alarm on permanently, the capability icons were unreadable on mobile, a low-supply warning could never be cleared after an update, and printer alerts stayed stuck on the last complaint. Five real bugs, none of which I would have found on an Epson.
Along the way I gave you three wrong diagnoses on that Lexmark, and each time a screenshot of yours was what corrected me. That’s the argument for asking for readings instead of reasoning from the code, and I’ll keep taking it.
I think you might be able to use the onoff capability for that. Homey’s setUnavailable() is only meant for reporting when a device is offline or unavailable. You can also provide a custom message there. Examples of usage: when Homey can’t connect to a device or a manufacturer’s server, when the manufacturer’s server reports the device as offline, if the function to poll the data threw an error, etc.
Yes, better now! Thx…
That was the last outstanding report in this thread — every one of them is now confirmed fixed on the reporter’s own hardware. Thank you for chasing it down with me.
But “class 3” and “class 4” is the actual toner left
It isn’t, and your own two screenshots prove it: the Ricoh’s web page shows Cyan at Resterend niveau 5 and the other three at niveau 4 — yet all four read class 3 in the app. If class were the level, Cyan would differ.
class is the printer telling us what kind of supply it is: 3 = a consumable that drains, 4 = a receptacle that fills. That’s why your Waste Cartridge is the only class 4 on the list.
The reason those cartridges show as unknown is separate: your Ricoh reports level -3, which in the standard means “there is some left, and I won’t put a number on it”. Its 1-to-5 gauge exists only in Ricoh’s own web page.
That distinction was worth making visible, so v1.0.17 now says some left rather than unknown for a -3, on both cartridges and trays. Same for your Tray 1. It doesn’t invent a percentage — a number that isn’t there shouldn’t be guessed — but it stops a healthy printer looking like a broken one.
Is transfer and fuser reported too?
Yes, whenever the printer puts them in the standard supplies table — a Lexmark C3326dw in this thread lists Fuser and Transfer Module and they show up as their own tiles. Yours doesn’t: it publishes only five rows there (four toners plus the waste bottle). The fuser, transfer unit and transfer roller on your web page live in Ricoh’s private MIB, which the app deliberately doesn’t touch — guessing at a vendor’s private OIDs without the hardware to test on is how you end up showing people wrong numbers.
Homey’s
setUnavailable()is only meant for reporting when a device is offline or unavailable.
You’re right, and that’s the lesson I took from this thread the hard way — a user asked for a greyed-out tile, I reached for that flag, and he got his readings hidden plus a prompt to repair a printer he’d switched off himself. v1.0.13 lets him turn the flag off entirely; onoff would be the better answer rather than just an escape hatch.
One caveat before I do it: onoff is settable by default, and this app is strictly read-only over SNMP — there’s no wake-on-LAN here, no way to switch a printer back on. So it would have to be declared setable: false, otherwise every printer grows a switch that does nothing.
With that, it does look like the right mechanism: the tile dims the way people expect, the levels stay on screen at their last reading, and the auto-generated Flow cards come free. Thanks for the pointer — it’s the kind of thing that’s obvious once someone who knows the SDK says it out loud.
Done — v1.0.18, in review now.
The device carries a read-only onoff, true whenever a read succeeds and false the moment one fails. The tile dims straight away, the last levels stay on screen, nothing prompts for a repair, and the Flow cards come along for free. setable: false, since SNMP can’t power a printer back on.
Marking the printer unavailable is now the separate, stronger step it should always have been — still there for anyone who wants it, still skippable, and no longer the only way to get a tile to grey out.
Thanks for the correction. It took a user being annoyed by the symptom and you naming the mechanism to get this right.
Is my understanding correct that after the change related to the unavailable status in v1.0.18, it is still possible to keep the capabilities displayed with their last known status? Instead of the repair screen?
If so, how can I achieve that? In the prior version I had set the ‘Show offline after’ setting to 0 seconds to have the capabilities displayed when the printer is switched off (not available).
In v1.0.18 this no longer works, though the help text at the ‘Show offline after’ setting, still indicates that I need to set the value to 0 seconds to keep the capabilities displaying their last known value when the printer is not available.
Is my understanding correct that after the change related to the unavailable status in v1.0.18, it is still possible to keep the capabilities displayed with their last known status? Instead of the repair screen?
Yes — and you found two real bugs in the way of it. Both fixed in v1.0.19, on Test now.
The Responding row was never added to your device. Every capability is added from a successful read, which is right for the rest of them — they describe what the printer reported. This one describes whether it reported at all, so the case it exists for is a printer that is off when the app starts, and that is exactly the case no read can cover. If your printer was off when 1.0.18 installed, you got no Responding row and no dimming at all. It is now added at startup.
In the prior version I had set the ‘Show offline after’ setting to 0 seconds
And 0 only ever declined to set the unavailable flag — it never cleared one already set. That flag survives an app restart, and only a successful read lifted it. So a device flagged before you turned the setting off stayed flagged, showing the exact repair screen the setting exists to prevent, with no way out but the printer coming back on. It is now cleared on the failing check, and the moment you save the setting.
It is still 0, same as before; only the hint wording changed. If 1.0.19 still greys you out, tell me two things: whether the device now has a Responding row, and what Show as offline after reads on it.
I checked version v1.0.20: you fixed it.
When my printer is powered down (offline) the device tile is dimmed and the last known capability values are available:
After I power up my printer, the device tile becomes grey/shows the on state and capabilities are updated.
I also noted that I now have a button tab with a read-only on/off button (as you indicated in one of your prior posts). My ‘Show as offline after’ setting is still at 0.
If by ‘Responding row’ you mean the entry in the device tile’s log tab, then yes it is there:
The first (most recent) entry indicates that the printer responded (after I switched it on). The second (older) entry was created when I updated the app and the printer was still powered down.
So, all in all, it seems to work as expected. Thanks again for your quick fix 
.
Yes, you need to run setAvailable() before your app sets the capabilities
Question: what will happen to the existing insights of the various trays, when the media type changes? So when the tray contains a different paper size/type than when during pairing the printer to the app.
Since the capability names and hence insights contain the type of media (like iso-a4-white and iso-a5-white), next to the name of the tray, will that result in new insight items every time you change the media type in a tray?
Or is the capability (and insight) name fixed based on the media that was loaded in the tray when the printer was first paired with Homey?
v1.1.1 is on Test. Two things in it are worth more than the feature work, so those first.
The condition card “a supply is below a level” has never worked. Not a regression — it has answered not below whatever threshold you set, in every version this app has ever published. If you built a Flow on it, that Flow has quietly done nothing since the day you wrote it.
The argument is an autocomplete, and Homey hands the run listener the whole object you picked, not its id. The code expected an id, matched nothing, and read that as “no level, so not below”. Fixed, and measured on a cartridge at 20 %: before, below 99 → false; after, below 99 → true, below 1 → false.
Worth re-checking any Flow you have on it.
Question: what will happen to the existing insights of the various trays, when the media type changes?
Nothing — the series continues, it just gets renamed. Insights is keyed on the capability id, and the media only ever appears in the title. I checked yours rather than guessing:
id: homey:device:…:measure_tray.1
title: "Sheet feeder bin 1"
Change the paper and the title follows the printer; the id is fixed by the tray’s position, so the history stays in one unbroken graph. That was already true before 1.1.0 — printer_tray_1 was position-based too.
you need to run setAvailable() before your app sets the capabilities
Correct, and I had it the wrong way round: the failure path wrote the values first and lifted the flag afterwards, so a device still carrying it dropped the very writes meant to dim its tile and only caught up a poll later. Reordered — thank you, that is twice now.
What else is in 1.1.0/1.1.1
- Every consumable gets its own row, however many the printer reports. The old ceiling of eight unnamed supplies is gone, and the four fixed paper trays with it. A laser listing toner, photoconductor, waste bottle, fuser, transfer module and rollers no longer drops one on the floor while the low-supply alarm keeps counting it.
- Levels can be shown beside the device icon as the indicator.
- The printer-error and cover alarms now use Homey’s own capabilities, so they come with built-in Flow cards instead of ones I had to write.
- Paper trays no longer lose their Insights history when a single reading is missed.
Two costs, stated plainly. Every level was renamed, so its Insights history restarts, and a Flow that inserted a level as a tag needs that tag picking again — cards that read a level keep working. And it needs Homey firmware 12.11 or newer.
@SunBeech, @Henk_Renting — one favour when you get to it. Your Lexmark and Ricoh are the only machines here that report a waste bottle and separate parts, and those are the two migration paths that have never run on real hardware; my Epson produces neither. If your waste tank and fuser come back with sensible levels and the right names after updating, that closes it. If a row goes missing or lands on the wrong part, I would rather hear it early.
Takk for informasjonen!
Thank you for this app!
Confirmed working with HP LaserJet CP1025nw.
It wasn’t discovered automagically (different subnets), but it works once I entered the IP address.
Thanks again, @byackee1!
Your app is already popular, considering the posts here… 
This is what my Ricoh shows like now:
Have also sent you a diagnostic report, if that helps…
c964f391-956f-4e24-aad1-44affa639f2c
Have also sent you a diagnostic report, if that helps…
It helped more than you know — it named a bug I shipped this morning, and your printer is not the one at fault. v1.1.3 is on Test with the fix.
Your log says it in one line:
Not recording a rename map: the printer's supplies no longer replay
to what this device holds (supply_waste).
Migrating 9 capability/ies: alarm_printer_error, supply_cyan, …
Migrating 0 capability/ies:
When 1.1.0 renamed every level, devices upgrading from 1.0.x need a map from the old names to the new ones, so Flows keep resolving. I added a check that refuses to write that map if it cannot prove it lines up — good idea, wrong comparison: it weighed the full list of supplies your Ricoh reports against a list that deliberately excludes the ones it already knows how to rename. Five never equals one, so it refused every colour printer, every time.
What that did to you: the four toners, both trays, the page counter and the two alarms migrated fine — those are renamed from a fixed table. The waste cartridge was left behind as a dead row that never gets a level, no map was written, and it repeated that refusal in your log every five minutes.
Fixed, and the comparison now lives somewhere it can be tested — against your Ricoh’s exact capability list. Putting the shipped version back fails three tests.
Updating is enough. The old row is still on your device, so the migration runs again on the next reading and this time believes itself. Nothing to re-pair — though I see you already did, which would also have worked.
One thing I would still like from you when you get a moment: whether the waste cartridge now shows up as its own row with a sensible name. Your Ricoh and SunBeech’s Lexmark are the only machines here that report a waste tank, and my Epson has none — so that path has still never been confirmed by anyone. It reports level -3, so expect some left rather than a percentage; the row existing and being named right is what I am after.
@Peter_Kawa — thank you for the report, and that is worth writing down: the automatic search only covers the subnet Homey itself sits on, so a printer on another one will never appear in it. Entering the address by hand is the supported path there, not a workaround. Glad the CP1025nw works.
I checked based on version 1.1.2. I deleted and re-paired my printer as I noted the transition from the pre-1.1.0 version to 1.1.0 apparently mixed up the capabilities.
I see the following capabilities now. The blue ones are the one you are referring to, if I am correct.
The Waste Toner Bottle status is the only one that I can actually check myself in the printer’s interface. There it is not reported as an inverted percentage, but as a three scale metric, similar as for the output bin: Full, Nearly Full and OK:
But I think the underlying data is percentage based, as the printer allows me to set a custom message based on the level in percentage.
For the Transfer Module and Fuser, the printer only reports the number of cycles/pages it handled on the statistics report (which also includes the waste toner bottle again).
There is no KPI for these two on the dashboard itself. I assume the printer monitors these components and will give a message on the panel/display when the fuser or transfer module needs replacing.
I think the percentage values for the three items is ok. I assume those are also the values actually reported by the printer over SNMP? My guess is that they will change when the waste bottle fills and the remaining waste space decreases c.q. the health of the fuser/transfer module decreases. So lowering the percentage.
EDIT - Just saw that you released version 1.1.3. The above also applies to that version.
I deleted and re-paired my printer as I noted the transition from the pre-1.1.0 version to 1.1.0 apparently mixed up the capabilities.
That was a real bug, not your Lexmark being odd — and you are the second person to hit it today. Fixed in v1.1.3, now on Test.
A device coming from 1.0.x needs a map from the old capability names to the new ones so Flows keep resolving. I added a check that refuses to write that map unless it can prove the two line up. Right instinct, wrong comparison: it weighed every supply your printer reports against a list that deliberately excludes the ones it already knows how to rename. Five never equals one, so it refused every colour printer. The toners, trays, page counter and alarms migrated on their own table, and the waste bottle was left behind as a dead row — which is exactly the “mixed up” you saw. Re-pairing was a perfectly good way out of it.
I think the percentage values for the three items is ok … they will change when the waste bottle fills and the remaining waste space decreases c.q. the health of the fuser/transfer module decreases. So lowering the percentage.
Your reading is exactly right, and it is worth saying so plainly because I got this wrong three times before your very first screenshot corrected me. RFC 3805 defines the level as “the current level if this supply is a container; the remaining space if this supply is a receptacle”. So a waste bottle counts down as it fills, just like a cartridge counts down as it empties — 100 % always means nothing to do. The app takes the number as the printer gives it and never inverts it. Your Lexmark reporting a brand-new bottle as 0 % was that inversion, and removing it in 1.0.8 is why it reads sensibly now.
There it is not reported as an inverted percentage, but as a three scale metric … But I think the underlying data is percentage based
That matches what SNMP hands over: a level and a capacity, from which the percentage falls out. The three-crank display is your printer’s own simplification of it — and the fact that it lets you set a message on a percentage threshold is good evidence the continuous value is what it holds underneath.
What you have just closed: the waste bottle and the maintenance parts appearing as their own rows, with sensible names and levels, had never been confirmed on real hardware by anyone. My Epson has neither. That is now confirmed — thank you.
One thing still open, and it is smaller than it was. Both of you re-paired, so nobody has yet watched an existing device migrate cleanly from 1.0.x. 1.1.3 is tested against a real Ricoh’s capability list, and a device left stranded repairs itself on its next reading rather than needing anything from you. But if you ever have reason to update another Homey that still has the old version on it, I would be glad to know what it does.
Now live in the App Store 
v1.1.3 is Live. Athom approved it this morning, so the app is out of Test and in the store proper — no special link needed any more, and installs update to it on their own.
It is the app’s first Live release. Everything before it only ever existed on the Test channel, which means the people in this thread carried it the whole way: every bug fixed since 1.0.1 came from someone here posting a screenshot, a log, or a flat contradiction of something I had just claimed. Twelve of them, and not one would have been found on my Epson. Thank you.
If you are on the Test channel, nothing to do — Live is the same build 24.
One thing worth knowing: 1.1.3 needs Homey firmware 12.11 or newer, and the last version that ran below that is no longer served anywhere. If you are on an older firmware you will simply stay where you are rather than getting a broken update, but you will not see new versions either.
What I would still like to hear about.
@SunBeech and @Henk_Renting both re-paired their printers rather than letting the old device migrate — reasonably, since the migration was broken when they tried it. So the upgrade path from 1.0.x to the new capability names has been fixed, and tested against a real Ricoh’s capability list, but nobody has actually watched it happen on their own hardware. It is the one part of this release resting on reasoning rather than observation.
Now that it is Live it will run on Homeys belonging to people who are not reading this thread. If your printer’s rows look wrong after the update — a level missing, a waste tank or maintenance part that never gets a value, a name on the wrong component — please say so here, or send a diagnostic report from the app’s settings. A device that ends up stuck repairs itself on its next reading, but I would rather know than assume.
That goes double for anyone with a laser: waste bottles, fusers, transfer modules and photoconductors are exactly the rows this release changed most, and I have none of them to test on.
