After upgrading to 3.2.0 release, two out of nine Tuya devices (all power metering plugs) became 'unavailable'

[liuk4friends]

Unfortunately the new version brought a small problem.
My two Teckin SP22 smartplugs have become 'unavailable'.
The other seven smartplugs I own (six Bakibo TP22Y and a Gosund doubleplug SP211) continue to work very well.

I activated the 'debug' function inside the 'logs' (the two Teckin SP22 have 192.168.178.46 and 192.168.178.47 IP address) and I can see something strange.
In fact, compared to the other devices, I can see in the 'logs' that a word is reported incorrectly:
'ablilty' instead of 'ability'.

2020-12-31 12:08:13 DEBUG (MainThread) [custom_components.localtuya.discovery] Discovered device: {'ip': '192.168.178.23', 'gwId': '*omissis*', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': '*omissis*', 'version': '3.1'}
2020-12-31 12:08:13 DEBUG (MainThread) [custom_components.localtuya.discovery] Discovered device: {'ip': '192.168.178.47', 'gwId': '*omissis*', 'active': 2, 'ablilty': 0, 'encrypt': True, 'productKey': '*omissis*', 'version': '3.3'}
2020-12-31 12:08:13 DEBUG (MainThread) [custom_components.localtuya.pytuya] [188...872] Sending command heartbeat (device type: type_0a)
2020-12-31 12:08:13 DEBUG (MainThread) [custom_components.localtuya.pytuya] [188...872] Send payload: b'{}'
2020-12-31 12:08:13 DEBUG (MainThread) [custom_components.localtuya.pytuya] [188...872] Waiting for sequence number -100
2020-12-31 12:08:13 DEBUG (MainThread) [custom_components.localtuya.pytuya] [066...724] Sending command heartbeat (device type: type_0a)
2020-12-31 12:08:13 DEBUG (MainThread) [custom_components.localtuya.pytuya] [066...724] Send payload: b'{}'
2020-12-31 12:08:13 DEBUG (MainThread) [custom_components.localtuya.pytuya] [066...724] Waiting for sequence number -100
2020-12-31 12:08:13 DEBUG (MainThread) [custom_components.localtuya.pytuya] [188...872] Dispatching message TuyaMessage(seqno=0, cmd=9, retcode=0, payload=b'', crc=2958142211)
2020-12-31 12:08:13 DEBUG (MainThread) [custom_components.localtuya.pytuya] [188...872] Got heartbeat response
2020-12-31 12:08:13 DEBUG (MainThread) [custom_components.localtuya.pytuya] [188...872] Decrypted payload: {}
2020-12-31 12:08:13 DEBUG (MainThread) [custom_components.localtuya.pytuya] [066...724] Dispatching message TuyaMessage(seqno=0, cmd=9, retcode=0, payload=b'', crc=2958142211)
2020-12-31 12:08:13 DEBUG (MainThread) [custom_components.localtuya.pytuya] [066...724] Got heartbeat response
2020-12-31 12:08:13 DEBUG (MainThread) [custom_components.localtuya.pytuya] [066...724] Decrypted payload: {}
2020-12-31 12:08:13 DEBUG (MainThread) [custom_components.localtuya.discovery] Discovered device: {'ip': '192.168.178.46', 'gwId': '*omissis*', 'active': 2, 'ablilty': 0, 'encrypt': True, 'productKey': '*omissis*', 'version': '3.3'}

I don't know if that's the problem.
Reinstalling version 3.1.0 will make the devices work properly again

My system is:

HassOS 2020.12.2
Supervisor 2020.12.7
Home Assistant OS 5.9

Thank you for your support

[GMTZMU]

Hi, I have the same problem, in my case I have the problem with all Tuya devices.

[rapi3]

Hi,
I also have the same problem with all 4 Nooie smartplugs not found/offline... downgraded and work again.

[postlund]

Do you have the devices on same VLAN as Home Assistant? Are you using them in the regular tuya integration or from anywhere else? We depend on discovery messages now and they are not broadcasted if someone is connected to the device.

[rapi3]

My Nooie smart plugs are in a separate (V)LAN and I have them all in config, like this

• host: 192.168.105.101
  device_id: bfdxxxxxxxxxxxxxxxxx
  local_key: 7608xxxxxxxxxx
  friendly_name: Priza N1
  protocol_version: "3.3"
  entities:
  • platform: binary_sensor
    friendly_name: Plug Status 1
    id: 1
    device_class: power
    state_on: "true" # Optional
    state_off: "false" # Optional
  • platform: switch
    friendly_name: Plug 1
    id: 1

[postlund]

You will need to forward UDP broadcasts for port 6666 and 6667 from the other VLAN to Home Assistant for it to work now.

[rapi3]

To much trouble, I can live with older version for now.

[postlund]

Your choice of course, but you lose a lot of good updates. The "passive device support" (which is what you got hit by here) is probably one of the best ones. I've mentioned before that I could write a script that listens for these broadcasts and let's you forward them to another host. So you would basically put in on a computer on the same VLAN as your plugs and point it toward your Home Assistant IP. Let me known if that would be interesting.

[rapi3]

My IoT VLAN it is only for them no other computers there so until I can do something from firewall it will not help in my case. Thanks anyway.

[postlund]

In that case no, it won't help. You would need some kind of computer on that network.

[liuk4friends]

Do you have the devices on same VLAN as Home Assistant? Are you using them in the regular tuya integration or from anywhere else? We depend on discovery messages now and they are not broadcasted if someone is connected to the device.

all my devices are on same lan (no VLAN at all) and I’m using them just in the localtuya integration (no regular tuya integration)

[BoneheadFraggle]

Your choice of course, but you lose a lot of good updates. The "passive device support" (which is what you got hit by here) is probably one of the best ones. I've mentioned before that I could write a script that listens for these broadcasts and let's you forward them to another host. So you would basically put in on a computer on the same VLAN as your plugs and point it toward your Home Assistant IP. Let me known if that would be interesting.

I would be very interrested in that since Unifi USG don't offer UDP broadcast forwarding out of the box.

[GMTZMU]

Hi, in my case I have a separated VLAN, I have one VLAN for all IoT devices.

I have opened all ports and protocols from HASSIO server to TUYA devices.

[postlund]

I will provide a "fix" which adds a re-connect like loop again just like before. It will be more simple, but should work in case discovery is not working or traffic is not forwarded. Should be ready by the end of the day.

[postlund]

Please try #288.

[liuk4friends]

Hi @postlund,
what should i do to try fix # 288?
Unfortunately, even with the new version 3.21 my two Teckin smartplugs become "unavailable".
I'd like to avoid going back to version 3.10...
Thank you (@rospogrigio too, of course) for your precious work. We appreciate it

P.S.
also I would like to draw your attention again to that error present in my logs.
I mentioned it opening this issue. I’m talking about the “ability” word.
My logs report it with the right spelling for all the “available” plugs.
On the contrary, for the two “unavailable” plugs I can see in my logs that it is reported with a wrong spelling, that is “ablilty”.

In addition, for the working ones I can see "mode: 0" in my logs.
In those not available, this word is absent.

I wonder if these are coincidence or not

[liuk4friends]

3.22 made my day!! All my tuya devices are working now!!!