Implement new zigpy radio API #97
Conversation
puddly
force-pushed
the
puddly/new-radio-settings-api
branch
from
19088d2 to
53150fd
Compare
puddly
force-pushed
the
puddly/new-radio-settings-api
branch
from
53150fd to
3ee8c2c
Compare
|
Hello @puddly, I tried to use the new radio API and last on the same conclusion as @pipiche38, I didn't succeeded in putting the pieces together.
Any idea what I missed? I'm still a beginner. I don't see the possibility to form a new network through an option of start_network(), should form_network() called directly ? |
The API hasn't really changed. You still use it the way you did before, you just need to install the "new radio API" branches of zigpy-znp and zigpy. In theory, nothing will change.
Pass |
It really a shame, we had a working environment and this small changes as you say, make the think not working anymore. I'm not sure this is a comminissioning issue, as the Coordinator works very well with the old radio API |
|
@puddly you should guess that if everything was working like before, we won't be there :) The startup from zigpy is not calling connect() so we have to call it first ? |
|
No, that's a regression. I will re-add it to zigpy's startup. |
|
I had to add a try/except on the call of await self._znp.start_network() in application.py or the function was not ending properly. |
@puddly, can you tell us, how is the standard framework, because I'm struggling that we are facing this issue and you not, no may be we are doing it correctly. Better than we use the same approach to avoid future issues |
|
Asked in zigpy/zigpy-zigate#117 if using puddly's new radio API repo branches for zigpy, zigpy-znp, zigpy-cli, and zigpy-zigate(?): https://github.com/puddly/zigpy/tree/puddly/new-radio-settings-api https://github.com/puddly/zigpy-znp/tree/puddly/new-radio-settings-api https://github.com/puddly/zigpy-cli/tree/puddly/zigpy-radio-api https://github.com/puddly/zigpy-zigate/tree/puddly/new-radio-api They are all updated so need to install those modified versions of zigpy and zigpy-znp from those branches to test new radio API: # May need to uninstall zigpy, zigpy-znp, zigpy-cli, and zigpy-zigate first
pip install \
git+https://github.com/puddly/zigpy.git@puddly/new-radio-settings-api \
git+https://github.com/puddly/zigpy-znp.git@puddly/new-radio-settings-api \
git+https://github.com/puddly/zigpy-cli.git@puddly/zigpy-radio-api \
git+https://github.com/puddly/zigpy-zigate.git@puddly/new-radio-apiAs mentioned may need to first uninstall all of them before installing the modified versions of them from puddly's repo branches. |
|
Hello Hedda,
Our concern is why only us met the problem? How the modification are tested and in which condition, that'll help. |
|
@puddly, we are trying to test your PRs by taking your repository for zigpy and zigpy-znp on the new-radio-api branche, but somehow the results are cahotic, which means sometime it works some other time it doesn't @deufo has identified that the start_network () fails time to time by just adding a try/except on line 183 - encapsulate the start_network()
So for now, we cannot even think to test zigpy-zigate. can you help us on this ? |
|
basically here is the change which makes our plugin working |
|
I will take a look at this later next week. |
|
Puddly, While testing zigpy (new radio-API and the znp/new-radio-api from your repository), I still get Timeout when requesting a permit to join to a particular router |
|
Looks like it works fine: 2022-06-16 14:50:25,779 DEBUG :Sending request: ZDO.MgmtPermitJoinReq.Req(AddrMode=<AddrMode.NWK: 2>, Dst=0x96BE, Duration=240, TCSignificance=0)
2022-06-16 14:50:25,792 DEBUG :Received command: ZDO.MgmtPermitJoinReq.Rsp(Status=<Status.SUCCESS: 0>)
2022-06-16 14:50:25,837 DEBUG :Received command: ZDO.MgmtPermitJoinRsp.Callback(Src=0x96BE, Status=<Status.SUCCESS: 0>)I also can't replicate the problem with ZHA. How are you permitting joins through a specific router? |
|
yes, it does work, however there is a TimeOut which is rise and it looks like until the timout is issue commands are just queuing So we don't get return from the self.app.permit(time_s=duration, node=target) call |
|
I believe the Timeout is triggered by the zigpy lib; can it be related to Don't know much your code, but is this test not the issue, as in that case, I do see that we setup a Callback_rsp as node != self.ieee and time_s != 0
|
|
I've added some extra logging to ZHA and everything is working as intended: # Before call to `permit(node=...)`
2022-06-16 13:51:29 INFO (MainThread) [homeassistant.components.zha.api] Permitting joins through cc:cc:cc:ff:fe:e6:8e:ca for 60s...
2022-06-16 13:51:29 INFO (MainThread) [zigpy_znp.zigbee.application] Permitting joins for 60 seconds
2022-06-16 13:51:29 DEBUG (MainThread) [zigpy.application] Sending 'mgmt_permit_joining_req' to cc:cc:cc:ff:fe:e6:8e:ca
2022-06-16 13:51:29 INFO (MainThread) [zigpy.zdo] Sending ZDOCmd.Mgmt_Permit_Joining_req (60, 0)
2022-06-16 13:51:29 INFO (MainThread) [zigpy.device] Sending profile, cluster, src_ep, dst_ep, sequence, data = (0, <ZDOCmd.Mgmt_Permit_Joining_req: 0x0036>, 0, 0, 12, b'\x0c<\x00') with seq=<zigpy.util.Request object at 0x10eaf5660>
2022-06-16 13:51:29 DEBUG (MainThread) [zigpy_znp.api] Sending request: ZDO.ExtRouteChk.Req(Dst=0x1B94, RtStatus=<RouteStatus.ACTIVE: 1>, Options=<RouteOptions.NO_ROUTE_CACHE|MTO_ROUTE: 3>)
2022-06-16 13:51:29 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.ExtRouteChk.Rsp(Status=<RoutingStatus.SUCCESS: 0>)
2022-06-16 13:51:29 DEBUG (MainThread) [zigpy_znp.api] Sending request: ZDO.MgmtPermitJoinReq.Req(AddrMode=<AddrMode.NWK: 2>, Dst=0x1B94, Duration=60, TCSignificance=0)
2022-06-16 13:51:29 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.MgmtPermitJoinReq.Rsp(Status=<Status.SUCCESS: 0>)
2022-06-16 13:51:29 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.MgmtPermitJoinRsp.Callback(Src=0x1B94, Status=<Status.SUCCESS: 0>)
2022-06-16 13:51:29 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.MsgCbIncoming.Callback(Src=0x1B94, IsBroadcast=<Bool.false: 0>, ClusterId=32822, SecurityUse=0, TSN=3, MacDst=0x0000, Data=b'\x00')
2022-06-16 13:51:29 DEBUG (MainThread) [zigpy_znp.api] Sending request: AF.DataRequestExt.Req(DstAddrModeAddress=AddrModeAddress(mode=<AddrMode.NWK: 2>, address=0x1B94), DstEndpoint=0, DstPanId=0x0000, SrcEndpoint=0, ClusterId=54, TSN=12, Options=<TransmitOptions.SUPPRESS_ROUTE_DISC_NETWORK|ACK_REQUEST: 48>, Radius=30, Data=b'\x0C\x3C\x00')
2022-06-16 13:51:29 INFO (MainThread) [zigpy.device] Received hdr args {'_command_id': <ZDOCmd.Mgmt_Permit_Joining_rsp: 0x8036>, '_tsn': 3} [<Status.SUCCESS: 0>] pending {12: <zigpy.util.Request object at 0x10eaf5660>}
2022-06-16 13:51:29 DEBUG (MainThread) [zigpy.zdo] [0x1b94:zdo] ZDO request ZDOCmd.Mgmt_Permit_Joining_rsp: [<Status.SUCCESS: 0>]
2022-06-16 13:51:29 DEBUG (MainThread) [zigpy.zdo] [0x1b94:zdo] No handler for ZDO request:ZDOCmd.Mgmt_Permit_Joining_rsp([<Status.SUCCESS: 0>])
2022-06-16 13:51:29 DEBUG (MainThread) [zigpy_znp.api] Received command: AF.DataRequestExt.Rsp(Status=<Status.SUCCESS: 0>)
2022-06-16 13:51:29 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.MgmtPermitJoinRsp.Callback(Src=0x1B94, Status=<Status.SUCCESS: 0>)
2022-06-16 13:51:29 DEBUG (MainThread) [zigpy_znp.api] Command was not handled
2022-06-16 13:51:29 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.MsgCbIncoming.Callback(Src=0x1B94, IsBroadcast=<Bool.false: 0>, ClusterId=32822, SecurityUse=0, TSN=12, MacDst=0x0000, Data=b'\x00')
2022-06-16 13:51:29 INFO (MainThread) [zigpy.device] Received hdr args {'_command_id': <ZDOCmd.Mgmt_Permit_Joining_rsp: 0x8036>, '_tsn': 12} [<Status.SUCCESS: 0>] pending {12: <zigpy.util.Request object at 0x10eaf5660>}
2022-06-16 13:51:29 INFO (MainThread) [zigpy.device] Resolving request 12 with [<Status.SUCCESS: 0>]
2022-06-16 13:51:29 DEBUG (MainThread) [zigpy.application] Sent 'mgmt_permit_joining_req' to cc:cc:cc:ff:fe:e6:8e:ca: [<Status.SUCCESS: 0>]
# After call to `permit(node=...)`
2022-06-16 13:51:29 INFO (MainThread) [homeassistant.components.zha.api] Successfully permitted joins through cc:cc:cc:ff:fe:e6:8e:ca for 60sWhat exact coordinator and firmware are you using? |
|
Yes the Permit to join work and I'm able to pair devices, however the permit call is not returning until it's timeout which them create some side effect in our environment. The problem occured with new-radio-API or not only on ZNP (not on bellows, not on deconz) with Firmware is 20220219 |
This is what I'm unable to replicate. I'm also using a ZZH with the same firmware. |
I'm glad for you, but how should I debug it ? all is in the zigpy layers as it never returns from the call and that is the zigpy async timeout which is triggered! |
|
Here is the stack trace when the Timeout is issued Here is global permit to join which do not trigger timeout Now is the Permit to join to a specific router Last I see a strange behaviour while sniffing the trafic as I see 2 Permit to join sent !!
|
Codecov Report
@@ Coverage Diff @@
## dev #97 +/- ##
=======================================
Coverage 98.59% 98.60%
=======================================
Files 44 43 -1
Lines 3916 3863 -53
=======================================
- Hits 3861 3809 -52
+ Misses 55 54 -1
Continue to review full report at Codecov.
|
Implements zigpy/zigpy#848.
Unit tests for zigpy-znp pass locally.