Steps to reproduce:

1. Use the official "FortiGate by HTTP" template.
2. Discover a FortiGate network interface using "Network interfaces discovery".
3. Check the discovered Link status item:
   fgate.netif.status{#IFKEY}

4. The item preprocessing is:
   - JSONPath: $.link
   - Boolean to decimal

5. The resulting Link status values are:
   - 1 = up
   - 0 = down

6. Check the trigger prototype:
   "Interface {#IFNAME}({#IFALIAS}): Link down"

The current problem expression is:

{$NET.IF.CONTROL:"{#IFNAME}"}=1 and
last(/FortiGate by HTTP/fgate.netif.status{#IFKEY})=1 and
(last(/FortiGate by HTTP/fgate.netif.status{#IFKEY},#1)<>last(/FortiGate by HTTP/fgate.netif.status{#IFKEY},#2))

The recovery expression is:

last(/FortiGate by HTTP/fgate.netif.status{#IFKEY})<>1 or
{$NET.IF.CONTROL:"{#IFNAME}"}=0

Result:

In our environment, we observed the following actual transition:

08:58:18 - down (0)
08:59:18 - up (1)

At 08:59:18, exactly when the interface changed from down (0) to up (1), Zabbix generated the following PROBLEM:

"Interface [wan1()]: Link down"

The event operational data showed:

Current status: up (1)

This behavior appears consistent with the current trigger expression because it requires the current value to be 1 and the value to have changed.

Conversely, the current recovery expression becomes true when the Link status changes to a value other than 1, which in this case is 0 (down).

Expected:

If the Link status values are:

1 = up
0 = down

we would expect the "Link down" trigger to enter PROBLEM state when the interface changes from:

1 (up) -> 0 (down)

and to recover when the interface returns to:

0 (down) -> 1 (up)

Could you please confirm whether the current trigger logic in the official "FortiGate by HTTP" template is intentional, or whether the problem/recovery conditions are reversed?

No modifications have been made to the relevant item prototype, preprocessing, value mapping, or trigger prototype in our environment.