Nope, but I’m not using hue.
Also no, there is no trigger for this time, I don’t know the reason, but if you look in the developer’s tools, you can see that the current time becomes longer for a moment (the trigger should work in theory), but it doesn’t work and then the next time changes to be longer than the current one . Perhaps the reason is milliseconds, or something else.
Maybe change the trigger to state instead of time?
I don’t see how it wouldn’t recalculate. It should recalculate after the next, did you copy the entire configuration or did you just paste the change in?
My test:
Now: {{ now() }}
Next: {{ states('sensor.next_swatch_time') }}
HA: {{ states('sensor.internet_time') }}
Template: {{ states('sensor.swatch_time') }}
My config:
- trigger:
- platform: homeassistant
event: start
- platform: time_pattern
seconds: /20
sensor:
- name: Next Swatch Time
state: >
{% set t = today_at().astimezone(utcnow().tzinfo).replace(hour=0) %}
{% set n = now() %}
{% set d = (n - t).total_seconds() % 86.4 %}
{% set last = n - timedelta(seconds = d) %}
{{ last + timedelta(seconds = 86.4) }}
- trigger:
- platform: homeassistant
event: start
- platform: time
at: sensor.next_swatch_time
sensor:
- name: Swatch Time
state: >
{% set time_bmt = utcnow() + timedelta(hours = 1) %}
{%
set delta = timedelta(hours = time_bmt.hour,
minutes = time_bmt.minute,
seconds = time_bmt.second,
microseconds = time_bmt.microsecond)
%}
{% set beat = (delta.total_seconds() * 10) | int // 864 %}
{{ "@{0:03d}".format(beat) }}
I don’t see any difference with your option.
you swapped now() with utcnow() on swatchtime, but ha’s pid loop doesn’t use utcnow in the original code.
Please just try the setup I provided as is without alterations. Otherwise you’ll have to debug the changes you make.
EDIT: pid loop is probably not the correct term
Either way, the updates should still occur and your test is showing they aren’t. If you reloaded, without unque_id’s the template integration will create sensor.next_swatch_time_1 which would explain why it’s not updating. Restart, or add unique_id’s so reloading isn’t causing issue.
1 Like
No, don’t have a second instance. I’m at this very moment installing 2024.2.1 which has in the changelog “Bump evohome-async to 0.4.18” which will solve the problem I think (looking at the changleog of evohome-async). Will edit this post if all turns out fine.
1 Like
Any ideas how to troubleshoot?
I have only one: sensor.next_swatch_time
I’ll change it, but it’s not critical, it’s not updated (or rather, it’s updated only when HA starts).
Lets just go back to the original calc
- trigger:
- platform: homeassistant
event: start
- platform: time_pattern
seconds: /20
sensor:
- name: Swatch Time
state: >
{% set time_bmt = utcnow() + timedelta(hours = 1) %}
{%
set delta = timedelta(hours = time_bmt.hour,
minutes = time_bmt.minute,
seconds = time_bmt.second,
microseconds = time_bmt.microsecond)
%}
{% set beat = (delta.total_seconds() * 10) | int // 864 %}
{{ "@{0:03d}".format(beat) }}
1 Like
I change utcnow() to now(), add unique_id, restrt HA and have wrong value:
but everything is the same:
I understand, it’s a pity it didn’t work out nicely. Therefore, this sensor is great in integration, and not very good in template.
Thanks, I’ll have to do a custom integration.
I think you’re doing something wrong. It’s matching here just fine. I just set it up to verify, matching numbers.
EDIT: It does require utcnow() not now()
I don’t even know what could be done wrong here. But the template trigger sensor is not updated.
As it was released in the last Supervisor and really took effect on the first HA update, I want to give a big Thank You! to @bdraco! 
This feature update is amazingly efficient! Backup and HA update together is just lightning fast! Wow!
1 Like
see: Increased processor use from Assist Pipeline · Issue #110112 · home-assistant/core · GitHub
there’s something cooking…
Very much appreciate the continue improvement effort! With all the icon handling enhancement in the release, was hoping to see the addition of a simplified ability to set a desired color for icon state on dashboard cards - eliminate the default yellow for “on” and allow the ability to specific a more relevant color like “green” for on and “red” for off.
Sorry I should have also included “arrived” as a state but since that state doesn’t use the “tolerance” setting (AFAIK) then it wasn’t applicable.
the “arrived” state is when you are already in the zone and therefore all other states are overridden.
With the met office link broken its a bit of a deal breaker so i’m back to 2024.1.6 until its fixed, unless somebody can reco an alternative ?
1 Like
Tried updating OSRAM/Ledvance zigbee power plug as it is offered by settings but it simply fails:
2024-02-09 16:01:24.811 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [546602741696]
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 240, in handle_call_service
response = await hass.services.async_call(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 2279, in async_call
response_data = await coro
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 2316, in _execute_service
return await target(service_call)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 892, in entity_service_call
single_response = await _handle_entity_call(
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 962, in _handle_entity_call
result = await task
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/update/__init__.py", line 161, in async_install
await entity.async_install_with_progress(version, backup)
File "/usr/src/homeassistant/homeassistant/components/update/__init__.py", line 465, in async_install_with_progress
await self.async_install(version, backup)
File "/usr/src/homeassistant/homeassistant/components/zha/update.py", line 156, in async_install
assert firmware
AssertionError
Tested with a LEDVANCE Smart+ Plug
Same issue as this: HA2024.2 - API error · Issue #110073 · home-assistant/core · GitHub
homeassistant.components.zha: debug is already set but does not provide further output.
had the same issue my HA core refused to start via sysctl but if i opened the venv and manually started it configured and ran nicely (but have gone back to 2024.1.6 because i need met office so havent done much on 2024.2.0 to ensure it all works)