Awesome! I’m not a great developer myself, but if you’re looking for test participants, I’d be happy to help.
Hello @fern ,
That’s a great move, thanks for trying and addressing the timer issue. Can I ask how you tested your implementation? Did you by any chance modify the core files of your existing HA with the modified version, or did you build a new HA with the modified files?
Any luck so far? Trying to integrate my B-Hyve system now. I have them in HA via the HACS integration so they are already showing in HomeKit as switches. Working on the YAML config edits now. TY for the effort.
I’ve started implementing support for linked duration entities based on the approach of @fern, you can find my progress here:
- GitHub - fabiandev/home-assistant-core at homekit-valve-duration
- GitHub - fabiandev/home-assistant.io at homekit-valve-duration
My plan is to open a PR to Home Assistant Core, let’s see how it goes.
There are some breaking changes between HA version 2025.7.x and current dev, so the integration from my Home Assistant Core fork won’t work with the current release. But I’ve put together a version that was tested with 2025.7.1: GitHub - fabiandev/ha-homekit-valve-duration
Use at your own risk! This is a POC and intended for testing purposes for developers who want to contribute to the Home Assistant Core implementation.
Any feedback or contributions are much appreciated!
3 Likes
Tested it this morning and works as expected!
1 Like
Hi! First of all, thanks a lot for your integration — it’s working great.
I’ve set up the input_number.sprinkler_duration with min: 0, max: 86400, and step: 60 (so up to 24 hours in seconds). However, in the Apple Home app, the timer slider still only goes up to 1 hour (3600 seconds).
Is there any way to extend this limit in the Home app? Would love to be able to select up to 24 hours directly. Thanks again!
The options in Apple Home app are fixed and unfortunately cannot be changed (as far as I know). I’m recommending to use min: 300 and max: 3600 to align the linked duration input number with the options in HomeKit.
Hi again!
Just to clarify why I’m sure the Home-app slider isn’t hard-coded to 1 hour:
-
HomeBridge proof – when I expose the very same Zigbee valve through the homebridge-irrigation-system plugin, Home lets me pick well beyond 60 minutes (the plugin sets
SetDuration.maxValueto 7 200 s by default) -
Eve Aqua example – Apple’s own Eve Aqua irrigation controller (no bridges involved) shows the 24-hour wheel out of the box. You can see the characteristic list here:
https://homedevic.es/8idm8
It advertisesSetDuration.maxValue = 86400and Home renders the full range.
So it looks like the Home-app UI simply uses whatever maxValue it receives during initial pairing. If HA’s HomeKit bridge published SetDuration with maxValue = 86400 (and minStep = 60), the same full 24-hour wheel should appear — just like with HomeBridge and Eve Aqua.
Would be great if those properties could be exposed the same way in Home Assistant.
Thanks for looking into this!
For additional context, here are screenshots of how the slider looks when using the HomeBridge Irrigation System plugin in the Home app:
and from HomeBridge:
Quick update after a bit of experimentation:
I manually edited the code of the homebridge-smart-irrigation plugin to increase the SetDuration.maxValue from the default 7 200 seconds (2 hours) to 86 400 seconds (24 hours). After this small tweak, the Home app immediately picked up the full 24-hour range without any issues
So this confirms that as long as the correct characteristic is advertised, Home app have no problem rendering the extended slider UI
Below are screenshots showing how the slider now appears in the Home app with the updated plugin:
Thanks for the details, appreciate your feedback!
The PR to add this feature to the HA Core integration is already in active review and I don’t want to add additional functionality on top anymore: Homekit valve duration characteristics by fabiandev · Pull Request #149698 · home-assistant/core · GitHub
Ideally the characteristic can read the min, max, and step from the linked input_number and set it up accordingly. I will try to find some time to follow-up on this.
2 Likes
Good news: the PR to add this feature was merged, so we will see this integrated in a future Home Assistant release 
Documentation update will also be published once released: HomeKit Bridge - Home Assistant
I will try follow-up with the default run time max value. I had a first glance but couldn’t yet get it working.
3 Likes
Thanks a lot for your work! 
If you ever need help with anything — testing, debugging or anything else — I’d be happy to assist!
Really appreciate your time and contribution.
Also, if you’re interested, I can share the code I used in the HomeBridge Irrigation System integration — I manually modified it to support a full 24-hour (1-day) duration.
Maybe it could be useful for your implementation or comparison. Just let me know
I’ve added support for setting the minValue, maxValue, and minStep for the HomeKit default run time characteristic by using min, max, and step of the linked_valve_duration input_number entity in the test repo: GitHub - fabiandev/ha-homekit-valve-duration: Fork of Home Assistant homekit integration, with support for duration characteristics
@Hotelk if you can give it a try and can confirm, then I will go ahead with writing tests and opening a follow-up PR to the HA Core integration.
Note: I experienced some caching behavior and had to change the type in the yaml config of the HomeKit integration, reload the integration, and change it back to see the updated properties in the Apple Home app UI. (For example from sprinkler to shower, and then back to sprinkler)
Thanks a lot for your help 
1 Like
Hi, sorry for the delay in replying — I was testing.
Yes, the sliders appeared and the automation now correctly stops the irrigation when it should. The timer is working fine from the Home Assistant side
However, I’ve encountered an issue with SetEndTime. The Home app sees the timer and counts down normally, but when I close the Home app, the countdown resets visually. Even though the countdown disappears in the app, Home Assistant still triggers the stop at the correct time, so the automation works
This is not critical, but I’m having trouble setting up this entity so that the timer in HomeKit keeps counting down correctly even after closing and reopening the app
@fabiandev This looks great and thank you! I’m testing it now and can see the timer.
I don’t think I have my linked_valve_end_time sensor set up properly because HomeKit did not shut off the valve when the timer ran out. Can you or someone elaborate more on how this should be configured? Should it store the start datetime + run time?
Edit: I’m also seeing the same behavior with the countdown reseting that @Hotelk reported.
This sounds to me as if the linked valve end time is not set up correctly, and the timer actually falls back to the linked valve duration.
My guess: HomeKit will start the timer with whatever is your configured as default run time (linked duration), but when you close and open the app again, it fails to load the end date (linked end time) and cannot calculate the remaining time, falling back to the default.
Can you enable debug logs for the integration and share the logs when reproducing the behavior please?
Edit: Are you using a sensor with device_class timestamp for the linked_valve_end_time?
HomeKit does not automatically turn off the valve when the end time is reached. This automation needs to be performed by Home Assistant.
The linked entities are a way to communicate the default run time and the remaining duration to HomeKit, but it does not perform any automated actions based on it.
You may be able to check if linked_valve_end_time is set up correctly: Activate the valve, force close the Home app, re-open the app. If you can see the timer picks up the actual remaining time, it should be fine. If the timer again starts with the value of linked_valve_duration it may not be correctly configured.
linked_valve_end_time should store be a sensor of device_class timestamp that stores when the valve is expected to be turned off. So you are correct it is usually start datetime + run time.
But just to mention again, the automation to actually turn off the valve when this point in time is reached has to be performed by Home Assistant (or any other 3rd party integration controlling the valve)
Thanks @fabiandev that all makes sense. I will work on updating my config and will report back soon. -Joe
@hotelk I fixed the Home.app countdown timer and the linked_valve_end_time sensor by using this template:
{{ as_datetime(states('input_datetime.linked_valve_end_time')).isoformat() + "+00:00" }}
Seems that the sensor wouldn’t take a timestamp/datetime without a timezone, and otherwise showed as “unknown”.
I now have an automation that is triggered by the sprinkler switch being turned on that sets the input_datetime to now() + input_number.linked_valve_duration. There is a second automation that turns off the switch when the linked_valve_end_time sensor time is reached. The sprinkler shuts off on time now and Home.app properly reflects that it was shut off.
@fabiandev The only remaining issue is that if I turn on the sprinkler switch in Home.app, the counter shows zero until I close out of Home.app and relaunch. Then it shows the correct countdown, and also persists through restarts of the Home.app. Also, if I look at the switch in another Home.app (like from my computer), that second instance shows the right time and then within a second or so the first instance updates to reflect the right timer.
Looks like HomeKit is picking up the linked_valve_end_time sensor value before it is properly updated in HA?
(Once I get that issue resolved, I’ll post here with code snippets for all my Helpers/Automations/etc for reference.)
1 Like