Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hub zigbee protocol 3.3 #77

Open
goodsale opened this issue Sep 23, 2023 · 11 comments
Open

Hub zigbee protocol 3.3 #77

goodsale opened this issue Sep 23, 2023 · 11 comments
Labels
bug Something isn't working

Comments

@goodsale
Copy link

after successfully testing the new version with Zigbee devices and a 3.4 protocol HUB, I'm doing the same thing with a 3.3 protocol hub.

On the hub with protocol 3.3 the same problem occurs as in the past where it was only possible to check the status of the device but not be able to send the on/off command.

Are there any differences between 3.3 and 3.4?

@goodsale goodsale added the bug Something isn't working label Sep 23, 2023
@Botsmall
Copy link

Botsmall commented Oct 2, 2023

Same problem.
There are 3.3 and 3.4 devices in the system.
We have two variants of development:

  1. control possibility 3.3, but impossibility of control 3.4 (settings gateway 3.3)
  2. control possibility 3.4, but impossibility of control 3.3 (settings gateway 3.4)

@goodsale
Copy link
Author

goodsale commented Oct 3, 2023

I have 2 houses with 2 different raspberries and 2 independent home assistant.
In a house I have a zigbee hub (Moes) with protocol 3.4 and here everything works perfectly and all the subdevices are controlled.

In the other house I have a similar configuration but here I have a zigbee hub with 3.3 protocol and here on/off doesn't work but only the states are detected

The sub-devices are similar (moes dimmer 1 or 2 gang).

Is there anything that can be done?

@Botsmall
Copy link

I have an error in your version:
Something failed when discovering devices. See log for details.

2023-10-10 12:02:42.948 ERROR (MainThread) [custom_components.localtuya.config_flow] discovery failed: reuse_port not supported by socket module
Traceback (most recent call last):
File "/opt/var/lib/homeassistant/custom_components/localtuya/config_flow.py", line 665, in async_step_add_device
self.discovered_devices = await discover()
^^^^^^^^^^^^^^^^
File "/opt/var/lib/homeassistant/custom_components/localtuya/discovery.py", line 106, in discover
await discovery.start()
File "/opt/var/lib/homeassistant/custom_components/localtuya/discovery.py", line 71, in start
self._listeners = await asyncio.gather(listener, encrypted_listener)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/lib/python3.11/asyncio/base_events.py", line 1363, in create_datagram_endpoint
File "/opt/lib/python3.11/asyncio/base_events.py", line 90, in _set_reuseport
ValueError: reuse_port not supported by socket module
2023-10-10 12:05:59.238 DEBUG (MainThread) [custom_components.localtuya.config_flow] An error occurred while trying to pull sub-devices 'bfdxxxxxxxxxxxxxxxx'

@xZetsubou
Copy link

xZetsubou commented Oct 10, 2023

I have an error in your version

What's your OS Version?. For some reason your socket lib doesn't supports reuse_port ? is your installation method core perhaps windows VM?
for now you can open discovery.py in localtuya inside of custom_integration directory, and comment out reuse_port. on lines 63, 66

image

@Botsmall
Copy link

Botsmall commented Oct 10, 2023

home assistant is installed on the router keenetic opkg/entware/hacs.

After commenting reuse_port devices started being added. Thanks.
But the original problem remains: control possibility 3.4, but impossibility of control 3.3.

DEBUG (MainThread) [custom_components.localtuya.pytuya] [bf3...o2j] Sending command 7 (device type: type_0a)
DEBUG (MainThread) [custom_components.localtuya.pytuya] [bf3...o2j] Sending payload: b'{"devId":"bf300877sdadasda","uid":"asdaaaaaad701dto2j","t":"1696965357","cid":"a4c13dgwrf05cc6","dps":{"105":-6.0}}'
DEBUG (MainThread) [custom_components.localtuya.pytuya] [bf3...o2j] Command 7 waiting for seq. number 25
DEBUG (MainThread) [custom_components.localtuya.pytuya] [bf3...o2j] Dispatching message CMD 7 TuyaMessage(seqno=25, cmd=7, retcode=0, payload=b'', crc=1258413219, crc_good=True, prefix=21930, iv=None)
DEBUG (MainThread) [custom_components.localtuya.pytuya] [bf3...o2j] ACK received for command 7: ignoring it

