dale_s
(Dale)
May 12, 2025, 6:14pm
1
What is the best way to set a trigger for time based automations based on the Jewish Calendar integration? The time sensor states are represented as ISO8601 formatted UTC time
At the moment I am using template triggers. For example to trigger when it is tset hakochavim I use the following template. The calue of the sensor is 2025-05-12T16:58:00+00:00
{{ (states('sensor.jewish_calendar_t_set_hakochavim') | as_timestamp)| timestamp_custom("%H:%M") == as_timestamp(now()) | timestamp_custom("%H:%M") }}
Is there a better way to do this? This works its just a pain to keep doing this for automations and I was wondering if there is a cleaner way
@tsvi Do you have any suggestions or best practices here?
123
(Taras)
May 12, 2025, 6:28pm
2
If the sensor’s device_class
is timestamp
then you can simply use a Time Trigger .
alias: example
triggers:
- trigger: time
at: sensor.jewish_calendar_t_set_hakochavim
conditions: []
actions:
... etc ...
dale_s
(Dale)
May 12, 2025, 7:30pm
3
I missed that option in the settings. Thanks
1 Like
tsvi
(Tsvi Mostovicz)
May 13, 2025, 5:29am
4
Yes, thanks @123 for pointing it out.
Up until about a year ago you had to do something like what you suggested in the OP.
@123 's suggestion is currently the recommended way. Note, that you can also have offsets in the time trigger so you can do stuff 5 min before or after.
123
(Taras)
May 13, 2025, 2:14pm
5
What happened a year ago?
FWIW, the ability to specify a datetime sensor for a Time Trigger was added by Paulus in late 2020.
dev
← time-trigger-datetime-sensor
opened 01:06PM - 06 Nov 20 UTC
## Breaking change
## Proposed change
Allow specifying a datetime sens… or as the `at` value for a time trigger. This will make it easy to automate on when your alarm is going to ring.
CC @dshokouhi
## Type of change
- [ ] Dependency upgrade
- [ ] Bugfix (non-breaking change which fixes an issue)
- [ ] New integration (thank you!)
- [x] New feature (which adds functionality to an existing integration)
- [ ] Breaking change (fix/feature causing existing functionality to break)
- [ ] Code quality improvements to existing code or addition of tests
## Example entry for `configuration.yaml`:
```yaml
# Example configuration.yaml
```
## Additional information
- This PR fixes or closes issue: fixes #
- This PR is related to issue:
- Link to documentation pull request:
## Checklist
- [ ] The code change is tested and works locally.
- [ ] Local tests pass. **Your PR cannot be merged unless tests pass**
- [ ] There is no commented out code in this PR.
- [ ] I have followed the [development checklist][dev-checklist]
- [ ] The code has been formatted using Black (`black --fast homeassistant tests`)
- [ ] Tests have been added to verify that the new code works.
If user exposed functionality or configuration variables are added/changed:
- [ ] Documentation added/updated for [www.home-assistant.io][docs-repository]
If the code communicates with devices, web services, or third-party tools:
- [ ] The [manifest file][manifest-docs] has all fields filled out correctly.
Updated and included derived files by running: `python3 -m script.hassfest`.
- [ ] New or updated dependencies have been added to `requirements_all.txt`.
Updated by running `python3 -m script.gen_requirements_all`.
- [ ] Untested files have been added to `.coveragerc`.
The integration reached or maintains the following [Integration Quality Scale][quality-scale]:
- [ ] No score or internal
- [ ] 🥈 Silver
- [ ] 🥇 Gold
- [ ] 🏆 Platinum
To help with the load of incoming pull requests:
- [ ] I have reviewed two other [open pull requests][prs] in this repository.
[prs]: https://github.com/home-assistant/core/pulls?q=is%3Aopen+is%3Apr+-author%3A%40me+-draft%3Atrue+-label%3Awaiting-for-upstream+sort%3Acreated-desc+review%3Anone
[dev-checklist]: https://developers.home-assistant.io/docs/en/development_checklist.html
[manifest-docs]: https://developers.home-assistant.io/docs/en/creating_integration_manifest.html
[quality-scale]: https://developers.home-assistant.io/docs/en/next/integration_quality_scale_index.html
[docs-repository]: https://github.com/home-assistant/home-assistant.io
tsvi
(Tsvi Mostovicz)
May 13, 2025, 2:28pm
6
You’re right. I was thinking about this part:
dev
← tsvi:time-sensor-offset
opened 11:19AM - 30 Jun 24 UTC
## Proposed change
Re-implementaton of #56838 for timestamp sensors only.
Th… is change was previously proposed to allow users to specify an offset for timestamp sensors. It was reverted due to the discussion in #58815. The discussion was never resolved regarding the option to implement this only for timestamp sensors.
This will remove the need for integrations like `gtfs` and `hvv_departures` to implement there own offset, as well as the need to create complex templates to get a timestamp based on an offset from a sensor (e.g. upcoming alarm)
This is basically the exact same implementation proposed previously by @RobertMe, barring the part for support of input_datetime which caused this to be reverted, and with some addditional quality changes (type hints, FrozenDateTimeFactory) based on the latest dev.
## Type of change
- [ ] Dependency upgrade
- [ ] Bugfix (non-breaking change which fixes an issue)
- [ ] New integration (thank you!)
- [x] New feature (which adds functionality to an existing integration)
- [ ] Deprecation (breaking change to happen in the future)
- [ ] Breaking change (fix/feature causing existing functionality to break)
- [ ] Code quality improvements to existing code or addition of tests
## Additional information
- This PR fixes or closes issue: fixes #
- This PR is related to issue:
- Link to documentation pull request: home-assistant/home-assistant.io#33611
## Checklist
- [x] The code change is tested and works locally.
- [x] Local tests pass. **Your PR cannot be merged unless tests pass**
- [x] There is no commented out code in this PR.
- [x] I have followed the [development checklist][dev-checklist]
- [x] I have followed the [perfect PR recommendations][perfect-pr]
- [x] The code has been formatted using Ruff (`ruff format homeassistant tests`)
- [x] Tests have been added to verify that the new code works.
If user exposed functionality or configuration variables are added/changed:
- [x] Documentation added/updated for [www.home-assistant.io][docs-repository]
If the code communicates with devices, web services, or third-party tools:
- [ ] The [manifest file][manifest-docs] has all fields filled out correctly.
Updated and included derived files by running: `python3 -m script.hassfest`.
- [ ] New or updated dependencies have been added to `requirements_all.txt`.
Updated by running `python3 -m script.gen_requirements_all`.
- [ ] For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
- [ ] Untested files have been added to `.coveragerc`.
To help with the load of incoming pull requests:
- [ ] I have reviewed two other [open pull requests][prs] in this repository.
[prs]: https://github.com/home-assistant/core/pulls?q=is%3Aopen+is%3Apr+-author%3A%40me+-draft%3Atrue+-label%3Awaiting-for-upstream+sort%3Acreated-desc+review%3Anone+-status%3Afailure
[dev-checklist]: https://developers.home-assistant.io/docs/development_checklist/
[manifest-docs]: https://developers.home-assistant.io/docs/creating_integration_manifest/
[quality-scale]: https://developers.home-assistant.io/docs/integration_quality_scale_index/
[docs-repository]: https://github.com/home-assistant/home-assistant.io
[perfect-pr]: https://developers.home-assistant.io/docs/review-process/#creating-the-perfect-pr
Allowing the user to add an offset in addition to the time trigger.
1 Like