Subflow parameters not being substituted

I am struggling with a problem that a node-red-contrib-pid user has posted against the node.

He is using the node in a subflow and using subflow properties to set the node properties. The problem is that some of the properties are not getting substituted, but are being picked up by the node as, for example, "${ENABLE}" instead of the value entered in the subflow settings. I have generated a debug version of the node that copies the config values into the payload, which he has installed, and it is showing
Other config params such as ti and pb are picked up correctly. I suspect there is some randomness as to which params are not substituted, but not certain yet.

He has exported the subflow instance and when I import it it works correctly for me, all params are substituted, so it is not a simple typo or similar problem.

He is using node red in Home Assistant, but that should not make any difference, though it does complicate things a bit.

Has anyone ever seen anything like this before? Or have any suggestions what might be happening, or what I can do to diagnose it further. I am waiting for a startup log.

The OP is using node red 3.1.0, but the release notes don't suggest any fixes that directly address the problem here.

I'm certain there was an issue with 3.1.0

Release 3.1.1: Maintenace Release · node-red/node-red · GitHub -
Fix env evaluation when one env references another in the same object (#4361)

(Sorry I didn't follow the full issue so may not be relevant, but, as you are not seeing the issue but a user on 3.1.0 is, I'd probably ask the user to upgrade.)

I have done, but unfortunately it appears that 3.1.0 is the latest version of the HA addon.

Does anyone know whether, with the HA node red addon, one can locally install node-red from a shell within the container, to override the one that comes with the addon. I know it is possible to manually install nodes in that way, as that is how the user has installed the pid addon direct from github, to get my debug branch.

I have downgraded one of my systems to node red 3.1.0 and confirmed that I see the same problem. So it is a bug in 3.1.0 which has been fixed in 3.1.3