Request: Ability to enable/disable a wlan through the rest interface

[trantoriana]

The ubiquiti allows a wlan to be disabled/enabled using something like:

POST
/api/s/default/rest/wlanconf/<WLAN ID>
payload: {enabled:false} or {enabled:true}

This functionality would be very beneficial to include in the package.

Thanks

[trantoriana]

The node-unifi library this node-red library utilizes already uses such a function:

**

• Disable/Enable wlan - disable_wlan()

• ---

• required parameter <wlan_id>
• required parameter = boolean; true disables the wlan, false enables it

*/
_self.disableWLan = function(sites, wlan_id, disable, cb)
{
var json = { enabled: disable == true ? false : true };

_self._request('/api/s/<SITE>/upd/wlanconf/' + wlan_id.trim(), json, sites, cb);

}

The portion in above request I do not get, should be "default" or something parameterized.
WLAN ID can be given as striing to the node rather theán discovered and selected.

Hope this is easy..

[Isaksson]

Hello.
I have now added support for disableWLan command, this is a special command and needs several arguments.
So to use this command send the command and arguments like this
msg.payload = { command: "disableWLan", wlan_id: "xxx", disable: false }; return msg;

I have also added a new command to get the wlan_id. Run command WLanSettings and use the _id from the result.

This is now pushed to Git will update on NPM

[Isaksson]

The new version is also pushed to NPM, please let me know how it goes when you have tried the new feature.

[trantoriana]

Hi Kristoffer,

This is excellent. I am in the process of setting up a new vm for my node-red stuff, so I will be able to test this within the next couple of days after I migrated everything.

Thanks for the quick reaction and implementation. This will help turning my guest wlan on and off based on a dashboard button or some other logic.

I will let know know as soon as possible.
Any plans for adding more functionality ?

Tran.

[Isaksson]

That sounds good.
I hope the migration goes as planned .

I do not have any timeline or so when I will add more functionality, do you have anything that you need just open a new issue and explain the command that you need, as long it is in the backend module then I could add it to this module.

[trantoriana]

Hi,

Migration kind of successful, just the normal problems associated with that.

I tested the WLanSettings command, and that works perfectly.

However, I have some trouble DISabling a wlan, when I construct a payload like:

msg.payload = {command:"disableWLan",wlan_id:"5a5a6860e4b073cbb84a0a45",disable:true};
return msg;

the node (which is set as WLanSettings) always goes in error like, the log shows following:

 ERROR: api.err.NoSiteContext

The reason for this is that the parent node-unifi library uses following to call the api:

 _self._request('/api/s/<SITE>/upd/wlanconf/' + wlan_id.trim(), json, sites, cb);

it seems clear that my site id is not <SITE>, but it is also not parameterized through the disableWlan function.

I replaced the <SITE> with the disable function with my site id, but still get the same error in the log.

Any ideas?

[Isaksson]

Let just make some things clear, the module is working when you use the GUI command WLanSettings?
then you just connect a Function Node with the code above and now the node does not work and gives you the error NoSiteContext?

I just made the exact same thing and it disable/enable my ssid
msg.payload = { command: "disableWLan", wlan_id: "53537caee4b0947d158fdf7e", disable: false }; return msg;

Do you use default site name?

[Isaksson]

And you still need to have the correct site name in the configuration for the unifi node, I get the same error if I change the site name in the configuration to a site name that I do not have.

[trantoriana]

Let just make some things clear, the module is working when you use the GUI command WLanSettings?

Correct

then you just connect a Function Node with the code above and now the node does not work and
gives you the error NoSiteContext?

Correct.

Oddly enough, also WLanSettings now stopped working with "ERROR: api.err.Invalid".
I removed and reinstalled, to no avail.

Hmm, did I break it somehow ?
Let me see how to fix this again.
Come back later..

[trantoriana]

Do you use default site name?
no, i do not.
But I added a new wlan definition in the default wlan group, and I was unable to disable that one also....

odd indeed.
For you it works in the default wlan group.. ? If I add my group name in the configuration, then it gets reverted back to default somehow.

[Isaksson]

Yes, it works in the default wlan group.
But i dont think that you really need the wlan group name.
Its the Site name that has to be correct.

Do you have the GUI commands up and running now?

[trantoriana]

It works again..

The flow I am using is following to test:

