[BitCloud] Mgmt_NWK_update_req

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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).

Last Edited: Fri. Oct 16, 2015 - 02:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

manuelp wrote:
i noticed that the ZDP response to the Mgmt_NWK_update_req request did not contain the EDScan_t values as expected.
It is not expected at all. Update request should be used by the node if it detects some problems with the network (probably RF interference) to inform network manager about such problems.

If you need ED scan results then use API designed to perform it: NWK_EDScanReq()

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

If you need ED scan results then use API designed to perform it: NWK_EDScanReq()

Yes but this works only local.

Quote:
It is not expected at all.

It is :-)
according to the standard the Mgmt_NWK_update_req (0x0038) could also be used to i) get ED-Scan results from a remote device (scanDuration set to 0-5 for this),
ii) to change the channel (scanDuration set to 0xfe) ... this does nothing here, but after Mgmt_Leave_req the new channel mask is used :),
iii) change apsChannelMask & nwkManagerAddr (scanDuration set to 0xff) works fine.

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

manuelp wrote:
It is :-)
according to the standard the Mgmt_NWK_update_req (0x0038) could also be used to
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.

manuelp wrote:
this does nothing here, but after Mgmt_Leave_req the new channel mask is used

It will after a timeout returned by NWK_GetBroadcastDeliveryTime().

manuelp wrote:
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.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
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.

Mine is the public 1_053474r17ZB_TSC-ZigBee-Specification.pdf from zigbee.org.

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".

Quote:
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.

Quote:

It will after a timeout returned by NWK_GetBroadcastDeliveryTime().

Cool, thanks I didn't know that.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

manuelp wrote:
this is not just a notify, it's also the reponse to Mgmt_NWK_update_req (cluster 0x0038).
It is sent in response, but it is not a response. Response callback for the Mgmt_NWK_Update_req is called right after the command is sent, this command does not assume any kind of explicit response.

ED scan may take a lot of time, any reasonable timeout will expire long before response will be ready.

manuelp wrote:
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.
Exactly this way stack behaves currently.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

manuelp wrote:
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?
Network manager is combined by default with the coordinator, so it will receive all such notifications. Even new version of the specification requires to send notification to the requesting device, but it is not something that can be done easily, so I don't expect this to be implemented any time soon (especially given that commands are optional).

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 :) ).

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.