It seems to me that here we can change 20 seconds to a minute… Without compromising functionality and accuracy …
Maybe? I didn’t put too much thought into it but I know 20 seconds would work.
Tuya issue that I can’t get solved.
I run Smart life app version 4.6.2 (international) - no updates available.
Tuya in HA requires to reauthenticate. When I follow the instructions there is no code shown under Account and Security in the Smartlife app. I can revoke HA, unlink email etc.
I tried all the ID’s and keys I have on the Tuya IOT platform but not the ones HA want.
Anybody an idea? In the meantime I restored to January version.
In Home Assistant, the beat option in the time_date sensor provides the Swatch Internet Time (or beat time).
Swatch Internet Time divides the day into 1000 “beats,” each beat representing 1/1000th of a day. The main idea behind Swatch Internet Time was to have a universal time system that is not bound by time zones and is easy to understand.
For example, if the beat time is 456, it represents 4 hours, 56 minutes, and 0 seconds.
In the provided configuration, adding “beat” to the display_options of the time_date sensor will include the beat time in the sensor’s output.
If you don’t use the beat option you can remove it.
True title would be
" More voice, more icons, more integrations, more problems, more… everything!"
Just kidding, couldn’t help myself.
this might work too…
- trigger:
- platform: homeassistant
event: start
- platform: time
at: sensor.next_swatch_time
sensor:
- name: Next Swatch Time
state: >
{% set t = today_at() %}
{% set n = now() %}
{% set d = (n - t).total_seconds() % 86.4 %}
{% set last = n - timedelta(seconds=d) %}
{{ last + timedelta(seconds=86.4) }}
- name: Internet Time
state: >
{% set time_bmt = now() + 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) }}
2 Likes
The following typed (or spoken) Assist conversation, before the 2024.2 update, correctly responded with the heater temperature and set the heater to the correct temperature but now the Assist conversation goes like this:
Assist: “How can I assist?”
Me: “office to 75” # same for “set office to 75”
Assist: “Unexpected error during intent recognition”
Yet the following Assist intents sentence, typed or spoken, results in Assist correctly responding and setting the heater temperature to 75 degrees.
Assist: “How can I assist?”
Me: “office to 75 degrees” # or “set office to 75 degrees”
Assist: “Temperature changed to 75 degrees”
My uneducated guess is that an intent sentence can no longer end in a number.
My custom sentences located at “/homeassistant/custom_sentences/en/temperatures_.yaml” has:
language: "en"
intents:
SetHeaterTemperature:
data:
- sentences:
- "([set]|[change]) {oil_heater} [temperature] to {temp_degrees} [degrees]"
- "set {oil_heater} to {temp_degrees}"
- "{oil_heater} to {temp_degrees}"
- "office to {temp_degrees}"
lists:
oil_heater:
values:
- in: "office"
out: number.irdecode1office_select_heater1_temp_42_95_f
- in: "bedroom"
out: number.irdecode2front_bdrm_select_heater2_temp_42_95_f
- in: "living room"
out: number.irdecode3livingrm_select_heater3_temp_42_95_f
- in: "dining room"
out: number.irdecode4diningrm_select_heater4_temp_42_95_f
temp_degrees:
range:
from: 42
to: 80
In “/homeassistant/configuration.yaml” I only have:
intent_script:
SetHeaterTemperature:
action:
service: "number.set_value"
data:
entity_id: "{{ oil_heater }}"
value: "{{ temp_degrees }}"
speech:
text: "Temperature changed to {{ temp_degrees }} degrees"
1 Like
I agree with mateuszdrab, although the automatic token expiration benefits me, because I go and delete unused tokens periodically, this cannot be a one-size-fits-all approach.
If you want to make HA work for the most users, there has to be an option for the user to enable or disable those features, nothing should be mandatory.
Look at the mess that forcing “prefixing of the friendly name” caused in ESPHome, I had to re-write most of my automation and scripts, and it caused chaos with the voice assistant, I had to rename all of my ESPHome nodes, just so that voice assistant would find them, it was a total mess.
I opened a discussion on the subject here: https://github.com/esphome/feature-requests/issues/2476.
I think the possibility to OTA flash zigbee devices is really cool,
hower none of my (sonoff) devices apparently needs an update.
never the less I did some research and found that it’s also possible to create custom firmware for zigbee devices.
I never knew fw update or custom firmware is possible for zigbee. I always thought zigbee is as is.
but now my question, would it also be possible to OTA flash custom firmware?
and it would be really cool if we could have some esphome like functionality for zigbee, but I think that would be far away.
Next to that the blackadder post seems to show that Z2M supports all added features by default where ZHA still needs a quirk.
This can ofcourse be because the custom firmware has been written for Z2M
Anyone else seeing no position info for blind tilts
Has anyone else tried to add the Govee Lights Local integration? My system can’t seem to find it. Clicking on the ‘Add Integration to My HA’ button here: Govee lights local - Home Assistant gives me this error:
This integration does not support configuration via the UI. If you followed this link from the Home Assistant website, make sure you run the latest version of Home Assistant.
I am fully updated on 2024.2.0 as of this post.
Same here.
Just seen this - Govee lights local fails to initialize · Issue #109941 · home-assistant/core (github.com)
Are you using the HACS Govee LAN integration? Sounds like removing that and restarting may fix the problem.
Ah, interesting. I just updated from Govee LAN to govee2mqtt yesterday, but it seems that it, too, causes the issue. Additionally, I had another HACS integration just called “Govee”. Deleting all three made the native integration work. However, the govee2mqtt integration is much more feature-rich, including the ability to set the Govee-based scenes. Not sure if I’ll migrate back or not. I do like to avoid HACS as much as possible.
Don’t quite get this new Proximity integration. How can I change unit of measurement to km. I can only set the Tolerance distance but have no idea in what unit is that 
It’s available in Node Red.
1 Like
All my template switches are missing after updating to 2024.2. What’s going on ? There is no breaking changes related to that in the release notes.
Why? It provides the devs far more flexibility to react to issues without waiting for the monthly release cycle or .x patches.
Any issue can be fixed very quickly and released. Also the devs don’t have to jump through the hoops that a native integration process imposes.
The way I see it, HACS is the better way for components to be be added and offers a better experience for both the user and the devs.
2 Likes
Don’t get me wrong, I love that HACS exists, and if a native integration does not exist for a given device type/ecosystem or the features of a native integration are lackluster, I will definitely use a community-driven solution. The fact is, as a software developer myself, the “hoops” that a native integration process “imposes” are actually good in my view, since that means a more stringent testing and acceptance process, and thus less bugs. I’ve had problems, ranging from minor to debilitating, with every HACS integration I’ve ever used, so I am definitely cautious about what I install.
While issues can be fixed very quickly it is not always the case that they are fixed very quickly. I don’t fault the devs for that, this is usually a hobby/passion project for them. I just err on the side of caution in order to keep things simple. I don’t have the time to deeply investigate the root cause of every instability in my HA instance.
1 Like
Same on my side. All climate entities coming from Evohome stopped working.
Rolled back to 2024.1.6 and it works again.