[{"id":"d752285e.27aaa8","type":"inject","z":"d1a7fc8a.5906d","name":"Info","topic":"","payload":"1","payloadType":"num","repeat":"","crontab":"","once":false,"x":430,"y":600,"wires":[["a0b5749f.5414b8"]]},{"id":"50c1b6f.1843a48","type":"debug","z":"d1a7fc8a.5906d","name":"","active":true,"console":"false","complete":"false","x":890,"y":600,"wires":[]},{"id":"34e31163.f71cce","type":"inject","z":"d1a7fc8a.5906d","name":"test wlan in default group : DISABLE","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"x":200,"y":660,"wires":[["95fc3b18.077ba8"]]},{"id":"95fc3b18.077ba8","type":"function","z":"d1a7fc8a.5906d","name":"DISABLE","func":"msg.payload = {command:"disableWLan",wlan_id:"5a5a6860e4b073cbb84a0a45",disable:true};\nreturn msg;","outputs":1,"noerr":0,"x":440,"y":660,"wires":[["a0b5749f.5414b8"]]},{"id":"a0b5749f.5414b8","type":"Unifi","z":"d1a7fc8a.5906d","name":"Access devices","ip":"10.50.1.32","port":8443,"site":"default","command":"110","x":660,"y":600,"wires":[["50c1b6f.1843a48"]]}]

[trantoriana]

If I change the site from default to my real site name in the config node, also the WLanSettings collecting goes on error.

If I go back and forth between my real site ID and the default one... the result is as follows:

default: wlansettings is OK, disableWlan errors
REALID: wlandsettings errors, disableWlan errors

perhaps I should revert to default site ? but that could crap up my whole installation potentially... family would not thank me that.

[Isaksson]

If you change the Site to a name that is not your site then the module will produce an error, and that is correct.
But do you still have issue with the disableWLan command?

[trantoriana]

see above (edited the previous post, and we crossed post)

[Isaksson]

I cant Import that flow so I cant test exact the same thing.
But what do you mean by add group name in configuration? that should not be added to any configuration.
Is there something that not is clear with the configuration of the module?

[trantoriana]

But what do you mean by add group name in configuration?
that should not be added to any configuration.

True, I mixed up site name with wlan group name..
I have a custom Site name and default has been removed. Also I have a custom wlan group, and no wlans in wlan group default.

Is there something that not is clear with the configuration of the module?

No, in the configuration I entered my custom site name.

[Isaksson]

That great, so now we know that you have the correct site name and that the module is working with GUI commands, but I still do not know if you still have problem with the custom command "disableWLan" and if you do, do you still get the same error as before api.err.NoSiteContext?

[Isaksson]

I created a new Wlan group and also a new Wireless Network in the new group, and I had no problems to enable/disable that network so there is no problem with not uring the default Wlan group.
I did not have to change anything except a new wlan_id for that new Network

[trantoriana]

The situation is odd and it has to do with the way the node treats the site name.

I have one working flow consisting of a timestamp injector into a unifi node with default site and wlansettings and a debug node. When starting this flow all goes well.

However, when I copy the above flow, the copied flow stops working with error:

ERROR: api.err.Invalid

No matter what I do, I am unable to create a second flow with a unifi node which does not give me an error..

Also, the moment, I enter my site name in the unifi node, run it (and it error), the sitename in the unifi node is changed automatically back to default on edit. After that it stops working at all.

[Isaksson]

Okey, but if you reuse the first node and just add a function node in between and send
msg.payload = {command:"disableWLan",wlan_id:"5a5a6860e4b073cbb84a0a45",disable:true}; return msg;
Then it works I guess?

[trantoriana]

nope, that does not work then.

For now even working unifi nodes stopped working and result in the same error.
I will restart the unifi controller itself, perhaps that one got screwed up.

[Isaksson]

I think you maybe should restart the node-red, I have never seen any issues to the controller that needed a reboot.
I am now testing the module and I am using four instances and trigger them at the same time from the same Inject node and no issues here, but then we should know that I am using the default site name.

[Isaksson]

[trantoriana]

one mystery solved. lastpass was messing with my password in the credentials every time I edited the unifi node. That at least explains the problems with the node stopping working in between site name edits.

Too silly...

I will recheck my original flow

[Isaksson]

Ahh, yes the browser and plugins could sometimes make the most strange things :)

Run some more tests and let me know how it goes, Its late here now and I will check in here again tomorrow.

[trantoriana]

sure, I might just try moving my wlan config to the default site. Unifi controller runs on proxmox so that should not be an issue.

It is late here also (europe). Good night and thanks for your help.

[trantoriana]

I must shamefully admit that the problems most likely are all related to my very bad javascript voodo.
I created following test flow:

The node has default as side name, and the command is set to "WLanSettings".
The code in the function is this:

          msg.payload = {command:"WLanSettings"};
          return msg;

As I understand things, both methods should have equal result.
If I run the unifi node as configured by triggering INFO I get a nice debug object with all WLANS defined on the unifi.

If I try to get the same info using the function node, with above payload setting, I always get an error.

My mistake must therefor in providing some bad json from the javascript node.

Can you look at my function code and provide me with a correct payload ?
I am sure that is the root of my problem.... my code :-)

