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

liuk4friends commented 3 years ago

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 commented 3 years ago

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

rapi3 commented 3 years ago

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

postlund commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

postlund commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

liuk4friends commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Please try #288.

liuk4friends commented 3 years ago

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 commented 3 years ago

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

rospogrigio / localtuya

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