OpensourceICTSolutions · benjofalanga · Jun 2, 2026 · Jun 2, 2026 · Jun 2, 2026 · Jun 3, 2026
diff --git a/.gitignore b/.gitignore
@@ -0,0 +1,2 @@
+nbxsync/*
+
diff --git a/README.md b/README.md
@@ -1,6 +1,6 @@
-# nbxSync – NetBox ⇄ Zabbix Integration
+# nbxSync - NetBox to Zabbix Integration
 
-**Integrate Netbox as Source of Truth with Zabbix as Monitoring Solution**
+**Integrate NetBox as source of truth with Zabbix as monitoring solution**
 
 ![CI](https://github.com/OpensourceICTSolutions/nbxsync/actions/workflows/ci.yml/badge.svg)
 ![Coverage](https://img.shields.io/endpoint?url=https://gist.githubusercontent.com/bvbaekel/1a1cf04e63a52d5497edd6e0a564ec2b/raw/4a293f964b246091d1fd943629408dbb7d9f597f/cov.json)
@@ -11,16 +11,28 @@
 
 ## Description
 
-nbxSync seamlessly integrates Netbox with Zabbix.
+nbxSync integrates NetBox with Zabbix.
 
 With nbxSync you can:
-✅ Create and manage all your devices in NetBox (your single source of truth)
-✅ Automatically sync devices to Zabbix for monitoring
-✅ Save time, reduce errors, and ensure consistent, up-to-date monitoring data
 
-This plugin bridges the gap between network/source-of-truth documentation and infrastructure monitoring – something many teams have been asking for.
+- Create and manage devices in NetBox as the source of truth.
+- Synchronize devices, virtual machines, host groups, templates, tags, macros, interfaces, proxies, and maintenance windows with Zabbix.
+- Keep monitoring configuration aligned with documented infrastructure.
+- Optionally synchronize Zabbix trigger dependencies from NetBox cabling.
 
-💡 If you’re running both NetBox and Zabbix, this is the missing link you’ve been waiting for.
+This plugin bridges source-of-truth documentation and infrastructure monitoring.
+
+## Trigger Dependencies
+
+nbxSync can optionally update Zabbix trigger dependencies after a successful device host sync. This allows dependencies such as:
+
+```text
+access point trigger -> switch trigger -> gateway/firewall trigger
+```
+
+The feature is disabled by default and is configured with ordered dependency levels. Each level defines the NetBox device role names/slugs it matches and the Zabbix trigger description to update. NetBox cabling determines the directly connected upstream/downstream device, while the configured level order determines dependency direction.
+
+See [Configuration](docs/configuration.md#trigger_dependencies) for details.
 
 ## Compatibility
 
@@ -33,12 +45,12 @@ This plugin bridges the gap between network/source-of-truth documentation and in
 
 ---
 
-## 📦 Installation
+## Installation
 
 ### 1. Install the plugin
 
 > [!IMPORTANT]
-> The steps below are for a non-dockerized setup. If you run Netbox in Docker containers, please see [their installation instructions](https://netboxlabs.com/docs/netbox/installation/)
+> The steps below are for a non-dockerized setup. If you run NetBox in Docker containers, please see [their installation instructions](https://netboxlabs.com/docs/netbox/installation/)
 
 Install using pip
 

diff --git a/docs/configuration.md b/docs/configuration.md
@@ -1,6 +1,6 @@
 # Configuration
 
-The plugin is configuration to do exactly what you want, by means of the plugin settings. As described in the [installation instructions](installation.md)), the default configuration is as follows:
+The plugin can be configured with NetBox plugin settings. As described in the [installation instructions](installation.md), the default configuration is as follows:
 
 ```python
 "nbxsync": {
@@ -74,6 +74,39 @@ The plugin is configuration to do exactly what you want, by means of the plugin
             'interval': 15, # 15 minutes
         },
     },
+    'trigger_dependencies': {
+        'enabled': False,
+        'levels': [
+            {
+                'name': 'access_point',
+                'roles': ['access point', 'access-point', 'ap'],
+                'trigger_description': 'AP status',
+            },
+            {
+                'name': 'switch',
+                'roles': ['switch', 'switches'],
+                'trigger_description': 'Switch status',
+            },
+            {
+                'name': 'gateway',
+                'roles': [
+                    'gateway',
+                    'gateways',
+                    'gw',
+                    'firewall',
+                    'firewalls',
+                    'meraki gw',
+                    'meraki-gw',
+                    'meraki mx',
+                    'meraki-mx',
+                    'mx',
+                    'security appliance',
+                    'security-appliance',
+                ],
+                'trigger_description': 'Gateway status',
+            },
+        ],
+    },
     'no_alerting_tag': 'NO_ALERTING',
     'no_alerting_tag_value': '1',
     'attach_objtag': True,
@@ -86,27 +119,27 @@ The plugin is configuration to do exactly what you want, by means of the plugin
 
 ### Source of Truth
 
-The `sot` key determines which system is the Source of Truth: `netbox` or `zabbix`. And as such, which way the sync works. If the SoT is Netbox, data will be synschronized from Netbox to Zabbix. If the SoT is Zabbix, data is synchronized from Zabbix to Netbox - if and where possible (Zabbix doesn't expose all information).
+The `sot` key determines which system is the source of truth: `netbox` or `zabbix`. This controls the sync direction. If the SoT is NetBox, data is synchronized from NetBox to Zabbix. If the SoT is Zabbix, data is synchronized from Zabbix to NetBox where possible; Zabbix does not expose all information.
 
 ### Statusmapping
 
-The `statusmapping` key influences how certain statusses are interpreted and used. The two models that are to be synchronized are Devices and Virtual Machines. Each of these can be configurated independently of eachother for maximum flexibility.
+The `statusmapping` key controls how certain statuses are interpreted and used. Devices and Virtual Machines can be configured independently.
 
 The key is the `netbox` status whilst the value is the action to be taken in Zabbix.
 
 ### Actions
 
 #### enabled
 
-This status results in the host to be enabled in Zabbix
+This status enables the host in Zabbix.
 
 #### disabled
 
-This status results in the host to be disabled in Zabbix
+This status disables the host in Zabbix.
 
 #### deleted
 
-This status results in the host to be deleted from Zabbix
+This status deletes the host from Zabbix.
 
 #### enabled_in_maintenance
 
@@ -118,11 +151,11 @@ If a host has this status, it is enabled in Zabbix, but it will have a tag with
 
 ### backgroundsync
 
-If wanted, system jobs can be used to automatically sync objects
+System jobs can be used to automatically sync objects.
 
 #### objects
 
-This key is used to determine if 'objects' (that is: Devices and/or Virtual Machines) are to be automatically synched to/from Zabbix
+This key controls whether objects, such as Devices and Virtual Machines, are automatically synchronized to or from Zabbix.
 
 ##### enabled
 
@@ -165,6 +198,38 @@ This runs as the `Zabbix Sync Maintenance job` system job. Only maintenance
 windows that have at least one period and one object assignment are included.
 See [Zabbix Maintenance](zabbixmaintenance.md) for details.
 
+### trigger_dependencies
+
+When enabled, nbxSync updates Zabbix trigger dependencies after a successful device host sync. The feature uses NetBox cabling and ordered dependency levels to build dependency chains such as:
+
+```text
+access point trigger -> switch trigger -> gateway/firewall trigger
+```
+
+This feature is disabled by default. Enable it only when the configured role tokens match your NetBox device role names or slugs and the configured trigger descriptions match your Zabbix trigger names.
+
+Both pieces are required:
+
+- Role matching decides which dependency level a NetBox device belongs to. Role names and slugs are compared case-insensitively.
+- Interface cabling decides which directly connected devices are considered.
+- The order of `levels` decides dependency direction. Lower levels depend on directly connected higher levels.
+
+For example, an access point role named `Wireless AP` will not match the defaults unless you add `wireless ap` or the role slug to the access point level's `roles`. A device with a matching role but no connected higher-level neighbor is skipped because nbxSync cannot determine its upstream dependency.
+
+| Key        | Default | Description |
+|------------|---------|-------------|
+| `enabled`  | `False` | Enable trigger dependency updates after host sync |
+| `levels`   | AP, switch, gateway/firewall | Ordered from lowest child to highest parent |
+| `name`     | Level-specific | Human-readable level name used for configuration clarity |
+| `roles`    | Level-specific role tokens | NetBox device role names/slugs that belong to this level |
+| `trigger_description` | Level-specific trigger name | Zabbix trigger description on hosts in this level |
+
+The default levels are ordered as access point, switch, gateway/firewall. With those defaults, a connected access point depends on its connected switch, and a connected switch depends on its connected gateway or firewall. Cable direction does not matter; nbxSync looks at directly connected devices and uses the level order to decide which device is the child and which device is the parent.
+
+To support more device types, add their NetBox role names or slugs to the appropriate level. To support a different hierarchy, add or reorder levels from lowest child to highest parent.
+
+Existing Zabbix dependencies whose descriptions do not match the managed parent trigger descriptions are preserved. Dependencies matching the managed parent trigger descriptions are replaced with the current cabling-derived parent triggers.
+
 ### no_alerting_tag
 
 This defines the tag to be set when a host has the 'enabled_no_alerting' status. Use just a string value with no ${ } around the tag. Defaults to 'NO_ALERTING'.
@@ -216,4 +281,4 @@ Two separate `sync_enabled` flags control whether synchronization to Zabbix is a
 
 **On `ZabbixServerAssignment`**: disabling this stops synchronization for that specific device/VM assignment only. Other assignments to the same or different Zabbix servers are unaffected.
 
-Both flags must be `True` for a sync to proceed. The "Sync Status" column on the Zabbix Server Assignments list shows a green check only when both the assignment and its server are enabled.
+Both flags must be `True` for a sync to proceed. The "Sync Status" column on the Zabbix Server Assignments list shows a green check only when both the assignment and its server are enabled.
diff --git a/docs/index.md b/docs/index.md
@@ -1,8 +1,8 @@
-# nbxSync - Netbox ❤️  Zabbix
+# nbxSync - NetBox and Zabbix
 
-This plugin integrates [NetBox](https://netbox.dev) with [Zabbix](https://www.zabbix.com/), providing a bridge to synchronize NetBox Devices, Virtual Device Contexts & VMs into Zabbix Hosts and (limited though) vice versa. Through custom models, these Devices, Virtual Device Contexts and VMs can be added to custom hostgroups, macro's can be provisioned with dynamic values (based on jinja2) and templates can be assigned on not only the object itself (so the device/vdc/vm), but can be inherited from Device Types, Manufacturerer, Device Roles and Platform.
+This plugin integrates [NetBox](https://netbox.dev) with [Zabbix](https://www.zabbix.com/), providing a bridge to synchronize NetBox Devices, Virtual Device Contexts, and VMs into Zabbix Hosts and, where supported, vice versa. Through custom models, these Devices, Virtual Device Contexts, and VMs can be added to custom host groups, macros can be provisioned with dynamic values based on Jinja2, and templates can be assigned on the object itself or inherited from Device Types, Manufacturers, Device Roles, and Platforms.
 
-In order to ease operational burden, configuration can be grouped together using Configuration Groups. These groups replicate the templated configuration (such as Zabbix Templates, Zabbix Host Interfaces, Hostgroups, et cetera) to the assigned Devices/VDCs/VMs.
+To reduce operational work, configuration can be grouped together using Configuration Groups. These groups replicate templated configuration, such as Zabbix Templates, Zabbix Host Interfaces, host groups, and tags, to the assigned Devices, VDCs, and VMs.
 
 ## Features
 
@@ -13,6 +13,7 @@ In order to ease operational burden, configuration can be grouped together using
 - Job-based execution for controlled syncing
 - Hostgroup & Tag values based on Jinja2 templates
 - Supports Configuration Groups to quickly apply a 'set of configuration items' to Devices, VDCs or VMs
+- Optional trigger dependency synchronization from NetBox cabling
 
 Built to make NetBox the single source of truth while leveraging Zabbix for monitoring.
 {: .slogan }

diff --git a/docs/installation.md b/docs/installation.md
@@ -2,7 +2,7 @@
 
 ## Docker
 
-Installing on Docker is fairly simple and [documented by the Netbox Docker project](https://github.com/netbox-community/netbox-docker/wiki/Using-Netbox-Plugins). Just ensure to restart both the Netbox and Netbox-Worker container, as both will need to have nbxSync installed.
+Installing on Docker is documented by the [NetBox Docker project](https://github.com/netbox-community/netbox-docker/wiki/Using-Netbox-Plugins). Restart both the NetBox and NetBox Worker containers after installing nbxSync, as both containers need the plugin installed.
 
 Also, replace `netbox_secrets` with `nbxsync` obviously.
 
@@ -13,7 +13,7 @@ Also, replace `netbox_secrets` with `nbxsync` obviously.
 - Python >= 3.8
 - Zabbix server >= 7.0
 
-In order to install NetBox, please see [their installation instructions](https://netboxlabs.com/docs/netbox/installation/). Once you have a working Netbox installation, proceed with the steps below.
+To install NetBox, see [the NetBox installation instructions](https://netboxlabs.com/docs/netbox/installation/). Once you have a working NetBox installation, proceed with the steps below.
 
 ### Steps
 
@@ -28,7 +28,7 @@ echo nbxsync >> /opt/netbox/local_requirements.txt
 
 #### Configuration
 
-If you want to change the default configuration, can add the following configuration and alter it accordingly. This is _not_ required though.
+If you want to change the default configuration, add the following configuration and adjust it for your environment. This is optional.
 
 ```python title="netbox/configuration.py"
 PLUGINS = ['nbxsync']

diff --git a/docs/permissions.md b/docs/permissions.md
@@ -1,6 +1,6 @@
 # Permissions
 
-nbxSync integrates with the [Netbox Permission system](https://netbox.readthedocs.io/en/stable/administration/permissions/).
+nbxSync integrates with the [NetBox permission system](https://netbox.readthedocs.io/en/stable/administration/permissions/).
 
 ## Zabbix Hostgroup