[trantoriana]

One minor addition, once the unifi node has errored, any next run (even the correct invocation using the INFO trigger) will error. This error stays until the whole flow is redeployed...

(While this behavior might be more related to the underlying node-unifi or deeper, it still makes test problematic)

[Isaksson]

You are doing everything correct, for some reason i called it WlanConf in the code, thats why you get error with that code. I will change it in the code so that it match the information :)

I just verified with two different payload commands, one that is working and one that gives error, no problem to send the correct one after the one that produces error, so in my tests it works as it should.
Need lite more info to try to reproduce that error.

[Isaksson]

So now I use the correct name :)

Here is a simple flow that i used to verify that the nodes goes OK after Error. Just connect this to your Unifi module. 1 will get ok and 0 will produce Error and then click 1 again and if it works as it should then the Unifi module should go into Ok again.

[{"id":"8e9c4833.cf5018","type":"inject","z":"7ed3a4f4.438a8c","name":"","topic":"","payload":"1","payloadType":"num","repeat":"","crontab":"","once":false,"x":368,"y":234,"wires":[["7d32237c.a322ec"]]},{"id":"7d32237c.a322ec","type":"function","z":"7ed3a4f4.438a8c","name":"","func":" if (msg.payload === 1){\n msg.payload = {command:\"WLanSettings\"};\n } else {\n msg.payload = {command:\"SitesStats1\"}; \n }\nreturn msg;","outputs":1,"noerr":0,"x":557,"y":277,"wires":[["f97a0475.eca578"]]},{"id":"82bd82a7.290b8","type":"inject","z":"7ed3a4f4.438a8c","name":"","topic":"","payload":"0","payloadType":"num","repeat":"","crontab":"","once":false,"x":369,"y":325,"wires":[["7d32237c.a322ec"]]}]

[trantoriana]

Ok, with WLanConf my function node works.

Using your above flow, the state of the unifi node indeed toggles between ok and error...

[trantoriana]

However, the unifi node which has a command set within as WLanSettings will not go back to OK after an error.

[trantoriana]

I added some logging in the node js, and the error now actually is:

ERROR: api.err.NoPermission

And indeed, I am using a read-only user in unifi.
Let me use a different user and let you know.

[trantoriana]

And indeed.... a read-only user has not privilege to disable a wlan... duh

[trantoriana]

let me test this with my real wlans, and I will let you know.

[Isaksson]

Ahh, then it works as it should, good that a read only cant change the configuration :)

[trantoriana]

Hi Kristoffer,

It works now as expected, thanks for providing this.

A couple of observations which might be added to the documentation as some point:

*) Unifi controller user must have at least 'administrator' rights (not read-only)
*) Controlling the node function through the input payload always seems the more reliable way (especially ones errors already have happened)
*) WLanSettings works with both default and custom unifi sites, it shows all available WLAN definitions across sites
*) disableWLan works with both default and custom unifi sites, it works on WLAN definitions across sites
*) Disabling or enabling a wlan kicks of a new provisioning of the AP's in the network, as such all connected devices will loose connectivity for a short period as result

A suggestion if possible. Rather then setting a node just to 'Error' in case of error, perhaps show the error message coming from the unifi-node as node status or in the debug window. This will give a clearer indication why the error occurred and fixing will be easier.

With this I thing this issue can be closed.

[Isaksson]

Thanks for the feedback.