2021.10.0: Z-Wave S2 support, Tuya, secure ESPHome and 400 new icons

[Tamsy]

Since upgraded to 2021.10.0 I see tons of these in the logs:

Logger: homeassistant
Source: /usr/src/homeassistant/homeassistant/runner.py:90
First occurred: 11:09:39 (190 occurrences)
Last logged: 11:26:41
Error doing job: Task exception was never retrieved

Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/async_upnp_client/search.py", line 83, in _async_on_data
    await self.async_callback(headers)
  File "/usr/local/lib/python3.9/site-packages/async_upnp_client/ssdp_listener.py", line 392, in _on_search
    ) = self._device_tracker.see_search(headers)
  File "/usr/local/lib/python3.9/site-packages/async_upnp_client/ssdp_listener.py", line 156, in see_search
    udn = headers["_udn"]
  File "/usr/local/lib/python3.9/site-packages/async_upnp_client/utils.py", line 57, in __getitem__
    return self._data[self._case_map[key.lower()]]
KeyError: '_udn'

HA Supervised on RPI4 4, Debian 11.

The UPnP/IGD integration is not used on the RPI. Wondering where the error is coming from. Neither a Supervisor nor a Host reboot remedies the latter.

Is somebody seeing similar in the logs?

[mftas]

@stirlo

If you upgrade to 2021.10, by default, you only have “Tuya v2 - new and improved edition but less device support” and will lose the ability to control covers, regardless of if you had covers working with the existing Tuya integration on 2021.9.7

I would change it slightly to say “Tuya v2 - new and improved edition but broken support for previously-supported device categories”

[chishm]

I’ve created an issue to track this on the async_upnp_client repo. It is due to the ssdp component searching for devices on your network (once per minute), and one (or more) of the devices responding in an unexpected way.

[jjroysdon (Jason Roysdon)]

I’m fine with having an official Tuya integration that requires the cloud. But leave the original FOSS Tuya integration there as well. Let us choose which one we want to use.

Fortunately, everything worked for me once I set up the API and edited all my dashboards.

[nickrout]

@kanga_who

Paulus says in the live stream @25:22 that, “Local is not planned right now…no schedule for when a local API will come available”

So not even a promise.

[francisp (Francis)]

@Mariusthvdb

the device class of the entity, power

power = Watt, energy = Wh or kWh

it is your state_class that needs adjusting.

[kurisutian]

Anyone else does have issues with ESPhome encryption? I did add it to my device and the reconfiguration message shows in HA but adding the key to the integration somewhat does not work. I always get an “Can’t connect to ESP. Please make sure your YAML file contains an ‘api:’ line.” error message and cannot connect encrypted whatsoever.

[kurisutian]

Also I noticed that after the upgrade my gas-meter won’t work any longer:

entity_unexpected_device_class
sensor.gasverbrauch

Last reset missing
The following entities have state class 'measurement' but 'last_reset' is missing:
sensor.gasverbrauch

It worked fine before. Also when manually editing these attributes to the sensor system complains that the unit ao measurement is wrong but it is not. It’s definitely set to m³ which should work fine… but somehow does not. Anyone else has similar problems?

[francisp (Francis)]

use state_class total_increasing instead of measurement.

[GSzabados (Gábor Szabados)]

This new Tuya integration is an interesting subject. Tuya generally has a weird tier based device model. They produce devices for hundreds of brands as a white label producer, but each brand has to define what tier (level of integration) they are paying for.

SmartThings does an integration model where the producer has to provide and maintain the code for the integration. The first Tuya brand was Globe Suite which was integrated to SmartThings. You could add Globe Suite devices to the original Tuya branded app and control them there, or add other (Tuya) branded devices to the Globe Suite app (skinned Tuya app) and control them.
But when the Globe Suite integration was added to SmartThings, it has turned out that only the Globe Suite branded devices were pulled from the API to the SmartThings system. Of course later on Tuya released a Tuya branded integration for SmartThings as well, but that doesn’t change the fact how it was visible where it works. The Tuya app provides a tab somewhere at the device level where you can see what services the devices works with, Google Home, Amazon Alexa, SmartThings, etc.
All of these integrations are separate tiers of the Tuya solution. Why wouldn’t be, pay for the code and server use as part of tier, and build it into the price of the device what you sell, easy enough.
It was a bit of similar story when Tuya was pulling out from the IFTTT integration, as they were not intended to pay for it. It was before IFTTT introduced their user payment model in 2020. Only one, as I can remember, some Australian skinned Tuya app was left which had the option to connect your devices with IFTTT.

