Alarms calendar
Displays alarms from any device, asset or entity alias on a month calendar, colour-coded by severity, with acknowledged and cleared states visible at a glance. Click a day to drill into its timeline; click an alarm to read its details and acknowledge or clear it, or to fire a widget action of your choosing. Busy days collapse into a cluster link. Calendar navigation drives the timewindow, so browsing month to month fetches the right alarms. Fonts and colours are configurable, with no scripting required.
Who it’s for
Ops and support teams watching alarms across a fleet ask “which days had trouble, and what happened on the worst one?” A flat alarm log makes that hard to see — patterns across a week or a month get lost in a scroll of rows. A month grid, colored by severity, shows the shape of a bad week at a glance and lets you drill straight into the day that needs a closer look.
What it does
A production line raises a Critical overheat alarm at 14:02 on the 12th
and a Major lowFuel alarm the next morning. Both show up as chips on their
own day cells, red then orange, ordered by severity within the day. Click
the 12th and the view drills into its hour-by-hour timeline, with a
breadcrumb back to the month.
- Month grid with alarms on the day they started, ordered by severity within each day, so the worst issue in a day sorts first
- Two chip styles — soft (a tinted fill with a colored spine) or solid (a full severity fill)
- Unacknowledged, acknowledged, and cleared read differently at a glance, with no extra icons needed
- Point-in-time or duration-span rendering — a span alarm draws a bar from its start to when it cleared, or to now if it’s still active
- Acknowledge and clear from a details popover, without leaving the
dashboard — each button disappears once its state is reached, disables
while the request is in flight, and reports a failure like
Clear failed (403)in place instead of losing the click - Calendar navigation drives the time window, so paging through months fetches the alarms for that range instead of relying on a fixed dashboard window
- Reads and acts on alarms only; it does not create, escalate, or reassign them beyond acknowledging and clearing
How to set up
Data keys
This is an alarm-type widget: it reads whole alarm objects from the alarm subscription, not telemetry or attribute values, so the data key list stays empty and anything you add there is ignored. These fields come from the platform automatically:
| Alarm field | Type | Used for |
|---|---|---|
startTs (falls back to createdTime) | number | Position on the calendar |
endTs | number | End of the bar in duration-span mode |
clearTs, ackTs, cleared, acknowledged, status | number / boolean / string | Alarm state, whichever shape your platform version reports |
type | string | Chip label |
severity | string | Chip color |
originator, originatorName, originatorLabel | entity id / string / string | Popover, the optional chip prefix, and the entity passed to actions |
assignee, details | object | Popover |
Alarms are positioned by start time — when the condition first became true, not when the platform processed it. A device sending backdated telemetry can make those differ; the calendar always uses the event time.
Alarm source & filter
| Setting | Default | Effect |
|---|---|---|
| Alarm source | — | A device, asset, or entity alias, picked the same way as any alarm widget. Every alarm raised by (or propagated to) the resolved entity or entities is a candidate for the calendar |
| Filter | — | The platform’s own alarm filter — status, severity, type, assignee, and whether propagated alarms count. It runs server-side, so narrowing it reduces what’s fetched, not just what’s drawn |
| Alarms page size | 1024 | Upper bound on alarms fetched for the visible range |
Actions
| Source | Fires on | Entity passed | Extra parameters |
|---|---|---|---|
| Alarm click | An alarm chip, when Clicking an alarm is set to trigger the action | The alarm’s originator | alarm, alarmId, alarmType, alarmSeverity, alarmStatus, alarmStartTs, alarmDetails |
| Day click | Empty space in a day cell | — | date, dateTs, allDay |
Attach any action type — navigate to a dashboard state, open a custom
dialog, run custom JavaScript, or trigger a mobile action. Because the
originator is passed as the entity, Navigate to new dashboard state works
with no extra wiring; inside a custom action, the rest is on
additionalParams, for example additionalParams.alarm.details. If no
action is attached to a source, clicking simply does nothing.
How to customize
Calendar
- To start the week on a different day — set First day of week to Sunday, Monday, or Saturday.
- To use a 12-hour clock — turn off 24-hour clock.
Alarms
- To draw alarms as bars from start to clear (or to now) — set Alarm rendering to Duration span instead of Point in time.
- To show which entity raised each alarm — turn on Prefix title with
originator name, so a chip reads
Generator 03 · lowFuelinstead oflowFuel. - To fire a widget action instead of the details popover — set Clicking an alarm to trigger the Alarm click action.
- To make the popover read-only — turn off Allow acknowledge / clear from the details popover. The widget can’t see a user’s permissions, so this hides the buttons rather than enforcing anything.
- To change when a busy day collapses into “+N more alarms” — set Alarms shown per day before clustering; 0 fits as many as the row height allows.
Style
- To switch chip styles — set Alarm chip style to Soft (tinted fill, colored spine) or Solid (full severity fill).
- To match your dashboard’s fonts — set Alarm text, Day number text, and Weekday header text.
- To recolor the grid — set Day number color, Weekday header color, Cell background, and Grid line.
- To hide the legend or the alarm counter — turn off Show severity legend or Show alarm counter.
Severity colors
- To use your own severity palette — set Critical, Major, Minor, Warning, and Indeterminate. Each color becomes the chip’s tint or fill, and the text switches between dark and white on its own to stay readable.
How the calendar’s time window works
An alarm subscription only returns alarms whose start time falls inside a time window, and that window has no idea which month is on screen — so the calendar drives it. Every month step, year step, month or year pick, drill-down, back action, and the initial load pushes the visible range as the new window; rapid clicks collapse into a single query. The range covers every cell on the grid, including the greyed leading and trailing days of the month, so those days are populated too instead of looking empty.
Whether that range stays on this widget alone or moves the whole dashboard is the platform’s own “use dashboard time window” checkbox, which this widget doesn’t override. On a shared dashboard, turn it off so navigating the calendar doesn’t drag other widgets along.
One consequence worth knowing: an alarm that started before the visible month won’t appear, even if it was active throughout it. This shows up most in duration-span mode, where you might expect a bar running across the whole grid.
Tips
- Narrow the Filter instead of relying on the calendar to hide alarms — status, severity, type, and assignee filtering runs server-side, so it also reduces what’s fetched.
- Keep Alarm chip style and Severity colors consistent with any other alarm widgets on the same dashboard, so the same severity reads the same way everywhere.
- Weekday names follow the dashboard’s language automatically; without the FullCalendar locales resource they fall back to English. Alarm types and severity labels are never translated — they render exactly as the platform reports them.
Share Your Widget with the Community
Built a custom widget? Export it as a JSON from ThingsBoard and publish it to the IoT Hub through a simple 4-step wizard (Upload, Listing, Readme, Review & Submit). Share it with thousands of ThingsBoard developers worldwide and get featured in the catalog.