I hear you.
But the HACS way does allow a very fast response to an issue, and recent upgrades suggest that “a more stringent testing and acceptance process, and thus less bugs” with a native integration is erroneous in my experience.
Things get missed and it is only beta testers that pick these up. Same with custom components. So I don’t see any differentiation.
But Hey ho 
1 Like
The issue for me was the Hikvision HACS integration. HA did not like the way it handled unique IDs. Removing that allowed the update.
A fix has been proposed for the Hikvision integration in HACS.
There is a problem with Nest Thermostat - the standard card is unresponsive. Clicking on it sends commands to thermostat but the card does not update.
Hey guys!
I’m pretty much in the dark here, am I the only one having issues with mqtt.publish suddenly unavailable in automations?
Was there anything done to them in this release?
Vide: 2024.2: More voice, more icons, more integrations, more... everything! - #88 by MariuszBit
Woking as expected here.
Ask Dwain.
migrated my HA Core venv from python 3.11 to 3.12 - wasn’t as smooth as usual - lots of failed pip dependencies.
so gave up trying to fix the dependencies, and just restarted the HA service - lots of issues, restarts problems - sysctl was set to restart the service if it didn’t appear to respond, which of course it didn’t as it was compiling loads of python code.
Fix was to run hass manually and let it compile everything. The restart the service
@Afterforever666 and @balogbence
Honeywell Evohome (Europe) could not be setup · Issue #110065 · home-assistant/core · GitHub (although I see neither of you have posted an issue!)
apparently you can change it in the entity settings.
open the entity and click the gear icon. then in there you can set the unit of measurement. I was told that it recalculates the correct value based on that setting so you shouldn’t need to.
(I haven’t updated so I can’t really fully test it)
the units (I think) are meters. Or it might be your default units you have set in HA for distance.
either way it is the number of units that the position needs to have changed since the last value for the direction of travel sensor to decide you are moving towards, away_from or stationary. At least that’s what it was in the yaml config.
1 Like
I’m completely surprised that there is ANY update to the Tuya integration.
There are a LOT, A LOT of unsupported or partially supported devices, tons of bugs and NO ONE GIVES ANYTHING about them. Users who are dependant on Tuya are just forgotten.
Glad to know they provided a better way to integrate into HA (but guess what, seems to be buggy, right?), but I really, REALLY hope they give us a bit more love than releasing partially-useless fan APIs and calling it a day.
Edit: “they” as in Tuya, I’m not complaining on the HA developers, but on the people that integrated Tuya into HA and then forgot it there, accumulating dust and unanswered issues.
1 Like
Just to be clear:
“they” being Tuya, not Home Assistant.
The rubbish Tuya public API is the issue here, not the way home assistant interacts with it.
So complaining here is unlikely to have much effect. Contact Tuya, tell them.
4 Likes
Do you have a link to that?
I’ve found this github:
1 Like
If we can get more tracking on grouping Zones it would somewhat get the job done. A bunch of small circular Zones next to each other / overlapping slightly to create the required shape.
Being able to interact with that Zone group as one entity would then make automations nice and easy. My example was that I wanted to have a Zone extend a distance down my street without going over the neighbouring houses. In the end I used Proximity instead, but a long narrow Zone would be really good too.
1 Like
After I updated to 2024.2, my Tuya integration wanted to reautenticate. I did that, and noticed that my Tuya door sensors show now “off” instead of “closed” (or, closed in my lanugage as they did before). Also, some elements in weather integration is also in english now, while others are in my language. Odd.
EDIT: The problem above was apparently fixed in 2024.2.1.
Also, there was a mention about Govee Local integration. I don’t find that from available integrations, only that cloud-based Govee that requires API key when installing.
That is TUYA for you, you chose their ecosystem, you have to live with it I’m afraid.
For the record I do use some TUYA zigbee devices, but usually someone has to develop a z2m/zha special case for that too. But at least I am not dependent on the cloud.
5 Likes
Installed the update yesterday. Everything finally working except wake on lan service which I use to power my Samsung tv. It was working fine until I upgraded. Anyone else having this problem?
Nope. WoL still working here.
ZHA integration uses the zigpy library so there needs to be Zigbee OTA provider download code to get unencrypted images from public sources that the official manufacturers in turn need to provide, see:
https://github.com/zigpy/zigpy/wiki/OTA-Information-for-Manufacturers
https://github.com/zigpy/zigpy/blob/6aeb8a6816585a4bda67e9ea1b125568c18fa702/zigpy/ota/provider.py
https://github.com/zigpy/zigpy/wiki/OTA-Device-Firmware-Updates
Previously it could only be enabled per provider (e.i. brand) and it would update all devices without interaction, what is new is that Home Assistant now has ZHA integration UI options to apply OTA firmware update (OTAU) per Zigbee device using the update integration as per this feature request:
Sonoff have only released firmware updates for their ZBMINI-L, ZBMINI-L2, and SNZB-06P:
https://zigbee-ota.sonoff.tech/releases/upgrade.json
This is one of the official OTA provider download sources that the ZHA users via the zigpy library, see:
https://github.com/zigpy/zigpy/blob/6aeb8a6816585a4bda67e9ea1b125568c18fa702/zigpy/ota/provider.py
1 Like