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

Error pairing friend of hue switch #229

Open
ffavero opened this issue Apr 2, 2020 · 6 comments
Open

Error pairing friend of hue switch #229

ffavero opened this issue Apr 2, 2020 · 6 comments

Comments

@ffavero
Copy link

ffavero commented Apr 2, 2020

I was trying to pair the battery-less Niko friends of hue switch with ZHA (home assistant 0.107.7, python 3.7.7) and I got this exception, any time as soon as I tap a button of the switch:

2020-04-02 23:49:23 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'3122b16d2bcc94b273a63a248067e2480b4c23abed4f6e8bfdd69c760381c0a7ebcddeca7effe7c08b2d618c4623a9eb763ba5ed71a6927341d2987e'
2020-04-02 23:49:23 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'8430fc7e'
2020-04-02 23:49:23 DEBUG (MainThread) [bellows.ezsp] Application frame 197 (gpepIncomingMessageHandler) received: b'7fe681002a3270012a32700197020400008109000010ffffffffff00000000a5f100201b5eff080000000007000000070424d3eb0d'
2020-04-02 23:49:23 ERROR (MainThread) [homeassistant.core] Error doing job: Exception in callback ThreadsafeProxy.__getattr__.<locals>.func_wrapper.<locals>.check_result_wrapper() at /usr/local/lib/python3.7/site-packages/bellows/thread.py:99
ValueError: 127 is not a valid EmberStatus

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.7/asyncio/events.py", line 88, in _run
    self._context.run(self._callback, *self._args)
  File "/usr/local/lib/python3.7/site-packages/bellows/thread.py", line 100, in check_result_wrapper
    result = call()
  File "/usr/local/lib/python3.7/site-packages/bellows/ezsp.py", line 221, in frame_received
    result, data = t.deserialize(data, schema)
  File "/usr/local/lib/python3.7/site-packages/bellows/types/__init__.py", line 9, in deserialize
    value, data = type_.deserialize(data)
  File "/usr/local/lib/python3.7/site-packages/bellows/types/basic.py", line 10, in deserialize
    r = cls(int.from_bytes(data[: cls._size], "little", signed=cls._signed))
  File "/usr/local/lib/python3.7/enum.py", line 310, in __call__
    return cls.__new__(cls, value)
  File "/usr/local/lib/python3.7/enum.py", line 564, in __new__
    raise exc
  File "/usr/local/lib/python3.7/enum.py", line 548, in __new__
    result = cls._missing_(value)
  File "/usr/local/lib/python3.7/enum.py", line 577, in _missing_
    raise ValueError("%r is not a valid %s" % (value, cls.__name__))
ValueError: 127 is not a valid EmberStatus

I'd like to help, but I don't have any clue of how bellow works.

Thanks

Francesco

@ffavero
Copy link
Author

ffavero commented Apr 4, 2020

Maybe the status:

EMBER_UNPROCESSED = 0x7F

