Add paper roll in cartridge for termal printers (it's consummables)

[ddurieux]

No description provided.

[guillomovitch]

This change isn't consistent with current specification, as consumable elements don't have child elements. So, the first step here would be to update specification.

Also, a suitable snmpwalk output demonstrating code effect would be welcome.

[ddurieux]

Ok thanks, I will update the code

[Stoatwblr]

these caseIDs are going to clash with the Ids I've used to handle more ink colours/fuser/transferkits (these are already emitted by the agent, but Fi4G isn't picking the up.

perhaps we can tentatively set aside ranges to be used for classes of consumable? It appears there are 15-20 more colours attributable to specialist printing devices that may need to be covered in future.

(Think: at least CMYKRGB, then "light", "dark", "photo", "matte", "chromatic" variants along with "enhancers" - and these come in "dye", "pigment" and "latex" bases - a printer is usually dedicated to one type of ink base but some of them have multiple sets - I'm learning more about these things than I want to because my employer is making advertising posters for conferences, etc and I have to know what to buy and support.)

Also: the larger poster printers also have some indicator of "feet/metres of paper left on roll" and may have 2-5 roll feeders.

Should this have lots of categories that have to be programatically added (potential spaghetti code) or is it time to consider maintainable database tables for all this stuff?

[guillomovitch]

This specification change should provide more flexibility, segregating individual piece of information (consumable type, color, unit) into different pieces of markup, and making color a free string, instead of part of an element name:
fusioninventory/fusioninventory.github.io#63

Using this specification, the new consumable type proposed by @david would become:

<CONSUMABLES>
  <CONSUMABLE>
    <TYPE>paperroll</TYPE>
    <VALUE>10</VALUE> # or LEVEL ?
    <UNIT>cm</UNIT>
  </CONSUMABLE>
</CONSUMABLES>

Of course, this would also requires a rewrite of the code handling this content on GLPI side.

[ddurieux]

Seems a very good specification, I will create a PR on GLPI to manage it if these specifications are accepted by @g-bougard

[g-bougard]

Looking at the code PR, what are the meaning of paperroll INCHES & CENTIMETERS ?
To follow my comment in #63 specs PR, is there a way to know about a "MAX" value ?

[ddurieux]

On thermal printer, the roll paper is a consummable and return the number of cm and inch used

[Stoatwblr]

used? Or remaining? (I suspect some will report one, some will report the other)

[ddurieux]

I think used, but I must check to be sure

[Stoatwblr]

I think being able to handle both cases would be best.

In terms of reporting, a lot of consumables stuff (eg: ink colours) is already being passed transparently by the agent and it's really a matter of handling the standard OIDs for most things, so the input side (FI4G/GLPI) needs to be more flexible in what it can handle (and also in terms of what it emits when it gets lines it "doesn't understand", such as color codes or consumable types that are currently unknown - the lack of information provided by the importer slowed me down a lot when trying to understand why my 8-ink printers weren't displaying all supplies properly in GLPI and why the HP printer Fusers/transfer belts weren't showing up)

If these can then be added by the admin as a database entry (Even better - added and automagically submitted upstream for incorporation in the next release - possibly with a "voting" mechanism if the same item is submitted with multiple conflicting descriptions? Inspired by the fail2ban type IP voting might work) it would save heavy code-customisation per model/maker

If there is any degree of "looseness" in interpretation of a parameter then the documentation should explain why and the reasoning. 3rd parties writing compatible XML generators need as much information as they can get.

[g-bougard]

Anyway @ddurieux can you update your PR to follow the new spec ? If you did I'll merge it for next release planned next week.

[guillomovitch]

I'll take care of the agent side. @david: please provide a suitable snmpwak output.

[g-bougard]

Hi @guillomovitch
I merged specs few days ago, see related PR files.
Do you still want to make the agent part ?

[guillomovitch]

I'm unfortunately not enough available to commit myself here currently, you'd better do it yourself if you want a faster result :)