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 get the 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 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, go to Integration Center → Alert Events
  2. Select Domotz and enter an integration name
  3. Configure the default route and select a channel. You can add more rules under Routing after creation
  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 in Domotz

Where: Domotz portal › Alerts › Contact Channels & Ticketing Systems › Webhooks › Add WebhookClick Add.
2

Create an Alert Rule that uses the channel

Where: Domotz portal › Alerts › Alert Rules › Add Alert RuleClick Save.
3

Apply the rule to devices

Where: Domotz portal › a device › Alerts › the datapointA 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.
4

Send a test notification and verify

Where: Domotz portal › Alerts › Alert Rules › Send Test next to the rule › Send Test NotificationTick the webhook and click Send Test Alert. Each test makes Flashduty create a new Info alert titled Domotz test notification, which shows Flashduty received the request. That alert does not recover automatically; close it by hand. Then let a real alert fire and recover and confirm the Flashduty alert closes.After a few seconds, go back to Flashduty. If the integration shows a Latest event time, the setup works.
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.

Status 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.