Need to be added in the types (https://docs.silabs.com/zigbee/6.4/af_v2/group-status-codes)

@ffavero
Copy link
Author

ffavero commented Apr 4, 2020

I've tried to add the EmberStatus types:

NO_SECURITY = 0x7C
UNPROCESSED = 0x7F

And I got this error instead:

2020-04-04 10:51:56 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'40adb16d28cdd7b273a63a248067e2480b4e27abed31987402269c760381c0a7ebcddeca7effe7c08b2d6148b42389ec763ba5ea5b80846ac30bd8c6c88042c8254eb31fe4bb5d9a93da9f5b5dfec3d9d07b25b343835c31041e9e3e4dcc8baab9b0bbb3cf7e'
2020-04-04 10:51:56 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'8520dd7e'
2020-04-04 10:51:56 DEBUG (MainThread) [bellows.ezsp] Application frame 197 (gpepIncomingMessageHandler) received: b'7ce7c2002a3270012a3270019700000000ffffffffe0ffffffffff00000000a5f100201b5eff08c4f2002000000000002e02c5f28f2dcb7728f07ad42b4908fa2eded7df09970114c209000004111011121314151617226062636465666768'
2020-04-04 10:51:56 ERROR (MainThread) [homeassistant.core] Error doing job: Exception in callback ThreadsafeProxy.__getattr__.<locals>.func_wrapper.<locals>.check_result_wrapper() at /usr/local/lib/python3.7/site-packages/bellows/thread.py:99
ValueError: 255 is not a valid Bool
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.7/asyncio/events.py", line 88, in _run
self._context.run(self._callback, *self._args)
File "/usr/local/lib/python3.7/site-packages/bellows/thread.py", line 100, in check_result_wrapper
result = call()
File "/usr/local/lib/python3.7/site-packages/bellows/ezsp.py", line 221, in frame_received 
result, data = t.deserialize(data, schema)
File "/usr/local/lib/python3.7/site-packages/bellows/types/__init__.py", line 9, in deserialize
value, data = type_.deserialize(data)
File "/usr/local/lib/python3.7/site-packages/bellows/types/basic.py", line 10, in deserialize
r = cls(int.from_bytes(data[: cls._size], "little", signed=cls._signed))
File "/usr/local/lib/python3.7/enum.py", line 310, in __call__ 
return cls.__new__(cls, value)
File "/usr/local/lib/python3.7/enum.py", line 564, in __new__
raise exc
File "/usr/local/lib/python3.7/enum.py", line 548, in __new__
result = cls._missing_(value)
File "/usr/local/lib/python3.7/enum.py", line 577, in _missing_
raise ValueError("%r is not a valid %s" % (value, cls.__name__))
ValueError: 255 is not a valid Bool
2020-04-04 10:51:56 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'50adb16d2bccd6b273a63a248067e2480b4c23abed0d6e8bfdd79c760381c0a7ebcddeca7effe7c08b2d618c4623a9eb763ba5ed71825763d7beea7e'
2020-04-04 10:51:56 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'8610be7e'
2020-04-04 10:51:56 DEBUG (MainThread) [bellows.ezsp] Application frame 197 (gpepIncomingMessageHandler) received: b'7fe6c3002a3270012a3270019702040000c309000011ffffffffff00000000a5f100201b5eff08000000000700000007040016fb9b'
2020-04-04 10:51:56 DEBUG (MainThread) [bellows.zigbee.application] Received gpepIncomingMessageHandler frame with [<EmberStatus.UNPROCESSED: 127>, 230, 195, <EmberGpAddress gpdIeeeAddress=70:32:2a:01:70:32:2a:00 sourceId=67278593 applicationId=0 endpoint=0>, 195, 9, <Bool.false: 0>, <Bool.false: 0>, 4294967057, 255, 255, <EmberGpSinkListEntry type=0 sinkEUI=08:ff:5e:1b:20:00:f1:a5 sinkNodeId=0x0000>, b'']
2020-04-04 10:51:57 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'60adb16d2bcad1b273a63a248067e2480b4c23abed0a6e8bfdd39c760381c0a7ebcddeca7effe7c08b2d618c4623a9eb763ba5ed715db9c64835467e'
2020-04-04 10:51:57 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'87009f7e'
2020-04-04 10:51:57 DEBUG (MainThread) [bellows.ezsp] Application frame 197 (gpepIncomingMessageHandler) received: b'7fe0c4002a3270012a3270019702040000c409000015ffffffffff00000000a5f100201b5eff0800000000070000000704dff85e04'
2020-04-04 10:51:57 DEBUG (MainThread) [bellows.zigbee.application] Received gpepIncomingMessageHandler frame with [<EmberStatus.UNPROCESSED: 127>, 224, 196, <EmberGpAddress gpdIeeeAddress=70:32:2a:01:70:32:2a:00 sourceId=67278593 applicationId=0 endpoint=0>, 196, 9, <Bool.false: 0>, <Bool.false: 0>, 4294967061, 255, 255, <EmberGpSinkListEntry type=0 sinkEUI=08:ff:5e:1b:20:00:f1:a5 sinkNodeId=0x0000>, b'']
2020-04-04 10:52:01 DEBUG (MainThread) [bellows.ezsp] Send command nop: ()
2020-04-04 10:52:01 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'07b221ad14e27e'
2020-04-04 10:52:01 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'71b2a1ad6a967e'
2020-04-04 10:52:01 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'8070787e'
2020-04-04 10:52:01 DEBUG (MainThread) [bellows.ezsp] Application frame 5 (nop) received: b''

@zoic21
Copy link

zoic21 commented Nov 6, 2020

Hello,

I'am working on ZGP on zigpy through billows (elelabs key) but I got some weird frame :

[2020-11-06 12:17:21][DEBUG] : Application frame 197 (gpepIncomingMessageHandler) received: b'7fd33e00ab6a5001ab6a50012e020100003e04000013473e1291ff00'
[2020-11-06 12:17:21][ERROR] : Exception in callback ThreadsafeProxy.__getattr__.<locals>.func_wrapper.<locals>.check_result_wrapper() at /usr/local/lib/python3.7/dist-packages/bellows/thread.py:97
handle: <Handle ThreadsafeProxy.__getattr__.<locals>.func_wrapper.<locals>.check_result_wrapper() at /usr/local/lib/python3.7/dist-packages/bellows/thread.py:97>
Traceback (most recent call last):
  File "/usr/lib/python3.7/asyncio/events.py", line 88, in _run
    self._context.run(self._callback, *self._args)
  File "/usr/local/lib/python3.7/dist-packages/bellows/thread.py", line 98, in check_result_wrapper
    result = call()
  File "/usr/local/lib/python3.7/dist-packages/bellows/ezsp/__init__.py", line 230, in frame_received
    self._protocol(data)
  File "/usr/local/lib/python3.7/dist-packages/bellows/ezsp/protocol.py", line 124, in __call__
    result, data = self.types.deserialize(data, schema)
  File "/usr/local/lib/python3.7/dist-packages/bellows/types/__init__.py", line 9, in deserialize
    value, data = type_.deserialize(data)
  File "/usr/local/lib/python3.7/dist-packages/bellows/types/struct.py", line 197, in deserialize
    kwargs[field.name], data = field.concrete_type.deserialize(data)
  File "/usr/local/lib/python3.7/dist-packages/zigpy/types/basic.py", line 480, in deserialize
    item, data = cls._item_type.deserialize(data)
  File "/usr/local/lib/python3.7/dist-packages/zigpy/types/basic.py", line 53, in deserialize
    raise ValueError(f"Data is too short to contain {cls._size} bytes")
ValueError: Data is too short to contain 1 bytes

If I take in progress decode I got :
[<EmberStatus.undefined_0x7f: 127>, 211, 62, EmberGpAddress(gpdIeeeAddress=50:6a:ab:01:50:6a:ab:00, sourceId=16920065, applicationId=0, endpoint=0), 62, 4, <Bool.false: 0>, <Bool.false: 0>, 306071315, 145, 255]

It's stop on EmberGpSinkListEntry which is not in frame, and I got "EMBER_UNPROCESSED " status. I'll try to dig more but if anyone has any idea.

@Hedda
Copy link
Contributor

Hedda commented Feb 15, 2021

FYI, zoic21 have made progress with ZGP for zigpy and is requesting regression testing of his new pull request in zigpy/zigpy#656

Can someone can test with this code if all it's ok ? No side effect. If it I think we can merge this first step (after I fix coveralls).

That is, he is asking people do functional and non-functional tests to ensure that his patch does not break any existing functions. If it does not break anything obvious in zigpy then it could possible be merged 'as-is' even if ZGP might be be fully production ready.

@VVlasy
Copy link

VVlasy commented Feb 25, 2021

Any progress? I am currently looking at these switches as I like the batteryless operation

@Hedda
Copy link
Contributor

Hedda commented Mar 1, 2021

@VVlasy You can follow the progress of the PR in zigpy/zigpy#656 (and any reports from regression testing is still welcomed there).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants