hi,
i noticed that the ZDP response to the Mgmt_NWK_update_req request did not contain the EDScan_t values as expected. (BitCloud 1.10)
But they will be reported in the ZDO_MgmtNwkUpdateNotf() callback after ZDP response was received. I don't know if this is a bug, but it would be more easier to have the scan results in the ZDP response itself(also to know from what remote device do they come).
i noticed that the ZDP response to the Mgmt_NWK_update_req request did not contain the EDScan_t values as expected.
If you need ED scan results then use API designed to perform it: NWK_EDScanReq()
If you need ED scan results then use API designed to perform it: NWK_EDScanReq()
It is not expected at all.
I think what u refer to is the Mgmt_NWK_Update_notify (0x8038) which could be fired without a previous request, but could also act as response to the above Mgmt_NWK_update_req.
Since BitCloud did respond to the request i think i works it's just a bit strange to not see the data in the ZDP response callback.
It is :-)
according to the standard the Mgmt_NWK_update_req (0x0038) could also be used to
this does nothing here, but after Mgmt_Leave_req the new channel mask is used
Since BitCloud did respond to the request i think i works it's just a bit strange to not see the data in the ZDP response callback.
Again, there is no Mgmt_NWK_update_rsp.
The only difference from the current specification is that scan results are always sent to the network manager, but in case of scan request they should be sent to the requesting device, but I think this change appeared recently in the specification.
What version of standard it is? Mine (053474r19ZB_CSG-ZigBee-Specification.pdf) does not have such statements. There is no Mgmt_NWK_update_rsp defined anyway.
Right, there is no explicit Mgmt_NWK_update_rsp but have a look into Mgmt_NWK_update_notify (cluster 0x8038) this is not just a notify, it's also the reponse to Mgmt_NWK_update_req (cluster 0x0038).
This is described in the "2.4.4.3.9.1 When Generated Section".
When sent in response to a Mgmt_NWK_Update_req command the status field shall represent the status of the request. When sent unsolicited the status field shall be set to SUCCESS.
It will after a timeout returned by NWK_GetBroadcastDeliveryTime().
Cool, thanks I didn't know that.
this is not just a notify, it's also the reponse to Mgmt_NWK_update_req (cluster 0x0038).
ED scan may take a lot of time, any reasonable timeout will expire long before response will be ready.
When sent in response to a Mgmt_NWK_Update_req command the status field shall represent the status of the request. When sent unsolicited the status field shall be set to SUCCESS.
Interesting stuff thanks for information! Makes sense to me now.
On more question to topic: since the recent changes to the standard, in the current bitcloud version these notifications will always be sent to the network manager so a individual device should not fire such request?
On more question to topic: since the recent changes to the standard, in the current bitcloud version these notifications will always be sent to the network manager so a individual device should not fire such request?
So it does not make much sense to send those commands. Most of the ZDO commands were invented long time ago and now are obsoleted and there is no real use for them, but they don't want to remove them from the specification for various reason (mostly - there are better things to do and no one will use those commands since they don't work anyway :) ).
