Environment
- Home Assistant Core 2026.7.4
- PetKit Fresh Element 3 New (model D3-1), firmware 1.462
- Observed via the RobertD502/home-assistant-petkit integration v0.1.14 (the predecessor of this one). Reported here because this is the actively maintained integration for the PetKit API family and two of the asks below are integration-side; the underlying behaviour is device/cloud-side, so it should reproduce identically through py-petkit-api.
Observed behaviour
The feeder's actual speaker loudness silently drops to its default after a device-side reboot, while the cloud-stored volume setting stays where the user left it. Home Assistant reflects the stored setting, so the volume slider shows 2 indefinitely and there is no signal anywhere in HA or the PetKit app that the real loudness has changed.
Evidence (10-day recorder window)
- The cloud-stored volume value that HA mirrors is pinned at 2 for the entire window — it never moves.
- The feeder goes offline for roughly 2 minutes at 05:33 local, every other night — consistent with a scheduled firmware restart.
- Perceived loudness after those nights does not match the stored setting of 2.
The inference: the reboot re-initialises the runtime loudness to default without writing back to the stored setting, so both HA and the app keep reporting a value that is no longer true.
Why the obvious client-side workaround is not acceptable
The natural fix is an automation that re-asserts the volume after the reboot window (write 1, then write 2, to force a change event). It doesn't work in practice: the Fresh Element 3 plays its confirmation prompt out loud on a volume write. At ~05:35 that is an audible announcement from a feeder within earshot of a bedroom, every other night. The workaround swaps a daytime volume bug for a nightly wake-up, so it is not something a user can just paper over locally — which is why this is worth reporting rather than automating around.
What we're asking for
Any one of these would resolve it, in rough order of preference:
- A silent write path for volume — set the value without triggering the spoken confirmation. If the API supports a quiet/no-prompt flag, exposing it would make a re-assert automation viable.
- Expose the device's actual runtime loudness (if the API reports it separately from the stored setting) as its own entity, so drift is at least visible and alertable.
- Confirmation that this is firmware-side and not an integration mapping bug — that alone is useful, and it gives the behaviour a public record.
Open question
Does the PetKit API distinguish "stored volume setting" from "current device loudness"? If those are two different fields and the integration surfaces only the former, the fix may be entirely on the integration side rather than firmware.
Environment
Observed behaviour
The feeder's actual speaker loudness silently drops to its default after a device-side reboot, while the cloud-stored volume setting stays where the user left it. Home Assistant reflects the stored setting, so the volume slider shows 2 indefinitely and there is no signal anywhere in HA or the PetKit app that the real loudness has changed.
Evidence (10-day recorder window)
The inference: the reboot re-initialises the runtime loudness to default without writing back to the stored setting, so both HA and the app keep reporting a value that is no longer true.
Why the obvious client-side workaround is not acceptable
The natural fix is an automation that re-asserts the volume after the reboot window (write 1, then write 2, to force a change event). It doesn't work in practice: the Fresh Element 3 plays its confirmation prompt out loud on a volume write. At ~05:35 that is an audible announcement from a feeder within earshot of a bedroom, every other night. The workaround swaps a daytime volume bug for a nightly wake-up, so it is not something a user can just paper over locally — which is why this is worth reporting rather than automating around.
What we're asking for
Any one of these would resolve it, in rough order of preference:
Open question
Does the PetKit API distinguish "stored volume setting" from "current device loudness"? If those are two different fields and the integration surfaces only the former, the fix may be entirely on the integration side rather than firmware.