Skip to main content
Use a Domotz webhook contact channel and an Alert Rule to send collector and device alerts to Flashduty On-call. Every Alert Rule notification carries a Problem or Resolved state and an alert_id, so Flashduty links them with one Alert Key: the problem creates an alert and the recovery closes it. Alert profiles bound through the Domotz Public API deliver named events instead (device up/down, TCP service, RTD, heartbeat lost, SNMP, and so on); those are covered under Events from Public API alert profiles.

​
In Flashduty On-call

You can obtain an integration push URL in either of the following ways.

​
Use a dedicated integration

  1. In the Flashduty console, select Channel and open a channel
  2. Select Configuration → Integrations → Private integration, then click Add an integration
  3. Select Domotz, then click Save
  4. Open the generated integration card and copy the Push URL

​
Use a shared integration

  1. In the Flashduty console, select Integration Center → Alert Events
  2. Select Domotz and enter an integration name
  3. Configure the default route and select a channel; after creation, add more rules under Route if needed
  4. Click Save and copy the generated Push URL

​
Configure in Domotz

You need permission in the Domotz portal to create contact channels and Alert Rules.
1

Create a webhook contact channel

  1. In the Domotz portal sidebar, open Alerts and select the Contact Channels & Ticketing Systems tab
  2. Scroll to the Webhooks section and click Add Webhook
  3. Enter a Name, paste the full Flashduty push URL into Add webhook address, and click Add. The URL must include integration_key
2

Create an Alert Rule that uses the channel

  1. Open the Alert Rules tab and click Add Alert Rule
  2. Enter an Alert Name, then choose the Entity (Collector or Device) and the Datapoint to watch, for example Connectivity → Device Status
  3. Choose the Condition and the Severity (Critical, High, Warning, Info, or No Severity)
  4. Under Notification Channels, click Add Channels, tick the webhook from the previous step, and click Set 1 Channels
  5. Click Save
3

Apply the rule

A new rule is not applied to anything yet (Applied To shows -). Open a device, choose Alerts, expand the datapoint, and tick the rule. Applied To then shows the number of linked devices.
In the Alert Rules list, Send Test next to a rule opens the Send Test Notification dialog. Tick the webhook and click Send Test Alert. Flashduty opens one separate Info alert titled Domotz test notification for each test. It never recovers, so close it manually.
Heartbeat lost, SNMP, IP change, configuration change, security issue, and WAN/LAN change events from Public API alert profiles have no recovery notification. Turn on auto-close in the channel that receives them, with a suggested duration of 24 hours.

​
Alert Key

For an Alert Rule notification (monitoring_profile_state_changed), Flashduty builds the Alert Key from the event name and alert_id. The Problem and the Resolved notification of one occurrence carry the same alert_id, so the alert closes when the state becomes Resolved. The next occurrence gets a new alert_id and opens a new alert. A notification without alert_id, or with a state other than Problem or Resolved, is rejected.

​
State and severity

data.state.current decides the state: Problem triggers the alert and Resolved recovers it.

​
Events from Public API alert profiles

Alert profiles bound through the alert-profile endpoints of the Domotz Public API deliver the events below. Flashduty builds the Alert Key from the event name, agent_id (collector ID), and device_id (device ID), plus the port for TCP services. The fields are joined with a non-printing separator and hashed with MD5. These identifiers come from the webhook event schemas in the Domotz Public API definition. Changes to device name, state value, or time do not change the Alert Key.
  • Events with a recovery state (agent_status, device_status, device_tcp, device_rtd, agent_speed_test) use the same Alert Key for the problem and the recovery
  • Events without a recovery state add the event timestamp to the Alert Key, so each notification is a separate alert
  • A notification without agent_id, or a device event without device_id, is rejected

​
State and severity by event

One device_tcp notification can list several ports. Flashduty creates one event per port, in ascending port order, and processes at most 50. Device discovery, feature discovery, and MIB discovery are accepted but create no alert. A state value outside the table returns a parameter error.

​
Labels

​
Troubleshooting

  • No alerts arrive: confirm the Alert Rule is applied to a device or collector (Applied To is not -) and lists this webhook channel under Notification Channels
  • An alert does not recover: only the events with a recovery condition in the table recover on their own; rely on auto-close for the rest
  • Flashduty returns a parameter error: an Alert Rule notification lacks alert_id or has an unsupported state, or an event from a Public API alert profile lacks agent_id / device_id
  • The webhook channel sends nothing: confirm the push URL is complete and uses HTTPS
For field details, see the Domotz Public API and Shared Alerts, Webhooks and Ticketing Systems.