mirror of
https://github.com/louislam/uptime-kuma.git
synced 2026-03-02 22:57:00 -05:00
Configurable Timeouts for MQTT #2664
Labels
No labels
A:accessibility
A:api
A:cert-expiry
A:core
A:dashboard
A:deployment
A:documentation
A:domain expiry
A:incidents
A:maintenance
A:metrics
A:monitor
A:notifications
A:reports
A:settings
A:status-page
A:ui/ux
A:user-management
Stale
ai-slop
blocked
blocked-upstream
bug
cannot-reproduce
dependencies
discussion
duplicate
feature-request
feature-request
good first issue
hacktoberfest
help
help wanted
house keeping
invalid
invalid-format
invalid-format
question
releaseblocker 🚨
security
spam
type:enhance-existing
type:new
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/uptime-kuma#2664
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Nurgak on GitHub (Oct 8, 2023).
⚠️ Please verify that this feature request has NOT been suggested before.
🏷️ Feature Request Type
Other
🔖 Feature description
Simiar to issue 877, but for MQTT: have a configurable timeout for MQTT message monitoring.
Use case
I have a battery powered IOT device that deep-sleeps between updates (closed connection). Currently, updates are configured to be published every 60 seconds. If the check timeout duration is lower than the publish period (which it is right now) UK may miss them. Currently, I see the state of the device toggling between up and pending (with retry set to 2).
If the timeout was configurable it could set it to definitely catch the MQTT message, or definitely fail.
✔️ Solution
Same as #2142 , but for MQTT messages.
❓ Alternatives
No response
📝 Additional Context
As an example, a new field like this:
