Version 1.0.11 has cleared the orange badge message 
.
I also rechecked my other point: After reinserting the paper tray, the Tray 1 capability changed to 100% again. However the Printer Message capability is not cleared. It keeps saying ‘Tray 1 Missing’.
Version 1.0.11 has cleared the orange badge message
Good — thank you for confirming it on a real printer.
the Printer Message capability is not cleared. It keeps saying ‘Tray 1 Missing’.
Real defect. The message was only written when the printer reported one — a guard meant to stop printers that never say anything getting an empty tile. Fine for deciding whether the row exists, wrong for the value: once your printer stopped reporting, the write was skipped and Homey kept the old text with nothing able to replace it. Row and value are separate decisions now, and the message is written every check, blank included.
Fixed in v1.0.12.
One thing I genuinely can’t tell from here, and I’ve guessed wrong about your printer twice already: whether your Lexmark cleared its console buffer or is still reporting that text. The fix is right either way — but if the message is still there on v1.0.12, the settings page shows the raw value next to Displaybericht, and that line will say which of us is holding the stale text.
Unfortunately the new version did not fix it. The ‘Tray 1 Missing’ message remains after I insert the tray back into the printer. Only the Tray 1 capability is updated (from '- ’ → 100%).
What happens on the printer itself:
After this, the Tray 1 capability is updated in Homey, but not the Printer Messages capability.
Power off detection doesn’t seem to work. Homey flags the off printer as unavailable.
Then no stats available as homey insists on a repair.
Homey flags the off printer as unavailable. Then no stats available as homey insists on a repair.
That’s my design mistake, not a detection failure. You asked for the tile to grey out and I reached for Homey’s unavailable flag without weighing the rest of what it does: it hides every reading, and because this app offers a repair flow it then prompts you to repair a printer you switched off yourself. You asked for a visual cue and got a fault report.
v1.0.13: the offline threshold now accepts 0, meaning never mark it unavailable. The levels stay on screen at their last reading and nothing nags you. The status capability still flips to Offline on the first missed check either way, so Flows are unaffected.
So it’s your call which annoyance you prefer: 1 for a quick grey-out, 0 for keeping the stats.
Unfortunately the new version did not fix it. The ‘Tray 1 Missing’ message remains after I insert the tray back
Thanks — and that sequence you wrote out is exactly what I needed to know about the printer’s side.
I’m not going to guess a third time on your printer, because I’ve now been wrong twice about it. There are two possibilities and they need opposite fixes: either your Lexmark clears its front panel but keeps that text in the SNMP console buffer it reports to us — in which case the app is faithfully showing what the printer says and the fault is the printer’s — or it does report a clear and we’re still not writing it.
I can’t tell them apart from here, and my own diagnostics page couldn’t either: it only printed the panel message when it was non-empty, so “the printer says nothing” and “this page doesn’t show it” looked identical. That’s fixed in v1.0.13 — the settings page now always shows the panel message, and says no panel message outright when there is none.
So on v1.0.13, with the tray back in and the panel cleared, could you check the settings page line for your printer? It’ll read either "Tray 1 Missing" or no panel message, and that one word decides which of the two it is.
I reperformed the procedure: after reinserting the tray, the Printer Message remains on ‘Tray 1 Missing’. Can I see somewhere what the current value is the printer is sending? I was looking in the app’s settings screen, but that does not seem to include the message value:
Another question: I was checking whether the app would work with a SNMP community string different than the default public one. It does work with numeric and regular characters, but special characters seem to be problematic. Which special characters are allowed?
Can I see somewhere what the current value is the printer is sending?
You already screenshotted it — it’s the quoted word on the third line: idle · "Gereed" · 1027 pagina's. That “Gereed” is the panel message, read live from the printer at the moment you opened the page.
So your printer is sending Gereed, and the app is receiving it correctly. The stale text is only on the tile.
Most likely explanation, and it needs no fix: the app reads on a schedule, five minutes apart by default. Your Tray 1 went to 100 % on a poll that landed after you reinserted the tray but before the panel cleared — so that same poll stored Tray 1 Missing, and nothing has read the printer since. The settings page, by contrast, reads live every time you open it, which is why the two disagree.
The test that settles it: run the Flow action Read the printer now, or just wait out one interval, then look at the tile. If it flips to Gereed, it was only ever timing. If it stays on Tray 1 Missing while the settings page says Gereed, then the write really is broken and I’ll dig again — tell me either way.
Which special characters are allowed?
None are blocked. The app hands the community string to the SNMP layer exactly as you typed it, with no filtering or escaping — the only change is trimming spaces at the very start and end.
So if a particular character fails, it’s the printer or the encoding, not a rule of mine. Tell me which character and I’ll chase it; non-ASCII ones are my first suspect, since we send them as UTF-8 and a printer expecting Latin-1 would reject that. You can try any string quickly under Test an address on the app’s settings page, without re-pairing anything.
Maybe we are confusing two different capabilities (sorry for my Dutch screenshots; my Homey is set to Dutch 
). Just to double check:
I ran a flow with ‘Read the printer now’ card, but that did not change the message.
Also note that I changed the default polling interval from 300 secs. to 60 secs. (so I don’t have to wait so long when testing 
). The ‘Tray 1 Missing’ message did not change in the last 2 hours. So I don’t think the message did not update yet because it was between two update intervals.
Regrading the special characters: I have to look into that. I did exactly what you said: use the repair screen to try whether the app was able to connect to the printer after a change.
Maybe we are confusing two different capabilities
You’re right and I was wrong — sorry, and thank you for pushing back instead of accepting my answer.
To be precise about that line though: idle is the raw Status, and "Gereed" in quotes is the panel message. Your printer’s panel is in Dutch, so it genuinely reads Gereed. Which makes your point stronger, not weaker: the printer is sending Gereed, the app reads Gereed live, and the tile still says Tray 1 Missing.
So this is a real write failure, not the timing I claimed. I don’t know the mechanism yet, and I’ve now guessed wrong about your printer twice — so v1.0.14 deliberately fixes nothing. It adds the instrument that was missing: the settings page now reads back what the device is actually holding and prints it beside the printer’s live answer, in red when the two disagree.
That was the gap all along. The page only ever showed the printer’s side, which makes “the printer is still saying it” and “we failed to write it” look identical — the exact question we’ve both been stuck on.
On v1.0.14, the line should say something like device still holds message: Tray 1 Missing next to "Gereed". If it does, I’ll have proof of the failure inside the app and somewhere concrete to dig. If it does not appear, the write is working and something further downstream is caching — also useful to know.
No need to apologize !
I appreciate you taking the time to create the app and fixing bugs. That must be challenging if you don’t have the hardware at your disposal yourself.
I made a screenshot of the settings screen:
Before I did that, the printer was asleep. I assume that is why the red text reads: ‘device holds message: Sleeping’
Does this info help? Or should I reperform the steps on removing and reinserting the tray?
the red text reads: ‘device holds message: Sleeping’
That’s the single most useful thing anyone has posted in this thread, and it flips the conclusion.
It means the capability did get written — it moved from Tray 1 Missing to Sleeping. So the write path works, and my “real write failure” diagnosis from an hour ago was wrong too. Apologies for sending you round that loop.
What it points at instead is your printer sleeping. The settings page reads the printer live, which wakes it; the tile holds whatever the last scheduled read got, and that one caught it asleep. The two disagree because they were taken in different states, not because anything failed.
Or should I reperform the steps on removing and reinserting the tray?
Yes please, with one addition that makes it decisive: right after you reinsert the tray and the panel clears, run the Flow action Read the printer now — that forces a read while the printer is definitely awake, instead of waiting for the next scheduled one.
If the message then goes to Gereed, the whole thing was the printer napping between reads and there’s nothing to fix. If it stays on Tray 1 Missing even immediately after a forced read on an awake printer, then something is genuinely wrong and I’ll have a much narrower place to look.
That must be challenging if you don’t have the hardware at your disposal yourself.
It is, which is exactly why these readings are worth more than my guesses — as this thread keeps demonstrating.
So I powered on the printer and waited until the Status capability in Homey changed from Offline to Ready (‘Gereed’). Note that the Printer Message capability is still displaying ‘Tray 1 Missing’ at this point.
Removed tray 1 out of the printer. The panel on the printer displays ‘Tray 1 missing’. Actually to be more precise: it alternates between IP address > Status > Message. The Status is Ready (‘Gereed’), the Message is ‘Tray 1 missing’. While the tray was out of the printer, I waited until the device in Homey updated. The Tray 1 capability changed from 100% to ‘-’; the Printer Message capability kept on displaying ‘Tray 1 Missing’.
I then reinstered the tray in the printer and confirmed the message ‘Use current tray settings?’ on the printer. Then I waited until the Homey device updated. After the update the Tray 1 capability changed from ‘-’ to 100%; the Printer Message capability did not change and remained displaying ‘Tray 1 Missing’.
I ran the ‘Read the printer now’ flowcard and checked the app’s setting page. There is no more red text:
The Ready (‘Gereed’) state is displayed in the Status capability, but the Printer Message capability is still displaying ‘Tray 1 Missing’. So the latter does not seem to update.
I did connect now, but the device still says “unavailable”.
The testbutton in the app gives this message:
No SNMP answer from 192.168.1.100:
NoSuchName: 1.3.6.1.2.1.1.5.0
Only when I change snmp to v1 manually it gives a status.
Mine should be capable of v.2c as well.
The testbutton then gives:
No SNMP answer from 192.168.1.100:
NoSuchName: 1.3.6.1.2.1.1.5.0
And above it says:
(onbekend translates as “unknown”)
Ricoh MFP
192.168.1.100 SNMP v1
idle “Ready” 27649 pagina’s Uitvoerlade: OK
Ready
Cyan Cartridge
-3/-2 tenthsOfGrams class 3 onbekend
Magenta Cartridge
-3 / -2 tenthsOfGrams class 3 onbekend
Yellow Cartridge
-3 /-2 tenthsOfGrams class 3 onbekend
Black Cartridge
-3 /-2 tenthsOfGrams class 3 onbekend
Waste Cartridge
-3 /-2 tenthsOfGrams class 4 onbekend
Bypass Tray Plain 0%
Tray 1. Plain onbekend
NoSuchName: 1.3.6.1.2.1.1.5.0
That error is the whole answer, thank you — it names the OID. 1.3.6.1.2.1.1.5.0 is sysName, which your Ricoh simply doesn’t implement, and NoSuchName is SNMPv1’s way of saying so. Your printer was answering perfectly well the entire time.
The app asks for six identity values in one request. My v1 code path already isolated them so a missing one costs only itself — but your Ricoh accepts a v2c request and then answers it with v1 semantics, so the whole batch failed on that one absent value, and the v2c path had no tolerance for it. Six asked, one missing, nothing returned, printer declared unreachable.
Fixed in v1.0.15: on that error the app now re-asks one value at a time instead of giving up, so everything the printer does have comes back.
Your readings look right otherwise, by the way — -3 / -2 tenthsOfGrams means the Ricoh reports “there is some toner left” without a number, so unknown is the honest display rather than a made-up percentage.
I ran the ‘Read the printer now’ flowcard and checked the app’s setting page. There is no more red text
That settles it, and the answer is that there’s no bug here.
No red text means the device is holding exactly what the printer just said — and the page shows "Gereed". So the message did get written; the app was faithful throughout.
What was actually happening: your printer’s SNMP message buffer clears more slowly than its tray sensor. The poll that caught Tray 1 going back to 100 % still read Tray 1 Missing from the buffer, and that pairing was correct at the instant it was taken. The forced read a moment later got Gereed and stored it.
it alternates between IP address > Status > Message
That’s the part I’d never have guessed without you spelling it out, and it explains the lag: the panel cycles through frames, and what SNMP hands us is the buffer behind it, not what your eyes see at that second.
Could you confirm the tile now reads Gereed rather than Tray 1 Missing? If it does, this one closes. If it somehow still says the old text while the settings page says Gereed and shows no red line, that would be contradictory and I’d want to look again.
Three wrong diagnoses from me on this printer, and each time your readings were what corrected it. Thank you for the patience.
the Printer Message keeps indicating ‘Tray 1 Missing’
Look again at your own screenshot — the Displaybericht tile reads Slapen, not Tray 1 Missing. Your red arrow is pointing at the Status tile.
So it did update: Tray 1 Missing → Slapen. Your printer went back to sleep between checks and its message buffer now says so, which the app is reporting faithfully.
That closes it, and there was never a bug in the message — three wrong theories from me along the way, each corrected by one of your readings. The one thing that genuinely was broken, the waste bottle at 0 %, your very first screenshot caught.
If it bothers you seeing Slapen rather than the last real message, say so and I’ll think about whether sleep states are worth filtering out of that tile — but I’d rather not hide something the printer is actually telling us without a good reason.
I now see that there is indeed a third capability ‘Display bericht’ (I think that translates to Display/Panel Message) that indicates ‘Slapen’. Which the printer is currently doing.
I was referring to the last capability on the sensor tab (with the bell icon). It is called ‘Printermeldingen’ (Printer messages). That keeps saying ‘Tray 1 Missing’. Or is it supposed to keep displaying the last message until a new (error)message is generated?
Were we talking about two different capabilities all along? My apologies if that was the case.
Were we talking about two different capabilities all along?
We were — and you’re the one who spotted it. No apologies needed; that’s two hours of me debugging the wrong tile.
It is called ‘Printermeldingen’ (Printer messages). That keeps saying ‘Tray 1 Missing’. Or is it supposed to keep displaying the last message until a new (error) message is generated?
No, it’s supposed to clear, and it’s a real bug. That capability reads the printer’s alert table. When your tray came back, the printer dropped the alert and the table went empty — and my code skipped the write on an empty table instead of blanking the tile, so the last complaint stayed put with nothing able to replace it.
It’s the exact bug I fixed for the panel message four versions ago, in the sibling I never looked at. Fixed in v1.0.16.
One refinement while I was there: an empty alert table and a failed read are not the same thing, and only the first is grounds for clearing. The app now tracks which it got, so a single missed read won’t make the tile flicker.
Your instinct on this was right from the start — the tile was stuck. I just kept checking the wrong one.
