What could explain a publishing interval of 300 seconds instead of 30 seconds?

[Mincka]

From time to time, my manually configured Alarm MQTT sensor in HA becomes unavailable, often after HA reboot.
I use a manually configured alarm to add a PIN code to it.

  alarm_control_panel:
    - name: Alarm with PIN Code
      unique_id: XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXX
      state_topic: >-
        ring/XX/alarm/YY/alarm/state
      command_topic: >-
        ring/XX/alarm/YY/alarm/command
      availability_topic: >-
        ring/XX/alarm/YY/status
      payload_available: online
      payload_not_available: offline
      code: !secret manual_alarm_code
      code_arm_required: false
      code_disarm_required: true

I use the HA Addon and when this happens, my "native" device (the official one, without PIN) is not offline.

I checked the addon logs and nothing suspicious.
I used MQTT Explorer to see what messages were published and I saw that messages were not published on the usual 30 seconds time interval but 5 minutes. I've waited for 20 minutes but the manually configured devices stayed offline, despite the messages every 5 minutes.

This is not a bug report because I cannot give you much info yet and I failed to get proper info before rebooting the addon.
I did not check if the discovery topics were published at all, and I did not check exactly what devices were published every 5 minutes, maybe not all of them.

The only reference to 5 minutes I found is here:
https://github.com/tsightler/ring-mqtt/blob/main/devices/base-ring-device.js#L196

I tried to reload MQTT settings and reload the HA integration but the device stayed offline.
The manually configured device came back online as soon as I rebooted the addon.

[Mincka]

I completely missed the disarm_code option... I guess I used the addon before it was implemented.
I will start by using it and remove my manually configured alarm_control_panel.

[tsightler]

I would guess that manual configuration of the panel is unlikely to be the issue. The 30 second updates only happen during the first 3 minutes after startup or whenever a HA restart is detected, during this time HA discovery is sent every 30 seconds followed one second later by a full state update for all devices. This is done because HA sometimes sends online state before it is fully ready to accept discovery and state. I'm not even sure if this is still a problem with recent HA versions, but the code is unchanged from 4 years.

The 5 minute updates are only for attribute data, state is only update when there is an actual state change, and online/offline state only changes based on the state of the monitored websocket. These events are all in the log so are relatively easy to track down.

Since you state that this happens often after an HA reboot, and you seem to have been using the plugin for a long time (disarm_code was added many years ago), you might want to verify that your HA MQTT setup has birth/last will messages configured using default settings as otherwise, when restarting HA, ring-mqtt will not be aware that it needs to resend state updates so devices will stay offline (restarting HA does not restart addons). Birth/last will has been the default in HA for a year or two now, but wouldn't get automatically updated for older version.

Full logs matched up with the state in HA should make it pretty easy to track down what is causing the issue.

[Mincka]

Thank you for your detailed answer. I was just adding that using the manually configured MQTT alarm_control_panel is not useful anymore for me since the only point to configure it was the ability to use a disarm_code (so before it was implemented in ring-mqtt). What was strange in the present issue was the fact that the automatically configured device was seen online but not the manually configured one.

I checked that birth/last will are configured with default value, that's the case.
I was using HA Mosquito and the the HA ring-mqtt add-on in the past, but I prefer separate completely the dependency with HA, so now I am running EMQX and ring-mqtt docker on another device.

If this issue arises again, I will report back there with proper logging. No additional support required for now. Thank you again.