I am just wondering where it will go with this Tuya maintained integration. Will Tuya introduce a tier for the Home Assistant integration where brands have to pay for that to be part of their product. Or is it even existing already and that’s why some people cannot see devices added as before.

I was never really a big fun of Tuya and their model. The cloud based overhead kills the device and leaves the buyer vulnerable to when a device will reach End Of Life or the cloud been shut down, firmware not updated etc… I prefer more any Zigbee device, as this is a general issue with any WiFi based product, if it hasn’t got any local control. But that is part of Tuya’s model as well.
I have only two Tuya/DSC devices what I have never connected to any WiFi networks or wasn’t able to reflash as they don’t use ESP chips or not supported by Tasmota. I would love to use them locally, but I think more and more that they were just a wrong purchase years ago.

[Mariusthvdb (Marius)]

no, check Sensor Entity | Home Assistant Developer Docs
power is either W or kW.

and state_class: measurement is correct.

[francisp (Francis)]

That is what I’m saying :

power = Watt, energy = Wh or kWh

[krovachek (Krisztian Borsi)]

These were the only used sensors from UPnP integration in my config

[Ajurna]

i found i had to delete tuya v2 to get it to work with the error below

File "/usr/src/homeassistant/homeassistant/components/tuya/__init__.py", line 6, in <module>
home-assistant   |     from tuya_iot import (
home-assistant   | ImportError: cannot import name 'AuthType' from 'tuya_iot' (/usr/local/lib/python3.9/site-packages/tuya_iot/__init__.py)

also i found the new tuya doesn’t support temp/humidity sensors…

[Mariusthvdb (Marius)]

don’t think I follow what you’re saying here, but my source is in kW is a power sensor and measurement.
kW is not the same as Wh.

[Speedtriple]

Z-wave of IP will not work anymore. Used RPi3 with WS-server.
In HA there is this error on Z-Wave JS module:
“Retrying setup: Z-Wave JS Server version is incompatible: 1.10.3 a version is required that supports at least api schema 10”

Rollback to 2010.9 works.

[kurisutian]

@francisp

e state_class total_increasing instead of measurement.

Thanks for the reply.
I just started with this and this value comes from a reed contact attached to a ESP8266 (Wemos D1 Mini) device used to count the gas consumption right at the meter. So all values come are automatically created from ESPhome integrating this sensor. Is there any way to do this from the ESPhome part? Sorry if this might be a dumb question but as mentioned, I just started with this and that was my first attempt to create something…

[nickrout]

Open a new thread in the esphome section and post your esphome yaml.

[chrisuki]

Thanks for the great work, amazing as always.

Still looking forward to migrate from Legacy Z-wave integration to Z-Wave JS…but as long no proper handling of cover move order + feedback, it is a no-go for me.
If anyone can help or has any ideas how to workaround this, you can check this thread:

Z-Wave JS : Cover State Feedback

Hi, I have 11 Qubino Flush Shutter modules, that I use in Venetian Blind mode. At the moment, I’m still using the old OZW 1.4 integreation “in production”, but currently preparing the move to Z-Wave JS on my “test platform”. By checking the functionalities of one module with Z-Wave JS integration, I have seen a behavior change in the cover entities created by HA. Let’s say the cover is closed (position 0) : When I set the position to “100”, the cover moves up as expected. The problem is, tha…

[Emiel86 (Emiel)]

Hello @frenck,
I have a question about the new netgear integration.
How is the security of the username/password in the netgear integration, because in the past you had to save that in the secrets.yaml file?