@Botsmall
Copy link

DEBUG [bf3...o2j] Sending command 9 (device type: type_0a)
DEBUG [bf3...o2j] Sending payload: b'{"gwId":"bf30dfsf54fdcc701dto2j","devId":"bf30dfsf54fdcc701dto2j"}'
DEBUG [bf3...o2j] Command 9 waiting for seq. number -100
DEBUG [bf3...o2j] Dispatching message CMD 9 TuyaMessage(seqno=0, cmd=9, retcode=0, payload=b'', crc=2958142211, crc_good=True, prefix=21930, iv=None)
DEBUG [bf3...o2j] Got heartbeat response
DEBUG [bf3...o2j] ACK received for command 9: ignoring it
DEBUG [bf3...o2j] Dispatching message CMD 8 TuyaMessage(seqno=0, cmd=8, retcode=0, payload=b'3.3\x00\x00\x00\x00\x00\x00\x9d\xbe\x00\x00\x00\x01\x8fq\t\x17\xcc\xa9\xd9\x95\xa5PE\xc4\x95\x95\xafBQ\x07,wOY%R\nM\x0f\xca\xe9\x8f\xd5\x19\x95\xea\x92\x94u\xb6n\xe09\\\x97\xdb\x06\x84,{\x8d\x9f+\xe7\xa9!\xefKMu\r\x1c\xa3\x17\xdf?', crc=1205680371, crc_good=True, prefix=21930, iv=None)
DEBUG [bf3...o2j] Got status update
DEBUG [bf3...o2j] Deciphered data = '{"dps":{"105":4},"cid":"a4c1334523f05cc6","t":1697012036}'
DEBUG [bf3...o2j] Sending command 9 (device type: type_0a)
DEBUG [bf3...o2j] Sending payload: b'{"gwId":"bf30dfsf54fdcc701dto2j","devId":"bf30dfsf54fdcc701dto2j"}'
DEBUG [bf3...o2j] Command 9 waiting for seq. number -100
DEBUG [bf3...o2j] Dispatching message CMD 9 TuyaMessage(seqno=0, cmd=9, retcode=0, payload=b'', crc=2958142211, crc_good=True, prefix=21930, iv=None)
DEBUG [bf3...o2j] Got heartbeat response
DEBUG [bf3...o2j] ACK received for command 9: ignoring it

@Botsmall
Copy link

devID and cid changed when creating a message...this is one device.
In this example, I pulled dps manually as a single variable from the thermostat.
For the experiment, I added it in automatic mode, and the result was similar.

@yabdali
Copy link

yabdali commented Dec 11, 2023

after successfully testing the new version with Zigbee devices and a 3.4 protocol HUB, I'm doing the same thing with a 3.3 protocol hub.

On the hub with protocol 3.3 the same problem occurs as in the past where it was only possible to check the status of the device but not be able to send the on/off command.

Are there any differences between 3.3 and 3.4?

How is your experience with MOES gateway? I ordered one (multi-mode) and few switches from MOES as well plus some switches from other vendors. Trying to figure out how I can use it with HA using the gateway instead of buying a separate USB dongle. Do you see any limitation in using the Gateway/hub without having a Zigbee dongle such as the Sonoff Zigbee (E)?

@alexualbu
Copy link

@Botsmall @goodsale

can you try a direct patch to the file and confirm this works (in 3.7.0 beta 12)?
you need to change /config/custom_components/localtuya/pytuya/init.py line 225 from this COMMAND: {"devId": "", "uid": "", "t": ""}, to this COMMAND: {"uid": "", "t": ""},

image

@goodsale
Copy link
Author

For me works fine!

Thanks!

@alexualbu
Copy link

Thanks, opening a PR now

@alexualbu alexualbu mentioned this issue Dec 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants