Running python script from TFTP server

P. 7 of the “Digi Python Programming Guide” describes the “set python” command which “Configures Python programs to execute on device boot.” It further says, “The command option allows for programs to be run from a TFTP server; however, this usage is not recommended.”

The possibility of hosting the python application remotely seems very useful, allowing deployment of code revisions to multiple devices merely by rebooting said devices. However, I’m concerned about the comment “this usage is not recommended.” Can someone please explain what the risk is?


I think it’s primarily going to depend on your environment. If you’re running on a controlled network, and a problem on the network that would cause the script fetch to fail is acceptable from time to time, perhaps this is an approach that will work for you.

One of the main obstacles with this approach is that while the main single script file can be TFTPd in this manner, the modules and additional files that may be needed for execution of that main module can not be. This severely limits the complexity of the application that you may wish to deploy this way.

DigiGuy42: Thanks for your reply. It sounds like the TFTP idea would NOT be a good approach for the following application: I envsion many sites having a ConnectPort gateway, each of which runs a Python program that I would provide. I thought that if I used a TFTP server I could deploy updates merely by telling ‘users’ to reboot their gateway. This would certainly not be a “controlled network” nor would it be acceptable for the download to fail.

Is there a preferred way to broadcast software updates to deployed ConnectPort gateways?

I appreciate any suggestions you might offer.

Hi hoff,

The official Digi solution to this is going to be the iDigi server platform. ( A quick summary is Digi hosts a publicly accessible server that other Digi devices such as the ConnectPort gateways can connect to. The user (you), would register each device with the server, and control them through a user account on the iDigi server.

From the user account you can send updates to file system files, firmware or configuration updates using SCI requests that can target singular or groups of devices. For more information, please go to the above website. Note that there is a demo version of this available at where a free account can be made with 5 registered devices.

Digi doesn’t provide any official alternative to managing devices in the field, but using python you could develop a connection to a centralized server of some sort, and push RCI commands down to the device to perform the updates as needed. This is not a trivial undertaking.


Hey mkotasek:
Thanks for the pointer to ‘iDigi’. It looks very useful, but in my case I just need a way to download updates to the app’ running on the ConnectPorts. Thinking a bit more, it seems pretty simple to do this by:
(1) Downloading python code from the web (e.g. via a http ‘get’)
(2) Writing the downloaded file(s) to the device.
(3) Forcing a reboot, to cause the device to run the updated code.
Of course care must be taken to ensure a bug in the code ‘patch’ doesn’t disable the device, but otherwise, it seems pretty simple, n’est pas?

TFTP Server is commonly used to upload/download executable images and configurations to routers, switches, hubs, XTerminals.
These are the steps used for run the python program on digi device.

  1. Write the program
  2. Test the program locally
  3. Move or upload the program onto digi device.
  4. Run the program.
    Now, the python script is on digi device…

data recovery services

Just be aware that TFTP can be highly unpredictable over wide-area-networks due to jitter & latency. For example running it over cellular might result in many failed attempts to upload new code.

Lynnl: Your point is well taken.
filerecovery: Your suggestion wouldn’t be an answer to the scenario/problem I posted on Jul 7. In short the challenge is to update the program (step 3 of 4 in your post) when you don’t have access to the digi device (i.e. you are not on the same ‘intranet’ as the device).