SNMP value_template unknown

Configuration
1

I have a printer whose uptime I’d like to have in a sensor:

- platform: snmp
  name: XEROX uptime
  host: !secret Xerox_ip
  baseoid: 1.3.6.1.2.1.1.3.0
  accept_errors: true
  unit_of_measurement: 'minutes'
#  value_template: "{{((value | int) / 6000) | int}}"
  value_template: >
    {% if value == 'unknown' %}
      -1
    {% else %}
      {{((value | int) / 6000) | int}}
    {% endif %}

All’s fine as long a the printer is on(line).

HA starts complaining if the printer is not reachable (which is OK), but instead of creating the sensor with the unknown value –the commented out line worked this way last year– it logs:

ValueError: Sensor sensor.xerox_uptime has device class ‘None’, state class ‘None’ unit ‘minutes’ and suggested precision ‘None’ thus indicating it has a numeric value; however, it has the non-numeric value: ‘unknown’ (<class ‘str’>)

The value_template stated above yields the same behaviour.

Maybe I missed some fundamental changes over the past months…
Could someone nudge me in the right direction?

2

I may be butchering the words, but when a sensor doesn’t have a value, it is an object of type None. You are trying to compare object type None to an object type string with value “unknown”, and this can’t be done. The sensor doesn’t have a string value to use to make the comparison.

If you want to use the same format of what you have, I think you can compare the sensor to None. As in:

{% if value == None %}

There’s also a has_value filter (one of the last bullet points). You’d have to rewrite the logic, but it’ll test if the sensor has an actual value.

 value_template: >
   {% if value | has_value %}
     {{ value | int(0) / 6000 }}
   {% else %}
     -1
   {% endif %}
3

Thank you for your fast reply.
The has_value filter indeed looks promising.
After implementing your code (and even completely restarting HA), the sensor.snmp takes its time(out) and finally yields the exact same error.
Maybe I’m looking at the wrong culprit?

4

Btw, {% if value is number %} doesn’t work either.

The culprit really may be outside of HA though: there was an update of the printer’s firmware some months back. Since April 12th the toner level input_numbers and last seen online input_datetime didn’t change, even though their respective automations still get called.
Perhaps Xerox changed the OIDs with that update?
Since I have no way of knowing, I sadly have to remove all of that printers sensors/automations. It took me days back then to figure out the right OIDs (Xerox’ documentation is lacking); I won’t go through all this crap again. :sob:

5

Next guess: in the SNMP integration documentation, there’s an option for accept_errors:. The docs say you can set this to true so the sensor will report a valid value, even though the printer is unreachable. This sounds like it may address the situation you’re having.

6

I already set this (see post #1).

Meanwhile I think the problem really lies within HA: If I connect the printer to the network where HA resides (192.168.168.x) all is well.
But the printer has to stay in 192.168.144.x, so I connected the server to this network too (HA is dockerized with network_mode: host), the routes are set on the host (I can snmpwalk the printer from the host, no firewall gets in the way).
Still, HA doesn’t recognize the printer within the second net. As if it is locked to the first interface it saw.
I gave up on the snmp integration.