Light control server: Potential bug when turning off

[Chris_Dev]

Good day,

I am currently using NCS V3.1.1 and nrf52840 devices.

We are making use of the light control server model and a ambient lux sensor device.

I do have the following enabled in my prj.conf:

CONFIG_BT_MESH_LIGHT_CTRL_SRV_REG=y
CONFIG_BT_MESH_LIGHT_CTRL_REG_SPEC=y

I have noticed some odd behaviour in the light control server regulator when trying to turn the light off.

To reproduce:

Set the run and prolong lux to some values like 150 and 50 with run time of 60 seconds and a prolong time of 5 seconds.

Send a Light on/off = On with the Light Controller enabled

The PI regulator will run until the desired lux level is reached (within the set error bound)

After a while send a Light on/off = Off. The light takes a very long time to turn off. It does not immediately turn off. The time it takes to turn off seems to depend on the Kp and Ki values configured in the property IDs. 

According to the MshMDLv1.0.1.pdf, table 6.51 specifies that when you are in an off state, the Lightness Out Formula is 0. It should not be dependent on what is currently stored in the regulator.... If you use high Ki values, then the light ramps down very fast (as expected). So seems like it could be integral error winding up, I am not 100% sure.

Not sure if I am misunderstanding something here or in the specification...

I would be happy to get some feedback on this potential issue. Please let me know if I can provide more information or have not explained the problem clearly enough. Happy to provide more information.

Thanks in advance!

[tesc]

Hi,

I do have a couple of questions, for clarity:

1. What device/app/other are you using for configuring and sending messages to the LC device, and what messages are you sending (or what exactly are you doing in the interface of the app etc.)
2. Can you quantify the time taken for the light to turn off and on? (I.e. number of seconds, instead of "very long time".) Preferably also what time you expect, in addition to what time you observe, for both turning off and on.

Regards,
Terje

[Chris_Dev]

Good day. 

Thank you for getting back to me.

1. We have a proprietary solution which consists of a frontend and backend which communicates with a mesh device to send data out over the air. Essentially, we use the messages provided by NCS client models:

Setting LC properties - bt_mesh_light_ctrl_cli_prop_set()

Setting controller coefficients is a bit different, for that we use - bt_mesh_light_ctrl_cli_coeff_set

LC On/Off set message (so that you don't turn off the controller when turning the light on and off) - bt_mesh_light_ctrl_cli_light_onoff_set


2. Well it depends on what lux values you receive from your sensor node... Sometimes it takes up to 5 minutes (without real lux values i.e. the sensor is not observing the true lux, it's just place somewhere random).....

In any event, I am expecting to see the light turn off immediately if you send a Light on/off = OFF message. According to the specification..... It does not matter what your run/prolong/standby values are. Also, this should not be dependent on the PI control loop, according to my understanding at least. Instead of the light turning off immediately, the controller regulates down to 0 eventually.

Hope this helps?

Apologies for taking so long to reply.

Regards

[tesc]

Hi,

I am sorry for the delay from my end as well. I do not find the Mesh Model Specification to be the easiest document to understand.

Now, if you have a look at figures 6.6 and 6.7, as well as read section 6.2.5.1 Light LC State Machine states, I think you will find that the Off state is for disabling the controller, while the state set when receiving an OnOff messages is Fade Standby Manual. The timing value for the Lightness Out state then becomes Light LC Lightness Standby - Timer / Transition Time * (Light LC Lightness Standby – Initial Lightness).

In other words, when receiving an OnOff message, the light should not immediately turn off, but rather fade according to certain timer settings. There might of course be more to it, but as far as I can tell our implementation seems to show the correct behavior according to the Mesh Model specification.

Regards,
Terje