PMP450 cnMaestro scripts no longer work after upgrading to 16.0.0.1

Products PMP
1

Wondering if anyone else has seen this.  We recently upgraded a sector to 16.0.0.1 for testing prior to rolling it out to our entire network.  The firmware seems to run well, except scripts don't seem to work from cnMaestro.  I know a few script names changed, so I started over from scratch using an existing radio on 16.0.0.1 as a template.

One example is location

{

    "userParameters":  {

        "location":  {

        "siteName": "${SITE_NAME=CustomerName-CITY-Cambium}",
        "siteInfoViewable": 0,
        "siteContact": "${SITE_CONTACT=NAME_PHONENUMBER}",
        "siteLocation": "${SITE_ADDRESS}",
        "height": ${ANTENNA_HEIGHT}
},

None of these have changed since prior to 16.0.0.1.  But when I push this config to a unit running 16.0.0.1, it sets the siteContact, siteLocation, and heigth.  However siteName does not get applied and remains what it was.

A second example is QoS Settings.  These did have some chagne names, new ones added, etc.  So I updated my JSON script to this:

"qosConfig": {
    "uplinkBurstAllocation": 0,
    "largeVCQ": 0,
     "prioritizeTcpAck": 1,
    "sustainedUplinkDataRate": ${UPLOAD_IN_Kbp},

    "sustainedDownlinkDataRate": ${DOWNLOAD_IN_Kbps},
    "downlinkBurstAllocation": 0,
    "maxDownlinkDataRate": 0,
    "maxUplinkDataRate": 0
},

"smQosConfig": {
"highPriorityDownlinkCIR": 0,
"mediumPriorityDownlinkCIR": 0,
"smPrioritizationGroup": 0,
"dataChannelCount": 1,
"ultraHighPriorityDownlinkCIR": 0,
"mediumPriorityUplinkCIR": 0,
"ultraHighPriorityUplinkCIR": 0,
"highPriorityUplinkCIR": 0,
"lowPriorityDownlinkCIR": 0,
"lowPriorityUplinkCIR": 0,
"highPriorityChannel": 1,
"bCastMIRUnits": 0,
"bCastMIR": 0
},

Before I only set highpriorityCIR and lowpriorityCIR under smQoSConfig.  However after upgrading to 16.0.0.1 it would no longer push the qosConfig:{sustainedUplinkDataRate}.  Once I added in all of the smQoSConfig from the active unit without changing anything under qosConfig, it now sets those two values.  However, even though the script sets dataChannelCount:1, after the scrip pushes the radio reboots and still is configured for two data channels.

Going to keep beating it into a brick wall, but hoping someone has seen it and knows a quick fix.

2

Hi Brian,

Regarding site name, if you have a name set for the device in the cnMaestro device configuration page, that value will be used when pushing configuration.  This may be why the name is not getting updated properly.  The same is true for height, but if you've never set it using the UI it may be why it does get changed.

We are looking into the QoS issue.

3

Don't know if this is relevant, but when onboarding a device, I cannot set the device name to xxx-xxx.  Can't use spaces or special charracters.  Once the unit is onboarded, I can set the name to whatever format I wish.  

Brian, try removing the dashes, as a test, and see if that works.

Again, may not be relevant, but a place to start?  Things that make you go hmmm!

Jordan, are you saying cnMaestro is designed to specifically ignore "siteName": "${SITE_NAME=CustomerName-CITY-Cambium}" designation and instead uses whatever was/is "stored" for Device Name?

Why would the program intentionally override any information I am specifically wishing to update?  I can see performing syntax validation and if something is incorrect not using that info, but I can't understand intentionally overriding/ignoring a change I'm trying to implement.

1 Like
4

Luis, we are aware of the inconsistency between pre and post onboarding name validation and have an open bug against it.

Regarding siteName, the intention is to preserve the name entered in the UI during or after onboarding and prevent it getting set to a generic value if siteName was left in a template with a static value.  Since there are dedicated fields specifically for Device Name we lean towards using that value.  There's also a bit of extra handling for updating the UI.  This field also lets us include siteName in configuration pushes which allows keeping cnMaestro and a device in sync in case it was offline when the name was changed.

I'm interested to hear your thoughts on this.  Can you list out a workflow that could lead to a conflict like this?  We're always looking to improve cnMaestro to better fulfill your needs.

1 Like
5

I had actually opened ticket #143460 last year about the site name not changing with a template push. I discovered I could set the name once, but then it changes back if I keep trying to apply a new name with a cnMaestro template variable. I was told the following:

"Site name can't be configured from cnMaestro configuration push. It is as per design and it will not work for both PMP 450 & PMP 450b devices.As per design, priority is for device details (device name) rather than one being set in template. You have to configure it from device configuration page "

I guess from our point of view if you are going to introduce this type of abritrary change in behavior for the SM name, you should make this heavily documented with disclaimers. The SNMP Site Name field on the SM is what we have used for the entire duration of the PMP product line, but now you are essentially forcing us to use the cnMaestro name field, instead of just pulling the info from the SM like you do with every other key:value. In our opinion, the behavior should be consistent for every SNMP field on the SM, and we would like to be able to change the site name with a template variable and have cnMaestro pull the name from the SM SNMP Site Name field, but that's just our opinion.

If going forward you are going to enforce using the name from cnMaestro, you might as well just remove the configurable field for the SNMP 'Site Name' from the SM software. 

1 Like
6

@jordan as for a workflow examle, I have a high tier and low tier QOS template exactly like Brian does with variables for each of the 3 SM SNMP fields for 'site name', 'site contact', and 'site location'. If a customer moved out and I wanted to change the configuration on the SM, I would expect to be able to just use my QOS template that prompts for the new contact, address, and SM name. But instead I not only have to apply my template, but then go through an extra step of changing the name in the cnMaestro UI, since you are forcing the cnMaestro name rather the SNMP 'Site Name'.

7

The name/location field has been working great for me, up until the last firmware upgrade.  I'm not sure if it's from the equipment firmware 16.0.0.1 or the cnMaestro server version.  We upgrade both right at the same time.  I have found the same thing where location seems to be ignored by cnMaestro now, or it's just overridden.

I thought I had my tempalte working by adding "smQoSConfig" prior to "QosConfig".  My three scripts, one data only, one voice QoS for a 450M, and one voice QoS for 450i.  I can push all three to my test unit at my house and it updates no problem.  We just installed another 450b, and it won't accept any of them.  It reboots like it takes the config and comes back with not one value set.  I'm guessing it has to be an ordering thing, where if I have it manually set up the file gets through but out of the box something is missing...   I've opended a ticket with Cambium but no response now for some time.