Trigger Test against unix date = 0?

[Linwood]

I'm feeling stupid.

I have an item defined as numeric, unsigned, with units unixtime.

The collection external check, in unusual circumstances, sets this to zero to indicate "not available" and I want to trigger from that.

The zero is reported on the Latest Data as the word "Never", but if I graph it, it looks like zero, but the actual graph says the word "Never" also.

I am using a trigger expression: last(/ha/entity_last_change[cover.right_bay])=0

It is not triggering on "never". I was pretty sure this didn't work: last(/ha/entity_last_change[cover.right_bay])="Never"

And indeed it doesn't trigger either.

What's the proper way to check for this?

Thanks,

Linwood

PS. Running 7.0.8.

[Brambo]

First you need to finger out what the value is.
If latest data overview shows Never (0) than the value is 0 and the value map on that item return text Never. You can only trigger on actual values OR the lack of value.
You can approach this in multiple ways. One is in your item and do a custom on fail set value and trigger on actual 0
Or make a trigger on nodata but that means it's not a 0 but really nothing. Example of nodata is agent availability trigger.

[kyus]

Just trying to add something...
I have some triggers that are using string values to create problems (using the "last" function).
So if the value received is actually "Never", I would assume your expression should work.
Though I'm not sure if it is case-sensitive.

I have this working in 6.0

[Linwood]

First you need to finger out what the value is.
If latest data overview shows Never (0) than the value is 0 and the value map on that item return text Never. You can only trigger on actual values OR the lack of value.
You can approach this in multiple ways. One is in your item and do a custom on fail set value and trigger on actual 0
Or make a trigger on nodata but that means it's not a 0 but really nothing. Example of nodata is agent availability trigger.

The value being sent to zabbix is actual numeric zero, I know because it's my perl routine that sent it.

So I think if I follow what you are saying, if it is actually zero, the trigger I showed should work?

But it is not working. Is the mapping of 0 -> "Never" occurring at a lower level than the trigger test? The item is declared as unsigned numeric, with units of "unixtime", there is no explicit mapping of values or pre-processing.

last(/ha/entity_last_change[cover.right_bay])=0

FWIW here is how the item's value is created in an external check script (the item is a zabbix trapper):

if ($state eq "unavailable")
  {
    zabbix_sender::zabbix_sender($zabCustom::ServerDNS , $hostName, "entity_last_change[" . $entity_id . "]", 0 ); # use time = zero if unavailable
  }
  else
  {
    if(defined $last_changed)
      {
        my $unixTime = int(str2time($last_changed));
        zabbix_sender::zabbix_sender($zabCustom::ServerDNS , $hostName, "entity_last_change[" . $entity_id . "]", $unixTime );
      }
    }
​

[kyus]

You don't have any value mapping in the item config, so Zabbix isn't receiving the value you expect...
The weird thing is, it is set to numeric unsigned, so you shouldn't be able to receive string values on this item...

[Linwood]

As a followup -- I removed the "unixtime" units, nothing else, and now the trigger works. Something about the "unixtime" is causing this translation before the comparison can be done. I'll just leave the units off I guess, but this to me seems a bit broken.

[kyus]

I did some testing, the "Never" value that you're getting is because of the way the unixtime unit is processed, but the value is still zero.

I was able to get this trigger to work, basically using last(//test)=0
Zabbix is in 7.0.0

It's weird that it doesn't work for you like that... Maybe something broke in the newer releases?

[Linwood]

It's weird that it doesn't work for you like that... Maybe something broke in the newer releases?

Or I have something screwed up in the LLD prototype, though the resdult sure does look correct. I am off trying to fix some other stuff, but I'll put the unixtime back and try again when I get some time. I'm not quite sure how to debug it other than, I guess, putting it in debug mode, which is just too much volume. Happen to know what process is responsible for trigger evaluation for zabbix trapper items?

[cyber]

When using differnt units, those should be only "visual". Like displaying Never instead of 0 for unixtime. All calculations should still be done by using the actual value, ie 0. If you do not want to expand units, you can use "!" in front of it, then Zabbix will not do all the automatic visual things, like convert b to kb or Mb, if there is enought o convert to next unit size. It should also work on your graph and not display "Never" there, but just 0.

Note that if a unit is prefixed with !, then no unit prefixes/processing is applied to item values. See preventing unit conversion.

[Linwood]

When using differnt units, those should be only "visual". Like displaying Never instead of 0 for unixtime. All calculations should still be done by using the actual value, ie 0. If you do not want to expand units, you can use "!" in front of it, then Zabbix will not do all the automatic visual things, like convert b to kb or Mb, if there is enought o convert to next unit size. It should also work on your graph and not display "Never" there, but just 0.

I'm unclear how I would do that in a trigger expression. That seems to apply for a constant like "100000B" but in this case it's the expression not the constant. What would the syntax look like for this trigger expression?

last(/Template Home Assistant REST Interface/entity_last_change[{#ENTITY_ID}])=0

I did some testing, the "Never" value that you're getting is because of the way the unixtime unit is processed, but the value is still zero.

I was able to get this trigger to work, basically using last(//test)=0
Zabbix is in 7.0.0

It's weird that it doesn't work for you like that... Maybe something broke in the newer releases?

I'm on 7.0.9 now. I set this up to try to run debug to see what happened and.... it's working now.

With latest-data showing "never" the trigger fires with the above trigger. So... did I imagine it? Or did something get fixed between 7.0.8 and 7.0.9. I looked over the release notes and didn't see anything that looked on point. But if I can't reproduce it, I can't debug it.