Use environment variables to configure the ports used by chip-tool

[vivien-apple]

Problem

chip-tool ask the user to configure the port to send messages. This default probably does not need to change much.

Also in some situations it is useful to configure the port used by chip-tool to listen messages. For example if you run both the chip-tool client application and an instance of the chip-app-server on the same machine.

If you do not configure them, both try to listen on the same port, and so chip-tool sends messages to itself...

Summary of Changes

• Add CHIP_TOOL_REMOTE_PORT environment variable
• Add CHIP_TOOL_LOCAL_PORT environment variable
• Rename CHIP_LOG_PROGRESS to CHIP_TOOL_LOG_PROGRESS
• Do not ask anymore the chip-tool users to type in the port if they use the default one.
• Update the documentation in case someone needs to override ports.

[mspang]

Can we use command line options instead?

[mspang]

Would prefer not to use environment variables for this as it's a support burden (it sweeps the option under the rug, where it can affect unintended processes - say you run more than one chip-tool as part of a test).

[gerickson]

Would prefer not to use environment variables for this as it's a support burden (it sweeps the option under the rug, where it can affect unintended processes - say you run more than one chip-tool as part of a test).

+1

[vivien-apple]

Would prefer not to use environment variables for this as it's a support burden (it sweeps the option under the rug, where it can affect unintended processes - say you run more than one chip-tool as part of a test).

This case is fine if you use the env variable on the same line as the command. The scope of the variable will not affect the shell. For example CHIP_TOOL_REMOTE_PORT=11098 chip-tool onoff on ::1 1 will run without changing the value of the remote port for following commands.

That said, I understand your point and a command line options would be way much better. The real issue is that chip-tool has grown without true command line parsing facility and is a bit dumb at the moment when it comes to command arguments...

@mspang Would you be fine with a followup to fix the real issue. It may take some time to reformat chip-tool to support it and I would like to move forward in the meantime.

[rwalker-apple]

Would prefer not to use environment variables for this as it's a support burden (it sweeps the option under the rug, where it can affect unintended processes - say you run more than one chip-tool as part of a test).

+1

[rwalker-apple]

approving with the assumption that this will get a real fix soon

[mspang]

Would prefer not to use environment variables for this as it's a support burden (it sweeps the option under the rug, where it can affect unintended processes - say you run more than one chip-tool as part of a test).

This case is fine if you use the env variable on the same line as the command. The scope of the variable will not affect the shell. For example CHIP_TOOL_REMOTE_PORT=11098 chip-tool onoff on ::1 1 will run without changing the value of the remote port for following commands.

That said, I understand your point and a command line options would be way much better. The real issue is that chip-tool has grown without true command line parsing facility and is a bit dumb at the moment when it comes to command arguments...

@mspang Would you be fine with a followup to fix the real issue. It may take some time to reformat chip-tool to support it and I would like to move forward in the meantime.

Ok (Sorry - please use the re-request review button).

[vivien-apple]

Thanks.

I will rebase this one once I'm done converting chip-tool to the new DeviceController API. Since it has landed the code to customise the udp listen port seems to not work anymore and I don't want to spend time fixing the deprecated API.

[andy31415]

@vivien-apple - any chance you could rebase? trying to cleanup old PRs and either get them merged or closed. Thanks!

[BroderickCarlin]

@vivien-apple once the merge conflict is addressed it should be good to merge :D

[vivien-apple]

I have rebased chip-tool over the new ChipDeviceController API in #3979 and I will rebase this one on top of it once #3979 has landed.

[vivien-apple]

@vivien-apple - any chance you could rebase? trying to cleanup old PRs and either get them merged or closed. Thanks!

Sadly I need to rebase chip-tool over the new ChipDeviceController API before rebasing this one. The old API code to set the UDP listen port seems broken and I rather prefer spending time fixing the new API than the old one !

[rwalker-apple]

@vivien-apple conflicts?

[vivien-apple]

I finally rebased this PR on top of chip-tool with the new controller API ChipDeviceController and on top of #4071.

It will likely not build until #4071 lands though since I use the SetUdpListenPort API from it.

That said, I remove the needs for ENV variables and use the .ini file that chip-tool now uses to permanently store it's association with devices.